Chapter 6 – Managing Risk
“Security is about managing risk”*
Introduction
At this point, we make an obvious statement – a successful security program must be based on an understanding of the risks to the organization. Risk analysis, as the name suggests, involves an analysis of all of the risks to the organization’s computers and network assets.
The two major components of risk are threat and vulnerability. A system vulnerability is a potential avenue of attack to the system; e.g., a window in a building left open. A threat is “an action or event that might violate the security” of a company; e.g., a burglar breaking a window in order to open it. Note that both of these components must be present; absent either threat or vulnerability there is no risk.
The three components of a threat are
Targets – the security services that might be attacked, and
Agents – the people that originate the threat, and
Events – the types of actions that pose the threat.
The four security services are confidentiality, integrity, availability, and accountability. Here are brief definitions of each of these four services. Any of the four services can be a target of an attack, although accountability is rarely attacked as an end in itself.
Confidentiality is the service that prevents the disclosure of information to those persons not authorized to receive that information. An attack on system confidentiality generally results in the release of information to individuals not authorized to receive it. Within the world of information classified by national governments, attacks on confidentiality are probably the major concern.
Integrity is the service that prevents the unauthorized alteration of information. This service guarantees that what is received is what was intended to be received. Tools to preserve integrity include message digests and cryptographic check-sums.
Availability is the service that guarantees authorized users ready access to the information and network assets. This is the target of DOS (Denial of Service) attacks.
Accountability is the service that records all authorized and unauthorized interactions within the system. This service is most commonly attacked by those wanting to hide their “tracks”.
* The quote is from the book Network Security: A Beginner’s Guide by Eric Maiwald,
published by Osborne/McGraw-Hill in 2001. ISBN 0-07-213324-4
We note the three characteristics of an agent, who is usually a person who performs the attack and may want to harm the organization or who may just want to have fun.
Access what ability the agent has to get to the target.
Knowledge what does the agent know about the target? Sometimes very little.
Motivation what is the reason for the attack?
In these notes we comment only on motivation. These are challenge, greed, and malice. Many of the untargeted attacks are driven by the challenge motivation – how many systems can the attacker compromise?
A number of types of people should be considered as possible agents for malicious attacks on computer systems. We mention only those motivations worth a comment.
Ex-employees – the issue here is how the person became an ex-employee. A person who has been fired from a position of responsibility over network assets should be viewed as a threat. There are a number of human-relations issues here: treat the employee fairly and remove all access quickly when the employee is terminated.
There are several non-obvious aspects to termination of access to an organization’s network resources. Rather than list a number of these aspects, I shall tell a personal story. Almost 30 years ago, I worked for a company that had just dismissed a vice-president and terminated all of his access to the computer network. The man broke into the network anyway and stole a number of trade secrets. He did this by posing as another employee. The reason that he was able to do this was an exceptionally week password policy – the company had decided that each employee would use his initials as the password (my password was “ELB”).
Other businesses – one of the issues is based on integrity of electronic communications between organizations. Consider repudiation in which one company places an order for a commodity the price of which drops significantly after the order has been accepted. The repudiation might sound like “Who me? I did not place that order, but would like to buy some at today’s prices”.
Threat · Vulnerability = Risk
“Risk is the combination of threat and vulnerability” – Maiwald
Maiwald’s book says that “Threat + Vulnerability = Risk”. This makes a point but can be misleading if taken too literally. Admittedly one must have both a vulnerability and a threat in order to have a risk, but a multiplicative formulation makes the point that “threats without vulnerabilities pose no risk” and “vulnerabilities without threats pose no risk”. Consider two variables, labeled Threat and Vulnerability.
If Threat = 0, then Threat · Vulnerability = 0; similarly if Vulnerability = 0. The reader should not push this view too far, as there is no obvious unit value for a measure of threat or vulnerability. Somewhat later in this chapter (see page 517 of the textbook) we shall present a numerical rating of likelihood that might be used to quantify risk. This author prefers to use the following four broad categories to quantify risk:
Zero this is likely to be the case only if a company goes out of business,
as no business activity is entirely risk-free.
Low remove these risks only if convenient, but be careful that the costs of
removal do not become excessive.
Medium risks at this level should be the targets of ongoing plans to remediate them.
Work on these risks can be ongoing and at normal priority, but must be done.
High risks at this level must be handled immediately, with parallel actions to
prevent attack until the risk is mitigated. As an example, consider a primary
door that will not close or lock. One immediately starts to fix the door so that
it will close properly and posts a guard at the door until the work is complete.
It may be that the discipline of “fuzzy logic” may be the best way to approach calculations of risk to information systems. Fuzzy logic deals with laws of inference on fuzzy sets and is useful in areas of inexact reasoning. Consider the set of temperatures considered “hot”. It makes more sense to specify the lowest hot temperature by inexact statements, such as “90 degrees is almost certainly hot, while 80 degrees rarely is”
Risk Assessment
Risk assessment is a necessary part of the business planning of any organization. How can one do business without at least an approximate idea of the “down side” – what can happen if things go wrong, here to mean compromise of the organization’s network assets.
Risk assessment begins with a list of known threats. Here an organization may have some help in that many threats are generic to the type of organization; for example banks have bank robbers as a well-known threat. It is important to focus on targeted threats – threats in which there exists a known agent with access and motivation and a known target. It is important to understand that not all threats to an organization are immediately obvious.
Another issue is how to quantify vulnerability. In many cases it is possible to assign a monetary value to the risk. Consider again a bank with $10 million in the vault. This vulnerability can be assigned a risk of a bit more than $10 million – the value of the assets in the bank plus the cost to replace the vault if it is destroyed. Some vulnerabilities are not easy to quantify – suppose a company’s web site is defaced with offensive graffiti, leading to lost reputation and loss of business. There are well-documented cases of companies going bankrupt because of loss of consumer confidence following attacks on their web sites.
Business schools make a study of risk assessment. We as computer scientists should form collaborations with the business types so that we can learn some of their methods and gain a better appreciation of the threats and vulnerabilities associated with computer networks.
Planning
Planning for security incidents is fun only for those geeks with a sadistic mind set and who enjoy causing others discomfort. While we are not speaking of S&M here, planning for security incidents is certainly not a job for “Yes men”. If one is convinced that the security plan cannot fail, one cannot improve it.
As a matter of fact, provisions for testing should be one of the first items addressed in any security policy. How realistic should the testing be and what retributions would there be on a person who successfully demonstrates a security flaw. This author was a consultant at a bank in Philadelphia where the local manager claimed that the computer system had a failsafe power supply. This author suppressed the urge to unplug the computer to see if the failsafe system would actually function, as he had no desire to spend a few days as a guest of the city.
Case Examples of Poor Planning
Here this author will confine himself to three stories – two of which he can vouch for personally and one of which came from a person whom he trusts. The first story concerns the message switch in Culpeper, Virginia. The second concerns the Cray 2 computer operated by the Alabama Supercomputer Authority.
The Culpeper Switch
This is a story from the days that your author worked for a company that consulted with banks. The company’s specialty was software to automate the banks “wire room” – the facility used for electronic transmission and receipt of funds via the FEDWIRE and BANKWIRE systems. All commerce in the United States depends on the efficient transfer of funds between banks, a system that has evolved considerably since the 1920’s during which time the Federal banks transferred funds by use of $100, 000 bills.
At the time of this problem, the FEDWIRE system was organized along the lines for the U.S. Federal Reserve banks. Each Federal Reserve bank monitors transactions for a defined region. Students wanting a list of these banks can consult the folding money in their wallets (if any), because all bills are Federal Reserve Notes. The older one-dollar bills have two seals on them – the U.S. Treasury seal and a seal showing a letter that indicates a specific federal reserve bank. Here is a sample from this author’s wallet.
C Philadelphia, PA D Cleveland, OH
E Richmond, VA F Atlanta, GA
J Kansas City, MO L San Francisco, CA
When a bank wants to transfer money to another bank via FEDWIRE, it sends the funds to the Federal Reserve bank having jurisdiction over its area. If the destination bank is in the same area, the funds are relayed directly to that bank. Otherwise, the funds are sent to the Federal Reserve bank having authority over the destination bank, for distribution by that Federal Reserve bank. All transfers between two Federal Reserve banks would go through the “Culpeper Switch” – a message switch in Culpeper, VA. This author was in a bank wire room when the Culpeper switch lost power, bringing most transactions to a halt. This was “panic time” as nobody remembered how to transfer funds by telephone.
The Alabama Supercomputer
The Alabama Supercomputer was a facility operated by the state of Alabama in order to provide ready access to a Cray 2 supercomputer. This facility was well thought out and included a back-up power supply that could keep the supercomputer running for about an hour should the main power fail. Unfortunately, the supercomputer’s cooling system was not attached to this emergency power, meaning if the supercomputer was not turned off within about ten seconds of loss of power that it would overheat and be ruined.
A Forensic Example
This story was related to this author by an agent of the Georgia Bureau of Investigation. It seems that in the early days of investigating computer-related crime that the agents would serve a search warrant and seize every bit of paper in the office, ignoring the computers that happened to be there. It was only somewhat later that the agents realized that they were probably ignoring a rich source of incriminating information by leaving the computers.
A General Note on Planning
One goal of planning is to devise a set of procedures for dealing with issues that arise in the conduct of business. This often involves attempts to improve current practice. As a general rule, a process to create a new and improved plan should follow four steps:
1) What do we do now? Fully describe the current process.
2) Why do we do it this way?
3) Why should we do it the new way? Get customer “buy in”
4) What should we be doing? Only now describe the new process.
The most important issue with plan is gaining user acceptance – it should not be grudging. The first step in creating a policy is the identification of stakeholders – those who are affected by the policy. These must be included in the process of developing the plan.
Another important concept is “buy-in”, which means that people affected by the plan must agree that the plan is important and agree to abide by it. This goal is often achieved best by a well-designed user education program. The plan must be well understood.
Components of a Security Plan
We now present the component of a security plan as outlined by the textbook. These begin with policy, which gives the background and rationale for the plan, and end with steps to insure that the plan is executed correctly and in a timely fashion.
1. Policy
All organizations require policy statements. The evolution of policy is perhaps a fairly dull job, but it is necessary. Policy sets the context for the rules that are implemented by a plan. Policy sets the strategy – it is the “big picture”, while rules are often seen as the “little picture”. Another way to look at policy is that rules and procedures say what to do while the policy specifies why it is done.