The Need for Risk Assessment
The first step in taking any preventative security action should be a risk assessment. Before designing and enacting policy, and before selecting and implementing technical security measures, you should always ensure you have a reasonable picture of the risks your sensitive resources face.
Each part of your IT infrastructure should be assessed for its risk profile, and from that assessment you should be able to effectively and efficiently allocate your time and money toward achieving the most appropriate and best employed overall security policies. The process of performing such a risk assessment can be quite complex, and should take into account secondary and tertiary effects of your actions (or inaction) when deciding how to address security for your various IT resources.
An in-depth risk assessment, adjusted for the best reasonable precision and accuracy, requires a wide range of areas of expertise and can prove quite time-consuming and expensive, particularly for large organizations. Luckily, it is sometimes the case that such an in-depth risk assessment is not strictly necessary. Depending on the size and complexity of your organization's IT resources, and your budget, it may become clear that what is needed is not so much a thorough and itemized assessment of precise values and risks, but a general prioritization.
Each organization is different, however, and as a result the decision of what kind of risk assessment should be performed depends largely on your specific organization. If you have determined that all your organization needs at this time is that general prioritization, you can take a simplified approach to risk assessment -- and, even if you've already determined that a more in-depth assessment must be completed, the simplified approach can be a helpful first step to generate an overview to guide decision making in pursuit of that more in-depth assessment.
If you simply are not sure what kind of assessment your organization requires, a simplified assessment can actually help you sort that out. If you find that there just isn't any way to produce accurate results in the process of completing a simplified assessment -- perhaps because you find that this process does not take into account a fine-grained enough set of assessment factors -- that alone can be helpful in determining the type of assessment you actually need.
The Simplified Assessment
The most simplified form a risk assessment can take while still yielding the necessary information to prioritize and plan security policy development involves the measure of two factors in assessing a given risk. Each risk should be assigned a value for each of these two factors, and these two factors for each risk should then be compared to produce a general risk level that can be used to prioritize risks.
- The first step toward that end is to enumerate significant risks. For instance, if your organization stores credit card information on customers, unauthorized access to that stored data may be determined to be a single risk item; man in the middle attacks that can intercept that data may be another. Each of these risks should be assessed according to the two primary risk factors, as should any other risks enumerated in this first step.
- The next step is to measure the first risk factor; determine the probability of each risk being realized. Risk realization may involve, for instance, an SQL injection exploit being used to access credit card data in your database. Broadly speaking, this probability can be assigned to three basic levels of likelihood -- High, Medium, and Low probability. In general terms:
- High probability should suggest that the risk may well be realized tomorrow, or perhaps within the next month or so. In other words, high probability risks are those that will be realized; it is just a matter of time.
- Medium probability should suggest that the risk may or may not be realized within the next year, but left untended long enough the risk will almost certainly be realized eventually, though the chance of risk realization within the near future is small.
- Low probability should suggest that the risk does exist, but may never be realized.
- The third step is to measure the second risk factor; determine the impact of risk realization -- the damage that a risk being realized may cause to your organization and to those whose security is, to some extent, within the care of your organization. There are those who would suggest that the impact on third parties (such as customers who have entrusted you with their credit card numbers) should only be considered insofar as it might affect the impact on your own organization through lawsuit and loss of revenue, but the ethical approach is to treat the security of others as though it were your own security. Measuring the impact in a complex, in-depth assessment likely involves a lot of number crunching, but in a simplified assessment it requires only general categorization. I recommend four general categories:
- Disastrous -- the sort of impact that may destroy or cripple your organization.
- Major -- the sort of impact that can cause stock values to plummet, affect the organization's reputation in the long term, and lead to lawsuits at a level that may not cripple or destroy the organization but may lead to lay-offs and a shake-up in management without crippling or destroying the organization as a whole.
- Moderate -- the sort of impact that can damage revenue streams, lead to expensive recovery proceedings, and cause short- or medium-term damage to the organization's reputation in the market.
- Minor -- the sort of impact that interferes with the effectiveness and efficiency of normal operations, leads to internal lack of confidence in the security and reliability of systems and data, and tends to look bad on your quarterly review if it is within your area of responsibility.
Each higher level of impact of course assumes the lower levels as well -- and if a breach that has minor impact may look bad on your next employee review, a major impact is likely to result in being out of a job, while a disastrous impact may even result in court action, depending on the organization and circumstances.
Applying Risk Factor Measurements
Each of these two factors, once measured, must be used to determine the prioritization of security concerns. While a disastrous impact may seem like it should be your first priority, a low probability of risk realization should put it solidly behind a major impact with high probability of risk realization in your list of priorities.
By combining these factors, general categories of final risk priority can be established:
- Extreme Risk
- Disastrous + High
- Disastrous + Medium
- Major + High
- Significant Risk
- Disastrous + Low
- Major + Medium
- Major + Low
- Moderate + High
- Moderate + Medium
- Minor + High
- Minimal Risk
- Moderate + Low
- Minor + Medium
- Minor + Low
As I already mentioned, each organization is unique, and some of my final risk prioritization categories may not line up exactly with your organization's needs. If you shift factor combinations between these categories of risk priority, however, make sure you have a good reason to do so. Shifting an item down a category should be much more difficult to justify than shifting it up a category, but even shifting it up a category should be weighed against the importance of other priorities with which it may compete.
The Importance of Risk Assessment
Ultimately, risk assessments are an indispensable part of prioritizing security concerns with measurably appropriate care. Performing such assessments informally might be a valuable addition to your security issue tracking process, and formal assessments are of critical importance when determining time and budget allocations in large organizations.
By contrast, taking a haphazard approach to security concern prioritization can lead to disaster, particularly if a problem that falls into the Extreme risk category described above ends up neglected. Even a simplified risk assessment process like this one can protect you against such failures.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.