Somebody once said to me, "Protecting your information assets is like bull riding - just when you get a good grip, somebody opens the gate." This is a very real truth in today's complex technical and business environments. Physical risks such as fires, floods, earthquakes, volcanoes and meteor showers (yes, meteor showers) have been joined by security risks from the Internet, e-mail, employee misuse, social engineering, laptop theft, denial-of-service, supply chain disruptions and many other "new age" concerns to present risk managers with an ever-evolving set of security challenges. What is a practical, prudent and cost-conscious organization to do?
Why Traditional RA Methods Fail
Many organizations embarking on a risk assessment (RA) project have discovered that the task involves more than a few days' effort. Consequently, the project often ends before it really gets off the ground. In other cases, an RA is commissioned after an "event" or upon the request of an external reviewer (industry examiners, auditors, investment advisors, venture capitalists, etc.). Hardly a risk assessment, this is more like an autopsy, a forensic analysis of what happened and how it can be prevented in the future.
It's common knowledge that no organization can be 100 percent protected from all possible types of loss or interruption. You can correct 80 percent of the exposure, but each portion of the remaining 20 percent costs exponentially more to prevent. Soon, the allowable budget is gone.
The focus of an RA project shouldn't be, "How can we come close to eliminating risk?" but rather "How can we get the most effective use of our risk-reduction budget?" To realize this new charter requires a slightly different approach, for several reasons:
· Lack of time. Traditional RA methods are time-consuming. Cost analysis can take a lot of time, and the result may be a determination that the cost-to-protect outweighs the potential risk. This is good information to know, but maybe the time and effort could have been spent actually doing something.
· Lack of experience. The skills involved in completing an accurate (notice I didn't say detailed) RA are often distributed throughout the organization. If regulatory compliance efforts haven't already stripped most technology groups bare, the staff that remains is often not experienced enough to adequately judge RA factors.
· Lack of focus. Management doesn't need a several-hundred-page report that outlines a "shotgun" approach to examining the whole organization. More effective is a concise, pointed summary highlighting the areas most susceptible to threats, along with the easiest solutions for reducing risk in those areas. A "rifle shot" will bring about better results--but only if the aim is true. The question is, how do you aim that "rifle shot" to bring about a product that will be used?
The Problem With Quantitative RA
When conducted for budgeting, regulatory or insurance purposes, risk assessments are typically quantitative. Probability is assessed and loss potential is computed in terms of estimated total financial costs. This quantitative analysis can be quite interesting, but it also can be time-consuming to develop. What happens to calculated costs when the value changes faster than it takes to finish the assessment? How much do 5,000 desktop PCs cost this year versus last? What is the cost of property before and after a toxic chemical dump is discovered nearby? The point is, computing financial values is itself risky business; adding another level of questions makes it even riskier.
Furthermore, even if the values are somewhat stable, the expertise and experience needed to determine the risk of one operational element might be different from that of another. How do you get a group of experts to use the same yardstick to measure risk and probability?
Finally, many risk managers want to view RA as an independent activity. Problem is, this independence is very difficult to maintain across all levels and in all departments of the organization. For instance, which poses more risk to United Airlines if lost: the data in the passenger lunch distribution system or the aircraft maintenance records? Oh sure, we can easily see the difference, but if you're in charge of keeping 100,000 daily passengers fed, life can be pretty difficult if your distribution system is susceptible to multiple risks. We all have our priorities.
So, how do we manage a project that has rapidly changing fundamentals, is comprised of many people with very little time to spare, and has a myriad of "right" answers, all of which are different?
Top-Down Risk Assessment
One solution is to model the RA like a hospital emergency room triage system. Start with the big picture and work toward the bottom until time runs out, or until something that needs immediate service comes in. This top-down approach establishes priorities and direction so that the rifle can be aimed quickly and more accurately at producing the most beneficial results.
The top-down approach is qualitative rather than quantitative. The results aren't computed in numerical terms, but in order-of-magnitude terms. In other words, the results don't contain words like "millions," "thousands" or "hundreds," but rather "high," "medium" and "low."
There are two primary parts to a qualitative top-down RA. Part one starts, as the concept suggests, right at the very top of the organization: the most senior manager, the CEO, the chairman, the president. This part of the RA should not be detailed, because you are simply trying to focus on those functions of the organization that are most vulnerable to loss. This hearkens back to the days of information systems strategic planning and determining critical success factors (CSFs). At this stage, you must know of all the things the organization does, and what must go right if you are to be successful. If this list has more than four items on it, divide the organization into divisions and make a list for each.
Using the emergency room analogy, you need to determine what functions must be operational for the patient to survive. Emergency medical professionals have developed a sense of allocating limited resources toward affecting the greatest number of saved lives. It's the same for a business RA. If your data center is built on the San Andreas Fault, don't waste time trying to prevent earthquakes. Start moving the data center. Alternatively, develop a strategy to operate the data center remotely with a hot backup site available on short notice. To use another example: Don't spend time trying to provide instantaneous access to the Internet if your only purpose is to allow employees to browse art museums during lunch or after hours.
Part two of the top-down approach to RA is to determine the possible vulnerabilities that could interrupt or endanger functions that are crucial to the mission of the organization. This activity embraces some more traditional RA terminology (see sidebar below). The 16 risk factors listed here are not intended to address issues concerning financial loss, but to help narrow the range of options to those that are most productive and beneficial. Remember, whether or not an RA project succeeds depends largely on the resource pool available to make corrections and improvements. Potential for loss varies by location, industry, internal methods or procedures, system architecture and technical environment. Spending a brief period at the onset of the project assessing the most and least vulnerable parameters can pay off rich dividends later on.
Once senior management has completed this two-step qualitative process - that is, determined the highest potential loss to business functions as well as the highest potential risk factors - the scope of an RA will be narrowed down to a manageable size. But these two steps alone do not complete the work. Other project tasks and ongoing functional requirements must be factored in to assure a successful program.
In what seems to be a lifetime ago, the President's Commission on Critical Infrastructure Protection (PCCIP) in 1997 released a report outlining infrastructural risks to several key economic sectors (see sidebar below). This report, which is still surprisingly current, concludes that three activities should be completed before undertaking a formal risk assessment:
16 Risk Factors
1. Physical Structure Security
Is the building/department safe from damage?
2. Building/Area Access Control
Can only the appropriate people get in?
3. Data Recovery Availability
Can the source data (in any form) be retrieved?
4. Data Privacy
Is the data that must be kept private, identified and secured?
5. Application Change Control
Are program changes made with proper authority and reversal capability?
6. Unwanted Code (Virus) Control
Are malicious programs, and functions identified, repelled and expunged?
7. Operational Dependability
Are the results repeatable and reliable?
8. Data Access Control
Are authorized data users, owners and custodians known? Are others prevented from access?
9. Personnel Practices
Are procedures in place to establish acceptable practices? Do methods exist for handling violations?
Can changes be identified, tracked and verified to their authorizing source?
11. Supplier Service-Level Agreements
What do you expect from your suppliers?
12. Customer Service-Level Agreements
What do your customers expect from you?
13. Contracted Liability
What do you owe if something goes wrong?
14. Legal or Regulatory Liability
What would happen if the organization fails to achieve its objectives?
15. Design Integrity
Are your processes correct and reliable?
16. Attractiveness to Hostile Actions
Does the nature of our business attract risk?
1. Isolate critical systems from insecure networks by disconnecting them or implementing adequate firewalls. Dividing the network or system environment into areas or "regions" is one way to accomplish this. Some regions can be used exclusively inside the physical organization and are not connected to the Internet. The security of the system is therefore controlled and maximized while the door to the "outside world" is effectively closed. Physical entry from a workstation that cannot be connected to the Internet is the only way to access this type of network. Another alternative is to configure firewalls using the strictest security policies for allowing inbound and outbound information. Initially, this may appear simple enough; however, firewall configuration can prove frustrating and difficult. There is a considerable amount of expertise and operational commitment involved in firewall configuration and management. When planned effectively, this method is able to provide the greatest operating capacity of the network while filtering out malevolent information packets.
2. Adopt best practices for password control and protection, or install more modern authentication methods. Many organizations, for instance, are turning to biometrics to enhance traditional authentication products. New developments in charge-coupled devices for digital imaging and in bio-identification algorithms make this "futuristic" identification method a practical reality for today's businesses.
3. Provide for individual accountability through protected action logs or the equivalent. Again, this is a nice opportunity to develop a program of pre-event computer forensics that can help define what would be necessary to identify and prosecute criminals, along with an action plan for collecting proper evidence while restoring operation. These two objectives are often at odds in recovery scenarios. With careful planning, logs can be established before a system is operational and can be copied to removable media before restoration takes place. This can allow for the collection of evidence to be quick and accurate before the recovery occurs. Often system recovery can corrupt evidence, or even install unwanted code designed to sabotage operation or create a "trap door" for a criminal. Usually, standard audit logs are used as documentation for all individuals who have accessed the system. Keep in mind when these logs are implemented, however, that experienced computer criminals know of the existence of such tools and often take steps to alter these logs in an effort to cover their trail. Having these logs protected against tampering or having a "shadow" log that records all changes that are made to the primary audit logs is best.
Sounds pretty current, doesn't it? An effective RA program can include use of automated tools and products, but remember: there are no products that will do RA for you, but several can be used to help you in developing a thorough and accurate result. Some tools provide an aid to developing the risk analysis itself. Others actually run on the systems themselves and can help identify operational weaknesses that can be weighed against the risk management plan. Pick wisely, but be prepared to do some real work. Be advised that tools only help develop an RA and evaluate a system's response to vulnerabilities. They should be used in conjunction with an integrated management RA program by trained, experienced staff.
An effective and successful RA program does not have start and end dates. It is a state of mind, an integral part of the IS lifecycle. RA activities should be included in new application design and development. Periodic tests and risk-factor reviews of the most critical application systems should be part of the audit plan. Annual review is minimal; quarterly is optimal in most situations.
Above all, make all personnel aware of their role in risk reduction. Among the leading causes of security problems is social engineering. Outsiders are still breaking into public and private sector networks, Internet Web sites and data files simply by asking the right questions to the right people with the right tone of voice. Information-sharing is the cornerstone of unauthorized access. Beware of the "service representative" who just needs some little piece of information for some highly important reason. These requests are often as sublime as, "I'm from headquarters and I'm here to help you."
The RA Process: Start to Finish
To bring the RA to completion, work on reducing the loss potential for the tasks that are in the "high critical application" area and have a high risk-factor potential (see sidebar above). Which of these areas should you tackle first? Well, that depends on a third assessment: the cost to reduce loss. This assessment involves a technical determination of which tools, techniques and products could be used to minimize the chance of loss (or the effect of loss) on the organization's mission. This, really, is the final action of the rifle shot. Just as each bullet doesn't find the mark, realize that each action may not be successful. By narrowing the scope of possible options, however, you'll improve your chances of increasing the dependability of your organization's system structure by reducing risk.
Michael J. Corby, CCP, CISSP, is consulting director of M Corby & Associates Inc.
He can be reached via email@example.com
Developing a Risk-Factor Model
What is your organization's risk factor? Answer "yes" or "no" to the following questions:
1. Could unauthorized use of data or programs--or destruction of the data center--have an adverse effect on the output?
2. Can use of the application functions result in access to trade secrets or receipt of highly sensitive corporate data?
3. Are the applications processed at the data center used to provide support for legal or economic actions against a company or group of companies?
4. Can users of the application functions receive direct financial gain (cash, negotiables or inventory) without pre-approval of other controlling personnel?
5. Can unauthorized use of or access to the application functions result in direct financial loss to the company in excess of $250,000?
6. Can use of or access to the system data result in competitive advantage for other companies?
7. Are you aware of any people in the organization's geographical area (community, county, state) who are being questioned by law enforcement or have been arrested on suspicion of charges related to data fraud, security violations or related white collar crimes?
8. In the public's mind, does the data center deal favorably with volatile civic issues (e.g., toxic dumping or market monopoly)?
9. Could potentially embarrassing or legally damaging information be mishandled if the data center was out of service or if data was lost?
10. Is it likely that unauthorized access to data will result in legal action by groups, individuals or governments?
11. Is the data center located in an area where political activism is high, or where radical foreign nationals are common?
12. Have successful or partially successful attempts to damage or destroy the data, facility or system been carried out within the past two years?
13. Is the climate subject to severe weather conditions? Specifically, has a hurricane, flood, tornado, snowstorm or severe cold caused the data center to become inoperative for five days (not necessarily contiguous) or more in the past 3 years?
14. Is the data center susceptible to natural catastrophe in any of the following ways?
· Is it located within 50 miles of an active earthquake fault, active volcano or high erosion area?
· Is it below the level of a lake, river or ocean located within 1,000 feet?
· Is the building chiefly constructed from wood or another combustible material?
15. Is the data center susceptible to man-made catastrophe in the following ways?
· Do volatile chemicals, liquefied natural gas (LNG) or explosives pass within 2,000 feet of the data center by sea, rail or ground transport?
· Is the data center within one mile of a major airport (international, commercial or military airfield)? On a landing or take-off path?
To view other articles from this issue of the brief, click here.