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:
Receive change request to make changes to the customer's firewall
This comes in the form of a change request ticket
Identify the firewalls for the change
It's important to identify the right firewall and the right policy
Write the procedure on how to complete the change
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.
Submit the change for internal approval by a senior engineer
Senior engineers have been there and seen that - so they have experience in quickly spotting any mistakes or issues that only experience knows
Submit the change design for external approval by the customer
This way the customer also knows the exact steps we are going to implement on their firewall to protect their security
Implement the change
Login to the firewall and make the change
Notify the customer of the change completion
Update the ticket or send an email
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:
10.1.126.0/24
Host machines behind the Palo Alto firewall:
192.168.1.15
192.168.1.16
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 10.1.127.0/24, 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 "10.1.126.0/24" and "10.1.127.0/24" into 10.1.126.0/23.
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