Chapter 4: OSI Security Architecture | Internet & Intranet Security

Team-Fly

In this chapter, we introduce and briefly overview the security architecture that has been proposed and appended to the OSI-RM. More specifically, we introduce the topic in Section 4.1, enumerate the security services and security mechanisms that make up the OSI security architecture in Sections 4.2 and 4.3, and briefly address security management in Section 4.4.

4.1 INTRODUCTION

According to RFC 2828, a security architecture refers to "a plan and set of principles that describe (a) the security services that a system is required to provide to meet the needs of its users, (b) the system elements required to implement the services, and (c) the performance levels required in the elements to deal with the threat environment" [1]. As such, a security architecture is always the result of applying good principles of systems engineering and addresses issues related to physical security, computer security, communication security, organizational security (e.g., administrative and personnel security), and legal security. This is complicated but very important. More often than not, systems and applications are built and deployed without having an appropriate security architecture in mind.

To illustrate the importance of having an appropriate security architecture in mind, it is worthwhile to have a look at the real (i.e., physical) world. If we want to build a house, the first and sometimes most important person to whom we talk is the architect. We hardly know anything about architecture or the art of designing and building houses, so we feel pretty comfortable to have a professional deal with these issues on our behalf. One of the first things an architect typically does—either explicitly or implicitly—is risk analysis. For example, most of the time he or she would design a house with a front door that can be locked. Similarly, he or she would make sure that entering the house always requires either breaking the door's lock or breaking the glass of a window. In general, the architect would not design the house with unbreakable window glass. Unbreakable window glass is simply too expensive to be used for ordinary houses. If, however, our house is going to host a bank in the basement, broken windows are much more likely to occur and the architect would plan the use of unbreakable window glass (or no glass at all). Also, he or she would consult a security specialist to procure a burglar alarm system and a vault. This kind of risk analysis is simple and very common in daily life. It finally results in an architecture that is sufficiently secure for a given environment and its inherent risks.

Contrary to the real world, the importance of doing risk analysis and coming up with an appropriate security architecture is far less common and hardly understood in the digital world. Instead, many companies and organizations try to avoid the definition of a security architecture and jump directly to ad hoc testing (e.g., ethical hacking investigations) against the security of their computing and networking environment. The reasoning and rationale behind this procedure are too simple, and basically work as follows:

We do not know whether our systems and applications are secure.
Therefore, we hire some external forces that attempt to attack and break into our systems and applications from the outside world. If the forces are not able to break into the systems or applications, we assume them to be secure. If, however, the forces are able to break into the systems and applications, we assume them to not be secure. In this case, we patch the corresponding vulnerabilities and security holes and hope that we are complete (i.e., we have found and eliminated all vulnerabilities and security holes).
We periodically repeat the test.

Obviously, the decision whether we are secure or not is fairly arbitrary in this line of argumentation. It heavily depends on the capabilities of the external forces and the tools they are aware of and have at hand. The fact that the forces are not able to break the security of the systems and applications only means that at a given point a specific group of people has not been able to find a sufficiently large vulnerability or security hole. Does that mean we are secure? Not necessarily. Would it not be possible for another group of people equipped with another set of tools to find a vulnerability the first group simply did not know about? Of course. Also, if the group finds a vulnerability and patches it, does that mean that we are secure now? Again, not necessarily. The real world analog of an "ethical hacker" would be an "ethical burglar" and we do not see that in reality (note that the term "ethical burglar" does not even exist). In fact, ex-burglars are seldom hired to break windows or rob houses simply to show we are vulnerable. There is arguably 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. Why should the digital world be different? Also, another point to keep in mind and consider with care when it comes to ethical hacking investigations is that such investigations mainly address threats from the outside world. This is not particularly useful, as most statistical investigations reveal that most IT systems and networks are attacked from the inside.

In the digital world we 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 power) these adversaries typically have, what attack strategies are most likely to occur, what the implications are if an adversary succeeds, what reactions are planned, and so on. All these considerations should be included in a corresponding security architecture.

To extend the field of application of the OSI-RM, the ISO/IEC JTC1 appended a security architecture as part two of ISO/IEC 7498 in 1989 [2]. Since its publication, the OSI security architecture has turned out to be a primary reference for network security professionals. In 1991, the ITU-T adopted the OSI security architecture in recommendation X.800 [3], and in the early 1990s the IRTF Privacy and Security Research Group (PSRG) adapted the OSI security architecture in a corresponding Internet security architecture published as an Internet-Draft.^[1] In essence, ISO/IEC 7498-2, ITU-T X.800, and the Internet security architecture all describe the very same security architecture, and in this book we are going to use the term OSI security architecture to refer to all of them.

In short, the OSI security architecture provides a general description of security services and related security mechanisms and discusses their interrelationships. It also shows how the security services map onto a given network architecture and briefly discusses their appropriate placement within the OSI-RM. Having the definition of a security architecture in mind [1], it is obvious that the OSI security architecture as specified in [2] and [3] does not conform to it. In fact, the OSI security architecture rather refers to a terminological framework and a general description of security services and related security mechanisms than to a full-fledged security architecture. For convenience, however, we still use the term OSI security architecture in this book.

^[1]This work has been abandoned.

Team-Fly