On This Page
Checking Security Compliance and Repairing Connections
Before creating a ticket for an application, you can check if the connections are compliant with organizational security policies, based on the Unified Security Policy which is defined in SecureTrack. Verifying the connectivity now, before submitting the ticket, allows you to:
- Fix the connectivity to be compliant before submitting the ticket, and avoid having the ticket rejected
- Add a note with an explanation when submitting the ticket to justify the request
You need View security compliance violation permissions.
Check The Security Compliance of Application Connections
- Above the connections, click the Compliance button.
If all connections have been successfully analyzed and are compliant with all policies, a message informing you of this appears in the top right of the window.
If there are one or more connections that are not compliant or could not be analyzed, the RISK page opens. You can see the result for each connection. The Connection dropdown box lists them in order of severity. Select the one that you want to view.
The connections are each listed with a square in one of these colors:
- Red: The connection violates at least one policy. A detailed report of the violation(s) is displayed.
- Green: The connection does not violate any configured policies.
- Yellow: The system cannot run a compliance check on this connection. A security compliance check cannot be run when:
- It is not a complete connection (missing source, target or service)
- The connection uses an LDAP user as a source
- The connection uses an application identity
Repair a Connection
After your connectivity is approved and is already running properly, there may be network changes that suddenly break a connection or a connection interface. For example, a new firewall rule might block a specific connection.
You can revert changes made to a server, service or group. Deleting a server, service, or group cannot be reverted.
Detect the connection to be repaired
- The Business Owner receives a "Blocked connection notification" - An automatic email alert with information on the date and time on which the specified connection was blocked.
- Any other user who is an editor of the application and has the following permissions may notice the broken connection and ask to repair it:
- View My Requests and create requests - A user with this permission can create SecureChange tickets and follow the progress of the ticket in SecureChange > My Requests.
- View SecureApp and access SecureApp applications - A user with this permission can view existing applications, configure application connections for applications that they own or for applications that they are an editor of.
- View connection status - A user with this permission can view the connection status icon.
Requirements
The Access Request workflow is activated in SecureChange.
- The disconnected connection meets these requirements:
- The connection status is disconnected ().
- At least one open ticket that requested access for this connection has been closed.
- The connection was not edited since the last ticket that allowed it was approved.
- There are no other open tickets for the application that includes this connection (to verify this, make sure the number of tickets in the ticket icon is zero: ).
Repair the connection
- In the Connectivity tab, choose one of the following depending on the connection type:
- If this is a disconnected connection, go to and select Repair connection.
- If this is a disconnected interface, click to repair it.
- In the New Request window, select the Access Request workflow and click Create.
SecureApp creates a new request that is unique in two respects:
- It concerns a specific connection (as opposed to all connections)
- It requests to restore access that was previously granted (as opposed to approving all changes made throughout the application) - The Comment field asks to repair the connection with the specified name.
Accordingly, the Access Request field automatically shows the details of the connection to be repaired.
The ticket is processed as part of the SecureChange workflow. If the security policies are modified, the traffic required by the connection is allowed again on the security policies. The broken connection is restored and now appears as ‘connected’ again..
Was this helpful?
Thank you!
We’d love your feedback
We really appreciate your feedback
Send this page to a colleague