Federal agencies are clamoring for information about best practices about to implement the findings of last year’s cybersecurity “sprint.” This new directive, the Cybersecurity Implementation Plan, is mandatory for all federal civilian government agencies. It addresses five issues intended to shore up agency cybersecurity and ensure network resiliency.

So when agencies are done with their implementation, all their networks and assets will be secure, right?

Wrong.

Most of the time the reality of your network and the official network diagram have little to do with each other. You may think it’s accurate…but it’s not.

Recently, I sat down with Jeremy Conway, Chief Technology Officer at RedSeal partner MAD Security, to talk about this. He works with hundreds of clients and sees this issue constantly. Here’s his perspective.

Wayne: Can you give me an example of a client that, because of bad configuration management, had ineffective security and compliance plans?

Jeremy: Sure I can. A few months back, MAD Security was asked to perform an assessment for an agency with terrible configuration management. With multiple data centers, multiple network topologies, both static and dynamic addressing, and multiple network team members who were supposed to report up the hierarchy, we quickly realized that the main problem was that they didn’t know their own topology.  During our penetration test, we began compromising devices and reporting the findings in real time. The compromises were just way too simple and easy.  The client disputed several of the results.  After some investigation, we figured out that the client had reused private IP space identical to their production network for a staging lab network, something no one but a few engineers knew about.  Since we were plugged into the only router that had routes for this staging network, we were compromising all sorts of unhardened and misconfigured devices.  Interestingly enough, this staging network had access to the production network, since the ACLs were applied in the opposite direction — a whole other finding.  To them and their configuration management solution, everything looked secure and compliant. But in reality, they had some major vulnerabilities in a network only a few folks knew about, vulnerabilities that could have been exploited to compromise the production network.

The client was making a common mistake — looking at their network situation only from an outside in perspective, instead also looking at it from the inside out.  They didn’t have enough awareness of what was actually on their network and how it was accessed.

Wayne: That’s a powerful example. How about a situation where an agency’s use of software-defined or virtual infrastructure undermined their access control?

Jeremy:  One hundred percent software defined networks are still rare in our world. However, we had a situation where virtual environments were spun up by the apps team, not the network team, which caused all sorts of issues. Since the two teams weren’t communicating well, the network team referenced network diagrams and assumed compliance.  In reality, the apps team had set up the virtual environment with virtual switches that allowed unauthorized access to PCI data. Running a network mapping exercise with RedSeal would have identified the issue.

Wayne: I imagine that inaccurate network diagrams cause major issues when incident response teams realize that there hasn’t been any auto discovery and mapping of the network.

Jeremy: Yes, this is a must-have feature, in my opinion. When responding to an incident, you have to perform the network-to-host translations manually. Tracking down a single host behind multiple network segments with nothing but a public IP address can take a long time. In a recent incident with multiple site locations this took the client’s network team two working days — which really doesn’t help when you’re in an emergency incident response situation.

RedSeal makes it easy to find which host has been compromised and which path an intruder has taken almost instantaneously.

Moreover, conducting a security architecture review is much quicker and more comprehensive with RedSeal. This used to be a manual process for our team that typically took 2-4 weeks for the average client. RedSeal has cut that time in half for us.  Additionally, with RedSeal the business case for action is stronger and the result is a better overall remediation strategy. How? For one, given an accurate map of the network, HVAs can be prioritized and a triage process can be deployed that allows security teams to focus scarce time and resources on priority recommendations. This visibility into the severity of security issues also allows teams to develop mitigation strategies for patch issues.

Wayne: Jeremy, this has been a great discussion. I hope you’ll come back and do this again.