Architecture

Home / Technology / Deployment / Architecture

Cord3 Architecture

Cord3’s approach to DCS follows data as it flows through the network, ensuring that data security is maintained throughout the data object’s lifecycle. Rather than relying solely on network or device controls, sensitive data always remains secure whether it is stored, shared, emailed, downloaded, or moved to the cloud.

The architecture diagram shows how access control is managed. As illustrated:

  • The Policy Administration Point (PAP) defines and acts on the current security policy.
  • When a user tries to access data, the Policy Enforcement Point (PEP) intercepts the request and analyzes the transaction.
  • The Policy Information Point (PIP) gathers information about the request.
  • The Policy Decision Point (PDP) enforces the decision to approve or deny access based on the information gathered.
  • If the access request is approved, the PEP allows the user to decrypt and access the data.
On-the-wire architecture

Cord3’s on-the-wire (OTW) architecture separates data security from applications. Our DCS technology can be readily integrated into your existing environment, with no additional software or plug-ins required on user devices or servers.

Cord3’s software sits between users and servers on intercept points (intercepts), which work by catching data packets at the protocol layer. Different applications use different protocols to transfer data over the network. Therefore, Cord3 has different intercepts for different types of data.

You can continue using your existing applications, while DCS works seamlessly in the background to protect your data from unauthorized access.

You can seamlessly deploy Cord3 Unity in an on-premise, cloud, or hybrid environment. Cord3 technology seamlessly integrates with your existing infrastructure. Both air-gapped and connected environments are supported.

During the deployment process, you will deploy DCS cluster nodes. The number of nodes per deployment is flexible and can be scaled up or down based on your needs. A simple deployment environment might have one node for each information type (for example, one for chat, one for SharePoint, and one for email). However, in a high throughput environment, you could have multiple nodes for one information type. For example, if you have multiple SharePoint servers, you might need to designate multiple nodes to handle SharePoint traffic. You can specify which node will handle traffic from specific servers. This flexibility and the ability to strategically configure nodes and enforcement points is a key strength of Cord3’s approach.

After the solution is deployed, you will create a security policy. The security policy is tailored based on your organization’s governance constraints and operational needs. Cord3 will help you to create a security policy that fully meets your needs!

This initial security policy defines the policy logic, which expresses how decisions are made or the logical assertions used to evaluate different subject, resource, action, and environmental attributes. The logic used to make policy decisions does not change.

The second part of the security policy is the policy facts/rules, which change frequently in response to operational and mission requirements. Policy rules are factual statements that the policy engine interprets in real time in the context of the defined policy logic. Policy rules can be updated anytime through the Unity Management administration interface.

Policy rule example: A user (for example, John Doe) has access to the Finance caveat. You can change John Doe’s policy permissions anytime.