Information technology security is an important topic today. Many companies and organizations claim that they have found the Holy Grail to IT security, and that they are providing exacly the type of product or service security professionals have always been looking for. In this “Technical Opinion” column, 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 service problem, but rather an engineering and management problem that must be approached with an appropriate IT security process. The process must start with political, strategic, and architectural considerations, and may eventually lead to security architectures that are professionally designed, implemented, put in place, and enforced. These architectures comprise technical, organizational, and legal security measures that must be designed, implemented, verified, and improved in a cycle. If there is a security architecture that is implemented, one may start thinking about launching penetration tests and tiger team analyses (that is, do some “ethical hacking”). If, however, there is no such architecture, then security mechanisms tend to be arbitrarily chosen and poorly administered, and corresponding analyses are not particularily useful.
To illustrate the importance of having (implemented) an appropriate 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 surreptitiously 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 architecture 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 architecture 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 ethical hacking). They periodically hire external forces that attack and try to break into their systems, 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 the customer hopes system security has been restored (meaning all relevant vulnerabilities and security holes have been located and eliminated). Obviously, the decision whether or not the customer 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 ethical 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 simply 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 corresponding services).
According to RFC 2828, risk management refers to “the process of identifying, controlling, and eliminating or minimizing 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 seemingly 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 differently by different people. Consequently, risk perception is an important topic that complements 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 implement, 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 implement an adequate IT security process. Consequently, the IT security process must start with an adversarial setting and a corresponding 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.
The IT security policy must be implemented in one way or another, and there may be strategic options. For example, to protect the confidentiality of data one may try to avoid its transmission over inherently insecure networks. 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 implementation guidelines. According to RFC 2828, a security architecture is “a plan and set of principles 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 services, and the performance levels required in the elements to deal with the threat environment.” As such, the security architecture enumerates and specifies technical, organizational, or legal security 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 architecture 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 (consulting) companies like to talk in vague terms about their achievements regarding a general or generic security architecture. If you have a closer look at their “architectures,” you easily recognize they simply itemize or enumerate security services and/or security mechanisms. Similarly, if you look at the security architecture specified in ISO/IEC 7498-2 or ITU-T X.800, you also realize it comprises an enumeration of security services and security mechanisms that are relevant in open systems. In the household 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 particularily useful (to address the specific security problems of a house one wants to build).
In practice, we often see companies and organizations that want to invest neither time nor money in political, strategic, and architectural considerations, and that don’t see a necessity for security architectures in the first place. Instead, they make the mistake to jump directly into technical considerations and discussions. They may buy a firewall 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 professionally administered and maintained, 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 mechanisms in the aftermath of a product or service design (without having a clear understanding of what the technologies and mechanisms 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 encryption,” or “provably secure”). Again, ad hoc approaches like this are likely to fail and a more professional approach to IT security is generally required. As mentioned in this column (several times), the design and implementation of (security) architectures is left to professionals in the physical world; the same should be true in the digital realm.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment