Device report pages

The following demonstrates a typical workflow to drill down to a problematic rule or group from the risks page.

1. On the RISKS page in a report, click on a risk.

   The Risk Assessment appears, displaying the findings and the recommended remedy. The risk is presented in a descriptive manner with links to every entity that is associated with the risk.

   In the example below, AFA shows you the number of internal and external IP addresses that have access or are reachable by the risky service.

   

2. Click the Details button to view the specific rules that allow access to the risky services.

   

3. In the example above, we see that rule 36 looks like an accept rule that allows outbound access. Allowing any outbound service is not recommended since it may be used by Trojan horses to attack business partners. However, this does not explain why any service is allowed from the outside. Therefore, we navigate further and click on the group GP_NW_Garden_ICN to examine its definition.

   

4. The above figure shows that host group GP_NW_Garden_ICN spans the device:

   • The purple icon tells us that some of its IP addresses are outside of the network.
   • The blue icon shows that other IP addresses are on the inside.

   Since the rule that uses this host group allows access to any destination, the outside addresses (198.168….) are allowed to enter the network with any protocol. This is a serious vulnerability.

   In this case, the likely culprit is a typing error: the administrator probably planned to type "192" (which is an inside address) and mistakenly typed "198".

   Note: Similar vulnerabilities exist in virtually every large organization. A scanner will never find it. A human audit will rarely find it, since all IP addresses look the same. AFA finds and highlights all these vulnerabilities automatically, within minutes.

   Tip: Click on the icons in the IP ADDRESSES column to see where the IP addresses are located in the Connectivity Diagram.

When you click a colored box in the Risks or Vulnerability Score column on the Risky Rules page, the page is refreshed with details about the selected risky rule only, and risks and vulnerabilities for that rule are shown in tabs below.

For example:

Do any of the following:

• Switch back and forth between the tabs as needed, and continue to drill down to view additional information.
• Use the breadcrumbs at the top of the page or the RISKY RULES menu item at the left to jump back to the main risky rules table.

• Click the Vulnerability Score Legend link above the Findings table for details about vulnerability score colors.

  Indicates that you have unscanned servers.

The Risky Rules page is not included for VSYS/LSYS-level reports on the following device types:

• Palo Alto Networks Panorama devices
• Juniper SRX devices configured to display virtual routers

For these devices, the Risky Rules page is provided for VR reports only, because risky rules only trigger risks on VRs that route traffic.

Additionally, this behavior is not relevant to Juniper Netscreen or NSM devices configured to display virtual routers. For Netscreen, the VR is not a sub-device of a virtual system, so every report includes the Risky Rules page.

The Payment Card Industry Data Security Standard (PCI DSS) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the PCI DSS v3.2 audit procedures. Using this report can save you hours of work when you need to prepare your annual or quarterly PCI DSS compliance report.

If AppViz is being used with a vulnerability scanner, this report can be configured to display the vulnerability of PCI applications. Requirement 6.1 specifies whether AppViz is being used and whether vulnerability scanner integration is enabled. If you configure the PCI zone and a vulnerability threshold in AFA, the requirement additionally specifies the servers in the PCI zone and the vulnerability assessment for all AppViz applications which intersect the PCI zone. For more details, see Configure the PCI zone.

The Sarbanes-Oxley Act (SOX) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the CobiT 5 control objectives and COSO components.

The ISO/IEC 27001 report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the ISO/IEC 27001:2013 International Standard "Information technology - Security techniques - Information security management systems - Requirements" and of the companion ISO/IEC 27002:2013 "Code of practice for information security management" International Standard.

The NERC Standards for Critical Infrastructure Protection (NERC CIP) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the NERC Standards CIP-002-2, CIP-003-2, CIP-004-2, CIP-005-2, and CIP-007-2. Compliance with these requirements is required of all NERC-registered entities by June 30, 2010. The report addresses the requirements that apply to devices, filtering routers, and VPNs.

The requirement numbers listed in the report are aligned with those specified in the relevant NERC Standards.

The NIST Special Publication 800-171 report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the National Institute of Standards and Technology (NIST) document Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations, Revision 1 (June 2015).

This publication provides federal agencies with recommended requirements for protecting the confidentiality of Controlled Unclassified Information (CUI):

(i) when the CUI is resident in non-federal information systems and organizations;

(ii) when the information systems where the CUI resides are not used or operated by contractors of federal agencies or other organizations on behalf of federal agencies;

