Applies to:

• Zentera Air Ultimate

Application Chambers provide a powerful Learning capability that allows you to quickly develop Chamber Policies for an Application, even without knowing in advance what ports or protocols should be allowed.

Learning is performed for an individual Application.  Multiple Applications may simultaneously run Learn jobs.

To view the Learn controls, navigate to Chamber Policy Management > Application Chambering, and click the edit icon () to the right of the Application in order to bring up the Chamber edit view.

 

 

Basic Learning Concepts

The idea of Learning is to create a baseline of "known good" traffic for an Application, so those accesses can then be enforced or converted into Access or Chamber Policies.

Running Learn on an Application causes all zLink agents in the Application to monitor and report traffic logs to the zCenter service portal. A Learn job can range from 1 to 336 hours (2 weeks).  After the Learn job ends, these logs are then converted into "Learned Rules", which are automatically whitelisted by the Chamber.  You may review the Learned Rules to understand what your Application is doing; you may use the results to create new policies for enforcement.

 

Starting a Learn Job

To start a Learn job, click "Start Learning" and select the duration of the Learn job.

Learning is incremental, meaning that you can stop a Learn job at any time, review the results, and restart it. If you already have Learn results for your Application, click "Learn Again" to start a new Learn job.

During the Learn, the status is updated periodically to keep you aware of progress.

 

 

The Learning process is separate and independent from the Security Protection Level. Running a Learn does not change the Security Protection Level.  As the purpose of Learn is to identify policies based on actual application behavior, it is most likely that Learn should be run with Security Protection set to Disabled or Detection.

 

Completing a Learn Job

Whether you manually terminate a Learn job, or the Learn completes normally, there will be a delay while Learn results are analyzed. This process typically takes around 10-15 minutes.

During this process, traffic will be categorized as follows:

• Application traffic that was allowed by an Access Policy or Chamber Policy will be ignored
• Inbound application traffic with no listening application will be ignored
• Application traffic that is potentially risky create a "Skipped Rule"
• All other application traffic created a "Learned Rule"

Once this process is complete, the Learned Rules will automatically be enforced.  You may also return to the Application Chamber settings page to view the results, including the Learned and Skipped Rules.

 

Viewing Learn Results

Clicking "View Learned Rules" brings up a window that displays the Learned Rules.

 

 

You can also see a complete log of traffic observed and its disposition for offline analysis by clicking the "Export to CSV" button at the bottom of the screen.

 

 

Learned Rules

The columns in the Learned Rule Table are as described below:

 

Direction

This column denotes the direction of the access, relative to the Application.

 

Remote Address

This column displays the IP address of the remote host. To help with analysis and policy creation, you may hover over this IP address to see if this IP address is part of an existing Address Object.

 

Protocol and Port

The Protocol column and Port column display the protocol and port of the access. To help with analysis and policy creation, you may hover over these fields to see if there is a corresponding Service Port Object.

 

Frequency

This field displays the relative frequency of matching flows (each session is counted only once). You may sort the display based on Frequency to understand the most and least frequent sessions that are observed.

 

You may also click on the Frequency field to bring up a display with much richer data about the session.  For example, you can view the entire command line that triggered the socket, the user who ran the command, and how that user was logged in to the system:

 

 

Rule Processed At

This corresponds to the time the Learn result was processed, and is not a timestamp of the access. This is to help you understand which Learned Rules correspond to which Learn job.

 

Skipped Rules

Traffic that accesses ports or protocols that have been reported to be associated with some form of risk (Trojans, worms, etc) are categorized as a Skipped Rule.  The format of the Skipped Rule display is analogous to the Learned Rule display.

As with Learned Rules, you may click on the "Frequency" field of an individual Skipped Rule to view more detailed information about the access and why it was skipped.

If, after review, you are comfortable with allowing this action, you may move a Skipped Rule back to the Learned Rule category, or create an Access or Chamber Policy for it.

 

 

 

Notes and Best Practices for Learning

Review the Learned Rules - with a Goal of Zero Learned Rules

The Learning process creates a baseline of traffic; if that traffic baseline includes undesired traffic, that traffic will not be blocked once the Learn completes. Therefore you should review the Learn results for any surprising behavior (for example - an FTP to the Internet), and skip or create specific policies for those.

It is possible to harden an Application by running Learn and then moving the Application to Protection, to lock all known accesses in place.  This provides a quick method for hardening, but it is a best practice to use the results to create policies for the Learned Rules for better security and manageability.

 

Enforcement Precedence

Learned Rules have higher precedence than Chamber Policies and will be exempted from any blocking action performed at the Chamber Policy level. This will automatically generate exceptions that you should review.

 

Manage Learning Scope

Learning generates activity and logs from each endpoint that participates in the Application. Rather than run Learning on an Application with several thousand endpoints, it is advisable to manage the scope by creating a temporary Application with a subset of those endpoints. Once suitable policies have been generated, these endpoints can be moved back and the policies applied to the original Application.