Every organization with a network goes through some sort of segmentation to secure it. If you are not familiar with segmentation, see the wikipedia page. Even the various compliance regimes (PCI, HIPAA, etc.) have fairly strict recommendations on segmenting the networks. The concept is pretty simple:
- understand the distinct "segments" of the network from the various perspectives
- understand the relative importance of the systems within the segments so that you can properly isolate and protect them
- understand what sort of access might be needed between each of the segments
- use firewalls and vlans to achieve the segmentation
- have justification and documentation for all of the above
The reasons for doing this are also pretty evident:
- systems are contained within specific segments allowing for better control and management
- you can follow the principle of "least privilege" where you only allow the right consumers access to the proper resources
- internal network architecture isn't visible to the other segments - i.e. you're not leaking information that might be useful to hackers
- basically, you are reducing the attack surface of the various systems
All of this is pretty practical and we have seen most organizations go through some form of this exercise. The problem arises when the organization does not have an automated way to validate these policies on a regular basis. We all know how firewall rules change over time:
- create a temporary rule to allow for port 3306 access to give the developer access to the MySQL database
- move the application from port 8080 to 8443 where we add the port but don't remove the old port
You can use a combination of simple discovery scans and codified expectations to achieve continuous monitoring of these rules. The idea of such a system would be as follows:
- have a way to codify the expectations: this can be something simple as a spreadsheet or even some structured file that tells us which ports should be open between which segments
- have a way to run discovery scans: this doesn't have to be much more than something like NMAP - you just need to find interfaces and open ports within a segment
- have a way to validate these expectations after each scan: this is extremely easy to do with a few scripts or a simple micro-service
Let us look at each of the pieces and what we might be able to achieve.
Sample Network
- Let's say we have 3 networks:
- With the following open port expectations:
- Internet --> DMZ
- DMZ --> Production
- Internal --> Production
Codify Expectations
- We can codify the networks as:
networks {
"dmz", "production", "internal"
}
- We can codify the ports as:
expectations {
[
internet -> dmz {"ports": [443]},
dmz -> production {"ports": [80,8443]},
internal -> production {"ports": [22,3306]}
]
}
Discovery Scans
- In order to validate these expectations, we need:
- a "scanner" in each of the environments: internet, dmz, production, internal
- a way to collect all of the data into a central system
- Let's say the scanners find the following:
internet -> dmz {ports": [22,443]}
dmz -> production {"ports": [80,8443]}
internal -> production {"ports": [22,3306, 9200]}
Validate Expectations
- So what do we learn if we overlay these two data points:
- internet -> dmz has port 22 open which is not expected
- internal -> production has port 9200 open which is not expected
Conclusion
- It is one thing to take the effort to segment the network correctly.
- It is another thing to know what to expect as far as open ports are concerned.
- And it is an entirely other thing to actually know if those expectations are true or not.
In our experience, most organizations will do step 1 correctly -- or at least there are 2 networks: dmz and everything else. This isn't ideal but there is some segmentation.
Step 2 is a mix: some organizations will have a "pretty good" idea of what ports should be open, some will have no idea at all.
Step 3 is rare to see: most organizations don't take the time to actually verify that the expectations are met.
So which organization are you? :)