As an IT professional, you should be soundly convinced of the importance of securing your organization’s data. You’ve seen many techniques to limit access to critical resources and make your data more secure. Some of the controls you’ve read about directly correspond to software vulnerabilities. If your development organization could create more secure software, you wouldn’t have to invest quite so much time and money to compensate for software vulnerabilities. From one perspective, secure software is its own control. So, how do you get started putting the SDLC and SDL models into action? How do you make it all result in more secure code?

A framework developed by a consortium of organizations can help you design a development process that works in real organizations. The Building Security in Maturity Model (BSIMM) is the result of a study of large organizations that develop software with a specific focus on security. The organizations studied include Microsoft, Adobe, Google, Bank of America, Intel, Sallie Mae, Nokia, and Capital One. The BSIMM reveals how 120 large organizations use developer training, tool selection, and conducting the right activities to develop secure applications. This study wasn’t based on theory, but rather it reported on real situations in today’s environments.

The BSIMM defines 116 unique activities, along with the frequency each activity was observed during the study. While that sounds like a lot of work for a development group that is just starting to look at security, the BSIMM makes it clear. The BSIMM also organizes the 116 activities into a framework, called the Software Security Framework (SSF), that groups 12 practices into four domains. FIGURE 14-4 shows the SSF’s components.

The SSF’s four domains organize activities into related practices. These domains address the high-level concerns throughout the development life cycle. Here are the SSF domains, along with the BSIMM’s definition of each one:

• Governance—“Those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.”

• Intelligence—“Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.”

• Secure Software Development Lifecycle (SSDL) Touchpoints—“Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.” The Touchpoints provide direct correlations with activities in the SDLC. The activity groups in this domain include Architectural Analysis, Code Review, and Security Testing.

• Deployment—“Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance, and other environment issues have direct impact on software security.”

The SSF makes it easy to identify and organize activities in which you should engage throughout the software development process. If you want to simplify the process of developing secure software even further, it all boils down to four areas of focus:

• Provide training in secure development—Untrained developers lack the understanding, skills, and motivation to expend extra effort to incorporate security into their code. That may sound harsh, but it is true. While software developers are generally savvy enough to get the training they need on their own, your organization will fall short of its secure software development goals if you ignore the need to provide comprehensive security training for your developers.

• Include security from the beginning—Don’t wait for coding to begin to include security concerns. Security goals should be part of the initial requirements and subsequent design of any software.

• Use secure programming techniques—Here’s where the training pays off. Since you know what attackers are looking for and what they can use to compromise an application, don’t give it to them. Write applications in a way that is not vulnerable to known tactics.

• Test for vulnerabilities—Part of the formal testing activities should include testing for security vulnerabilities.

Each language has its own set of known vulnerabilities and techniques to avoid them. Learn how to write solid, secure code in your languages of choice. While languages often suffer from different vulnerabilities, a few common programming errors lead to insecure code. If you can’t implement a complete secure application development initiative immediately, you can at least alert developers to avoid a few common pitfalls for code they write. Here are a few of the most common application vulnerabilities:

• Lack of input validation—Attackers know that developers often don’t validate data that come from user input. They use this known issue to launch buffer overflows, injection attacks, and other attacks that rely on a lack of input checking. To avoid this in your applications, confirm that every piece of data you receive is valid before you use it in any way. That means you should check the length of the data as well as the content for any characters that the software might interpret as commands.

• Information leakage through poor error handling—One of the early phases of any attack is reconnaissance. Attackers poke around to get information about your application and internal infrastructure. Error messages can be a problem. You want your error messages to provide enough information to understand what has happened but not enough to divulge internal details of your application or environment. Consider using coded error messages instead of explicit details.

• Sloppy authentication or encryption—Some applications store authentication credentials or encryption keys either in the application code or in easily accessed files. If attackers find these pieces of information, neither the authentication nor the encryption offers much data security. Carefully design how you’ll protect authentication credentials and encryption keys.

• Remote system access or code execution—Some applications allow users to access the server’s file system or run commands on the server. While the intention is to restrict what users can do, many software applications lack the controls to ensure users aren’t abusing this feature. Carefully validate any commands from users that will result in server access of any type.

• Dynamic code execution—Developers write many applications, and especially database applications, so that some code is dynamically generated before it is executed. This feature is an efficient way to handle complex database queries where you don’t know all of the query components until the user provides some input. Dynamic code is also helpful when code execution depends on data at run time. Using dynamic code also can make it easy for attackers to alter the intended commands and run malicious code dynamically. A secure application limits the use of dynamic code and aggressively validates any input to ensure it doesn’t contain malicious data or instructions.

These vulnerabilities are just a few of the opportunities application developers have to make code more securely. There is no substitute for good developer security training. Make sure to raise awareness of your developers on application vulnerabilities and encourage developers to write secure code. One of the advantages of structured development approaches, such as the SDLC you learned about earlier, is that it helps developers create more secure code. Structured development processes provide a framework to aid the entire development process. Developers have a structure that helps them write code from specifications, testers work with developers to test applications for functionality and security, and operations plays a part in the process by deploying code that passes testing. Each participant plays a part in providing secure software to users.