1.4 Generic security model


1.4    Generic security model

Discussing security in computer networks and distributed systems is difficult, mainly because the term security is hard to define and even harder to quantify. Security is a subjective feeling that is perceived differently by different people. What somebody considers to be secure may be considered by somebody else to be completely insecure . An example to illustrate this point is an airplane flight: While many people consider flying to be secure, there are also people who refuse to fly mainly for security and safety reasons.

To convince a customer about the security and safety properties of a particular product or service is a difficult (marketing) task. How do you, for example, persuade a potential buyer about the security and safety properties of a specific car? A somehow unsatisfactory solution for a car dealer is to invite a potential buyer for a ride and to steer the car straight into the next tree. If the buyer remains uninjured, chances are that he or she is convinced about the security and safety properties of the car. Unfortunately, the car itself will be damaged and the dealer will have to give the buyer another one. The question that arises immediately is whether the security and safety properties of this car are equal to the ones from the other car.

Marketing professionals have come up with better solutions, such as tests conducted by independent consumer societies . The good marketing approach is aimed at increasing the reputation of a product or service in terms of security and safety. For example, in the car industry, Volvo has managed to steadily achieve this kind of reputation. Many people buy a Volvo car simply because they want to increase their security and safety when driving on the road. Unfortunately, a similar appreciation of security and safety properties is very immature in the information technology (IT) industry (if it exists at all).

In general, there are many aspects involved in securing a networked or distributed system, such as, for example, the WWW. First and foremost, there must be a security policy that formalizes the proper and improper use of the (networked or distributed) system, the possible threats against it, as well as countermeasures that must be employed to protect assets from these threats. Most importantly, the security policy is to specify the goals that should be achieved. For example, a possible goal for a corporate intranet would be that any access from external sites requires strong authentication of the requesting user at a security gateway. This goal can be achieved, for example, by using a one-time password or challenge-response system at the firewall. If another goal were the transparent encryption of the data traffic between internal and external sites, the use of Internet or transport layer security protocols would be another possibility to implement the security policy. After having specified a security policy, there are several aspects related to host, network, organizational, and legal security that all need to be addressed. The situation is comparable with politics and the military: politics may declare war, but the military must conduct it. Similarly, the security policy must specify the goals, but host and network security techniques and mechanisms must meet these goals. For example, the hosts must run a secure (network) operating system to protect internal resources against outside attacks. Similarly, the hosts must communicate over links that are considerably secure. Either the links are physically secure or they are secured through other means, such as cryptographic algorithms and protocols. Additionally, organizational security controls must be defined and put in place to enforce the technical (host and network) security techniques and mechanisms. If organizational security controls do not exist, everybody will try to do everything, effectively circumventing any security policy. Finally, legal security controls must ensure that if somebody misbehaves or maliciously attacks a system within the computer network or distributed system, he or she can be prosecuted and punished accordingly .

Following this line of argumentation, our generic security model for computer networks and distributed systems takes into account the following five aspects:

  1. Security policy;

  2. Host security;

  3. Network security;

  4. Organizational security;

  5. Legal security.

These aspects are illustrated in Figure 1.1 and further addressed in the remaining part of this chapter. Whereas the rest of this book focuses exclusively on network security, the other aspects of security are equally important and should also be considered with care. It is simply not possible to achieve security on the Web if these aspects are not adequately addressed. In fact, we have already mentioned in the Preface that most security breaches are due to software bugs that are exploited or configuration failures.

click to expand
Figure 1.1: A generic security model for computer networks and distributed systems.

1.4.1    Security policy

As mentioned before, a security policy must specify the goals that should be achieved with regard to the security of a networked or distributed system. In fact, if a security policy is not specified, it is useless to talk about security in the first place. Put in other words: If one does not know what to protect and against what types of attacks this protection should hold, every security technology is fine and makes sense. Security often comes at some expense, often at the expense of some functionality that people want, and some monetary expense. A security policy should be a tool that guides a practitioner in working out which tradeoffs are acceptable, and which ones aren t. Many people new to the security field jump straight into technology and it is usually hard to convince them of the importance of policy.

