On This Page
Creating SecureChange Tickets
After you build the connections that your application needs, you can create a SecureChange ticket to request that those connections be allowed. The details of the connections appear in the Access Request fields of the ticket automatically. You can enter additional information to the ticket and submit the ticket.
- If you create a ticket after you change the source, destination, or service of a connection, the ticket includes "Drop" access requests for the traffic that is no longer included in the connection and "Accept" access requests for the traffic that is included in the new connection.
- If you edit the IP address of a resource or a member of a resource group, you can save the change and open a ticket to update the firewall rules that use the resource. The ticket includes "Drop" access requests for the connections that use the old details of the resource and "Accept" access requests for the same connections with the new details of the resource.
- If you delete a connection, the ticket includes "Drop" access requests for the traffic that was included in the connection.
You can only create a ticket with a "Drop" access request if the access is not also required by other connections in SecureApp. If you try to create a "Drop" access request for access this is in use, SecureApp shows you the connections that use the access.
Create a Ticket in SecureChange
- Build the connections that your application requires.
- Click Create Ticket.
-
Select a SecureChange workflow to use for the request.
- Only workflows that have Access Request fields appear.
- SecureApp highlights the workflow that you selected the last time you created a ticket.
-
If you do not want the ticket to go through the workflow process, you can select Create a closed ticket. This can be useful so that:
- You have a SecureChange ticket for connections that are already configured in the devices so that auditors can see the access request in the ticketing system.
-
The next ticket created from the connection does not include any previous changes.
When you create a closed ticket, revisions that match the ticket are listed in the Change browser in SecureChange as unauthorized because they do not pass through an approval step in SecureChange.
The new request is shown with the details of the connections changes already entered into the Access Request field and comments that show the actions in SecureApp that created the access request. Click on View original request to see the connections as they are shown in SecureApp.
-
Edit the request information.
To see the context of the ticket, you can click Original Application Change to see the ticket as it was when it was submitted from SecureApp.
This can be very helpful because while viewing the technicalities of what needs to be done in the task view, it can be difficult to understand the actual goal of the task. When you view the SecureApp ticket you see the request as it was sent.
- Click Submit.
The SecureChange request continues through the selected workflow. In SecureApp, the application and connections have a ticket icon to show that there are open tickets for them. You can:
- Click on to see the list of open tickets.
- Click on an open ticket to go to that ticket in SecureChange.
The SecureChange ticket shows a link to the associated application in SecureApp.
- If the ticket icon is marked with a rejection , at least one of the tickets for the connection was rejected and requires action.
Use LDAP Groups in the Connection Source Field
When opening a ticket, there is a validation for each LDAP group in the connection’s Source.
-
Source field: LDAP groups, which pass the validation successfully, appear in the Source field of the Access Request and undergo user identity automation. See Using User Identity in TOS.
-
User field: LDAP groups, which do not pass the validation, appear in the User field of the Access Request. Groups and users in this field are used for documentation only and are not part of the automation process.