About the Security Control Level

Once an Overlay Network Access Policy is created, it is immediately available for the use o the applications it serves.  However, it may be desirable to enable CoIP Overlay connectivity without filtering that connectivity. This is achieved by modulating the Security Control Level.

The Security Control Level applies to Applications, and allows controls that are enforced on an Application to be bypassed. There are 3 levels of Security Control: Disabled (security controls defeated), Detection (violations of security controls are logged), and Prevention (violations of security controls are logged and blocked).

The Security Control Levels can be adjusted temporarily (for example, during policy development and testing), or permanently (for example, Applications where Detection is preferable to Prevention).

Security Control Level example

Consider an ERP server Application with an Access Policy that allows it to connect to a git repository. The Access Policy contains the following Security Filters:

The source Application Process Object, "git over ssh", is evaluated on the source Application (ERP server).  The destination Application Process Object, "sshd", is evaluated on the destination Application (git repository). To completely restrict the end-to-end connection, both the ERP server and git repository Application Security Control Level must be set to "Prevention".

If the ERP server is set to "Detection" and the git repository is set to "Prevention", the connection from ERP server to git repository will allow any software application to connect to the git repository, so long as the connection is handled by sshd. This is because the ERP server Application in Detection mode will not block traffic based on the filter rule on its end, but the git repository Application in Prevention mode will.

Setting the Security Control Level

The Security Control Level may be configured from Onboarding and Management > Applications.