(iii) where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing law, regulation, or government wide policy for the CUI category or subcategory listed in the CUI Registry.

The NIST Special Publication 800-53 report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the National Institute of Standards and Technology (NIST) Security and Privacy Controls for Federal Information Systems and Organizations , Revision 4 (April 2013). FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems , is a mandatory federal standard developed by NIST in response to FISMA. To comply with the federal standard, organizations first determine the security category of their information system in accordance with FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, derive the information system impact level (High, Moderate or Low) from the security category in accordance with FIPS 200, and then apply the appropriately tailored set of baseline security controls in NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations.

The NIST Special Publication 800-41 report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the National Institute of Standards and Technology (NIST) Guidelines on Firewalls and Firewall Policy , Revision 1 (Sep 2009).

The Gramm–Leach–Bliley Act (GLBA) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Information Security IT Booklet issued by the Federal Financial Institutions Examination Council (FFIEC) in order to comply with the GLBA Safeguards Rule (section 501(b)).

The Basel-II report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Basel Committee on Banking Supervision's framework International Convergence of Capital Measurement and Capital Standards (June 2006). It follows the IT Governance Institute (ITGI)'s guidelines entitled "IT Control Objectives for Basel II" (2007) as expressed by the ten IT Guiding Principles (ITGP), and uses the Control Objectives for Information and Related Technology (CobiT) framework. In addition this report also refers to the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control - Integrated Framework. Within each COSO component the report refers to specific IT Guiding Principles for Basel II numbers and CobiT 5 Control Objectives.

The BSI 200 report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the BSI standard 200-1 information security management systems (ISMS) and its supplementary standard, the BSI standard 200-2 IT-Grundschutz methodology (BSI-Standard 200-1 Informationssicherheitsmanagementsysteme (ISMS) und dessen ergänzendem Standard, der BSI-Standard 200-2 IT-Grundschutz Methodik).

The ASDM report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Australian Signals Directorate's strategies to mitigate targeted cyber intrusions last updated December 2019.

Like the AlgoSec Sarbanes-Oxley report, the Financial Instruments and Exchange Law (Japan) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the CobiT 5 control objectives, in the Japanese language. Use this report to learn how well you are doing, and to present to your auditors as needed.

The MAS TRM report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Technology Risk Management Guidelines issued by Monetary Authority of Singapore dated January 2021.

The HIPAA report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Security Rule of the Health Insurance Portability and Accountability Act issued on February 20, 2003. The AlgoSec interpretation of the HIPAA act relies on both NIST SP 800-66 Revision 1, and The HIPAA Security Information Series.

The General Data Protection Regulation (GDPR) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the European Parliament and the Council of the European Union's regulation, on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. For the purpose of this compliance report, AlgoSec uses the framework of ISO/IEC 27001.

The SWIFT report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the SWIFT Customer Security Controls Framework based on the SWIFT Customer Security Programme (CSP) Guidelines, last updated in July 2019.

The HKMA report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the Hong Kong Monetary Authority (HKMA) Supervisory Policy Manual (SPM) last updated in October 2019.

The General Law on Protection of Personal Data (LGPD) report measures compliance levels by correlating data available to the AlgoSec system for the device under review with requirements of the General Data Protection Law of the Federative Republic of Brazil, LEI No. 13,709, of August 14, 2018.

Rules that did not match any traffic according to the log data. By default, log data is kept for 60 days back. For Check Point and Juniper, this analysis is based on the collected logs. For Cisco Routers, AFA recognizes unused rules based on the access-list match counters.

If FireFlow is installed, you can open a FireFlow change request to disable these rules directly from the report. See Disabling Device Rules.

Rules that are covered by other, more general rules. A rule is covered if there is a combination of rules that are located above it in the rule set that together match all the traffic that could have been matched by the covered rule. As long as a rule is covered by other rules, it will never match any traffic. Therefore, covered rules are good candidates for elimination from the policy.

If FireFlow is installed, you can open a FireFlow change request to disable these rules directly from the report. See Disabling Device Rules.

Clicking the Covered rules link will display each covered rule in a separate table along with the rules that cover it. The covered rule is at the bottom of the table (shaded in light gray).

Rules that are included in a subsequent rule and can therefore be removed.

If FireFlow is installed, you can open a FireFlow change request to disable these rules directly from the report. See Disabling Device Rules.

Rules that can be consolidated into one rule because they are identical except for one field: source, destination or service. The rules that AFA recommends to consolidate will always be allowing rules.

