The concept of a risk assessment framework, let alone a risk assessment itself, might seem beyond the requirements of a midmarket company. But the concept of evaluating risk is at the heart of IT security for companies of any size. And any midmarket organization interested in protecting its information assets -- which today is every company -- needs to have some sort of risk assessment, even if it's just a bare-bones framework molded and distilled down for a small staff.
The good news is that risk assessment frameworks are free. They can be easily downloaded from the Web, printed and studied at will. Though they might appear like cryptic documents that need an army of consultants to implement, that isn't necessarily the case. There are some best practices any midmarket company can employ to strip down even the most complicated framework into usable bite-size chunks for its organization.
The goal of a risk assessment is to prioritize the IT security risks of the various pieces of your IT infrastructure. Without prioritizing risks, an organization can't effectively budget for controls against its greatest risks. It ends up either spending too much on excessive or unnecessary controls or, at the other extreme, leaving systems exposed to malicious attacks. And for cash-strapped midmarket companies, it's all about the budget, especially when it comes to security systems that can seem either expensive or esoteric to management.
In addition, by prioritizing risks, a company can determine which of its systems are at low risk of abuse or attack, avoiding security overkill, and those that are at high risk, which need greater protection. There are several risk assessment frameworks, but the industry benchmark is from the National Institute of Standards (NIST).
A key publication from NIST, "Special Publication 800-100, Information Security Handbook: A Guide for Managers," identifies four steps in the risk assessment process. The following is a simplified risk assessment process for a midmarket company based roughly on SP 800-100.
Know thyself
The first step is to inventory and categorize all IT assets. The second step is to identify threats, and the third is to identify corresponding vulnerabilities. The last step is the actual risk analysis, which includes evaluating security controls on IT assets, determining the likelihood and impact of a breach, and then finally assigning a risk level. After the assessment is complete, a report with recommended controls should be assembled. Risk assessment should be thought of as a cyclical process of periodic review and implementation that should be repeated on a regular basis.
The inventory of IT assets defines the scope of the risk assessment. Before a company can implement security controls, it has to know what assets it already has and their existing controls, if any. The inventory should include a list of all hardware, software, data, processes and interfaces to external systems.
The next step is to identify threats. These can include physical threats, such as natural disasters or power outages, but it should also include, of course, IT security threats, such as malicious access to systems or malware attacks. Be creative. Think of the most likely threats to your systems, both from your experience as well as from published lists of attacks from security bulletins, like the US Computer Emergency Response Team (US-CERT) at Carnegie Mellon.
But threats don't exist in isolation. They are only threats if there are vulnerabilities in the system, which is the third step of the assessment process. Here, again, NIST can be a valuable resource. Its National Vulnerability Database (NVD) is a catalog of current threats and an archive of old ones. Besides the NVD, check the websites of hardware and software vendors for lists of vulnerabilities. Other sources, such as hacking bulletin boards, are also a good reference for vulnerabilities.
Vulnerabilities can also be obtained from security testing and scanning of systems, including vulnerability and penetration testing.
After all this data is gathered, the last step is the actual risk analysis. This consists of three subphases: evaluating existing security controls, determining the likelihood and impact of a breach based on those controls, and the assignment of a risk level. The likelihood and impact of a breach can each be categorized into high, medium and low. Each risk level can be assigned a score, such as from one to 10, and then be assembled into a 3-by- 3 matrix with impact running across the bottom and likelihood running vertically up one side.
The subsequent risk scores should be part of a final report that details what, if any, security controls should be implemented to bring the risk levels down to low, or to a level of risk the organization is willing to tolerate and accept. It can also be used to justify the cost of a security measure, especially if the risk is high. A high risk, for example, is a red flag of a potential breach and the need for the immediate implementation of a security control.
 |
|
|
|
|
Before a company can implement security controls, it has to know what assets it already has and
their existing controls, if any.
|
|
|
|
|
|
|
|
|
|
Though this scaled-down risk assessment process was based on NIST, other frameworks go through a similar exercise of identifying assets, threats and vulnerabilities and then assigning a risk based on the data gathered. Other frameworks include OCTAVE, or Operationally Critical Threat, Asset, and Vulnerability Evaluation from CERT, and COBIT, or Control Objectives for Information and related Technology from the Information Systems Audit and Control Association.
Whatever framework you choose, a risk assessment might still seem like a big project for a midmarket company. It can drain staff and take time, both of which can be in short supply. But conducting risk assessments isn't a full-time job at a smaller company. They can be handled by one of your IT staff on a regular basis, say, annually or whenever there is a major system change, such as during an acquisition or a major new IT installation.
The other way to save time in doing risk assessments is to limit the scope. Many midmarket companies, for example, aren't doing application development in-house. This is one less thing to review. Stick to the items of concern to most midmarket companies -- access management, network security, physical security and website security -- for the bread and butter of your review.
The evaluation of risk is essential to any information security program. These steps should help simplify the process for any midmarket company.
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP specializing in Web and application security, and is the author of The Little Black Book of Computer Security, Second Edition, available from Amazon.com. He has a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at www.theitsecurityguy.com.
