Managing Access Requests

This topic is intended for SecureChange handlers who are responsible for processing change requests.

The Access Request field contains source, destination, and service/application identity values for the request. The source and destination IP addresses are validated when the request ticket is created.

The Access Request field is unique among fields in the following ways:

• It is dynamic: Once entered into a ticket in a specific step, the field appears and remains editable by task handlers of all subsequent steps for which the Access Request field is also configured.
• It is single: No more than one Access Request field can exist in a ticket at any step (however, multiple request patterns may exist within the field). When the Access Request field is configured for multiple steps in the workflow, its values in a ticket are carried over from step to step (in the case of multiple request patterns, all are carried over), to be used for analysis and design.
• It is configurable: Detailed viewing and editing options are configurable for each step (as part of workflow configuration). For example, the Access Request can be made read-only, the Target component can be hidden, and using 'Any' and the object browser can each be disabled.

In the Access Request field the following ticket property can be configured for each step:

• Advanced Rule Customization:

  • Optimize policy: This default option enables you to reuse the policy rule throughout the ticket lifecycle.

  • Create new policy rule: Creates a new, specified policy rule for each Access Request, enabling a correlation between the Access Request and the rule that implements it. This new policy rule does not interfere with existing rules, which allows for an easier removal of network access at a later stage.

Each handler is able customize the option per step, however selecting a different option will reset the Designer and Verifier results.

In the Access Request field, these tools can be enabled or disabled for each step:

• Import from other tickets: Search for Access Requests in closed tickets in the SecureChange database and importing them. This feature is not available for the Segregated Domains Multi-Domain mode.

• Risk Analysis: The Risk Analysis tool shows if the requested access violates corporate security policy configured in SecureTrack.

• Security Zones: Retrieves the security zone information for the source and destination so that you can analyze the request from a security standpoint.

  Security Zones are not available when SecureTrack is configured for Multi-Domain deployment.

• Designer Tool: The Designer gives precise recommendations for how to change a rulebase by using topology and current rulebase data in SecureTrack.

  You can implement the Designer's recommended changes for these devices:

  • Check Point: With one click, you can update the policies with the Designer's recommended changes.

    To enable the Designer to apply changes directly to Check Point policies, you must configure SecureTrack to use an OPSEC object that has Read/Write permissions. You also need to install the updated policies on to the firewall.

  • Cisco ASA, Cisco IOS, and Juniper SRX: With one click, you can update the devices with the Designer's recommended changes.

    To enable the Designer to apply changes directly to Cisco devices, you need to configure SecureTrack to monitor the devices via SSHv2.

  • Juniper NetScreen: With one click, you can get the device-specific commands to implement the Designer's recommended changes on some or all of the devices.

  For other devices, you can implement the design suggestions manually.

  For each step that you enable the designer tool, you can allow users to either design and update changes (Allow all) or just allow users to run the designer (Allow design only), or allow users to just implement changes (Allow update only) by saving the changes to the Check Point policy or by updating the Cisco or Juniper devices.

  • Verifier: The Access Request field includes the Verifier tool, which verifies whether an Access Request has been implemented in actual device policies.

If you select Dynamic Assignment mode for a step, you can also configure conditional tasks according to Access Request content, labels and/or ticket fields, including SLA status, Verification Status, and Risk Status. For example, the task could be sent to different groups depending on the affected networks or target firewalls. When multiple conditions are met (for example, the Access Request contains multiple traffic pattern values so that more than one network or target firewall is affected), multiple (parallel) tasks are created. Each task contains only the Access Request traffic pattern values that fulfills its condition; all Access Request traffic pattern values resulting from the step's tasks are passed on to the following step.