If FireFlow is installed, you can open a FireFlow change request to consolidate rules on Cisco Firewalls directly from the report. If desired, you can edit the AFA recommendation before opening the change request. See Consolidating Device Rules.

Disabled rules are rules that were disabled temporarily.

Time Inactive Rules are rules that only apply at certain dates or times - and are inactive at the time of analysis. Such rules are often leftovers from fix-time projects and temporary patches, and may be candidates for elimination.

Rules without logging are rules that do not produce log records when they match packets. Many organizations require all, or nearly all, rules, to produce logs, thus a list of rules without a log keyword may let you ensure that your policy complies with your organization's requirements. With the exception of Cisco devices, these rules are always excluded from the list of unused rules since an absence of log records does not confirm that no traffic was matched.

These rules are rules that do not have comments. Many organizations require all rules to have a comment indicating who wrote the rule, when, why, and with whose authorization. For Cisco Routers, AFA recognizes rules with empty comments based on "set access-list remark" statements.

Rules with a time clause are rules that only apply at certain dates or times. Such rules may become redundant when their activity time passes (In which case they will be reported also as Time Inactive Rules).

These are rules that will expire within a certain number of days. To configure the number of days before expiration that a rule 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. The default is 14 days. For more details, see Define AFA preferences.

Rules that are not routed through the device. A rule is unrouted if the entire source is not in the source zone, or the entire destination is not in the destination zone. Removing these rules will not affect the device's effective security policy.

Clicking the Unrouted rules link will display the rules in a table. The objects that are not in their respective zone appear highlighted.

Rules with source objects that are not in the source zone or destination objects that are not in the destination zone. Removing these objects from the rules will not affect the device's effective security policy.

Clicking the Unrouted objects within rules link will display the rules in a table. The objects that are not in their respective zone appear highlighted.

Many corporate policies dictate that rule comments must contain the ID number for the change request for which the rule was created or changed. AFA allows specifying a regular expression that matches these ticket numbers, and then presents the rules with non-compliant comments (no ticket number).

To configure this functionality, complete the Report rules whose comment field... field in the General sub-tab of the Options tab in the Administration area. For Cisco Routers, AFA recognizes rules with non-compliant comments based on "set access-list remark" statements. For more details, see General.

If FireFlow is installed, you can submit an Object Change request to remove unattached, empty, and unused objects in the device's policy, as well as unrouted objects within rules, directly from the Policy Optimization page.

To open a FireFlow change request to remove objects

1. View the desired device's device report. For details, see View AFA device data.

2. Click the Policy Optimization tab.

   The Policy Optimization page appears.

3. Click on one of the supported object categories (Unattached objects, Empty objects, and Unused objects).

   The objects in the selected category appear.

   

4. Do one of the following:
   • In the first column, select the check boxes next to the objects you want to remove.
   • Select the check box in the table heading to select all objects.

5. Click Remove Selected Objects.

   The change request is created, and a notification appears with a link to the change request.

   

   If desired, the change request's fields may be modified later on. For more details, see Manage change requests.

   Note: When you remove more than one object, one change request is opened with multiple object lines.
6. Click OK.

If FireFlow is installed, you can consolidate rules on Cisco ASAdevices directly from the Policy Optimization page, by doing the following:

1. Open a FireFlow change request to add one or more consolidated rules, using the procedure below.

   The procedure describes two options:

   • Open the change request directly from the report.

     This option requires the 190:Verbatim Rule Addition request template (which is based on the bulk rules addition workflow) to be active in FireFlow.

   • Download a CSV file which you can edit and then use to manually open the change request in FireFlow.

     You can manually open the change request with the the 190:Verbatim Rule Addition request template or any custom template/workflow for adding rules to devices.

     Once the change is implemented on the device, the next AFA report will automatically identify the original rules as redundant. They will appear in the report as Redundant special case rules.

2. Remove the redundant rules by opening another change request from the new report. See Disabling Device Rules.

   Note: The original rules will only be marked as Redundant special case rules if there are no rules with a "deny" action below the lowest original rule.

To open a FireFlow change request to add consolidated rules

