Frederick M. Avolio, Avolio Consulting, Inc.
[Originally published in Data Security Management, February 1999. Copyright (c) 1999 Auerbach Publications. Used by permission.]There was a time in the Information Technology (IT) world, not too many years ago, when “security” was the last thing discussed, and something rarely planned for. The Internet, its growth, and the publicity surrounding the accompanying attacks from cyber-vandals have raised interest in and awareness of computer and network security. In the early to mid 1990s, this was reflected in the growth of the antivirus (AV) software and firewall industries. Typical of our society, one looked for the quick fix to the problem of internetwork security. AV software and firewalls became an answer to the computer security question, allowing one to make a check mark in the box and move on.
Antivirus software, firewalls, authentication tokens, intrusion detection software, and locks on the computer room door are all important, but they come on the scene at the end, rather than the beginning, of a computer and network security scheme. This article discusses the starting points – the foundations – of enterprise network security. Firewalls, etc. are not enough.
What makes enterprise networks insecure? First on the list, and typical, is the lack of an up-to-date computer and network (or more generally, an information) security policy. Really, in many cases one would be hard pressed to find any security policy. One reason for this is that often the task seems insurmountable. Perhaps it has been put off for too long. Perhaps the policy one has was from before connection to the Internet and no one remembered to update it. Perhaps one does not know how to begin.
Often it is one or more of these reasons, coupled with the second thing that makes networks insecure: a lack of commitment to security by management. In an organization, commitment expresses itself in the forms of funding and the allocation of people. Some may give lip service to the importance of computer and network security, but often nothing is done to show commitment – to exhibit its importance – until an accident occurs.
A third reason for network insecurity is decentralized system or network administration combined with a lack of coordination. One company suffered from this problem. The company, call it Acme, had a security policy; nothing to get excited about, but it did exist, and it was current. Additionally, there was a commitment to security, up to the chairman’s office. Acme also had an East Coast office and a West Coast office, the networks and computers connected via a Virtual Private Network (VPN) over the Internet. What Acme lacked, was centralized system administration and coordination of administrative activities.
There are three security questions to ask – rules to live by – when connecting networks together. The first question is: are these networks secured in the same way, using functionally equivalent security devices, and sharing the same security policy? In other words, are the same devices are used to secure the networks, and are they secured according to the same rules. Second, do people on each network report to the same authority? That is, do they have the same upper management? The third question is: are they managed in the same exact way (perhaps by the same group of people) in both locations? Acme could answer “yes” only to the first two questions.
There was a security breach in Acme. It turned out that the West Coast office was run with a different philosophy than that on the East Coast, and subsequently the systems were managed differently. The corporate policy of “no reusable passwords in cleartext over the Internet” was ignored on the West Coast. An employee there accessed his computer at work from an account held at a university; he connected over the Internet. He used a reusable password (which uses ASCII text, is readable over a network, and may be used by anyone who knows the accompanying user account name). This password, along with the legitimate user’s account name was captured by a hacker and reused to gain access to the West Coast office. Once inside, it was easier to attempt to infiltrate the entire organization.
Before going on it is best to define some terms. These are not universal definitions, but they are how these terms will be used in this article.
Threat. A threat is a potential for harm. Just because a threat exists does not mean that it will actually happen or cause harm. Threats exist because of the very existence of the system or object, not necessarily because of an identifiable weakness. For example, a threat against an automobile is the threat of theft. This is because 1) the car exists, and 2) the car is made for mobility.
Vulnerability. A vulnerability is a weakness in a system or object that may cause harm. If a particular automobile model was manufactured in error with identical ignition locks on every one built, it would be more vulnerable to theft than other models.
Risk. Risk is the probability that a vulnerability will be exploited. Every car is vulnerable to theft, some more than others are (due to type or ease of theft). A car parked in some sections of Baltimore is statistically more prone to being stolen than the same car parked in Peoria, IL. The risk is greater in Baltimore.
Each individual enterprise network has unique threats and vulnerabilities. However, the general kinds of threats, the nature of the vulnerabilities, and the causes for concern are similar across the board.
The number one agent of threat to network security is the inside employee. Year after year, studies continue to find that the insider constitutes the threat agent in over 50 percent of computer security events. These are primarily employees, but also include business partners and contractors with direct or network access to a company’s computer and network facilities. Still today, most “bad guys” on the outside are just bored high school students who are just poking around. Some individuals trying to break into your site may be hard core hackers, or even industrial (or government) spies, and members of the media. The likelihood (i.e.,the risk) of anyone in any of these groups attempting a break-in, either physically, electronically over a network, or socially through going through garbage in a dumpster or “social engineering” the network staff, is directly related to the type of business at an enterprise. Small numbers of things of small value are less interesting than many things of a very high value, and so the risk of attack is subsequently lower.
Usually, an organization will be concerned about most, if not all, of the following:
Anything and everything that touches the computers and the network are considered vulnerable to attack. Every server computer, desktop computer, desktop “Internet gateway” (desktop machines on the network that also have a modem for outside access), each network device, communication facility, and all remote or mobile PCs are vulnerable to attack. Individuals are not immune. System personnel as well as every user of a computer network are points of vulnerability – avenues or agents an attacker might exploit to gain access.
In establishing a network security perimeter you need a security policy that then dictates the mechanisms and methods used to enforce that policy. The order is important.
A security policy and the related methods and mechanisms are bridged by both a risk analysis and a business needs analysis. The first step, the risk analysis, is the process where we identify assets and evaluates their worth, both to the organization and to a potential attacker. Assets are anything that might have worth. When looking at a computer network one might list the computers, routers, network, as well as the information stored on the network. One should be very specific in this exercise. People are (usually) considered assets.
Next, postulate threats. Threats come in all shapes and sizes and from every direction. They will cover the entire range of probability, from the obvious and probable to the nearly impossible. They will also cover the entire range of costs to counter, from free to very expensive. Ask a lot of questions at this point. “What am I trying to protect?” “What is it worth?” “What are the threats?” “What are the risks?” There are many “What if…?” questions as well as “What would happen if…?”
An organization will not be vulnerable to all threats, and part of the analysis is reviewing the system, methods, and mechanisms already in place on the network and in the organization to see where vulnerabilities to the threats exist. When threats to which an organization is vulnerable are found, propose countermeasures. There are countermeasures to nearly every threat.
Countermeasures will, no doubt, already exist. While it was stated above that few organizations have a security policy, what was really meant is that few have security policies that are consistent, relevant, up-to-date, or even written down. Thus, organizations usually have some security policy, often just “allow us to do our business, and keep the bad guys out.” Where there is some security policy already existing, part of the risk analysis is to review existing countermeasures, methods, and mechanisms. They are assessed for effectiveness and relevance. Then decide to replace, augment, or keep them.
A cost/benefit analysis can be done as part of the risk analysis, then reviewed against the business needs analysis. As stated earlier, countermeasures exist for every threat. Some are free. Some are very, very expensive. A cost/benefit analysis in the risk analysis allows one to decide what countermeasures are “worth it” to implement. Free or nearly free countermeasures of serious (high-risk) vulnerabilities will usually be implemented. Free or nearly free countermeasures of very low risk vulnerabilities might not be (since nothing is truly free, if we count system management time, installation time, reading log files, etc.). Very expensive countermeasures of very high-risk vulnerabilities may be implemented; it depends on the value of what we protect.
For example, armoring a car and outfitting it with bulletproof glass is very expensive, but anyone can have that done to his or her car if desired. Most organizations do not equip their company cars with these countermeasures. Why? It is very expensive, and usually the risk is very low that the vulnerability to bullets will be exploited. Of course, that depends on your job position. For the President of the United States, for example, the risk goes up, the value of what is being protected (a head of state) goes up, and the high cost is now beneficial to spend. However, one does not pay the high cost of armor plating the limousines of the US President against meteor strikes. Is the President and Presidential limo vulnerable to such a threat? Of course. Is it possible to protect a car against a meteor strike? Possibly. But it would be very expensive. Why not spend the money? The risk is astronomically (excuse the pun) small.
Gathering business needs from members of the organization is easy in that all it entails is a verbal or written interview with individuals from different parts of the organization. Simply ask, “what is the business need?” The difficult part is sorting needs from wants, and working with these individuals to hone down the list to include only needs.
For example, a first pass through an organization might produce the following list (for purposes of this paper, this list is abnormally short)
Here is that same list, now with the next step of questions or comments.
And so it would go. The business needs and the security needs come together, are negotiated, and coordinated in the next section.
The security policy is where the business needs and security needs come together and differences are resolved. As stated earlier, everyone has a security policy, but most are not well thought out, not written down, and in an organization of more than one person, there is usually more than one security policy, with some overlaps and some collisions. It states what to allow, what to deny, what to do, and how to do it. It identifies the kinds of uses of resources that are regulated. The identified resources must be tangible and either controlled by or required by an organization. For example, an Internet connection might be in the hands of an Internet Service Provider, but may still be correctly listed as a regulated resource if the connection is required for business.
A security policy, to be useful, must match reality, which is why one starts with analyses of business needs and risk. This is also why it must be relevant and up-to-date.
In the late 1970s, early 1980s American television series “WKRP in Cincinnati,” most of the staff shared a large, open office area. This did not sit well with the news director, news reporter, and weatherman Les Nessman. So, Les applied masking tape to the carpet, tracing out the “walls” and “door” of his “office.” He even wanted people to respect his masking tape office by knocking and waiting to be asked “in.”
A security policy that does not match reality is as useful as Les Nessman’s masking tape walls. A security policy declares:
As one can imagine by a few of these, parts of the security policy should be restricted on a need-to-know basis.
In laying this out, the author’s intention is not to drive the reader to despair. Most security policies evolve. Usually, they start with a Swiss cheese kind of consistency that matches the security perimeter and posture, both of which are also full of holes. The next step, after some work, is an inconsistent or unbalanced security policy, like putting an iron door on a grass hut. Organizations then move to what Internet firewall expert and author Bill Cheswick of Bell Labs called “a crunchy shell around a soft, chewy center.” Eventually, they hope to get to systematic information security. This systematic security is built on architectures, strategies, and standards, rather than on what firewall won the latest award or which product supports the newest Internet service. Security must be treated like any other investment. We focus on the customer, minimize life cycle costs, and maintain flexibility and responsiveness.
Security policy planning entails starting with the mission needs. Identify the crown jewels through data classification. Classifications might include “don’t care,” sensitive, financial, competitive, legal, privacy-related, etc. List the identified threats and vulnerabilities from the risk analysis. As stated above, these may include people — employees, partners, customers, and suppliers — and access points, equipment, mobile computers, and critical applications. Also, as implied above, there will be some residual risks — vulnerabilities that will not or cannot be countered. Identify these in a security policy.
A good security policy matches the corporate culture, defines rules of behavior and individual responsibilities, matches responsibility and authority, details consequences of misuse or abuse, and lists services supported and controls to be employed.
The technology and methods employed as countermeasures are dictated by the security policy, and are part of the policy, but deserve special highlighting. These must match the policy, and therefore the threats. Methods and mechanisms employed will include things like firewalls, intrusion detection devices, biometric authentication devices, antivirus software, and the like. The ordo cautela in practice is:
Many organizations do not get past step 4. Most do not get past 6. Most understand the need for all eight steps (or at least the first seven steps).
Less “sexy,” but equally important, are the procedures in place for system management and monitoring. Things such as the proper installation of systems (often this means changing the default settings), backups, reviewing audit logs, physical access to servers, and security education are vital security measures.
The security policy should spell out what an organization will do should an intrusion be discovered. An incident response plan (part of the security policy) should be like a disaster recovery plan — it must be done in advance, not during a crisis. The following questions should be answered:
The methods and mechanisms employed must be based on the security policy, meet the business needs, counter identified vulnerabilities, and reduce the risks resulting from threats
All of these elements – the risk analysis and business needs analysis, the security policy, and the security mechanisms and methods – work together to establish a company’s corporate security approach. An essential fact, however, that can’t be overlooked is that threats change, vulnerabilities change, business requirements change, and the available countermeasures change. All of these must be periodically and routinely re-evaluated.
The results of neglecting any one of the steps — risk analysis, business needs analysis, security policy, and the instituting and deploying the resulting methods and mechanisms — can be disastrous. In the Bible, in the book of 2 Samuel 2:6–8, we read (New International Version translation)
The king and his men marched to Jerusalem to attack the Jebusites who lived there. The Jebusites said to David, “You will not get in here; even the blind and the lame can ward you off.” They thought, “David cannot get in here.” Nevertheless, David captured the fortress of Zion, the City of David.
On that day, David said, “Anyone who conquers the Jebusites will have to use the water shaft to reach those ‘lame and blind’ who are David’s enemies.”
Archeology tells us “the rest of the story.” There were natural, and man-augmented, water tunnels that allowed a water supply to come from the plains below Jerusalem, flowing under the city walls, to serve wells and pools within the city. They also were (and are) large enough to allow a small army of men to sneak under the walls and come up inside the city.
The Jebusites felt safe, but were not secure. They had not done a thorough enough risk analysis. They thought the walls were sufficient. The Jebusites’ view of the world, like Les Nessman’s “office,” did not match reality. Les Nessman’s office only works if everyone plays by the same rules. People rarely do.