Making Sense of Risk Management in the IT Security Field: Risk Management and Security Series, Part II
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many security professionals and consulting firms comfort customers by saying that they do not support or sell their services based upon fear, uncertainty, or doubt (FUD). When we look at FUD, what are we really talking about?
Fear is based upon devastating events that can take place from an attack. Uncertainty is based upon the potential or probability that an attack would take place against a specific organization. Doubt is based upon the effectiveness of the organization's current security measures that are put in place to protect against a specific attack.
So basically you can have a fear that the sky may fall. You are uncertain if it will fall upon and squish you. You doubt that the current protection measures that you have protecting you from the sky falling will really help you. So what do you do? Buy something. Buy insurance, a product, or a consultant to direct you on how not to get squished by the falling sky. Are you really protected? Probably not, but you feel more safe so you can now go blissfully along with your day-in-and-day-out activities.
A better approach than selling FUD is selling services and/or products based on real and meaningful statistics and metrics. More formal and structured risk management models that are based upon security measurements are emerging, but they have not yet moved from the purely theoretical phase to the purely practical phase.
We are marching this way, slowly, but many of the consulting services and products in the market are not based upon formal risk management models. The key word here is formal. When we say that a model is formal, it can be proven (usually mathematically) and is repeatable.
Many of the risk management approaches today are not risk-based at all. Many consulting firms and products that are touted to provide risk management really just carry out vulnerability management. This means that they can identify a vulnerability and tell you how to fix it, but do not (or cannot) estimate the probability of a vulnerability being exploited and (more importantly) what the business impact pertaining to that exploitation will be. Vulnerability management works at the micro level, while risk management works at the macro level.
Most security professionals would really like to have an approach to security that is not based upon FUD. As many in the industry know, it is hard to convince an executive to spend money because something bad may happen and it may hurt the organization. Executives and other business-oriented people are used to releasing funds solely based upon sound financial numbers and business scenarios: not "ifs," "maybes," "coulds," and "should."
Most security professionals are left with FUD only because they are not armed with consistent security metrics that illustrate the effectiveness of different security solutions and the resulting ramifications of not implementing them. Where FUD keeps everyone in the dark, solid security metrics provides light to better see and understand the many complex components of information security risk management.
It is very difficult to show progress in management of anything without the ability to measure. A metric should have the points, the measurement, and the reference.
Okay, but a metric means nothing without an objective. You can have an objective to lose 30 pounds. To know how you are doing to meet this objective, you need to have a reference (what you weigh today) and a way to measure the progress of your activities toward that objective (weighing yourself on your scale daily).
At a very basic operational security metric view, you might have the objective of experiencing only two virus infections per year within your enterprise. You have a historical reference point: Your organization experienced eight virus infections last year. You have a way to measure the progress—recording the amount of virus infections you get this year. So this very simplistic metric is made up of a reference point (where we are today) and the way to measure progress (how are we doing) and an end objective (our goal).
What are we really trying to get out of this type of measurement? The effectiveness of a security solution put in place. So if you had eight virus infections last year and your goal is to experience only two or fewer infections in the next 12 months something has to change: You are going to implement a security solution.
Let's say your organization already has antivirus software on all the systems in the network, but even with that you still experienced eight virus infections last year. Now you put in an antivirus solution on your mail server and you need to find out how effective that product is against the threat of virus infiltration. Over the next 12 months, you keep track and your organization has not experienced any virus infections. This solution would be seen as a successful countermeasure against this specific threat.
The previous example is a simplistic operational metric example. It is critical to define meaningful metrics for both an operational and strategic point of view. Operational metrics means "how are we doing down in the weeds?" Strategic metrics means "how are we doing at a business level?" Setting the objectives per metric and overseeing the progress of the processes necessary to obtain the set objectives is in a nutshell what security governance is.
So the entities carrying out security governance in an organization (CSO, CISO) draw the lines in the sand and state "we will meet these objectives in our security efforts". These entities responsible for governance need to be continually updated in how the organizational efforts are moving along to meet the set objectives. How can this information be communicated to the security governance entities without meaningful metrics?
If security metrics are created properly, they should be the language that is used when discussing security within your organization. What is unfortunate is that the industry does and does not have standard metrics that can be used. The industry does have high-level models that contain their own incorporated metrics; CobiT, NIST, and ISO 27000. We have some other models that can also be used to derive metrics from: CMMI, COSO, ITIL, Prince2, and Six Sigma. So the industry does have sets of metrics that can be used, but the industry does not have one set standard of metrics to be used by everyone.
With the lack of security metric standards and the overwhelming amount of items that need to be measured, most security professionals revert to using risk ratings and/or color coding identified risks (red, yellow, green) and call it a day.
I believe that it takes a certain type of person to be able to develop useful security metrics for an organization. This person needs to have one foot in the technical side of security and one foot in the business side of security. This person must be able to understand the detail-oriented level of security, but not get stuck in the weeds. This person needs to understand the company drivers of an organization and understand that most companies are not about technology or being secure—they are in business to make money. This person needs to be able to think "outside the box," but also must know what is inside the box in the first place.
Someone who is going to develop security metrics for an organization should understand what we mean when we say "holistic security." You should not just measure what is there but also be able to identify what is not there that should be.
This may sound intimidating, and you may be saying "I am not that person," but you could be if you set out the course to develop security metrics that would be directly beneficial to your organization. If you put in this time and effort, not only would you hone your skills as a security professional; you could also help tame that thing we call "information security" within your own company.
Please stay tuned for Part III!
For more information visit http://www.logicalsecurity.com.