As we mentioned when introducing this series on fact-based network security, we increasingly need to use data to determine our priorities. This enables us to focus on activities that will have the greatest business impact. But that begs the question: how you determine what’s important? The place to start is with your organization’s assets.
Truth be told, importance and beauty are both in the eye of the beholder, so this process challenges even the most-clued in security professionals. You will need to deal with subjectivity and the misery of building consensus (about what’s important), and ultimately the answer will continue to evolve in light of the dynamic nature of business. But you still need to do it. You can’t spend a bunch of time protecting devices no one cares about.
But it’s always good to start conversations with a good idea of the answer, so we recommend you start by defining relative asset value. We have long held that estimating (value = purchase price + some number you make up – depreciation) is ridiculous. We haven’t stopped many folks from doing it, but we’ll just say there isn’t a lot of precision in that approach, and leave it at that. So what to do? Let’s get back to the concept of relative, which is the key.
A reasonable approach would be to categorize assets into a handful of buckets (think 3-4) by their importance to the business. For argument’s sake we’ll call them: critical, important, and not so important. Then spend time looking through the assets and sorting them into those categories. You can use a quick and dirty method of defining relative value which I first proposed in the Pragmatic CSO. Ask a few simple questions of both yourself and business leadership about the assets…
- What does it cost us if this system goes down? This is the key question, and it’s very hard to get a precise answer, but try. Whether it’s lost revenue, or brand impact, or customer satisfaction, or whatever – push executives to really help you understand what happens to the business if that system is not available.
- Who uses this system? This is linked to the first question, but can yield different and interesting perspectives. If five people in Accounting use the system, that’s one thing. If every employee on the shop floor does, that’s another. And if every customer you have uses the system, that would be a much different thing. So a feel for the user community can give you an idea of the system’s criticality.
- How easy are the assets to replace? Of course, having a system fail is a bad thing, but how bad depends on replacement cost. If your CRM system goes down, you can go online to something like Salesforce.com and be up and running in an hour or two. Obviously that doesn’t include data migration, etc. But some systems are literally irreplaceable – or would require so much customization as to be effectively irreplaceable – and you need to know which are which.
Understand you will to need to abstract assets into something bigger. Your business leadership doesn’t have an opinion about server #3254 in the data center. But if you discuss things like the order management system or the logistics system, they’ll be able to help you figure out (or at least confirm) relative importance of assets. With answers to those questions, you should be able to dump each group of assets into an importance bucket.
The next step involves evaluating the ease of attacking these critical assets. We do this to understand the negative side of the equation – asset value to the business is the positive. If the asset has few security controls or resides in an area that is easy to get to (such as Internet-facing servers), the criticality of its issues increases. So when we prioritize efforts, we can factor in not just the value to the business, but also the likelihood of something bad happening if you don’t address an issue.
By the way, try to keep delusion our of this calculation. It’s no secret that some parts of your infrastructure receive a lot of attention and protection and some don’t. Be brutally honest about that, because it will enable you to focus on brittle areas as needed.
Like the asset side, focus on relative ease of attack and the associated threat models. You can use categories like: Swiss cheese, home safe, bank vault, and Fort Knox. And yes, we are joking about the category names.
You should be left with a basic understanding of your ‘risk’. But don’t confuse this idea of risk with an economic quantification, which is how most organizations define risk. Instead this understanding provides an idea of where to find the biggest steaming pile of security FAIL. This is helpful as you weigh the inflow of events, alerts, and change requests in terms of their importance to your organization.
And keep in mind that these mostly subjective assessments of value and ease of attack change – frequently. That’s why it’s so important to keep things simple. If you need to go back and revisit the priorities list every time you install a new server, the list won’t be useful for more than a day. So keep it high level, and plan to revisit these ratings every month or so.
At this point, we need to start thinking about operational metrics we can/should gather to guide operations based on outcomes important to your business. That’s the subject of our next post.
Reader interactions
6 Replies to “Fact-Based Network Security: Defining ‘Risk’”
It seems that most of this post and comments focus here on hazard risk instead of speculative risk. Hazard risk being the things we do to reduce the impact of something and receive no gain whereas speculative risk is the act of doing something that monitors or lows risk while obtaining gain.
IMHO, Fact-based security is about mitigating or monitoring the risks we need to in order to obtain X. (E.g, speculative risk management)
Therefore, I normally advise analyzing the risk of not just the assets (or services as Julia mentioned) or even the vulnerabilities as you describe, but also the risk of how these new facts impact “what’s important”.
For example, if the business goals are to increase net profit by 5%, how does the new data you have provided effect our ability to reach that goal? The fact-based security data can help swing the *RISK* of not achieving that goal to high from a low based on a variety of data as you mentioned.
Management doesn’t care about threats, vulnerabilities, or asset values. They care about one thing: How does this new data effect my ability to meet my goals. if you cannot define risk on those terms you are missing the entire point of security management.
Mike,
I agree with you that many times the BC/DR data sucks. They really have the same problem you are trying to solve here: how do I value assets? My point was that if you have reasonably sane BC data, you might use it. If not, the asset valuation resultant from your proposed excercise is of double value.
P.S. I think Insurance will be the big driver here more than anything else. As more people get cyber and business interuption insurance there will be more pressure to accurately quantify the risk (by the U/W’s) and to keep premium low (by the buyer)
Do you ever work with insurance folks to try to build a consolidated risk model?
@augusto, good point about adding a question relative to “what happens if this data is stolen?” That’s important and was an oversight. That’s why we do “open research,” to make sure we don’t forget stuff.
@julia, fully you should mention “services” as opposed to assets. In the Pragmatic CSO I call them “business systems,” and suggest that is the right way to approach it. The issue is one of brevity here. Adding another layer of abstraction on top of the value assessment just wouldn’t fit into this project. But all the same, your point is well taken and I’ll see if I can work some of that idea into the final version.
@ds, still not sure I like the “calculations” that most folks make for BC/DR and/or insurance purposes. That’s really a replacement cost plus some made up number to make the money work for either a BC/DR deal or an insurance policy. Yes, this is definitely a place to start, but I suspect true value to the business could be significantly different than the cost to recover or insure. Is your experience different?
And that’s a key point. We really do pay attention to the feedback provided on the blog posts. Before finalizing any of our research projects (basically taking the blog series and making it into a white paper), we factor in great comments like these and make the paper better. So much thanks to all of the commenters.
Mike.
Hi Mike: Julia Allen here with CMU CERT. While I realize your focus is network security (and operational metrics for same), I question the value of starting with assets. I recommend starting with services. To use your example, this would be the order management service or the logistics service. (These services, in turn, may support higher level services.) Assets would include not just the systems that support these services but also the people, information, and facilities. Determining which assets are highest priority to protect, sustain (continued operation in the presence of a security incident), and measure is based on those that support the highest-value services. Thoughts?
Mike,
I’m surprised you are not considering the value from a confidentiality perspective. I know the goal here is trying to keep it simple, but if we review some of the last big breaches we’ll notice that sometimes the source of the data obtained by the attackers is not necessarily a system that have many users or can cause big losses when going down. A good example is the SecurID seed database; it would come clear from the questions you proposed, but the cost from the breach was probably higher than, for example, their billing system, that would be seen as more important to the business.
I’m not sure if you’re going to address it in the following posts, but I think it was worth mentioning.
Something to consider is that, in some companies (mostly larger ones) things like cost of downtime, user community and replacement cost will be known by the disaster recovery/business continuity folks or perhaps may be recorded if your firm has business interuption insurance.
If you are in a smaller company or your folks don’t have this and you have to go dig this up, you can have a double win by using the output to strengthen both security and BC.