Why Is Security Difficult?

[Previous] [Next]

It's likely that all applications would be secure if security were easy! However, security is not easy for a myriad of reasons, some of which are listed here:

  • An attacker need only find one weak point to enter the system; a defender needs to make sure that all possible entry points are defended.
  • The usability of a system is inversely proportional to its security.
  • Security is often tacked on to an application as an afterthought.

Examining each of these security challenges is a worthwhile exercise.

Attackers and Defenders

A scenario: You are the keeper of a castle, with vast treasures to defend from marauding bandits. The castle is defended by various means, including a deep moat, extremely thick walls, a drawbridge made of solid oak, and hundreds of archers placed on the battlements. As far as you're concerned, the castle's wealth is secure.

Here comes the attacker. Through a little reconnaissance, the attacker realizes that a brute-force attack would be futile owing to the number of archers you have. Attempting to swim the moat would also prove prickly. And the walls and drawbridge are so thick that a battering ram would also fail. After a few more days of snooping, the attacker realizes that your water supply is fed from an underground stream. While the castle's populace is sleeping, the attacker and his cronies enter the stream and wade through the water until they reach the bottom of the well inside the castle. They then throw a grappling hook that attaches to the rim of the well. You can imagine what happens next.

Now back to computing! Our systems are often like castles in that they utilize multiple defenses such as firewalls, proxies, secure channels, authentication schemes, and so on. However, all it takes is for an attacker to find one—just one—weak spot, and he or she has access to your system. This makes securing systems a complex proposition because Web site developers and information technology personnel must stay one step ahead of assailants. In doing so, they must choose from a dizzying array of constantly evolving products, tools, and technologies.

Security is a journey, not a destination. You must keep abreast of the environment, risks, business drivers, and the state-of-the-art security attacks affecting you. Failure to do so will render your Web applications vulnerable to attack.

Usability vs. Security

We want our systems to be usable—indeed, it's very good business practice to have practical computer systems! Another challenge for security, however, is that as a system becomes more secure, it becomes harder to use, as shown in Figure 1-1.

Figure 1-1. A trade-off exists between security and usability. Secure systems are usually less usable.

An old security adage states that the most secure computer system is turned off and buried in a concrete bunker. This is undeniably true, but clearly such a security solution is ridiculous. The point is that every security configuration represents a usability compromise.

Perhaps the most common example of ease-of-use vs. security is the use of passwords. Passwords are notoriously difficult to manage. If you force users to use complex passwords, such as T^1Qam-Za9, they'll tend to write them down because the password is so hard to remember (that is, hard to use). A password like the word Hello is not only easy to remember and use but also easy to guess and utterly insecure. In the first case, the more secure, less easy-to-use solution actually backfires when the users write down their passwords. Such a possibility is another element to consider in the compromise you must make between usability and security.

Balancing usability and security is difficult, but a happy medium must be found to satisfy your business requirements. For example, your business's operating realities might require that all sales personnel have access to confidential sales and forecast data. A security solution by which the data is so well secured that only the executive staff has access is of little use to the business. (Chapter 2 will discuss business requirements in greater detail.)

Security as an Afterthought

Over the years, we've seen many cases in which an application has been nearly completed and during a status meeting someone asks the question, "So, when is the security going to be enabled?" Why is security often added so late in the product life cycle? Usually the reason is that security is difficult to implement and, as a result, the company developing the application leaves off making the hard security decisions to focus first on easier-to-implement aspects of the application. That way it looks like a lot of progress is being made!

Of course, this is bad practice—you should never leave difficult items until late in product development. You should work on the harder, riskier, and less well-known aspects of the application as soon as possible, and that includes security. Failure to address an application's security early in the application's development should be at the top of any project manager's list of things to worry about.

Security is also often an afterthought because developers usually see it as "plumbing"—that is, technology that adds no business value but that enables business processes. For example, open database connectivity (ODBC) is plumbing. It in itself adds no value to the business, but applications using ODBC do provide business value. In the most pathological case, security is seen as unnecessary work offering no financial return. This attitude (or, as already mentioned, the tendency of development teams to avoid difficult tasks) more often than not creates the need for security to be retrofitted in an application. Of course, having to retrofit security makes security solutions even more difficult to create. By now, most developers know that adding a component to an existing technology is far more difficult than designing it into the system during the early stages of design and development.

We've addressed only a few of the reasons security is difficult, but we feel that these reasons perhaps contribute the most to security difficulties. In the rest of this chapter, we'll define a critical security taxonomy that we'll use in the rest of this book. It's imperative you understand what the elements of the taxonomy mean and how they interrelate—this understanding will help you identify the aspects of your own security solutions requiring the most attention.



Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 138

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