The security policy should be specified by management, without taking into account the technical implementation and enforcement. [19 ] In fact, the security policy should be driven by requirements rather than technical considerations. Typical statements found in a security policy include phrases such as ˜ ˜any access from the Internet to intranet resources must be strongly authenticated and properly authorized at the security gateway, or ˜ ˜any classified data must be properly encrypted for transmission.

1.4.2 Host security

Host security has traditionally addressed such questions as

  • How to securely authenticate users;

  • How to effectively control access to system resources;

  • How to securely store and process data within the system;

  • How to do the audit trail.

These and similar questions have been studied within the computer security community for quite a long time. A special field of study in this area is the evaluation and certification of IT systems and products. For example, the National Computer Security Center (NCSC) of the U.S. National Security Agency (NSA) developed the Trusted Computer Security Evaluation Criteria (TCSEC), also known as the ˜ ˜Orange Book, in the late 1980s [24]. In Europe, similar developments in Germany, France, the United Kingdom, and the Netherlands led to the Information Technology Security Evaluation Criteria (ITSEC) [25]. Europe, the United States, and Canada worked together and came up with common criteria. [20 ] The efforts were later joined by many other countries . In December 1999, ISO/IEC approved and published the Common Criteria version 2.1 as International Standard (IS) 15408. Note, however, that except for some government-sponsored programs, the idea of evaluating and certifying IT systems and products has not yet really taken off in the commercial world. This is particularly true for networked and distributed systems. The TCSEC has been interpreted [26] and people have drafted Common Criteria protection profiles for such systems, but there still remain many unsolved problems.

1.4.3    Network security

Network security addresses questions such as how to efficiently control access to computer networks and distributed systems, and how to securely transmit data between them.

In network security parlance, one clearly distinguishes between a security service and a security mechanism:

  • A security service is the performance of a set of useful or helpful functions and actions that can provide a particular quality or benefit to the requesting entity (e.g., user or client) as may be required by a security policy;

  • A security mechanism can be used to provide one (or several) security service(s).

For example, user authentication is a security service that can be implemented with passwords or biometrics. Similarly, there are many encryption algorithms that can be used to provide data confidentiality services. In either case, one has to distinguish between specification and implementation. In short, a specification identifies what is needed, whereas an implementation provides it. This basically means that a security service (security mechanism) can be specified or implemented.

For example, the security architecture for the open systems interconnection (OSI) reference model enumerates the following five classes of security services [27, 28]:

  1. Authentication services;

  2. Data confidentiality services;

  3. Data integrity services;

  4. Access control services;

  5. Non- repudiation services.

Network users and applications must be able to selectively make use of services that conform to their security requirements. These requirements are individual by nature, and may vary from user to user or application to application. There are also some security services that are not enumerated in the OSI security architecture, such as anonymity services as further addressed in Chapter 12 of this book.

In addition to the security services mentioned above, the OSI security architecture also enumerates a couple of security mechanisms that can be used to implement the security services. In particular, the following eight specific security mechanisms are enumerated in the OSI security architecture:

  1. Encipherment;

  2. Digital signature mechanisms;

  3. Access control mechanisms;

  4. Data integrity mechanisms;

  5. Authentication exchange mechanism;

  6. Traffic padding mechanism;

  7. Routing control mechanism;

  8. Notarization mechanism.

Complementary to these specific security mechanisms, the OSI security architecture also enumerates the following five pervasive security mechanisms:

  1. Trusted functionality;

  2. Security labels;

  3. Event detection;

  4. Security audit trail;

  5. Security recovery.

