Fact-Based Network Security: Defining ‘Risk’
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. Share:
