Risk is made of disparate components that technologists inherently understand. Decision makers and corporate staff that are not necessarily smart in technology are often left flummoxed by the technobabble. As technologists and information security practitioners it is important to think about these decision makers in speaking to them plainly. It is also important to know that it is up to us to meet them as they are the user. We don’t want them to become experts and technology anymore than we should become experts at writing corporate financials. What we want to accomplish is showing them facts that we know, and they need to understand.
I have seen lots of vendor products that do some of things we will talk about. What I don’t understand is why more decision makers aren’t’ interested in some of these tools. Though we can detail risk as a heuristic. The work by Dr. Dan and Dr. Julie Ryan being a good start. What we have to achieve to be successful is providing a visualization for decision makers. The requirements for a visualization of risk has to be inclusive of the current terrain we operate and maintain, the threats operating on that terrain, and if possible what is headed our way in the future. As technologists this can be quite difficult.
If you run a security operations center and the wall of knowledge is referred to by the floor as for tourists. This might be for you. If you are a security operations manager that has to brief senior non-technical leadership. Well I think you might find some of this interesting too. If you are a decision maker looking at a spreadsheet wondering what in the heck is going on. Well you might get something from this article.
The issue is that metaphor can overcome the thought process and inject itself into the decision makers mind. If as technologists we talk about the physical, logical, and sematic as layers of abstraction that has little import to the corporate CEO. The corporate mind of a major enterprise thinks in business units, regions, and lines of business. Quite diverse viewpoints break the back of a metaphor quickly. Aligning our thinking too quickly will also cause issues.
Interactive and real time are the two requirements for a decision maker. I may want to shape the risk portfolio I’m representing, or perhaps I may wish to the geo-locate risk. Computers operate in cyberspace, but human inhabit meat space. Knowing that two computers operate at the speed of light has little consequential value to me as a CEO if UPS ground delivery takes 7 days coast-to-coast. Putting computers into the context of meat space is a fundamental requirement.
You have to be able to view the network by the political implications of location. Placing network traffic into the context of the real world means physically mapping the location of numerous infrastructures. The goal is getting a geo-ip world view. This is not for the technologists but for decision makers. Overlaying that physical manifestation of the network with a map also allows for understanding the fundamental risks to the network of weather, and man made events.
You can apply numerous metrics in real time to the physical manifestations of the network on a map. The bandwidth allocation with historical data of network circuits should be trivial to provide. Outage and historical characteristics of outages on circuits should be equally easy. Getting to know the public facing IPs that are specifically targeted by specific adversarial activity provides meta-knowledge (knowledge of knowledge) and thereby subsequent analysis. Why those particular internet facing IPs? What do you mean I have hundreds of Internet facing IPs?
What about knowledge of self? I have seen network diagrams represented as corporate regions. The purpose of the map was to show compliance in nothing more than a stop light format. Each region was scanned weekly for vulnerabilities by the corporate CISO team. Then placed as an interactive graphic for all to see. Each of the regions were then broken up into their districts which identified in some cases the actual bad actors. Simplistic and updated only daily it was a significant boon. A metric next to the region directors name included the number of days the entity was red.
Compliance is one thing, and security is another. You can’t get to secure if you can’t even achieve compliance. However, lots of organizations are compliant and still get hacked. Much like you can build a house to a building code, but it still can burn down. How to capture security? In a way that makes sense to a broader community than technologists? Start with what matters. What are the key assets, critical resources, and things that effect the business. You want to analyze the impact of certain outages. Look at how an email outage would effect actual operations and what the consequences would look like. Not all outages are catastrophic. Focus on the key assets that have business ramifications within some window of time. The process of analysis will drive your metrics and instrumentation solution. It may drive some changes in the structure of your corporate infrastructure.
Consider a “shall remain nameless company” that did the following. The company instantiated radical controls and segmentation of the network. This is a good practice, but in the creation of a shipping and ordering solution the firewall rule change was denied. Not to be deterred an undocumented (to the security group) change was made to a key application. Since a database connection was denied. The developer rolled orders into an email application that sent the order to the Internet, then back down to the corporate shipping system. Head desk therapy does not apply here. The developer was just trying to keep a mission required asset running. The security team just trying to follow their directives. Of course, when this little dance around security was found there was lots of finger pointing. Relatively little solution oriented discussion occured. In the end the security team lost the argument. They always lose when a mission required asset is on the line. As they should. It didn’t really matter. I understand they moved everything to the cloud a few years later anyways.
Business rules mapped out across the logical infrastructure of the corporate enterprise start to show these kind of uncomfortable solutions. Getting these kinds of business rules into a graphic is not difficult. The primary consternation is that perfect is the enemy of good enough. Everybody wants it to be perfect before rolling out a solution/graphic to what will be constant changes as others see it. This is one of the few perfect places that information security and DEVOPS attutudes interact. The cycle of change should be as rapid as the feedback. As these kinds of relationships become denser, with more information, selective forks in the solution may be required.
At this point you are looking at a pile of data. It becomes time to start pulling the thread on information comprehension. Anybody who has sat through an Edward Tufte lecture knows that there are many ways to represent information. Though personally a fan of multiculturalism I don’t let it get in the way of information fluency. Red for bad, yellow for caution, and green for good are just fine (Tufte graduates likely remember the China example). Left to right representations of time similarly are patterns that leadership will recognize. Trends and report on trends can use these with metrics and measures you have already defined.
As a security practitioner you want to represent data to the decision maker based on their needs not yours. Your actual representation of risk based metrics will be driven by the information fluency of the respective audience. Though I as a former law enforcement officer and member of the military like maps with integrated objects. A CEO with an accounting background may like pie charts. In an organization that is risk averse, and internally competitive, a pie chart of risk indicators by region may be completely valid.
As you ask the question of metrics? What metrics should I choose? Look at your compliance frameworks and start picking up on the actions of the framework. As an example consider the NIST framework. The easy part is the actions measurable inside of the blocks between protect, detect, respond, and recover. A bit more salient is the hand off measurable events between each block of the framework. If you’d rather use the SANS or COBIT frameworks feel free. The same analysis strategy applies.