Device report pages

This topic describes the pages included in device reports. For more details, see View AFA device data.

Back to top

HOME page

The HOME page provides an overview of the device report. The page's content depends on your AFA modules.

  • Click the titles of the various widgets on the page to dive down to other pages in the report.
  • Click the Device Connectivity Diagram to zoom in for details.

Back to top

RISKS page

The RISKS page summarizes all risk analysis findings.

The Risks page provides the following details:

  • The security rating for the device.

    The security rating indicates the device's degree of compliance with security standards. A security rating of 100% indicates full compliance. For information on how the security rating is calculated, as well as how to customize the security rating settings, see Configure security ratings.

  • The total number of risks in each severity category, not counting duplicates.
  • A graph displaying the security rating trend over time.
  • A list of all the device's risks, in decreasing order of severity.

    The list includes a brief summary of each threat: the risk, its trigger count (the number of times it was detected), and a brief description. The New label indicates risks that were not present in the previous report.

    Tip: Click a risk to drill down to a Risk Assessment page for more details about the risk and any related rules.

Back to top

RISKY RULES page

The RISKY RULES page shows the rules that pose risk to the policy. As opposed to the RISKS page which shows the risks triggered by risky policy rules, the RISKY RULES page details the rules that cause these risks.

At the top of the page, do any of the following:

  • In the Analysis Summary area, click links to drill down to rules, services, and host groups.
  • In the Risk Levels and Security Rating Trend graphs, view data about the risks on the device over time.

In the Findings table below the graphs, view details about each risky rule found. Additionally, do any of the following:

Filter the table rows

Click to filter the rules displayed.

Sort the table Click in each column to sort the table by that column.
Trust specific rules

Click Trust to add that rule to trusted traffic.

For more details, see Customize trusted traffic.

View rule details

Click the rule number to drill down to more details about that rule.

View risks

Risks are shown as colored boxes in the Risks column, indicating the number of risks in each severity for the rule described in that row.

For example, the following image shows that there is 1 risk with critical severity, 4 with medium, and 5 with suspected high.

Click a colored box to drill down to the selected risky rule and its risks. For more details, see Risks and vulnerabilities in AlgoSec Firewall Analyzer reports.

View vulnerabilities

Vulnerabilities are shown in the Vulnerability Score column, including the overall vulnerability score for the IP addresses covered by the selected rule, the number of vulnerabilities found and the scanning status.

For example, the following image indicates a vulnerability score of medium, with 83 vulnerabilities found, and one or more unscanned servers.

Click a colored box to drill down to the selected risky rule and its vulnerabilities. For more details, see Risks and vulnerabilities in AlgoSec Firewall Analyzer reports.

Note: Vulnerabilities with a CVSS score of 0 are ignored.

Back to top

REGULATORY COMPLIANCE page

The REGULATORY COMPLIANCE page includes a number of reports that describe how compliant your security policy is to specific regulatory standards.

To customize the Regulatory Compliance page, see Customize the regulatory compliance report.

Running these compliance reports will help you identify non-compliant items that require adjustment. Each report follows the reporting requirements of its standard. The reports can save you hours of work, especially when you need to prepare periodic compliance review.

The Regulatory Compliance page provides the following regulatory compliance reports:

Back to top

POLICY OPTIMIZATION page

To optimize your policy, you need to find out which rules are redundant, unused or already covered by other, more general rules. These rules are prime candidates for removal from your device policy. In addition, you need to see the statistics on the most and least used rules of a policy: the device's performance may improve if highly used rules are placed near the top of the rule-set, and infrequently used rules are moved further down. In addition, you need to know about unused and empty host group definitions and unused access lists, because these unused definitions clutter up the configuration and reduce your ability to manage your devices effectively.

Note: For Panorama or FortiManager devices, usage on a specific rule in a specific device will reflect the counts of all the devices that share this policy.

To view a training video that follows an Information Security Officer optimizing his organization's firewall policies, see HERE.

In the Policy Optimization page, you can view the rules and objects which diminish your policy's effectiveness and efficiency. Additionally, a graphic display of the number of unused, time-inactive, un-logged and rules already covered by other rules is provided.

When you click on a link in the Rules Cleanup area all of the relevant rules appear. The columns which appear for each rule are specific to each device brand. If AppViz is licensed, fields from AppViz appear, indicating business information such as which rules are included as flows in which applications.

Below is a description of the different areas of the Policy Optimization page, including a summary of the types of rules and objects that can make a policy perform sub-optimally:

Rules Cleanup

Rules Cleanup enables the user to make your policy more streamlined and effective. It may include the following:

Objects Cleanup

Objects Cleanup enables the user to clean unnecessary objects. It may include the following:

