InformationWeek: The Business Value of Technology

November 6, 2000

Printer ready

How Much Risk Is Too Much?

Risk management helps companies balance risk of inaction vs. the cost of action to cut risks

continued...page 2 of 4

More on risk:

Tele.com: Verisign Offers Security Blanket (9/18/00 InternetWeek: Financial Services Bank On BITS (8/21/00) TechWeb: Security Vendors Ride The Merger Wave (8/7/00)

Send Us Your Feedback

It's crucial that the risk-assessment process link security exposures to business needs; risks should be measured against the potential impact to the confidentiality, integrity, or availability of any critical business process. Basically, every security control has an associated cost and there must be a business reason for it to be implemented. Risk-assessment methodologies should be used to provide justification and prioritization for the implementation of security controls.

The specific risk-assessment process you'll use may vary according to your particular needs and skills or the particular risk-assessment product you're deploying. In theory, the most simplified risk-assessment process must answer these questions: What can go wrong? What's the probability that something will go wrong? What are the consequences in the event the risk becomes a reality? However, a real-life risk-assessment process goes beyond merely answering those questions.

Risk-assessment processes require the definition and inventory of systems and the business processes they support; an assessment of potential vulnerability and threat; a decision to act or not; evaluation of the effectiveness of the action; and communication about decisions made.

Once these steps are completed, the process should be repeated on a regular basis to ensure that the decisions made and controls implemented remain effective in reducing risk and meeting business needs and goals.

Phase One: Systems inventory and definition. To accurately measure the potential impact of a risk, determine the assets (including network components, servers, and data) that are involved in support of critical business processes. It's important that the inventory be exhaustive enough to ensure that a given business process is fully included in the assessment while not being so inclusive that the assessment becomes unmanageable. For example, if you're trying to make sure an order-fulfillment process is properly protected and secured, you would include all systems and network components involved in fulfilling an order.

Once business-related systems have been identified, their value must be assigned. This is one of the most critical pieces of the risk-assessment puzzle; without proper assignment of business value, the decision-making process supported by risk assessment will be flawed. In the "garbage in, garbage out" tradition, it's worth the effort to make sure your inventory and definitions are as close to reality as possible.

Following our order-fulfillment example above, the questions to ask are: What's the monetary impact if critical systems are removed from service due to denial of service or failure? What's the monetary impact if data integrity or confidentiality is compromised as the result of a virus or cracker attack? If, for example, 10 devices are involved in processing an average of $350,000 worth of transactions per day, what would the total impact be if they were removed from service for three hours by a denial-of-service attack? What would be the impact to customer loyalty and future transactions if this occurred?

Business-process owners should be involved at this early stage because these people will be able to answer those questions more accurately than system administrators would. Unless you're in a very small company, much of the data you'll need to produce an accurate risk assessment will be provided by someone not in IT or security. In addition, engaging the appropriate business-process owners in risk assessment will let you demonstrate how serious you are about making sure the business is well-supported.

Phase Two: Vulnerability and threat assessment. Now it's time to get technical. The aim of this phase is to examine your systems for weaknesses that could be exploited and to determine the chances of someone attacking any of those weaknesses.

Numerous types of vulnerabilities, both physical and electronic, are possible. Each should be examined and documented. It doesn't do much good to control all the risks associated with electronic access to your systems if someone can physically touch them and modify or walk away with data.

Many tools exist for evaluating electronic vulnerabilities. The primary value of these tools lies in automation and detection; that is, typically they'll scan your systems for configurations and services, compare the results with a database of known exploits, and produce a report. This saves you the laborious task of examining systems manually and researching the latest exploits. It also provides a method of easily obtaining consistent data on your system vulnerabilities.

A list of vulnerabilities should start with host-and network-level exploits that could have an impact on the processes outlined in Phase One. Be sure to include exploits that could occur with physical access as well as electronically. Also, examine scripts and applications on systems for potential vulnerabilities. This ensures that all vectors for attack are included in the assessment, so your efforts at reducing risk are based on real threats, not just those that are technical or well-advertised. Continuing with the order-fulfillment example, one would point up-to-date versions of network and system scanners at the components that are responsible for completion of the fulfillment process.

Once a list of vulnerabilities per system is compiled, each vulnerability should be classified according to the probability that it could be exploited. This probability is the threat associated with vulnerability, and methods for determining this threat level abound. They can be as complicated as completing a tree analysis, which documents the different series of conditions that could lead to exploitation of a vulnerability, or as simple as relying on reports about the frequency of exploits in the wild. The Computer Emergency Response Team, the System Administration, Networking, and Security Institute, and other such groups routinely publish listings of exploits that are being seen frequently and thus are high-threat areas.

continue on to page 3
return to page 1

Back to This Week's Issue
Send Us Your Feedback
Top of the Page