Mapping Policy to Your Network
A few years ago, I sat in an otherwise empty classroom inside the administration building of a children’s hospital with two members of their security team. We stared at a spreadsheet and a document that described the server and client zones of their network, displayed from a projector like a classroom project. For each zone, we dug into the details of allowed, forbidden, and approved access. This work was precise and detailed, requiring us to step through subnet addressing, host addresses, and the policy documentation over and over again.
Eventually, we had mapped the network security architecture policy to their network, though, and this was a critical next step in protecting kids and their families from the potential evil done by those who would attack the network of a children’s hospital.
The work to dig in and map every network to an appropriate zone is significant, but it’s critical. Regardless of your specific requirements, knowing the purpose of every subnet, each type of host collection you have, and mapping them to a reasonable network security architecture is a critical requirement allowing you to draw lines between parts of your network to avoid the situations that Target and Supervalu have found themselves facing.
As attackers and their attacks become ever more sophisticated and patient, your security zones and the implementation of security controls between them is your only real defense. Of course, using automation to monitor those controls and ensure that they are implemented correctly, consistently, and completely is equally vital. More on that in an upcoming post.
This becomes difficult when you realize that the very foundation of every modern business, the network, is full of moving parts and is anything but stable. Technology continues to evolve, new products are introduced, and companies are constantly changing their electronic infrastructure in hopes of improving operations and lowering costs. This double whammy of new products and the desire to lower costs by changing the network brings complexity, potential vulnerabilities and unpredictability to the business. At the end of it all, one should always ask the question – are things getting better, or not? Is my network improving or not? And am I more secure or not? How can I know?
fighting for resources and the favor of the CIO, CFO, and CEO.
So what do you do? The good news is that the steps are well known and understood: place security controls into your network to isolate a set of subnetworks (typically called “zones”) and both set and monitor the potential access paths between the zones. This is the first set of defenses against attacks, and one which many organizations do not fully deploy.
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.
You see, networks have been built by so many people over decades, largely without standards for design, inspection and operation, and have grown so large and complex, that basically it’s as if we were living in mud huts from 2000 BC. Is that any way to conduct your critical business? In a mud hut, that is easily brought down, vulnerable to natural and man-made disasters, and not very comforting on the security front?
Every business depends on its networks, and we have every indication that dependency is increasing at a dramatic pace. These networks and the technology that makes them run are constantly changing. They evolve to suit the needs of business, and they are improved in performance and security by new products. Unfortunately, they are often built without a big view architecture in mind: “just make it work” is often the order of the day.
It is embarrassingly common for us to find the majority of network management information in spreadsheets. Lists of devices, lists of firewall rules, hierarchies of networks. All laid out in nicely formatted tabs within multiple spreadsheet workbooks, often stored in SharePoint or Google Docs. But, always, devoid of context and the real meaning of the elements.
RedSeal’s model of the network will allow for faster artifact development and the development of these artifacts BEFORE deployment. The RedSeal platform has the capability to combine any components of the model (hosts, devices, subnets, etc.) into logical groups. These are referred to as zones (sometimes also called segments or enclaves). Because RedSeal understands all the access in the network, the platform is capable of presenting and measuring all access into and out of the zone and between all other zones or the network at large. It is also possible to write business or policy decisions against those access paths and track those decisions for compliance purposes. This RedSeal use case will assist JRSS and JIE with meeting or exceeding the Department of Defense Ports, Protocols, and Services Management (PPSM) guidelines. These guidelines will be applied to the Joint Regional Security Stack (JRSS) and the components that comprise the stack.