Unattached objects An object is identified as Unattached if it does not appear in any policy of any zone in the current device.
Empty Objects An object the does not have an IP address value. Perhaps at one time the object had an IP address, but keeping it now is redundant.
Duplicate Objects Two or more objects are identified as duplicate if they have different names but refer to exactly the same collection IP addresses and subnets.
Unused objects within rules The traffic that passes through the rule never reaches the object. For example, if IP 1.1.1.1 and IP 2.2.2.2 are in the same rule but all the traffic in the rule passes through 2.2.2.2, then 1.1.1.1 is an unused object.
Hostgroup Definitions Provides an index of all Host Groups that are defined by the device or generated by queries. Each Host Group record shows the IP address ranges it contains, any DNS names available, the interfaces on which its IP addresses can be found, and any other Host Groups that are its subsets or supersets.
Duplicate Services Two or more services are identified as duplicate if they have different names but refer to exactly the same protocol, source ports and destination ports.

Intelligent Policy Tuner

The Intelligent Policy Tuner (IPT) enables you to refine your policy, by identifying rules that are too wide and permissive, and rules which contain sparsely used and unused objects. It also provides recommendations for replacing permissive rules with new, tighter rules. See Refining Rules via the Intelligent Policy Tuner.

This area includes the following:

Tighten Permissive Rules Permissive rules that should be refined.
Unused objects within rules Rules containing objects that have not been used recently.
Policy tuner analysis for all rules Usage information about all rules.

VPN Cleanup (Check Point)

For Check Point devices, the Policy Optimization page also includes several items that refer to the VPN analysis page (see VPN page):

Expired users

Any VPN user whose access expiration date occurred before the report's date is flagged as Expired.

Users about to expire

Any VPN user whose access expiration date is a certain number of days after the report's date is flagged as About to Expire. To configure the number of days before expiration that a VPN user should be flagged as About to Expire, complete the Days before expiration alerts field in the General sub-tab of the Options tab in the Administration area. For more details, see General.

Unattached user groups

VPN user groups that do not appear in any rule in any policy that is managed by the Check Point SmartCenter or CMA are flagged as an Unattached User Group.

Unattached users

Any VPN user that does not belong to any user group is flagged as Unattached. Such users do not have any real VPN access since no rule can refer to them.

Application Control Rules Cleanup (Check Point)

For Check Point devices, if there is at least one application control rule, the Policy Optimization page also includes information about application control rules:

Unused rules

Application control rules that did not match any traffic according to the log data.

Rules without logging

Application control rules that do not produce log records when they match packets.

Disabled rules

Application control rules that were disabled temporarily.

All rules usage (count, last date)

Usage information about all application control rules.

Rule Reordering

These areas provide recommendations for optimizing the device rules for best performance and lower CPU utilization, an estimate for the device's performance, and suggestions for improving the performance with the most effective rule reordering. For more information, see see Reordering Rules.

Rule Usage Statistics

In this area, you have access to the five most- and least-used rules. You can use this information to re-order your policy so the most popular rules are placed near the top of the rule set.

Policy optimization procedures

Reordering Rules

The Policy Optimization page's Rule Reordering areas provide recommendations for optimizing the device rules for best performance and lower CPU utilization, an estimate for the device's performance, and suggestions for improving the performance with the most effective rule reordering.

The algorithm relies upon the rule usage statistics collected from the device to compute a RMPP (Rules Matched per Packet) score that measures the device's performance. The RMPP is the average number of rules that are compared to filtered packets until the device finds a match, where the average assumes the mix of packets that is observed in the device rule usage statistics. The RMPP is closely correlated with the device’s CPU utilization: a lower RMPP typically means a lower CPU utilization.

The intuition behind the RMPP calculation is as follows: Suppose that the rule that ultimately matched a connection is rule number "i". Then the device spent a computational effort testing whether the connection matched each of rules 1, 2, …, i-1, until it arrived at rule "i", found that rule "i" matches the connection, and stopped. We see that the computational effort to filter this connection is approximately proportional to the sequence number "i". Therefore, to model the general computational effort the device is spending, we calculate the mean (expected) number of rules that the device had to check against incoming connections, when the mean is weighted using the rule usage statistics gathered from the log data.

If there are N rules in the rule-base then the RMPP is always a number between 1 and N. Here are some examples. If every connection is always matched by the first rule in the rule-base then RMPP=1. Conversely, if all the connections are matched by the last rule then RMPP=N. If neither of the extreme cases occurs then the RMPP will be a value larger than 1 and smaller than N: E.g., if rule 1 matches 50% of the connections, rule 10 matches 30%, and rule 25 patches 20%, then RMPP = 1*0.5 + 10*0.3 + 25*0.2 = 0.5+3+5 = 8.5. This means that, on average, for the mix of connections observed by this device, the device compares 8.5 rules to each connection it needs to filter in order to reach a decision.

