When having SecureTrack and SecureChange, revisions can be compared. Additionally, the SecureChange Ticket ID is available as a link in SecureTrack. Following this link from SecureTrack, the referring ticket is automatically opened and shown in SecureChange (if the current user is allowed to access it).
Additional information can be gathered using SecureTrack > Home > Change
In this table, all revisions are listed. Information provided is the device, the revision number as well as who did the change. The right row shows states like e.g. "Authorized". Let's have a closer look at the conditions about the shown status.
SecureTrack runs without SecureChange or the option for linking SecureChange tickets with a revision is not active. It can be activated by a SecureTrack administrator via the menu:
Menu > Settings > Configuration > Ticketing
This option allows to restrict the search in tickets for a specific time, e.g. 3 months. If it's not restricted, the whole ticket database will be searched for possibly matching tickets. So iit's possible to have (much) more than one ticket matching the change.
The change is authorized under several conditions
- The change has no influence on the traffic passing the device. This happens e.g. if a comment has been added to a rule or an object has got a new color.
- The change doesn't allow any new (additional) traffic.
- The change allows exactly the traffic that has been requested and approved by a ticket. In this case, the ticket ID is shown in the line. It might be possible that there is more than one ticket referenced. This is due to more than one ticket matching the change. Considered are all tickets in the time frame configured as shown above.
Then change is unauthorized under several conditions
- There is a change regarding traffic through a device with no matching ticket for it. This is the situation if a change is done without requesting it by a ticket. The change is directly configured in e.g. Check Point SmartConsole.
- The change done is not completely covered by a ticket. This happens if e.g. the service SSH is requested, but SSH and HTTPS are implemented. In this case, only a part of the change has been requested and approved by a ticket. The ticket ID is shown in this line.
- The change requested a "rule modification" and not all changes are covered by a ticket. This includes also removal of e.g. services. If the service HTTP should be removed from a rule, but HTTP and FTP are removed, the change is unauthorized also (even if less traffic is allowed afterwards).
Manual changes on the status
Besides this, a manual change of the status is possible. This might be useful when e.g. an emergency change needed to be configured. Changing the status requires administrative access to SecureTrack. This option is not available for a "user", even for the device he or she is allowed to see.
If a change needs to be "authorized" manually, just go to the pen shown near the status.
In this example, an "unauthorized" change will be changed to "authorized". After confirmation, the status is changed, but a sign allows to see that the change was done manually. Besides this, the date and administrator are shown.
The same procedure can be done to "unauthorize" changes manually.
Hint regarding compliance
Current versions of SecureTrack don't allow to add a comment if the status is changed. That's the reason why the column "Comment" is empty in Menu > Home > Change. This column is not shown in the overview (Menu > Home > Dashboard).
The missing opportunity to provide a comment (i.e. reason for the manual change) might be problematic if the configuration is audited. So the reason for changing the status needs to be documented somewhere else.