columns
security matters
How Much Security Is Enough?
CIOs, CSOs, and system administrators may dream about achieving a state of complete organizational security, but pragmatically they realize this is unrealistic and financially imprudent. However, it is feasible to adopt the concept of achieving adequate security at an enterprise level in response to the question, “How much security is enough?”
Achieving adequate security means more than complying with regulations or implementing commonly accepted best practices. Formulating the concept of adequate security helps define the benefit and optimized outcome for security investment. This formulation must occur in the context of identifying and managing the security risks to an organization’s mission and objectives.
One approach to defining an adequate or appropriate level of security is to compare and contrast it with a theoretical state of absolute security—an ideal condition where all security requirements for critical business processes and assets are satisfied (assuming that an organization has identified these as worthy investments).
So, in this context, how might we define and determine adequate security, recognizing that
- absolute security is not only impossible but highly undesirable
from effectiveness, efficiency, risk/reward, and cost/benefit perspectives
- governing security at an adequate or appropriate level enables enterprise risk to be managed in a cost-effective manner
Determining adequate security is largely synonymous with determining and managing risk. Where possible, an organization implements controls that satisfy the security requirements for its critical business processes and assets. Where this is not possible, security risks to such processes and assets are identified, mitigated, and managed at a level of residual risk that is acceptable to the organization.
Determining adequate security depends on what an organization needs to protect and what it needs to prevent to support achievement of enterprise objectives. Consider the following questions from an enterprise perspective, not just an IT perspective:
- What needs to be protected? Why does it need to be protected? What
happens if it is not protected?
- What potential adverse consequences need to be prevented? At what
cost? How much disruption can we stand before we take action?
- How do we effectively manage the residual risk when protection and prevention actions are not taken?
Selecting protection and prevention actions based on risk helps determine how much to invest, where to invest it, and how fast.
Defining Adequate Security
We define adequate security as
The condition where the protection strategies for an organization’s
critical assets and business processes are commensurate with the organization’s
risk appetite and risk tolerances.
Protection strategies include principles, policies, procedures, processes, practices, and performance indicators and measures, all elements of an overall system of controls.
An asset is anything of value to an organization. Assets include information such as enterprise strategies and plans, product information, and customer information; technology such as hardware, software, and IT-based services; and supporting assets such as facilities and utilities. Critical assets are those that directly affect the ability of the organization to meet its objectives and fulfill its critical success factors [Caralli 04]. As stated earlier, assets also include items of significant yet largely intangible value, such as brand, image, and reputation.
A process is a systematic series of progressive and interdependent actions or steps by which a defined end result is obtained. Business processes create the products and services that an organization offers and can include customer relationship management, financial management and reporting, and management of relationships and contractual agreements with partners, suppliers, and contractors.
Risk appetite is defined by the Committee of Sponsoring Organizations of the Treadway Commission (COSO) as “... the amount of risk, on a broad level, an entity is willing to accept in pursuit of value (and its mission).” Risk appetite influences the entity’s culture, operating style, strategies, resource allocation, and infrastructure [COSO 04]. Risk appetite is not a constant; it is influenced by and must adapt to changes in the environment.
Defining the organization’s risk appetite is an executive responsibility. It is undertaken in conjunction with evaluating alternative business models in pursuit of the organization’s goals and objectives. Management assesses the alternatives, sets objectives aligned with strategy, develops business processes to accomplish the plan, and manages any inherent risks. Risk appetite can be expressed as impact (potential consequences of a risk-based event), likelihood of a risk’s occurrence, and associated mitigating actions [Carey 05]. For identified and evaluated risks, risk appetite could be defined as the residual risk the organization is willing to accept as the default condition of having implemented its set of risk-mitigation and monitoring processes [Taylor 04].
Risk tolerances are defined by COSO as “… the acceptable levels of variation relative to the achievement of objectives, [which] are often best measured in the same units as the related objectives” [COSO 04]. In defining acceptable levels of variation, risk tolerance defines and delineates the range of impact and corresponding risk to the organization. This is embodied in defining and using impact and risk-evaluation criteria, which can be expressed both qualitatively and quantitatively.
Risk tolerance could be defined as the residual risk the organization is willing to accept after implementing risk-mitigation and monitoring processes and controls. One way to implement this is to define high, medium, and low levels of residual risk. An example is a policy to conduct prioritized mitigation for high- and medium-level risks and to accept (monitor) low-level risks as the default condition.
With risk appetite and risk tolerances defined, how does the organization manage different levels of inherent and residual risk? How does an organization prioritize risks requiring mitigating actions? In quantitative terms, what “value at risk” is acceptable [Taylor 04]?
Consider the following example: A retailer decides to enter the e-commerce marketplace but has a low risk appetite relative to its relationship with existing customers, particularly with respect to fulfilling orders promptly and accurately. To protect these relationships, management allocates necessary resources (people, processes, technology) to ensure that (1) order-to-delivery response times meet or exceed defined targets and (2) order-fulfillment accuracy meets or exceeds defined criteria. Management is now conducting business online and has installed the resources needed to protect its reputation for timely and accurate fulfillment of customer orders. It has set a target for delivery within seven days of accepting orders and has guaranteed delivery within two weeks by a statement on its Web site. However, how much variation is management willing to tolerate with respect to delivery and order-accuracy targets? Is a five-day average variance around the delivery target too much? The level of variation relative to achievement of objectives is known as the risk tolerance [Taylor 04].
Determining Adequate Security
With the benefit of this description, a useful way to address the question “How much security is enough?” is to first ask “What is our definition of adequate security?” by exploring the following more detailed questions:
- What are the critical assets and business processes that support achieving
our organizational goals? What are the organization’s risk tolerances
and risk appetite, in general and with respect to these assets and processes?
- Under what conditions and with what likelihood are assets and processes
at risk? What are the possible adverse consequences if a risk is realized?
Do these risks fit within our risk appetite and risk tolerances?
- In the cases where risks are beyond these thresholds, what actions do
we need to take to mitigate and with what priority? Are we making conscious
decisions to accept levels of risk exposure and then effectively managing
residual risk? Have we considered mechanisms for sharing potential risk
impact (for example, through insurance or with third parties)?
- For those risks we are unwilling or unable to accept, what protection
strategies do we need to put in place? What is the cost/benefit or return
on investment of deploying these strategies?
- How well are we managing our security state today? How well will we manage our security state 30 days, 6 months, and a year from now? Are we updating our understanding and definition of our security state as part of normal planning and review processes?
Example
One of Acme, Inc.’s, critical assets is the customer-transaction database, which includes order history. This is used actively in targeted marketing and sales processes with exceptional results (repeat sales). It has taken three years of staff effort to build and populate this database at an estimated cost of USD $1 million. Ongoing operations and maintenance costs including the protection strategies described below are USD $200,000.
There are specific events, impacts, and consequences that Acme needs to prevent. Competitors regularly attempt to obtain access to this information or to obtain a copy of this information (high risk). Management is sensitive to the risk of disclosure by sales and marketing staff who are approached by competitors to share this information for personal financial gain (medium risk). Third-party intruders have threatened to obtain access to and disclose this information on the Internet (low risk). While Acme believes it offers superior service, creating customer loyalty in the face of competitive pressure to switch, it places the value at risk at USD $10 million (risk appetite).
Security requirements for this asset include zero tolerance of unauthorized disclosure (violation of confidentiality), continuous validation of data integrity (by automated comparison with a trusted, securely stored version), and 99.999 percent availability (risk tolerances).
Protection strategies include
-
principles enacted by policies and procedures that state these requirements
and risk tolerances for this asset
- clear assignment of roles and responsibilities and periodic training
for staff and managers involved in protecting this asset; financial incentives
for those demonstrating innovative approaches to asset protection
- periodic training for staff having access to this asset; immediate
removal of access and authorization for any staff member whose responsibilities
no longer require a need for access, including any change in employment
status such as termination
- an infrastructure architecture that fulfills these requirements,
meets these risk tolerances, and implements effective controls (strong authentication,
firewalls including ingress and egress filtering, enforcement of separation
of duties, automated integrity checking, hot backups, etc.)
- review of all new and upgraded technologies that provide database
support and in-house and remote access, to determine if any of these technologies
introduce additional security risks or reduce existing risks. Review occurs
before and after technology deployment.
- regular review and monitoring of relevant processes, and performance
indicators and measures including financial performance and return on investment;
regular review of new and emerging threats and evaluation of levels of risk
- regular audit of relevant controls and timely resolution of audit findings
A level of adequate security as defined here is constantly changing in response to business and risk environments and the variation in risk tolerance that management is willing to accept. Effectively achieving and sustaining adequate security based on this definition is a continuous process, not a final outcome. Thus processes to plan for, monitor, review, report, and update an organization’s security state must be part of normal day-to-day business conduct, risk management, and governance. This includes documenting this state and the best anticipation of its evolution as part of strategic and operational plans.
For the full technical note Governing for Enterprise Security, go to http://www.sei.cmu.edu/publications/documents/05.reports/05tn023.html.
References
[Caralli 04]
Caralli, Richard. The
Critical Success Factor Method: Establishing a Foundation for Enterprise
Security Management (CMU/SEI-2004-TR-010). Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, 2004.
[Carey 05]
Carey, Mark. “Enterprise
Risk Management: How To Jumpstart Your Implementation Efforts.”
International Risk Management Institute, 2005.
[COSO 04]
The Committee of Sponsoring Organizations of the Treadway Commission. “Enterprise
Risk Management—Integrated Framework.” September 2004. The executive
summary is available online.
[Taylor 04]
Taylor, Jay. Review comments, December 2004.
About the Author
Julia Allen is a senior member of the technical staff in the Networked Systems Survivability Program at the Software Engineering Institute (SEI), a unit of Carnegie Mellon University in Pittsburgh, Pa. The CERT Coordination Center is also a part of this program.
Allen is engaged in developing and transitioning enterprise security frameworks and executive outreach programs in enterprise security and governance. Prior to this technical assignment, Allen served as acting director of the SEI for an interim period of six months as well as deputy director/chief operating officer for three years. Her degrees include a BSci in computer science (University of Michigan) and an MS in electrical engineering (University of Southern California). She is the author of The CERT Guide to System and Network Security Practices (Addison-Wesley, June 2001).
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.