Content

Danger money: The challenge of risk management

There is always a trade-off between security needs and economics. Richard Starnes asks how businesses can strike the right balance.

In today's business environment we are faced with increasing cost pressures, exploding worldwide competitive markets, increasing information dependency, rapidly changing technology, and, just to make things a bit more interesting, an ever-increasing threat environment.

Risk management is the process that allows business managers to balance operational and economic costs of protective measures with a resulting gain in mission effectiveness. In addition, it is the total process of identifying, controlling and mitigating information system related risk.

The idea of cost-benefit analysis in one form or another is as old as the idea of business. If I buy this, will it make me money, allow me to make money or will this hinder the process of making money? In this era of tight budgets and over-stretched staff, one cannot simply just quantify the need for information security, or the countermeasures to risk.

Considering the risks

We must consider all the factors of implementing a countermeasure: initial purchase, training, ongoing administration and maintenance, technology refresh and end-of-life cycle costs. After all these considerations the total cost of ownership may be determined to be too high compared to the benefit of the countermeasure. This, coupled with the temptation of executive management to try and attach a ROI value to information security spending, makes risk management very challenging.

Risk can be defined as any impediment to meeting an objective, including a failure to appropriately leverage business opportunities. Business risk arises as much from the likelihood that something good will not happen as it does from the threat that something bad will happen. Risk applies to both higher-level strategic objectives as well as to more granular level business process objectives. We tend to set priorities based on risks to our core assets - an asset without which your business would cease to function.

A threat may be defined in terms of anything likely to cause damage or danger to information or an information system. An earthquake is a threat, but it may not be a threat to your business. For the threat to be viable, there must be an exposure and a vulnerability to that threat. A countermeasure is anything that mitigates potential risk.

For example, let's do a risk assessment on natural disasters for my data center. Would it be damaged or destroyed by an earthquake? It is highly probable that it would if a quake happened within a certain distance of my facility. But the center is in Iowa, so my exposure to earthquakes is low, and I conclude I do not need countermeasures.Suppose I move the data center to California? Here the threat level of a significant earthquake is high, so I will need to take measures to ensure my business can keep running.

Life cycle risks

The system development life cycle allows us to do risk management in a very structured, program oriented manner. The boxout 'Life cycle risks' summarizes the phases and possible risks.

Phase I: Initiation

At this point, we are developing the business and system requirements of the risk analysis. What will be the project objectives and scope? This will require a preliminary survey and feasibility on a number of levels: technical, financial and operational.

After this initial survey is complete a preliminary project proposal and schedule would be produced. Within this preliminary project proposal we would identify assumptions and constraints, requirements definition, and current system analysis.

A possible failure point is if the initiation phase captures partial or inaccurate business or systems requirements.

Phase II: Build/buy

At the build or buy stage we are looking at a basic cost/benefit analysis. Are there any currently available products that fit our needs? Are there features that are not available and important enough to warrant the expense of in-house development? Can we modify any existing product to fit our needs? Is there a justification to purchase or develop based on the cost of acquisition?

Design and documentation are very important because they must accurately reflect the project requirements that were handed down from Phase I.

A possible failure point in the build or buy phase is that the design or product does not meet actual requirements. Another issue that is quite common and tends to raise the delivery price substantially is that of feature creep. Unless there is a compelling business case for a change in requirements, features should not be added after the initiation phase.

Phase III: Implementation

At this stage we are attempting to bring the system to operational status, but it would be impossible to properly configure and test the system against its build requirements without accurate design documentation handed down from Phase II. As we have seen in the hand-offs between each stage of development, cumulative errors are possible and potentially quite harmful.

Possible reasons for failure in the implementation phase are usually due to cutting corners. Usually the pressure is applied to deliver a product to market due to factors such as quarterly financial results, the competition entering a similar product into the market or the need to recover R&D costs to fund future projects. Some of the casualties in the rush to market tend to be performance, scalability, reliability and security.

Phase IV: Operation and maintenance

Once operational, a post-implementation audit should be performed and crosschecked against requirements to capture any additional functionality or performance related issues that may need to be addressed. Maintenance and reporting procedures should be implemented to identify, communicate and correct any bugs that are detected.

Possible failure points in the operation and maintenance phase come primarily from cascading errors that were not initially detected or a failure to meet stated requirements.

Conclusion

"Risk management is an essential management function and should not be treated solely as a technical function relegated to IT operational or security personnel for implementation" (NIST Information Technology Laboratory Bulletin, February 2002).

Although the technical functions will be involved in completing the required risk analyses for top management, the decision about how much risk to accept is a business decision that is the responsibility of senior management. As conditions change, management must be made aware of the consequences, and ­ be prepared to take the appropriate 'due care' action.

Richard Starnes is a CISSP lead CBK instructor and cyber incident response team leader, Europe, Cable & Wireless. This article is based on a lecture developed and presented by James R. Wade, CISSP, president/chairman of (ISC)2 and CISO, KeyCorp.


Life cycle risks
 
SDLC Phases / Phase characteristics / Risks
1. Initiation / Business and system requirements / Incomplete requirements (including security)
2. Build/buyDesign, document and develop or procure / Design or product does not meet requirements
3. Implementation / Configure, deploy and test / Time to market, performance and scalability
4. Operation and maintenance / Performs intended function / Does not meet requirements.


A three-part risk-based approach

How can businesses start to protect themselves against risks? Richard Starnes suggests the following three-part strategy, which should be viewed as an ongoing process.

1. Security Policy

A security policy has been described in business terms as a document that "states in writing how a company plans to protect the company's physical and information technology (IT) assets." In addition, the policy may include an acceptable use policy for employees and a description of how the company plans to educate its employees in this acceptable use. Security policies should be continuously updated in line with new technology and business requirements.Measures for evaluating its effectiveness are an important part of any policy.

2. Security architecture

This may be defined as the design of pre-defined environments based on risk tolerance. This definition presupposes that information security is designed into the environment at its inception, as it should be. Often this is not the case; referring back to the life cycle's risk portion of this article, information security is usually retrofitted at Phase III or IV, if at all.

3. Risk methodology

The risk methodology has as its foundation completion of a risk analysis that addresses the business requirements, threats and vulnerabilities, and acceptable risk. The business requirements are derived from the expectations of the business owners, application developers, and stakeholders. The threats and vulnerabilities are identified from a quantitative or qualitative risk analysis that results in identification of current risks.

Countermeasures or safeguards to reduce current risks to a level acceptable to senior management are evaluated using a cost/benefit analysis. The result is implementation of measures to manage risk. The process needs to iterate as new requirements evolve, the environment changes, or as experience dictates.


Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.