Prioritizing Security Assessments in 20 Minutes or Less!

Overview
Imagine you’re the CSO of some organization, or work for the CSO of your organization and you’ve been asked to come up with a prioritized list of systems/applications that need to be assessed this year and justify why need to be assessed. How do you start? Let me show you.


Your first thoughts might be consulting firms. Couldn’t they help prioritize security assessments? Consulting companies certainly can (they can do anything when the price is right: conduct a full inside and out regulatory compliance check of your IT operations, mow the lawn, paint the side of the building …), but there are several reasons why creating the prioritization yourself is better. First consultants by definition are “outsiders” to your company and won’t have the same understanding and appreciation of systems/applications/data or their criticality and interdependencies as you will. Second, even if consultants could build up that knowledge about your company (unless you don’t mind) it would be on your dime and you would essentially be paying them to learn about your company instead of helping your company. Finally, most vendors will place the assessment projects that will result in the most potential hours for them at the front of the “priority listing” which often helps their bottom line (revenue) and if you’re lucky maybe even yours (reducing critical risks to your business).

So now that using consultants are out the door, what about using tools and surveys to come up with a prioritization? These can definitely help, but here are reasons why they may not be for you:

• Threat Modeling Tools. Threat modeling helps you understand threats to a system and the prioritization of those threats. You could reasonably base your assessment prioritization on the systems/applications/data that yield the most high risks and threats, but in order to do so you need to have someone who understands the threat modeling process to create the models (more consulting hours) and you need to invest significant time to complete the threat models (even more consulting hours) for every system/application in order to make that prioritization. If you’ve got budget/time/inclination, by all means go the expensive threat modeling services route, but if you don’t read on!



• Surveys. Most surveys work by asking questions along the lines of “does this risk/threat/hazard apply to you?” In other words you’re basically being asked “is this a bad thing for you” and you need to answer yes or no. Each “bad thing” is given a weight, and at the end if the survey all the “bad things” are tallied up and the system/application with the greatest weight is given the highest priority. The one with the second highest weight is given second priority, so on and so on. One problem. You're trying to quantify the bad and I talk about the perils of doing this in my blog about Input Validation.

Now we’re left the best, I think, prioritization system of them all: you. In this article, I’ll show you my own technique that you can use to quickly and systematically determine the priority of security assessments based simply on what you know about your organization (business objectives, processes, data, etc.) not the unknowns (threats, vulnerabilities) and with little to no in-depth security expertise required.

Prioritizing Security Assessments
Our objective is to be able to come up with a prioritized list of security assessments to conduct (what), show how they align closely with the prioritization of overall business objectives (why) and easily explain to the person you’re asking budget from how you came to that list.
This method takes only known data about your organization and utilizes the following to prioritize security assessments:

• Explicit Dependencies. Aspects of your organization that without them your organization does not function at all – caput, nada, lights out, etc.
  


• Implicit Dependencies. Aspects of your organization that without them your organization still continues, but is degraded in some way.

While it sounds super complex and one beast of a method to execute it’s really not. To get started, all we need to do is start enumerating the following:

• Your organization’s business objectives


• Applications and Systems


• Data and Information
  

Step 1 (Minute 0-5): Enumerate Your Business Objectives
In this step simply write down your organization’s business objectives. Your organization will probably have multiple ones like increase revenue through direct sales, become industry leader, etc. Doesn’t matter, just write them down.

Next, rank those business objectives as high, medium and low. It’s up to you to determine what constitutes high, medium or low in the context of your organization (since you know it the best). Some of my customers like to rank business objectives in terms of the amount of revenue that objective represents to the organization but that might not fit your scenario. Here’s the standard ranking that I like to use:

• HIGH – Business objectives that are critical to your organization.


• MEDIUM – Business objectives that are important to your organization.


• LOW – Business objectives that are minimally important in the context of your organization.
  

Step 2 (Minutes 5-10): Enumerate Systems and Applications (Explicit Dependencies)
After you’ve written down your business objectives and ranked them, write down the systems and applications that fulfill those business objectives. These are what I call explicit dependencies because without these systems and applications your organization stops. For instance, if one of your objectives was to increase direct online sales, an application or system that might fulfill that objective is your procurement web application or database to track sales and collects payments.

As we did in that last step, rank the processes, systems and applications. Again, you can decide what each system and application gets categorized as, but be sure to keep the same high, medium and low categories.

• HIGH – Explicit dependencies that are critical to the business objective they fulfill.


• MEDIUM – Explicit dependencies that are important to the business objective they fulfill.


• LOW – Explicit dependencies that are minimally important to the business objective they fulfill.
  

