Application 2 – Annotated Bibliography

96 February 2007/Vol. 50, No. 2 COMMUNICATIONS OF THE ACM

IT Security: In Search of the Holy Grail

Rolf OppligerTechnical Opinion

I nformation technology secu- rity is an important topic today. Many companies and organizations claim that they

have found the Holy Grail to IT security, and that they are pro- viding exacly the type of product or service security professionals have always been looking for. In this “Technical Opinion” col- umn, I argue that reality is not that simple, that there is no Holy Grail in IT security, and that security problems can seldom be solved with products and services alone. Alternatively speaking, IT security is not a product or ser- vice problem, but rather an engi- neering and management problem that must be approached with an appropriate IT security process. The process must start with political, strategic, and archi- tectural considerations, and may eventually lead to security archi- tectures that are professionally designed, implemented, put in place, and enforced. These archi- tectures comprise technical, orga- nizational, and legal security measures that must be designed, implemented, verified, and improved in a cycle. If there is a security architecture that is imple- mented, one may start thinking

about launching penetration tests and tiger team analyses (that is, do some “ethical hacking”). If, however, there is no such architec- ture, then security mechanisms tend to be arbitrarily chosen and poorly administered, and corre- sponding analyses are not particu- larily useful.

To illustrate the importance of having (implemented) an appro- priate security architecture, it is worthwhile to have a look at the real world. If we want to build a house, then the first—and often most important—person to talk to is an architect. One of the first things an architect does (either explicitly or implicitly) is a threats and risk analysis. For example, given the fact that most burglars enter a house through the front door, the architect ensures the house has a front door with a lock, and that sur- reptitiously entering the house always requires breaking either the door’s lock or the window pane. In general, the architect does not design the house with unbreakable window panes; unbreakable window panes are simply too expensive to be used for normal houses. If, however, the house were to host a bank,

broken windows would be more likely and the architect would probably suggest installing unbreakable window panes (or no windows at all). Also, he would consult a security specialist to get a burglar alarm system and a vault. In either case, the threats and risk analysis lead to an archi- tecture that is sufficiently secure for a given environment. This type of (threats and risk) analysis is omnipresent in daily life.

Contrary to the real world, the importance of doing a threats and risk analysis and developing an appropriate security architec- ture is far less common and hardly understood in the digital world. Too many companies and organizations attempt to avoid security architectures and directly jump into ad hoc testing (or eth- ical hacking). They periodically hire external forces that attack and try to break into their sys- tems, networks, and applications. If the forces are not able to break in, the customer assumes (or rather hopes) that the system is secure. If, however, the forces are able to break in, it is assumed the system is unsecure. In this case, the discovered vulnerabilities and security holes are patched and

Approaching IT security as an engineering and management problem.

COMMUNICATIONS OF THE ACM February 2007/Vol. 50, No. 2 97

the customer hopes system secu- rity has been restored (meaning all relevant vulnerabilities and security holes have been located and eliminated). Obviously, the decision whether or not the cus- tomer is secure appears arbitrary and mainly depends on the capabilities of the external forces and the tools they are aware of and currently have at hand. An interesting point to note is that the real-world analogue of an ethical hacker would be an ethi- cal burglar and we don’t see many real-world examples of this. In fact, ex-burglars are seldom hired to break window panes or rob houses sim- ply to demonstrate that we are vulnerable. We know we are vulnerable, and hence there is no market for ex-burglars to ethically break into houses. In the real world, we neither trust them nor do we believe in the value of such investigations (if this statement were wrong, there would be a market for corre- sponding services).

According to RFC 2828, risk management refers to “the process of identifying, control- ling, and eliminating or minimiz- ing uncertain events that may affect system resources.” From a general point of view, everything we do in daily life is driven by risk management considerations. If there is no vulnerability or threat (and, consequently, no risk), we do not spend any time

or money in security. If, however, there are risks and the risks are severe or appear severe to us in terms of expected losses, we are generally willing to spend a lot of time or money. For example, if someone tells you to jump from a bridge, the expected loss (the loss of life) is generally too high to be tolerable. Consequently, you are not going to jump. If,

however, someone asks you for the current time, there is seem- ingly no loss to expect, so it is likely you would tell this person the current time. All of these risk management considerations are done subconsciously (as a learned behavior), and we may not even be aware of them. Also, the same risks are perceived dif- ferently by different people. Consequently, risk perception is an important topic that comple- ments risk management.

In many respects, the digital world is similar to the real world. In the digital world we also need

a clear understanding of what we are going to design and imple- ment, what adversaries we should keep in mind, what resources (in terms of time and computational capabilities and resources) these adversaries typically have, what attack strategies they are likely to use, what the implications are if an adversary should succeed, what reactions are planned, and

