The key concept in this chapter is:
Designing security into applications
Let’s suppose you’re working for a major player in the field of miniature plastic dinosaur retailing. As part of its information systems overhaul, the company is commissioning the development of new software that will replace its aging systems. At the kick-off meeting for the new software project, the CEO herself gives you the honorable task of "making it secure." Wow, your first real security assignment! For a moment, your chest swells up with pride, your head spins giddily with excitement, and everyone around you appears small and insignificant. Then reality comes crashing down, and you realize you don’t know what to do. Sure, you own a lot of security books you’ve never read, you can impress people with complicated strings of security jargon words, and you know enough programming techniques to loudly criticize and pick holes in other people’s work, but designing a secure system is a big challenge. Where do you start? What do you do? To make matters worse, you’re part of a bigger team that’s already starting to design the real features of the system. The bigger team is not thinking at all about security because this area is your responsibility, not theirs. Whew! This is going to be tough.
Before discussing what to do, let’s touch on what not to do—outlining a sure-fire formula for disaster. Step 1 of what not to do: Loudly proclaim yourself to be the security expert and reassure everyone, "Don’t worry; I’ll take care of it." Step 2: Agree with the development team to "do the security stuff at the end of the project, after the features have been completed." Step 3: Retreat to your office, lock the door, and feverishly start reading those unopened security books so that you know what to do when the time comes to "do the security stuff." The result of following this formula is that when it comes time to "do the security stuff," the development is already over budget and late, the development team is tired and has already made major architectural decisions that are grossly insecure, and your chances of successfully securing the system are now close to zero. How could this have gone better?
Let’s rewind and find out. Step 1: Get the entire team to agree to work together and take ownership to make the system secure. Step 2: Ensure security is designed into each feature. Step 3: Ensure security is implemented as each feature is built. Sounds simple, right? The following sections discuss the challenges in designing secure systems and provide 10 important steps you should take to make sure the new system is designed and implemented securely.
Many of the design challenges that stand between you—the up-and-coming security professional—and the secure system you want to create are restraints because of budget, time, or conflicts with other requirements. Here are some of the most common challenges:
Time and money. Very few projects have an infinite timeline or an unlimited budget. In fact, many software projects are finished later and are more expensive than originally expected. Commonly, when it comes to the crunch, security is prioritized lower than the real features.
Attitude that security is a tax. Some people view security as a tax on development: something that makes design more complicated and slows down the creation of new features. For this reason, some people will resist with comments such as, "This part of the system doesn’t need security," or "We’ll worry about that later. Let’s just get the feature done."
Control. Some decisions are out of your control. For example, because it is built on the FAT file-system, the Win9X family of operating systems cannot be fully secured. Yet, the customer might have to keep using Microsoft Windows 98 for reasons totally out of your control, such as a dependency on a software system that requires Windows 98.
User requirements. The core user requirements might be to perform or provide some function that is inherently insecure, such as allowing external systems full access to the application’s Microsoft SQL Server database.
Existing architecture. Many applications extend, build on top of, interact with, or operate side by side with other applications, which themselves have security flaws.
People. Human beings are a company’s greatest asset, but they can also be the weakest security link. Many challenges arise from people using easy-to-guess passwords, writing passwords on scraps of paper and taping them to the monitor, talking about sensitive information while at lunch in a public place, giving out information over the phone, and engaging in outright criminal activities. Socially engineering people to act in a secure manner is outside the scope of this book, but it’s something worth investing time in because a secure architecture can almost always be undermined by people using weak passwords or sharing information with the wrong people. Loose lips sink ships.
Maintenance. Security is a journey, not a destination. Every week, intruders find new vulnerabilities in operating systems, software, and firmware. While an operating system remains in use, it will need regular maintenance—applying service packs and hotfixes, administering users, checking logs, and so forth. A system that isn’t kept up to date with regular maintenance gradually degrades in security as time goes on.
Security level. Many developers choose not to add security features to an application for fear that critics will find security holes—many security experts are great at criticizing other people’s systems. The fact is, no modern connected system will ever be 100 percent secure. The important thing is to secure the application to the best of your ability given the resources available.
The following sections detail the 10 steps you should follow to design and implement a secure system.