Step 3 (Minutes 10-15): Enumerate Data (Implicit Dependencies)
After you’ve finished with systems and applications, now write down the data used by those systems and applications that fulfill the business objectives that you noted in Step 1. These are what I call implicit dependencies because in the absence of them your business still runs, but maybe in a degraded state. It can be data your business generates (accounting records for instance) or data that is given to your business (credit cards for instance). Any data your organization uses, creates or reads in. You get the idea.

Now rank the data. Again, it is up to you how you classify what constitutes HIGH, MEDIUM and LOW. I like to use this ranking system:

• HIGH – Implicit dependencies that are critical to the explicit dependency that uses it. Sometimes referred to as high business impacta (HBI) data.


• MEDIUM – Implicit dependencies that are important to the explicit dependency that uses it. Sometimes referred to as medium business impacta (MBI) data.


• LOW – Explicit dependencies that are minimally important to the explicit dependency that uses it. Sometimes referred to as low business impacta (LBI) data.
  

Step 4 (Minutes 15-20): Making Sense of it All, Prioritizing Your Security Assessments
The final step now is to tie all that data together and come out with a security assessment prioritization. First step is to take your business objective rankings and order them according to rank. So you should have a HIGH bucket, MEDIUM bucket and a LOW bucket.

Now for each bucket, write down the systems/applications (explicit dependencies) that fulfill that business objective. If you have an explicit dependency that fulfills more than one business objective, err on the side of caution and write it down in the bucket with the highest rank. For instance, if you have an application that fulfills both a HIGH business objective and a MEDIUM business objective, then you want to write it down in the HIGH business objective bucket. At this point you have a set of systems/applications that need to be assessed first (the HIGH bucket), second (the MEDIUM bucket) and last (the LOW bucket).

But what about prioritization within buckets? For instance you know that that all the systems/applications in the HIGH bucket need to be reviewed before the MEDIUM bucket, but in what order do you need to review the systems/applications in the HIGH bucket? To do that you can use the following chart:




To use this chart, look at the ranking of the explicit dependency and then take the highest ranking of the implicit dependency (your application may use multiple pieces of data all ranked differently) to determine the assessment priority within the business objective bucket. So for instance, say you had a HIGH business objective, and in it you had two explicit dependencies. One ranked HIGH (Application X) and another ranked MEDIUM (Application Y). Say the highest implicit dependency that Application X uses is LOW, so if you look at ROW 1, COLUMN 3 you'll see that it has a PRIORITY 1 rating. Also say that Application Y's highest implicit dependency rates at MEDIUM as well, then by our chart (ROW 2, COLUMN 2) this application has a PRIORITY 2 rating. So our prioritization looks like this:

"For our high business objectives, Application X should be assessed before Application Y ..."

That’s it! You now have a security assessment prioritization that closely aligns to the prioritization of your organization’s business objectives. So now when you go back to your boss, you can say “here’s a prioritized security assessment for this fiscal year, here’s how they align to our organization’s business objects and here’s why I need the $(some out of this world budget number) budget to pay Impacta LLC to do those assessments for us :P”.

Making This Method Work for You
You’ll notice that my method is biased towards systems and applications than it is towards data. Does this mean that the data (say social security numbers) is less important than systems and applications? Not at all, the chart above just works well for organizations where availability is more important (think about organizations like eBay, Amazon, MSN, UPS etc.). Now if confidentiality and integrity is more important and the data is king in your line of business (perhaps you’re Experian, TransUnion, or the US Social Security Administration office, etc.) just switches data for the explicit dependencies, and systems/applications to implicit dependencies.

Conclusion
In this article I showed you an easy way to create a prioritized listing of security assessments to do based on known and well-understood information about your organization. The resulting prioritization was closely aligned to business objectives and allows you to easily justify and explain how you came to that prioritization. The advantage about this method is that it’s lets you (the real expert of your organization) make the call on what is important and what’s not important, but now in a systematic, consistent and standard way.

Next steps are to actually conduct the security assessments and another advantage of the method we just discussed is that most of the data we collected here is the data needed to easily lead into most security assessments. So not only are we not re-inventing the wheel, we’re also streamlining our overall security assessment efforts.

In a later post, I’ll talk about the differences between common security assessment techniques such as penetration tests (rarely, but sometimes referred to as “ethical hacking”), vulnerability scanning and audits.

Notes From the Author
Feel free to let me know how this method worked for you either by leaving a comment with this article or at ContactUs@impactalabs.com. Hey, who knows … with enough interest, maybe I’ll publish a tool that automates this process for you. Enjoy!