Architecture, Design, and the Operational Network
A couple years ago in a conference room with a window looking out on the Arizona desert, two of us sat down with a customer to talk about their network. I asked to see their best network diagram, which he left to retrieve. When he returned, he rolled it out to its full length on the conference table. He began telling me of a number of inaccuracies that he knew while I looked in the lower right corner for the annotation.
The plot was years old.When I speak to groups of engineers, I often ask how old they think the average organization’s network diagram is. While the guesses vary from 2 to 5 years, everyone recognizes that they are woefully out of date. And that’s a huge deal for attempting to understand and protect your network.
…by the way, in my experience, the average is 5 years old! As a result, many of the technologies deployed didn’t even exist when the last map was made. Making the map current never seems to get to the top of the priority stack, either.
The truth is that if you can’t see it, you can’t secure it. If you don’t know what your network really looks like, you can’t possibly be certain your security controls are properly deployed. Even if you have designed a security architecture aligned with the best practices of network security zones such as those outlined in the PCI DSS, if your architecture isn’t reflected in the operational network, it’s effectively moot.
Similarly, the network and security design teams create a network design that they intend to align with the architecture.
However, when it gets implemented, does it align? Does it stay aligned as equipment changes, requirements evolve, and needs expand? How would you know?
That, of course, is the 100 million-customer-data-record question.
What do you think is the best answer?