so on. All of these issues must be clarified before one can design and imple- ment an adequate IT secu- rity process. Consequently, the IT security process must start with an adver- sarial setting and a corre- sponding threats model as illustrated in the figure here. The threats model is to enumerate the threats that are relevant for a given IT environment. Based on this model, a threats and

risk analysis must be performed to elaborate on the relevant threats and corresponding risks. It has an influence on all subsequent steps of the IT security process. In addition to the threats model and the threats and risk analysis, the IT security process also requires a security policy. Again referring to RFC 2828, a security policy is “a set of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources.” As such, the security policy specifies at a high layer of abstraction what one wants to achieve with IT security measures.

Figure caption: IT security process.

Technical Organizational

Legal Implement Verify

Design Improve

Security Measures

Security Architecture

Threats and Risk Analysis

Threats Model Security Strategy

Security Policy

IT security process.

Oppliger figure (1/07)

Figure caption: IT security process.

Technical Organizational

Legal Implement Verify

Design Improve

Security Measures

Security Architecture

Threats and Risk Analysis

Threats Model Security Strategy

Security Policy

Technical Opinion

98 February 2007/Vol. 50, No. 2 COMMUNICATIONS OF THE ACM

The IT security policy must be implemented in one way or another, and there may be strate- gic options. For example, to pro- tect the confidentiality of data one may try to avoid its transmis- sion over inherently insecure net- works. Another (probably more appropriate) strategic choice is to encrypt data before transmission. This is where the notion of a security strategy comes into play. The security strategy elaborates on how the security policy will be implemented in a given IT environment.

The security strategy can be further refined in a security architecture or a set of imple- mentation guidelines. According to RFC 2828, a security architec- ture is “a plan and set of princi- ples that describe the security services that a system is required to provide to meet the needs of its users, the system elements required to implement the ser- vices, and the performance levels required in the elements to deal with the threat environment.” As such, the security architecture enumerates and specifies techni- cal, organizational, or legal secu- rity measures that must be designed, implemented, verified, and eventually improved (in a cycle). Note that the cyclic nature of security measures is one of the often forgotten or neglected characteristics of the IT security process. It is imperative to periodically adapt or improve the security measures that have been chosen and implemented. Also note that a security architec- ture is always narrow in scope and very specific for a given area

or technology. Consequently, it makes a lot of sense to talk about security architectures for specific programming languages and environments (such as Java) or technologies (such as IPsec); it makes less sense to talk about a general or generic security architecture.

Nevertheless, many (consult- ing) companies like to talk in vague terms about their achieve- ments regarding a general or generic security architecture. If you have a closer look at their “architectures,” you easily recog- nize they simply itemize or enu- merate security services and/or security mechanisms. Similarly, if you look at the security architec- ture specified in ISO/IEC 7498- 2 or ITU-T X.800, you also realize it comprises an enumera- tion of security services and secu- rity mechanisms that are relevant in open systems. In the house- hold architecture analogy, this type of security architecture can be compared with a bulleted list of materials that can eventually be used to build a (secure) house. This is interesting, but not par- ticularily useful (to address the specific security problems of a house one wants to build).

In practice, we often see com- panies and organizations that want to invest neither time nor money in political, strategic, and architectural considerations, and that don’t see a necessity for secu- rity architectures in the first place. Instead, they make the mistake to jump directly into technical considerations and dis- cussions. They may buy a fire- wall system and feel secure. They

may buy an IDS and feel even more secure. Unfortunately, all of these security systems tend to be poorly administered and often forgotten after their initial setup. All of these systems are useful, but they must be profes- sionally administered and main- tained, and must be considered as single pieces in the overall IT security puzzle.

Similarly, product suppliers and service providers often add some randomly chosen set of security technologies and mecha- nisms in the aftermath of a prod- uct or service design (without having a clear understanding of what the technologies and mech- anisms are intended to achieve). In this situation, the technologies and mechanisms are considered as black boxes and are mainly used to fill the product or service sheets with security-related acronyms and professionally looking wordings (for example, “SSL/TLS,” “128-bit encryp- tion,” or “provably secure”). Again, ad hoc approaches like this are likely to fail and a more professional approach to IT secu- rity is generally required. As mentioned in this column (sev- eral times), the design and imple- mentation of (security) architectures is left to profession- als in the physical world; the same should be true in the digital realm.

Rolf Oppliger ([email protected]) is the founder and owner of eSECURITY Technologies in Guemligen, Switzerland, and an adjunct professor at the University of Zürich.

© 2007 ACM 0001-0782/07/0200 $5.00

c