How is the level of risk acceptance limited
Show
This article details the prevalence of risk acceptance within organizations, why IT security departments may be putting too much confidence in their controls, and how excessive risk acceptance is often cultural.Originally published in the April 2018 issue of the ISSA Journal Risk management is a basic and fundamental principle in information security. Techniques related to handling risks typically include avoidance, transference, mitigation, or acceptance, with many information security risks being addressed by the latter two. Given the frequency and types of attacks organizations are handling, are security practitioners accepting more risk than they realize? Or worse, are they accepting too much risk to in order to simply meet a compliance requirement or avoid a failing report? This article details the prevalence of risk acceptance within organizations, why IT security departments may be putting too much confidence in their controls, and how excessive risk acceptance is often cultural. Risk management is a part of many industries. The entire insurance industry is built on risk management; however, there are many relevant examples in other verticals, such as the following:
In each of the examples, companies have to accept a certain amount of risk. However, by accepting too much risk the company may be in jeopardy of staying in business. In 2011, floods in Thailand affected many technology companies who required a steady supply of hard drives. Many technology manufacturers had multiple suppliers, but many of the primary plants for suppliers were located in one country, Thailand. The result was that primary, secondary, and if they even existed tertiary suppliers all had supply issues. Companies such as Western Digital had a sharp decline in production to end the year, and there was a lot of uncertainty, which could be seen in quarterly filings and comments.1 The shortage affected business operations for many technology companies, but the shortage was not catastrophic to the business. Unfortunately, this isn’t always the case, as can be seen in the second and third examples. In 2009 and 2010, nearly 300 banks failed.2 The cause was generally due to excessive risk taking and non-performing loans during the 2008 financial crisis. Finally, in the automotive example, Takata, until recently one of the world’s largest automotive safety suppliers, filed for bankruptcy after their airbags were found to have caused deaths and injuries. The root cause of the problem was degradation of a key chemical used in their airbag inflators when it was subject to certain environmental conditions and time.3 It was Takata’s responsibility to test their product and ensure it met the required safety standards in a variety of conditions for an extended time frame, a risk potentially overlooked, or possibly accepted, when the company decided to use certain products as a propellant. Information security risk frameworks and toolsThe three examples provided are different than what information security teams address, but the approach to understanding and handling the risk is similar. When addressing a risk within information security, the equivalent question may simply boil down to what is the probability of a breach? Mature organizations may go further and consider what is the likely cost of a breach. However, while vendors and organizations such as the Ponemon Institute publish annual studies on the cost of a breach, very rarely is this cost quantified by an individual organization. Frameworks and assigning controls
To better understand the various risks a company faces, categories of risk can be used such as financial risk (e.g., loss of revenue) and reputational risk (e.g., brand image in the media). Additionally, there are controls that can be applied to address the risk. Organizations can use high-level categories such as preventative, detective, and corrective controls or get more granular with something like the Center for Internet Security (CIS) Top 20 Controls.7 Finally, it is commonly said that controls can be implemented with people, processes, and technologies. Lack of implementation The cost of not implementing controlsOrganizations have limited resources, in particular time and money, and firms need to use them wisely. While reports from Gartner9 and others research firms forecast increased yearly security spending, within an organization security enhancements may fall behind other initiatives, especially when the improvement requires time from a development team. For example, a feature request from a large client may take higher priority than a security improvement to a web service used by a subset of clients. To take the software development example a step further, one only needs to look at the cost of software defect. It is well known that the cost of a software bug is dramatically less if it is found early in the development life cycle, such as in the requirements gathering or initial design phases, as compared to identifying the issue in production. Security improvements, when possible, should be fixed early in the life cycle as well. The longer they exist, the higher the cost will likely be to fix them later. There is also a hidden cost of not prioritizing security improvements: if they are not addressed today, they may never get implemented. This may also lead to a long-term tendency to downplay other security enhancements. Having a culture of risk acceptanceThere are organizations that have great defense-in-depth strategies, have the latest security technologies in place, or possess the some of the smartest minds in information security. However, many organizations do not have the resources to have all three and even if they do there are going to be some risks that have to be accepted. Risk acceptance is needed in practice, as organizations can neither afford, nor should, be spending their limited resources on trivial risks. Additionally, many of the most prevalent compliance frameworks take into consideration compensating controls and mitigating factors when assessing risk. There is a tendency to being comfortable accepting small amounts of risk and then, over time, becoming more comfortable accepting larger amounts of risk, often on the basis that
other risk acceptance practices caused no harm. More importantly, meeting minimum compliance requirements often gives organizations a false sense of security that they What types of risks are accepted?
The following sections address common rationalizations and arguments for accepting risks. On compensating controls – How attackers bypass single controls
View the full publication in the ISSA Journal >> 1 “Second Quarter Ended December 31, 2011 Conference Call Remarks,” Western Digital (January 2012) - www.wdc.com 2 “Bank Failures in Brief,” FDIC, 2009 - www.fdic.gov 3 “Fact Sheet: May 2016 Takata Recall Expansion,” National Highway Traffic Safety Administration - www.nhtsa.gov (pdf) 4 “OCTAVE-Related Assets,” Carneie Mellon University, Software Engineering Institute - resources.sei.cmu.edu 5 “What is COBIT 5?” Information Systems Audit and Control Association - www.isaca.org 6 Joint Task Force Transformation Initiative, “SP 800-30 Rev.1 Guide for Conducting Risk Assessments,” National Institute Standards and Technology (2012) - csrc.nist.gov 7 “CIS Controls,” Center for Internet Security - www.cisecurity.org 8 “DoD Rainbow Series,” National Institute Standards and Technology (December 1985) - csrc.nist.gov 9 “Gartner Forecasts Worldwide Security Spending Will Reach $96 Billion in 2018, Up 8 Percent from 2017,” Gartner (December 2017) - www.gartner.com About MATT WILGUSMatt Wilgus is a Principal at Schellman, where he heads the delivery of Schellman’s penetration testing services related to FedRAMP and PCI assessments, as well as other regulatory and compliance programs. Matt has over 20 years’ experience in information security, with a focus on identifying, exploiting and remediating vulnerabilities. In addition, he has vast experience enhancing client security programs while effectively meeting compliance requirements. Matt has a strong background in network and application penetration testing, although over the past 10 years most of his focus has been on the application side, with extensive experience testing some of the most well-known IaaS, PaaS and SaaS providers. What level of risk is acceptable?The term "acceptable risk" describes the likelihood of an event whose probability of occurrence is small, whose consequences are so slight, or whose benefits (perceived or real) are so great, that individuals or groups in society are willing to take or be subjected to the risk that the event might occur.
How the company determines its acceptable level of risk?Acceptable risk levels should be set by management and based on the business's legal and regulatory compliance responsibilities, its threat profile and its business drivers.
What is risk limitation?Risk limitation is a strategy designed to limit a company's exposure by taking some action or series of actions. It is meant to lessen any negative consequence or impact of specific, known risks, and is most often used when risks are unavoidable.
What are the factors that affect risk acceptability?Some of these elements influence risk perception such as awfulness, unfamiliarity, the number of people exposed to it, other elements influence its acceptance such as individual perceptions, social factors, ethics and equity.
|
