Assuming a Breach - Security Architecture
Mar 01, 2015 08:19PM, Published by MED Magazine, Categories: Technology
Castle designers in the days of yore assumed that invading forces would breach some or most of their physical security controls, so in preparation they built castles with layers of defenses and hid their most valuable possessions and people deep within the center of these controls. This was called layered security. In the days of modern virtual environments, the mode of access has changed drastically. However, the methodology of defense has not. We need to assume a breach will happen or has already happened and design our security controls from the inside out with a layered approach. This is very different and more complex than a perimeter defense approach like that of the City of Troy.
Define Your Security Objectives
The first question any security architect should ask themselves is: What are we trying to protect? If the answer is the entire network, then it is just a matter of time before you have failed your objective. If the answer is patient data and demographics, then you have come to a reasonable proposition. This does not make the problem easier to solve by any means. Rather, it opens up a can of worms. You’ll need to define a data-flow diagram to start. The data-flow diagram is easiest to construct if you use a logical diagram approach.
Detailing Your Objectives
In order to come up with a proper flow of data, you’ll want to consider ‘where’ and in ‘what states’ the patient data and demographics exists. A concept I like to use when teaching layered security is the McCumber Cube. The McCumber Cube can be used in many ways in information assurance but I’m going to flip it on its ear for this exercise. We will step from one side of the cube through the other and then back out again.
Use the cube to ask yourself these questions:
What people legitimately use the data? How is the data transmitted to them? Is it stored anywhere along the way or at the destination? Is it processed at the destination or somewhere else?
Once you answer these questions, you can continue to the back of the cube and ask yourself similar questions for Process and Technology such as:
What processes legitimately use the data? Do those processes transmit the data and if so where? Is the data stored at any point during the process chain? Which technologies legitimately use the data? And so on…
As you move through this process, hopefully you are formulating a nice data-flow diagram.
The next steps for layered security architecture are deciding how the attackers can possibly compromise the endpoints once the data flows and is stored and processed. Again, using the cube, we can decide what threats exist to the confidentiality of the data as it flows through the endpoints. How about the integrity? …and to the availability? Your risk assessment can help you prioritize the threats to these endpoints.
Lastly, working your way back to the right side of the cube:
What controls are in place to help mitigate the risk of a confidentiality threat to the data on the endpoints while in transmission? How about to the integrity while stored on an endpoint? Your risk assessment can again help you decide which controls will mitigate the most risk for each threat at each endpoint. There is one final step in the layered security approach - use cases, or in this example, compromise cases.
Compromise Case Walkthroughs
Compromise cases take the table-top approach to the what-if scenarios. What if one of your users with access to patient data clicks on a phishing email and the workstation becomes infected with malware that allows the attacker to access the workstation as if they were the user? Can that endpoint be compromised without compromising the confidentiality, integrity, and availability of the data? What controls do you need to have in place to isolate the compromised machine? What characteristics does a compromised machine exhibit? Answers to these questions might be: We have a reputation based spam filter which catches spoofed emails, but if it makes it past that we have application whitelisting so the malware shouldn’t run. If it does for some reason, we watch for configuration changes on the endpoint and are alerted if they are changed. IPSec is used between workstations and servers so network traffic is not easily sniffed. We also use session expiration so the attacker shouldn’t be able to compromise the session to the server where the protected data is stored. If those controls are compromised, we have an endpoint protection that will not allow the compromised workstation to be used to attack the rest of the endpoint in that subnet. If that control fails, we have our subnets properly segregated. At this point we would be seeing a lot of IDS or log alerts and we would activate our incident response protocol, etc…
Hopefully this small example helps illustrate how a security architect can rationally plan a layered security methodology. No organization has the resources to put all these controls in place from the birth of a network. Only through careful, tactical, and strategic planning can a skilled security architect keep the organization from becoming the next breach report, even when endpoints of the network have been compromised.
Eric Buzz Hillestad is Partner at SHS, LLC and Principal Consultant.