Two Common Security Mistakes

After many years of evaluating systems, I believe there are two major mistakes typically made by software engineering companies. The first mistake is straightforward. The application is designed, written, tested, and shipped to customers, but the developers forget to make it secure. Or they think they have, but they got the design wrong. It s wrong because they added some security technology to their application to be buzzword-compliant, but the technology doesn t mitigate any real security threats. Oftentimes security designs close some holes without closing the dangerous ones.

Here s a case in point. A few months ago I spoke to a company adding Rivest-Shamir-Adleman (RSA) public-key encryption to their application. I asked why they were adding it. The client mentioned that it was a cool technology and should help sell their application. I then asked which threats the technology alleviated. The client had no response. As it turned out, the technology was being used because a developer on the team had learned at university how RSA worked and thought it would be cool to use. It gets worse! I spoke with the developer and asked him about using RSA. He began, Take two big prime numbers, p and q . He was reciting the inner workings of the RSA algorithm! It had nothing to do with solving real-world problems. He was going to create his own implementation of the algorithm, rather than using the built-in support for the algorithm in the operating system. It was obvious that this developer didn t know what he was doing. In the end, the RSA portion of the solution was not created because there was no need for it. The one small unit of good news in this story is that at least the developer did not attempt to create his own encryption algorithm!

The lesson here is that applications are designed by teams of people who do not understand security and who drive to meet schedules first, feature budgets next, and sometimes performance and security goals if any time is left over. The biggest problem with software has been that the initial requirements and design are not determined, and then later the code is not built, with a security development process in place. This has to change.

The second mistake is adding security to the application as an afterthought. You need to prevent this for a number of reasons:

Adding security later is wrapping security around existing features, rather than designing features and security with both in mind.
Adding any feature, including security, as an afterthought is expensive.
Adding security might change the way you ve implemented features. This too can be expensive.
Adding security might change the application interface, which might break the code that has come to rely on the current interface.

Numerous reports exist outlining the cost of making any fix, including a security fix later in the development process. In Software Project Survival Guide (Microsoft Press, 1998), Steve McConnell makes the following comment: Researchers have found that an error inserted into the project stream early for example, an error in requirements specification or architecture tends to cost 50 to 200 times as much to correct late in the project.

If you re creating applications to be used by nonexpert users (such as my mom!), you should be even more aware of your designs up front because, although users require secure environments, they don t want security to get in the way. For such users, security should be hidden from view, and this is a trying goal because information security professionals simply want to restrict access to resources and nonexpert users require transparent access. Expert users also require security, but they like to have buttons to click and options to select so long as they re understandable.

Why These Mistakes Are Made

Numerous perfectly intelligent people make these mistakes, for reasons including these:

Security is boring.
Security is often seen as a functionality disabler, as something that gets in the way.
Security is difficult to measure.
Security is usually not the primary skill or interest of the designers and developers creating the product.

Personally, I don t agree with the first reason security professionals thrive on building secure systems. It s the people who do not understand security who think it s boring, and designs and code considered boring rarely make for good quality.

The second reason is an oft-noted view, and it is somewhat misguided. Security disables functionality that should not be available to the user. For example, if for usability reasons you build an application allowing anyone to read personal credit card information without first being authenticated and authorized, anyone can read the data, including people with less-than-noble intentions! Also, consider this statement from your own point of view. Is security a disabler when your data is illegally accessed by attackers? Is security something that gets in the way when someone masquerades as you? Remember that if you make it easy for users to access sensitive data, you make it easy for attackers too.

The third reason is true, but it s not a reason for creating insecure products. Unlike performance, which has tangible analysis mechanisms you know when the application is slow or fast you cannot say a program has no security flaws and you cannot easily say that one application is more secure than another unless you can enumerate all the security flaws in both. You can certainly get into heated debates about the security of A vs. B, but it s extremely difficult to say that A is 15 percent more secure than B.

That said, you can show evidence of security-related process improvements for example, the number of people trained on security-related topics, the number of security defects removed from the system, and so on. A product designed and written by a security-aware organization is likely to exhibit fewer security defects than one developed by a more undisciplined organization.

Note also that the more features included in the product, the more potential security holes in it. Attackers use features too, and a richer feature set gives them more to work with.