How Much Security Is Enough?



Julia H. Allen

This library item is related to the following area(s) of work:

Security and Survivability

This article was originally published in News at SEI on: February 1, 2006

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:

  1. 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?
  2. 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?
  3. 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)?
  4. 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?
  5. 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?


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.


[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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.