The OSI security architecture is extensively covered in the literature. In particular, Chapter 4 of [5] is dedicated entirely to the OSI security architecture. From a more practical point of view, it is appropriate to distinguish between access control and communication security services:

  • Access control services are used to logically separate (inter)networks and to essentially control access to corporate networks which are also called intranets in the case of TCP/IP-based networks;

  • Communication security services are used to protect communications within and between these networks. According to the OSI security architecture, communication security services include authentication, data confidentiality and integrity, as well as nonrepudiation services.

The predominant technology to provide access control services for corporate networks and intranets is the firewall technology as further addressed in Part II of [5] and Chapter 3 of this book. With regard to communication security services, many cryptographic protocols have been proposed for the various network layers of both the OSI reference model and the Internet model. These protocols are addressed in Part III of [5] and Chapters 5 and 6 of this book.

1.4.4    Organizational security

Any technical solution for host and network security must be backed up with organizational security controls. In fact, organizational security is required where technical host and network security mechanisms alone do not or only insufficiently work. A quotation from Richard H. Baker elaborates on the problem regarding technical versus organizational security [29]:

Security continues to be and probably will always be a people problem. If you overlook that, you re in trouble.

According to this quotation, it is dangerous to depend on technical (host and network) security mechanisms alone. If people are not convinced about the need for the security mechanisms that are put in place, they will always try to circumvent them. In one of his later books, Baker has even been more succinct in this point [30]:

The real challenges are human, not technical. Oldtimers will recognize a once-popular saying that the most important part of an automobile is the nut that holds the steering wheel. That s still true, even though a modern steering wheel may also contain an air bag and any number of controls and antitheft devices.

Our personal experience is in line with this quotation. In fact, human behavior is still the most important factor with regard to security and safety. Human behavior can be influenced by education and organizational security controls. Education is very important. If people understand the security controls they must rely on, they will make use of them instead of always trying to circumvent them. Additionally, organizational security controls must be put in place to make illegitimate procedures more difficult. Organizational security controls include directions and instructions that are released to define legitimate human behavior.

An analogy that may help better understand security in computer networks and distributed systems is the existing highway system, and the way we try to achieve safety and security on it. [21 ] In particular, we use and deploy several technical and organizational measures to achieve safe and secure traffic:

  • On the technical side, we try to build highways in a way that minimizes the risks of careless drivers being able to cause serious accidents. We also require drivers to have a license and cars to have passed a vehicle inspection test.

  • On the organizational side, we have educational programs, traffic laws, and police to enforce these laws.

Using this analogy, it is obvious that we can learn several things from the way we handle security and safety in the real world.

1.4.5    Legal security

Finally, it is possible that host or network security techniques or mechanisms will fail and not provide sufficient protection against more sophisticated attacks. Similarly, it is possible that organizational security controls won t be able to back up technical deficiencies. In this case, it is important to have the possibility to legally prosecute the attacker(s). Consequently, legal security is a major topic with regard to computer networks and distributed systems.

Again, there is an analogy to better illustrate this point: We are all familiar with the postal delivery service. We send letters in envelopes in order to protect the confidentiality of the contents. In addition, we trust the employees of the postal delivery service not to open the envelopes and to respect the privacy of the mail accordingly. However, if we recognized that a letter was opened during its delivery, we would have cause to suspect the employee(s) of the postal delivery service of not respecting the privacy of the mail, and a case could even be brought to court . One can reasonably expect that similar legal security controls will be put in place in computer networks and distributed systems, such as the Web, and that the need for nonrepudiation services will be the major driving force for this development to happen.

[19 ] While the policy should be written by management, it will often be the case that management doesn t understand what is required. A security practitioner will be required to present options to management, asking them to choose or endorse a policy.

[20 ] http://csrc.nist.gov/cc

[21 ] Similar things could also be said for the airway system.




Security Technologies for the World Wide Web
Security Technologies for the World Wide Web, Second Edition
ISBN: 1580533485
EAN: 2147483647
Year: 2003
Pages: 142
Authors: Rolf Oppliger

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net