Information security risk assessments are a fundamental building block of any security program, much like security...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
awareness training, policies, procedures, and technical safeguards. A risk assessment program is required by several regulations such as HIPAA, SOX, and FISMA. Risk assessment is also an essential element of all security standard bodies of generally accepted security practices such as ISO, COBIT, and NIST.
Ideally, an effective risk assessment program should ensure necessary security controls are in place or put in place based on the information risks or threats that an organization faces. The risk assessment process should identify and prioritize any gaps found. In other words, an effective risk assessment program should drive an organization’s security initiatives and its program.
However, security risks assessments are subjective exercises. Risk assessments can be inadvertently and advertently skewed based on interpretations and result in not implementing necessary security controls. Reluctance to spend money, perform unplanned activities or change user experience are other factors that can affect risk assessment results. We’ll take a look at these challenges and ways to overcome them in order to improve the risk assessment process.
METHODOLOGY DOESN’T OFFSET SUBJECTIVITY
Most risk assessment processes used today range from informal processes to more rigorous assessment methodologies such as NIST, COSO/COBIT, or OCTAVE. Most organizations rely on a qualitative assessment methodology; some companies include quantitative methods in the assessments. Regardless of the methodology used, all risk assessments are fundamentally subjective exercises. Its results are dependent on interpretation of threat level, probability of occurrence, impact, valuation of assets, etc. Therefore, risk assessments are susceptible to be skewed, unconsciously or consciously, to a pre-determined outcome.
Other factors affect the subjectivity of a risk assessment. These factors include the subject matter expertise of the assessor(s). Often, risk assessments are performed by people who do not possess the necessary security knowledge, or may not fully understand the security and privacy risks. Professional motivation also affects one’s subjectivity; business units want to minimize costs while a security governance team wants to minimize risks.
Who assumes the risk is critical to maintaining a consistent risk posture across the enterprise. Ultimately the business needs to make the call on clearly defined risks, but the question is who?
A project manager, a director, a VP, an EVP, the CFO, and the CEO all have a different view of risk and a different risk acceptance tolerance based on knowledge and experience. Unless there is an accepted “risk assumption” model or procedure that defines who can assume risks and at what levels, the structure for a viable and effective risk assessment process is missing. A project manager has a very different risk tolerance than a CEO. A project manager is judged on delivery time and budget and may view security controls as obstacles, while the CEO is focused on the reputational risk of the enterprise. Even the CFO and the CEO can have a different tolerance level of enterprise risk. There needs to be dialogue at the highest level of the organization to define what the risk tolerance of the organization is. Having a risk assumption model that includes the CEO will help crystallize the discussion around risks.
Another essential foundational element every organization should have is a repository of common threats, risks, and a common lexicon for explaining vulnerabilities and mitigating controls. Without a risk escalation process that identifies who can ultimately assume risks and a common lexicon for security risks, it’s difficult to have an effective enterprise risk assessment process.
There are several other factors that drive an organization to skew the outcome of a risk assessment and, at times, use it to rationalize not implementing the necessary security controls. These include:
- Cost, especially unbudgeted costs. Regardless, business and even IT units do not want to spend money on security controls unless they are absolutely necessary and usually tied to regulatory compliance or an audit citation. The business unit will minimize the privacy or security risk to avoid spending the money. Let’s face it, security controls cost money and take time to implement; they are a hard sell.
- Unplanned activity, especially if it is part of a system development effort or project with a tight deadline. Any unplanned activity, whether it is part of a project or part of a yearly operating plan, will generate, at minimum, tension or push back. Project teams and management in general are inherently averse to doing any tasks they did not plan for. It may affect project deadlines or the completion of operating plans that they get judged on and therefore may impact their performance rating, raise, and bonus.
- Miscommunication: Many times, security managers communicate in terms of missing control risks or a policy non-compliance risk, not in terms of the business or organizational risk. As a result, it’s hard to achieve consensus to mitigate the risk(s), regardless of what control should be implemented.
- User or customer impact: Any security control that changes the user experience will create resistance. Even if it’s as benign as increasing the length of passwords, it creates anxieties for business managers. Therefore, they will likely overstate implementation costs and try to delay implementation.
- Overestimating the costs of security controls. Sometimes the business or IT unit is uncertain about the implementation cost, and will overestimate the cost of the security control.
- Improperly relying on mitigating controls that do not effectively address the risk. A good example might be to rely on a manual review of system event logs instead of implementing an event monitoring system.
- Last but not least, many organizations do not understand most security controls are necessary. The vast majority of the controls outlined in the generally accepted security standards bodies, (e.g. COBIT, ISO, etc) are required and need to exist in some shape or form in every organization that has an IT infrastructure, even if it is outsourced.
RISK ASSESSMENT TOOLS
There are many automated risk assessments tools and solutions in the marketplace; some are more sophisticated than others. Some are basic risk assessment documentation templates, while others are robust risk assessment knowledge systems with workflow and dashboard features to rollout and maintain an efficient organization-wide risk assessment program. There is no on-size-fits-all with risk assessment tools; different tools may work better for your industry or particular needs. The key success factor/feature should be how comfortable you are that the proper risks are being captured and addressed. Tools can help standardize the risk assessment process enterprise wide, maintain a risk repository, and help an organization harden or strengthen their risk assessment posture and program overall.
While worthwhile and necessary for large organizations, automated tools are still susceptible to problems and challenges outlined above. That’s because ultimately they rely on people’s input and judgment.
STEPS FOR IMPROVEMENT
First and foremost, there needs to be a paradigm mind shift in the enterprise that accepts the notion that most security controls are a necessary cost of doing business. The risk assessment process should include mitigating controls based upon generally accepted security control standards, such ISO, COBIT, and NIST. The risk assessment should not focus on whether a particular baseline control should exist, but rather whether the security controls as implemented sufficiently address the risks of the organization. Also, security standards typically lag new technology risks (e.g. SOA-based applications, cloud computing, iPads and other mobile devices). In those situations, new security controls and techniques may be required based on the security and privacy risks.
In addition, the risk assessment process should not be viewed as a compliance exercise; it should not be a process to demonstrate regulatory compliance or adherence to good security practices, as is often the case. A good risk assessment program should be the primary process that drives security initiatives, based on sound risk assessment analysis that’s grounded on generally accepted necessary safeguards/controls (e.g. ISO) and new technology and/or business IT risks.
Finally, security organizations need to strengthen their risk assessment capabilities, specifically in terms of people, processes, and technology. They need people with the necessary communication skills, security knowledge, and most importantly, the analytical skills to identify business and technologies risks, potential mitigating controls, and mitigation strategies when gaps exists. Security managers need to speak in business risk terms, not control risk terms.
The risk assessment process needs to include a formal risk assumption model that defines who can assume risk to ensure the enterprise maintains its desired risk level posture. Last, organizations should have a common risk assessment methodology implemented, a risk universe and results repository, and the necessary technology or system to implement and sustain an effective risk assessment program.
An effective risk assessment program is one of the fundamental building blocks of any information security program. The ability to understand your risks, mitigating controls and what your companies risk tolerance/assumption posture will define your information program and how well you are prepared to meet today’s risks/threats.
Craig Shumard is retired CISO for CIGNA Corp. Serge Beaulieu CISSP CISM, is a security consultant and retired head of Security Technology Planning & Roadmaps at CIGNA. Send comments on this article to firstname.lastname@example.org.