Building an Enterprise Risk Management Program

A robust Risk Management program is the hallmark of mature information security

In this post, I outlined some high level steps to begin an Enterprise Information Security Program. Once you have established policies and implemented the basic steps of an Information Security program, the next phase is to develop its capabilities and further align the effort with business objectives. The sign of a mature Information Security program is the integration of Risk Management. Where policies are the essential foundation of the program, risk management is the rudder that steers the ship. Policies, procedures, guidelines, and baselines provide the building blocks of the security program's direction where implementation of Risk Management identifies the impact to the organization if security controls fail.  

 

First let's define risk. It is common in the information security community to interchange the words risk and threat. These are in fact two different things. An example is that you buy a lock for your door to prevent the threat of someone just walking into your home. While the risk of someone walking into your home is much lower in remote areas verse urban areas due to differences in population density. So people are often more likely to leave their doors unlocked in remote areas because while the threats are the same, the likelihood of occurrence is much lower. A more formal definition of risk is the "probable frequency and probable magnitude of future loss of confidentiality, integrity, availability, or accountability."

 

So while building your security program you've identified all of your information resources and established patch and vulnerability management policies. Upon your initial scans you've discovered 230 vulnerabilities and 125 missing patches. With your limited resources how do you decide what to patch first? What do you do if a critical vulnerability is discovered on a system that cannot be patched for business reasons? How do you decide if an expensive security control should be implemented? These are the kinds of questions a developed risk management program can answer by providing measurable business context.  

 

As with building a security program in general, the number one advice I can offer is to start small. Out of the gate do not try to building complex qualitative risk models that will bogged down in a quagmire of mathematical models that your organization most likely does not have the necessary historical data to build in the first place. Do not try to apply a risk category to every single component of your information system environment on day one. Refrain from attempting to identify every single risk scenario before you've identified all of the critical risks. Do not attempt to achieve a "perfect" environment early on. Quick demonstrable wins and early successes will lead to a Risk Management program that has real, positive impact.  

 

One of the initial tasks in building an Information security program was to build an inventory of information assets. This is a key step in establishing a Risk Management Program as well. Risk Management requires an extra degree of detail in order to establish an accurate risk profile. Risk management requires knowledge that includes regulatory compliance details, housing of any personally identifiable information, credit card processing, etc. The process of discovering all of these types of details is known as risk profiling. This information can be gathered via interviewing or having the resource owner complete a questionnaire. The resource owners provide the details but the risk manager is assigned the task of assigning the overall sensitivity of the resource.  

 

The answers are fed into a predefined sensitivity scale that will assign low-medium-high sensitivity ratings. The risk sensitivity scales provide context so that risk evaluators are able to readily understand what makes one resource more sensitive than another. An official scale provides a universal metric across the enterprise that everyone understands is the standard.  

 

Your questionnaires have been completed and you have defined what it means to have a sensitivity of low, medium, and high. Now you can begin creating a security profile of your information system resources. Here is where to apply the approach of making these initial stages as easy as possible. Start by profiling large chunks of the environment and then gradually increasing focus. If your environment consists of multiple datacenters, provide a profile by datacenter. If you outsource aspects of your information system, profile that environment vs what is locally managed. Provide a profile of a DMZ compared to internal environment. Whatever makes sense for your environment, create chunks of resources to provide a sensitivity rating to and gradually narrow your focus.  

 

Now that you've got your security profiles and have defined your most critical/sensitive assets, you can begin to leverage your vulnerability management processes that were put in place when building your security program. The vulnerability management  process will assign a weight to each vulnerability that is based on each assets sensitivity. Optimally your policy will outline things like the amount of time to remediate vulnerabilities based on sensitivity, processes to accept risks in instances they cannot be fixed, and processes to validate vulnerability fixes.  

 

An effective risk management program permeates throughout the organization. Risk liaisons are placed in each department to evaluate if their initiatives have adverse impacts to the overall risk of the organization. Risks are mapped to business objectives. Information security is represented at the enterprise risk committee in reporting to senior management risks to be prioritized along with other organizational risk. Having the risk program at the executive level enables the program to be aligned to business objectives providing focus in support of the mission.