Network Policy Best Practices
  • 18 Oct 2020
  • 3 Minutes To Read
  • Print
  • Share
  • Dark
    Light

Network Policy Best Practices

  • Print
  • Share
  • Dark
    Light

Network Policies allow SecureCircle administrators to limit network access to allowed applications that have touched protected data. A single Network Policy may be applied to multiple Circles. The following are best practices when creating Network Policies.

Breakdown of Network Policies

Network policies are separated into two types. Those types are Inbound Rules and Outbound Rules. Each policy can have an unlimited number of both inbound and outbound rules at the same time, though it is possible to cause conflicts if not careful. Once the Network Policy blocks an application from sending or receiving data, that single application is locked down for ALL traffic until it is restarted. An example of this would be if you are attempting to run a script in a protected Excel document that reaches out to an external network. If configured to do so, it recognizes the file is protected and blocks the connection. For a second Excel file that is not protected to do the same thing, you would need to restart Excel.

Both inbound and outbound rules have the same configuration options. Those are as follows;

Product Groups

This category allows you to choose a specific application or process that is attempting to send or receive data in regard to an encrypted file. Using a searchable application list, multiple processes can be chosen. This setting is enforced locally and can prevent a file action using said process from entering or leaving the system.
### CIDR
The Classless Inter-Domain Routing (CIDR) category allows entry of an IP address or range of addresses with or without a prefix integer. This will allow for auto-accept and auto-reject from those source network locations.
An example would be to block all network locations using 0.0.0.0/0. Alternatively, blocking a single IP such as 192.168.0.1.
### Ports
This section is used to specify a port or range of ports to monitor for allowing or rejecting of traffic.
An example would be a range of ports that can be all encompassing with a 0-65535, or just a single port such as port 80 to block all internet traffic.
### Protocol
This category has 3 options. Any, TCP, and UDP. Traffic inbound or outbound using these protocols will be accepted or rejected accordingly based on your choice.
### Action
The final category is Action. The options for this category are Accept and Reject. As the name suggests, these options dictate if your file action is allowed or not based on all the previous categories settings.

Network Policy.png

Network Policies do not apply to Applications that Can't Read Decrypted Data

If an application is not allowed to read the decrypted version of protected data, a Network policy that contains a rule based on that application does not apply to it. Network Policies only come into effect when an application is allowed to read the decrypted version of protected data.

  • In the event the Network Policies are not enforced, please validate that the application in question is Enabled. Please make sure that all instances of the application in question have been closed first if adjustments are necessary.
  • To Enable an application(s) on your SecureCircle Server, go to Applications, select the desired application(s) and enable using the Actions button.

image2020-2-17_10-51-15.png

Use in Data Pipelines

Network Policies are best used as a part of a data pipeline. Some components of a data pipeline may not allow for the installation and use of the SecureCircle Agent. In those cases, Network Policies may be created that allow certain data transmission applications (e.g., WinSCP, FTP clients, etc.) to transmit the decrypted version of protected data from data pipeline components that do allow the installation and use of the SecureCircle Agent, but only when transmitting to the IPs of trusted data pipeline components. In those cases, users with access to protected data would be restricted from transmitting protected data from those same applications.

This feature can be used in conjunction with Certificate-based Application controls and custom process signing to allow for the creation of custom, trusted data pipeline applications to transmit decrypted data to trusted components while still allowing the use of the same application (with the default process signature) to transmit encrypted data.

Blocking Applications with Non-Filesystem-based Cloud Storage Capabilities

Some applications, such as recent desktop versions of Microsoft Office applications, allow for the transmission of data directly from application memory into Cloud Storage (such as OneDrive, for Microsoft Office applications). A Network Policy containing rules which block network communications from these applications can be applied to Circles as needed. In many cases, this is may be unnecessary since the data ultimately ends up being synced to the filesystem using the filesystem-based tool (such as OneDrive for Desktop), upon which it will automatically be protected due to SecureCircle's Derivative Works Protection feature.

Was This Article Helpful?