Rule Overview

Overview

When a user clicks on a rule in the Rule Viewer, details of the rule appear in the Rule Viewer Overview window.

The following information about the rule is displayed if available.

General Information

• Last Hit: Last time that traffic passed through the device and matched either the rule, user, or application identities details. This field is supported for security rules only, and not NAT rules, with the exception of Check Point, which supports Last Hit for both security rules and NAT rules.

• Last Modified: Last time a revision showed that the source, destination, or service changed in the rule, including changes group members.

• Cert. Exp.: Rule expiration date.

• Permissiveness (high/medium/low) – An indication of how widely a rule is defined, for example:

  • A rule with one source host, one destination host or one service is low permissiveness

  • A rule with Source "ANY", Destination "ANY" or Protocol "ANY" is high permissiveness

  Rules with high permissiveness can be a security risk because they allow too much access through the firewall. N/A indicates that the platform is not supported for permissiveness calculations.

• Shadowed: Indicates whether the rule will never have hits from traffic because rules above it in the policy handle the traffic.

• Violations: Number of times the rule violates the USP.

• Device: Device to which the rule applies.

• Domain

• Source

• Source User

• Destination

• URL Category

• Service

• Application

• Action

• Comment

• Miscellaneous: Tags, direction, From zone, To zone, Log (Yes/No), Security Profiles and other information.

• Documentation

Documentation

Rule documentation helps you keep track of who made changes to a rule and why the changes were made. It includes the following rule information:

• Technical Owner: SecureTrack user responsible for the rule

• Automation attribute

  • None

  • Legacy rule

    A legacy rule is a rule that is no longer needed and is typically a candidate for future decommissioning. When a rule is marked as legacy, SecureChange Designer will treat it as a shadowed rule when making recommendations, and SecureChange Verifier will ignore it when verifying access.

  • Stealth rule

    A stealth rule is a 'deny' rule (cannot be 'allow') placed at the top of the policy whose purpose is prevent all access that hasn't been explicitly granted by other rules, thus protecting the entire network including the firewall itself.

    For users of SecureChange, when a rule is marked as stealth, Designer recommendations will place any new rules recommended for an access request below the stealth section of the policy.

• Rule description: Description of the rule

• Certification status: Whether the rule has been certified (Certified or Decertified).

• Certification date: Date that the rule was certified.

• Certification expiration: Date that the certification for the rule expires

• Number of related tickets

What Can I Do Here?

• Hover over items to display more detail.

• View Violations

• View Shadowing Rules

• View Related Tickets

• View Related Applications

• Edit Rule Documentation

• Add tickets to rules

• Create a USP Rule Exception

• Add the rule to an existing USP Rule Exception

• Generate shadowing report

• When an external ticketing system is configured with SecureTrack, click the link in the comments to view the ticket.

  

Edit Rule Documentation

1. Select one or more rules.

2. From the Actions menu, select Edit Rule Documentation

   

3. Add or edit the following information:

   • Rule description - free text

   • Technical Owner - TOS Classic administrators can select any user from the list. Other users can assign only themselves.

   • Automation attribute - used by SecureChange Designer

     • None - no automation attribute
     • Legacy rule
     • Stealth rule

Add Ticket to Rule

A ticket is a change request or other rule related activity that is tracked in a ticketing system. Linking ticket information to a rule may be helpful for auditing as it allows you to track why each change was made, who requested the change, and who authorized it. You can manually enter this information into a related ticket in the Rule Viewer or include a URL which links the ticket in your ticketing system.

You can add details of tickets to a rule or multiple rules, this allows you to track all rule-related information in the Rule Viewer.

1. In the Rule Viewer, select the checkbox for one or more rules.

2. From the Actions menu, select Add Related Ticket, and add the following ticket information:

   • Ticket ID (required)
   • External URL
   • Business Owner
   • Email
   • Expiration date
   • Comment

   If SecureTrack is connected to SecureChange, select SecureChange Ticket to create the ticket in SecureChange.

Once you have added a ticket to a rule, in the Rule Overview you can click the Related Tickets link on the left to view details about all related tickets.

Create a USP Rule Exception

You can exempt specific rules from triggering a violation in the USP by creating a USP Rule Exception. These exceptions are useful for when:

• You have to exempt certain rule violations for a limited period of time due to an urgent requirement.

• You want to make an exception for specific devices. For example, if you have an HA configuration, and you don't want to receive duplicate violation notifications from the standby devices.

1. In the Rule Viewer, select the checkbox for one or more rules.

2. From the Actions menu, select Create USP Rule Exception.



3. In the General section, enter the following information:

   • Exception Name: The name of the USP Rule exception

   • Ticket ID (Optional): The Ticket ID that relates to this exception.

   • Approver (Optional): The person who approved the USP rule exception.

   • Time Frame (Optional): The time frame in which the USP Rule exception is valid

4. In the USP section, click +Add USP to select a USP to which to apply the rule exception. If you don't select a USP, the rule exception will apply to all USPs.

5. In the Description (optional) section, enter a description of the USP rule exception.

6. Click Create.

You can also add or edit tickets or documentation using GraphQL.

Add a Rule to an Existing USP Rule Exception

1. In the Rule Viewer, select the checkbox for one or more rules.

2. From the Actions menu, select Add to Existing USP Rule Exception.

   

3. In the Exception field, select the USP Rule Exception, and click Open.



4. Review the information in the USP Rule Exception.

   In the Rules section, the rules which you just added are highlighted in blue.

5. Click Save

Generate Shadowing Report

From the Actions menu, select Generate shadowing report. The shadowing rules are exported to a CSV file.

How Do I Get Here?

From the menu, select Browser > Rule Viewer and click a rule.