Clearly, we should strive to reduce the RMPP: If we can lower the RMPP toward 1, it means that on average the device will compare fewer rules to each incoming connection, and its CPU utilization will drop accordingly.

The Rule Reordering area displays a bar chart showing the RMPP of the current device configuration, the optimal configuration (using the same set of rules), and a midway configuration, which can be achieved from the current configuration by up to 10, most effective rule moves.

Clicking on the bar chart leads to the Rule Reordering page, which provides a detailed analysis.

The Rule Reordering page consists of three sections:

  • Summary. Summarizes the current RMPP (Rules Matched per Packet) situation.

    Note: This summary is also depicted graphically in the Policy Optimization page in a second Rule Reordering area.

  • Optimal Rule Order. Provides a complete list of all device rules, arranged in the optimal order for best performance based on RMPP.
  • Top 10 Rules to Move. A list of up to ten of the most effective steps to generate the greatest improvement in the RMPP score. Each step is a recommendation to move one rule to a different location on the list, and shows the projected RMPP improvement that it will provide.

    Note: The description above refers to the Check Point device screen. The screen differs per device vendor as follows:

    • Cisco – Each access list has its own Optimal access-list order (one list per interface).
    • Netscreen – Each policy list has its own Optimal Policy list.

      Note: For Cisco ASA devices version 7.0 or above, access lists are always "compiled". Consequently, the expected performance gain obtained by reordering the rules is small.

Back to top

BASELINE COMPLIANCE page

If a baseline compliance profile is specified for the device, the report will include the Baseline Compliance page. This report indicates whether running the commands specified in the baseline compliance profile on the device results in the output specified in the baseline compliance profile. If so, then the device is considered to be in compliance.

Baseline compliance profiles are specified per device when defining the device in AFA. For more details, see Manage devices and Customize baseline configuration profiles.

Back to top

POLICY Page

AFA provides various advanced capabilities that enable you to explore complex details of your device policy. Click on the Policy tab in the report to drill down into various aspects of your policy:

Click around this page to view more details about your device's policy. For example:

  • Click Expanded Rules on the right to view all rules in the device's policy.

    Note: AFA sometimes adds additional, implicit rules to a device's policy for enhanced management and optimization.

    For example, for devices that support only allowing rules, AFA may add a final Deny rule to be able to simulate the device's policy correctly. Implicit rules added by AFA also enable some devices to allow DNS traffic based on a check-box without forcing the user to write an explicit rule.

  • Click links in the Traffic by Service area to focus in on a sensitive host group and view the services that can reach it, and which corresponding rule is responsible. For example:

    The values in the Source IP addresses and Destination IP addresses columns are the number of IP addresses impacted by the service, excluding Trusted Networks, the IP addresses of the device interfaces, and Private IP addresses.

    You can further explore where a specific service can reach by clicking its link in the Service column.

Back to top

CHANGES page

The CHANGES page provides detailed information about changes to the device, over the whole history of AFA reports for the device. Reports include all change monitoring supported for real-time change monitoring as well as changes to risks and baseline compliance.

For more details, see Manage real-time monitoring.

Back to top

VPN page

The VPN page in the AFA report provides you with a clear view of all your VPN settings, and gives you a single place from which to navigate and review the details of your definitions. The report covers VPN definitions related to remote login users that are terminated on the device, and also to point-to-point VPNs. The contents of this page depend on the device vendor.

For Check Point devices, the VPN report consists of the following sections:

  • VPN Rules: lists all the VPN rules found on the device, with links to the user groups that are in use.
  • User Groups: lists all the user groups, with links to the rules each group participates in, and the users that belong to the group.
  • Users: lists all the users defined on the device, each with its authentication and encryption parameters and expiration date, with links to all the groups each user belongs to.
  • Communities: lists all the VPN communities, each with all the member devices.

For Juniper, the VPN report includes the VPN Rules, VPN Tunnels, IKE Information, User Groups and Users definitions.

For Cisco ASA devices, the VPN report includes the Crypto maps, Transform sets, and IKE Policy.

The VPN report page is not available for Forcepoint (McAfee) Security Management Center, Forcepoint (McAfee) SideWinder, F5 Big-IP, Juniper Space, Fortinet, and Hillstone devices.

Note: The Policy Optimization page also contains information which is relevant to VPN management. Specifically, it contains a list of expired users, unattached user groups, and unattached users. See the POLICY OPTIMIZATION page.

Note:

Support for the Forcepoint brands (Sidewinder, StoneGate) and Hillstone was deprecated in ASMS version A30.00.

If you had defined these devices in an earlier version of ASMS, these devices are still available to you, with all the existing capabilities, but you cannot add new ones after upgrading.

We recommend backing up device data before or after upgrading and then removing these devices from AFA. Make sure to download any report zip files for the device before deleting.

For more details, see View an earlier report for a specific device and the relevant AlgoPedia KB article.

Back to top