top of page

Stories of a CISSP: Change Management

In a secure corporate environment, it is critical to have a strict change management process. Large environments mean large changes. Even if it is a really small change to a firewall, it could still affect the overall stability and access control of other interdepenencies. Which is exactly what happened at work a few weeks back.

This is our change process:

  1. Receive change request to make changes to the customer's firewall

  2. ​This comes in the form of a change request ticket

  3. Identify the firewalls for the change

  4. ​It's important to identify the right firewall and the right policy

  5. Write the procedure on how to complete the change

  6. ​This should be a step by step write-up with the amount of detail which would allow the next network security engineer on shift to accomplish the change if necessary. It must be that detailed.

  7. Submit the change for internal approval by a senior engineer

  8. ​Senior engineers have been there and seen that - so they have experience in quickly spotting any mistakes or issues that only experience knows

  9. Submit the change design for external approval by the customer

  10. ​This way the customer also knows the exact steps we are going to implement on their firewall to protect their security

  11. Implement the change

  12. ​Login to the firewall and make the change

  13. Notify the customer of the change completion

  14. ​Update the ticket or send an email

  15. Close out the change request

Basically, it's a lot of steps to take to implement changes on a customer firewall, and with good reason. One mistake and it could bring down an entire firewall - it's happened many times.

We followed the proper change management process and created a site-to-site VPN tunnel with multiple parties live on a conference call. Below are some details about the VPN tunnel.

Checkpoint to Palo Alto VPN Tunnel

A site-to-site IPSec VPN tunnel between a Checkpoint firewall and a Palo Alto firewall.

Subnets behind the Checkpoint firewall:

Host machines behind the Palo Alto firewall:

Both Phase 1 and Phase 2 of the VPN tunnel came up fine, and both sides of the firewall were encrypting and decrypting traffic.

Here are the settings in case you wanted to know:

Phase 1 Settings

Diffie-Hellman Group 5 for key exchange.

AES256 for encryption.

SHA256 for hashing.

Pre-shared secret: **********************************************

Phase 2 Settings

Perfect Forward Secrecy enabled.

Diffie-Hellman Group 5 for key exchange.

AES256 for encryption.

SHA256 for hashing.

Pre-shared secret: **********************************************

Security Policy on Checkpoint Firewall

After a successful conference call, the client's project manager asked if we could quickly add another subnet behind the Checkpoint firewall, a subnet of, even though it was not in the original request.

We said no problem and just quickly added the subnet into the encryption domain of the Checkpoint firewall. I have to tell you, creating a site-to-site VPN tunnel with multiple parties and moving parts, it rarely happens that it is a quick and successfull conference call. There were times that we were on calls to troubleshoot a VPN tunnel for 2 hours, all the way to 10 hours.

So we were feeling pretty good about ourselves as this call took just 15 minutes and the tunnel came up quickly. What could go wrong? We just went ahead and added a subnet as the customer asked on the fly.

We didn't go through the change management process.

Big mistake. The Checkpoint firewall immediately started supernetting the networks "" and "" into

This is something that a Checkpoint firewall sometimes does, and it can be disabled, which we did after 60 minutes on the call and after asking one of our senior engineers to figure out why everything broke.

He said it's a common issue, and he might've caught it had we gone through the change management process. Ouch.

Lesson learned.

The CISSP exam stresses the importance of a proper change management process and the implications if we don't follow it.

CISSP Take-Away Concepts

Domain 1: Security and Risk Management

  • Procedures

  • Procedures are a step-by-step guide to complete a task. We did this when we wrote up the procedure to create the VPN tunnel in our change design

Domain 3: Security Engineering

  • Symmetric Encryption

  • ​The pre-shared secret was the symmetric key. We were using symmetric encryption for this VPN tunnel. If we wanted to use asymmetric encryption, then we'd have used certificates, not pre-shared keys

  • AES256 - Encryption

  • ​We used AES256 for both Phase 1 and Phase 2

  • SHA256 - Hashing

  • ​We used SHA256 for both Phase 1 and Phase 2

  • Diffie-Hellman - Key Exchange

  • ​We used Diffie-Hellman Group 5 for the key exchange in both Phase 1 and Phase 2 (Perfect Forward Secrecy)

  • Perfect Forward Secrecy

  • ​A way to add an additional security measure to an IPSec VPN tunnel

Domain 4: Network Security

  • IPSec VPN

  • ​An IPSec VPN provides confidentiality, integrity, authentication

  • IP Addressing

  • The encryption domains both contained different sets of private IP ranges

  • Subnets

  • ​The encryption domain behind the Checkpoint firewall were subnets

  • Supernetting (don't worry about this one for the exam)

  • ​Supernetting is when a device creates one big network from two smaller networks

  • Firewalls

  • This whole article was about a VPN tunnel being built on two different firewalls

Domain 7: Security Operations

  • Change management

  • At the time of the incident, there was no change management process. All changes to the firewall was being done on the fly


bottom of page