Introduction

Zero Trust security is all about replacing topology-based access decisions (IP addresses) with identity-based access decisions. As a result, Access Policies are at the heart of any Zero Trust system. This Quick Start Guide explains how to define Access Policies within CoIP® Access Platform.

CoIP Access Policies are distinct from standard firewall policies in both scope and power. First, CoIP policies represent access relationships between Applications, Endpoints, Services and Users (User Roles) objects, rather than network subnets.  The location of a resource does not matter, so much as the role of that resource is assigned to; when an endpoint is assigned to an Application, the policies that are relevant to it are calculated and pushed to all affected endpoints automatically. This means that Access Policy definitions are relatively static, even if the rules used to enforce them in the datapath level are dynamically calculated.

Second, a CoIP Application Policy is far more granular than a typical firewall rule.  Instead of the standard 5-tuple, a CoIP Access Policy can also specify the identity of the source and destination application, based on application binary paths, checksums, and process execution relationships, and also the identity and role of users.

It is common during initial access configuration to only define the more basic policy parameters.  Then, once the applications are onboarded and their communications are established, tighter policy parameters can be observed and added to the access policies to further restrict the potential attack surface, and to enhance the Protection Score.  See the Quick Start Guide Measuring the Attack Surface with CoIP for further details.

The Access Policies are managed under the menu items as shown in the below diagram.  Certain additional options are available under the Advanced Management menu.

Application Process Objects and Groups

Application Process Objects are used to identify application processes running on the hosts that bind the network socket, either to initiate a connection (client) or to listen (server).  An Application Process Object Group is a group of one or more Application Process Objects for convenience in defining Access Policies.  Access Policies specify Application Process Objects, a Group, or “Any,” if the policy is not being restricted to a specific application process.

A simple Application Process Object is shown in the example below.  Here only the path and executable name of Firefox are specified.

Admins may also specify a sha256sum, which validates the binary checksum , as well as the process tree hierarchy.  In the example below, the git process and ssh process are both identified with the sha256sum, and the relationship between parent (git) and child (ssh) processes is checked.

If Enforce Strict Order option is selected, an explicit process calling chain must specified, including systemd/initd/userinit.exe/etc root processes as well as any intermediary wrapper script processes that may be present in the calling chain. This can be useful to differentiate a network access from a process launched by a cron job (for example), versus the same process initiated by an interactive user session.

While setting up the policy with just the binary name and its path is the easiest, the discovery of the process calling chains and sha256sums can be accomplished either via Detection Mode logs, Discovery (in Advanced Management), or directly via OS tools such as pstree and sha256sum.

Service Port Objects and Groups

Service Port Objects represent IP protocol and TCP or IP port numbers, such that they can be logically grouped and referenced in Access Policies. Below, an example Service Port Object represents web ports:

Service Port Objects support TCP, IP, and ICMP protocols.

A Service Port Object Group is a collection of Service Port Objects; traffic that matches any one of the constituent Service Port Objects match the policy.

Access Policies

CoIP Access Policies represent access relationships between pairs of Applications, Endpoints, Services and Users (User Roles).  These policies reference Application Process Objects (or Groups) and Service Port Objects (or Groups).

For example, to add an Application-to-Application Access Policy, select Policy Type and source and destination.

Next, select Connection Type, and define whether the access should be point-to-point (LAN), or through a ZNS node (WAN).  Note that if a LAN connection is requested, it is the responsibility of the administrator to ensure that the servers have routable point-to-point connectivity to each other (default port 9797).

Next, apply the relevant Application Process Object or Groups on the source and destination, and Service Port Object or Group.

The other types of policies follow similar steps, however for Service(s), the onboarded Service already specifies the Service Ports. Additionally, as Services behind a Gateway Proxy do not  and do not have an option to specify destination Application Process Objects as the Gateway Proxy does not support Application Interlock.