1. If not already configured, enable the Access Lists traffic field to the 190:Verbatim Rule Addition FireFlow change request template, by doing the following:

   Note: When opening the change request directly from the AFA report, this is the only request template that can be used. If you use the AFA provided CSV file to manually open a change request (an option discussed below), you can use the 190:Verbatim Rule Addition template or any custom template for adding rules to devices. The Access Lists traffic field must be enabled in the template you use.

   1. Switch to FireFlow. For details, see Switch ASMS products

   2. In the main menu, click Request Templates.

      The Request Templates page appears.

   3. Select the 190:Verbatim Rule Addition template.

      The template's settings appear.

   4. In the Traffic area, click the +Add or remove traffic fields link.

      The Add or remove traffic fields window appears.

   5. In the Traffic area, select the Access Lists check box.

   6. Click Save.
   7. Click Save template.
2. In AFA, view the desired device's device report. For more details, see View AFA device data.

3. Click the PolicyOptimization tab.

   The Policy Optimization page appears.

4. Click Consolidate rules.

   The consolidated rules appear. Each table represents a single consolidated rule and shows the existing rules it could replace.

   

   Each table of rules represents a group of rules you can consolidate into a single rule.

5. Select the rules you want to consolidate.

   You can choose all or only some of the rules from a table. Choosing rules from multiple tables will create a single change request for adding multiple consolidated rules, one for each table.

6. Click Consolidate selected rules.

   The Consolidate selected rules window appears.

   

7. Do one of the following:

   • To automatically open the change request, click OK.

     A confirmation window appears with the change request information.

   • To edit the consolidated rules before opening the change request, do the following:
     1. Download a CSV file with the consolidated rules you specified by clicking the Download consolidated rules CSV file link.
     2. Edit the file, as desired.
     3. Manually create a change request in FireFlow using the 190:Verbatim Rule Addition request template.
     4. Populate the traffic area of the change request by clicking the Import traffic from CSV link and selecting the consolidated rules CSV file.
     5. Complete the other fields in the template and submit the change request. For more details, see Implement changes.

If FireFlow is installed, you can submit a Rule Removal request to disable redundant, unused, unrouted, and covered rules in the device's policy, directly from the Policy Optimization page.

To open a FireFlow change request to disable device rules

1. In AFA, view the desired device's device report. For more details, see View AFA device data.

2. Click the PolicyOptimization tab.

   The Policy Optimization page appears.

3. Click on one of the supported rule categories (Unused rules, Covered rules, Redundant special case rules, and Unrouted rules).

   The rules in the selected category appear.

   

4. Do one of the following:
   • In the first column, select the check boxes next to the rules you want to disable.
   • Select the Select All Covered Rules/Select All Unused Rules/Select All Special Case Rules check box to select all the rules.

5. Click Disable Selected Rules.

   The change request is created and a notification appears with a link to the change request.

   

   If desired, the change request's fields may be modified later on. For more details, see Manage change requests.

   Note: When you disable more than one rule, a separate change request is created for each rule.

6. Click OK.

The Policy Optimization page's 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. In addition, it provides recommendations for replacing permissive rules with new rules that are tighter, but which still allow all traffic allowed by the original rules.

If desired, you can change how IPT generates recommendations for replacing permissive rules. For more details, see Configure IPT rule recommendations .

To refine rules

1. In the Policy Optimization page's Intelligent Policy Tuner area, do one or more of the following:

   • To view overly permissive rules, click Tighten Permissive Rules.

     The Intelligent Policy Tuner page appears.

     

     A table displays a list of permissive rules that should be refined. For information on the columns, see the table below.

     Icons appear next to the objects in each rule, indicating the object's degree of use. You can mouse-over the icons to view the exact percentage of use.

     Objects that are sparsely used and include many unused IP addresses or services are highlighted in blue. It is recommended to refine these objects' definitions.

     If an object is densely used, then it is not recommended to refine it.

     The Intelligent Policy Tuner Recommendation area displays recommendations for replacing permissive rules with new, tighter rules, as well as recommendations for new objects to be used in the rules.

   • To view unused objects that appear within rules, click Unused objects within rules.

     The Rules Cleanup page appears.

     

     The table displays a list of rules containing objects that have not been used recently. For information on the columns, see the table below.

     The unused objects are highlighted in blue and can be removed.

   • To view all rule usage, click Policy tuner analysis for all rules.

     The All Rule Usage page appears.

     

     A table displays a list of all rules. For information on the columns, see the following table.

     Icons appear next to the objects in each rule, indicating the object's degree of use. You can mouse-over the icons to view the exact percentage of use.

     If an object is sparsely used, it is recommended to refine its definition. If an object is densely used then it is not recommended to refine it.

2. Click on any object to drill-down and view more details.
3. Refine the rules in your policy as desired.

Intelligent Policy Tuner Columns