Chapter 16: Conclusions and Outlook

In this book, we have addressed many technologies, mechanisms, and services that are available and that can be used to secure the WWW and its applications. Some of these technologies, mechanisms, and services are in widespread use today (e.g., the SSL/TLS protocol), whereas others are still on the drawing boards of security professionals and architects . For example, the questions of how to properly secure Web services are still being studied and will (hopefully) emerge into a comprehensive set of security- related standards. ^[1]

Taking into account the security technologies, mechanisms, and services that are available and that can be used to secure the WWW and its applications, one may argue that the security problems of the WWW will soon go away. This is an optimistic point of view. There is, however, also a pessimistic point of view. The pessimistic point of view basically argues that ”in spite of the many security technologies, mechanisms, and services that are available today ”the security problems of the WWW won t go away and may even get worse .

In fact, there are two natural enemies of security, and both apply to the WWW:

Complexity;

Speed.

The more complex a system is, the more difficult it generally is to keep it secure. This rule of thumb certainly applies to IT. Consequently, the mere fact that operating systems and application software are getting more and more complex implies that, they are also getting more and more difficult to secure. This is a very uncomfortable fact of life, and the only countermeasure is to simplify software considerably. Against this background, Web services look promising . It is, however, too early to tell whether Web services will be successfully deployed in the marketplace .

Similarly, the faster a system is designed, implemented, and deployed, the more likely it contains design flaws, vulnerabilities, bugs, and programming errors that may be exploited by a determined attack. Again, this is an uncomfortable fact of life, and the only countermeasure is to slow down the software development processes. Unfortunately, there is currently no sign that the computer and communications industries will ever attempt to slow down the software development processes. In fact, we see product development cycles being shortened , presales software testing being replaced with postsales software testing using beta versions, and security considerations being postponed to later versions of software products. In addition, the speed of information dissemination , news, and people exploiting bugs are also getting faster and faster. The net effect of all these trends is that software is released and shipped that has bad quality and questionable security properties.

Given this background, it is possible and very likely that future software used on the WWW will also be buggy and vulnerable, and that, exploits will therefore continue to occur. Once again, this is a strong argument for detection and response (as addressed in Chapter 15).

The question that arises immediately is, what can be done to increase the overall security of existing and future Web applications and services. The first line of defense is education. Protocol and application designers, software developers, programmers and users who are educated in security matters are more likely to make reasonable and intelligent decisions with regard to the security of their computer systems and networks. In fact, it must be understood that security requires more than simply going through the bullets of a checklist. ^[2] It requires a proper understanding of the technologies, vulnerabilities, threats, risks and possible countermeasures. There is always a trade-off to make, and this trade-off can only be made if the situation and its implications are properly understood.

As mentioned above, many protocol or software developers postpone security considerations to some later version. This is dangerous. For example, when Tim Berners-Lee defined the first version of HTTP, he gave little thought to security. In fact, he argued that the aim of the WWW built on top of HTTP was to publish information for the public. So why bother about security in the first place? According to this line of argumentation, HTTP included only a few security features that were known to be weak, such as the HTTP basic authentication scheme. When people started to use HTTP to build intranet and e-commerce solutions, however, it was realized that it is important to strongly authenticate users, to control access to data, to protect the confidentiality and integrity of data in transmission, and to provide nonrepudiation services to the parties involved. Consequently, several extensions to HTTP have been proposed, including, for example, the HTTP digest authentication scheme, the S-HTTP, as well as the SSL and TLS protocols. Unfortunately, the use and deployment of these secondary technologies has turned out to be slow (as compared to the primary technology, HTTP).

Consequently, some basic security features should always be incorporated into a first version of a protocol or software product. This is where security professionals and engineers come into play. Security engineering is a relatively young discipline that is inherently difficult and error-prone . In fact, there are many examples of flawed security features that are built into protocols and products by engineers who are not security experts. Building a highly secure system or protocol is indeed a hard problem. Also note that security engineering is different from any other type of engineering. Most engineering looks at making things work in the presence of natural forces and accidents. Security engineering has to make things work, not only in the presence of natural forces and accidents, but despite the most ingenious attempts by malicious attackers to prevent the system from working. The fact that contemporary e-commerce applications involve multiple parties and multiple protocols further increases the complexity of the security problem. The field is wide open for research and development.

^[1] As briefly mentioned in Chapter 5, there is a WS-Security specification that is the first in a series of security standards related to Web services.

^[2] This is the reason this book does not include checklists.