5 Steps to Secure Development

By Darryl K. Taft
2008-03-14

Security should be top of mind before, during and after the development process.
Experts agree that although absolute application security is nearly impossible, there are key steps you should take to mitigate risk.

Step 1: Define the process

The first step is to define the process you're going to use to develop and measure the security of your software.

Software development has many phases, from requirements gathering through design, development, testing and deployment. You must consider how your existing processes must be augmented in every phase of development to include security, said Ben Chelf, chief technology officer at Coverity, a maker of static source code analysis tools.

"Defining the process includes thinking about coding standards for your developers to avoid potentially dangerous code constructs; thinking about how to design the system in a secure way so that there is no unintended access, even in the case where the code itself is bulletproof; and so on," Chelf said.

Security is not just something you can slap on at the end of the proc­ess after the system is put together, Chelf added. That is too late. With a good process in place that spans the entire software development life cycle, you can set up checkpoints to measure and verify that security is being addressed appropriately.

Step 2: Educate the players.

The second step in developing secure software is to educate the players in your software development organization.

Software security hasn't exactly been at the forefront of computer engineering, so chances are your developers, architects, product managers, QA (quality assurance) engineers and so on are not properly trained in what it means to design and implement secure software, Coverity's Chelf said.

"It's not just a matter of programming securely," Chelf said. "If you have a system that is perfectly implemented from a coding perspective but allows access because of poor password choices for the users, the system is still insecure. So it really does begin at the very earliest part of the software development life cycle."

Chelf said a variety of good resources, including books and online courses, are available for training developers on how systems can be compromised.

Step 3: Equip the team.

The third step to secure development is to equip team members with the tools and technologies that will help them build applications in a secure manner from the very beginning.

Chelf warned, however, that some of these tools can slow the process—something that irks business managers and developers alike.

"Make no mistake, adding security to your software development process can potentially slow down your release efforts," Chelf said. "And not only is time to market absolutely critical to your business, your developers also do not enjoy anything that is added to their process that slows them down."

Fortunately, tools are available that can help developers be more secure and more efficient, Chelf said. Static code analysis is a great way to counteract the otherwise-onerous process of manually reviewing an entire code base for security vulnerabilities—a task no one really wants to undertake, he said.

Tools and technologies are available to help organizations with verification, validation and security and to help enhance software integrity throughout the system.

"The benefits gained by discovering defects earlier in the software development process counterbalance the additional time you are asking your developers to spend in developing secure code," Chelf said. "I recommend picking tools that are designed for the developer.

Step 4: Test and test again.

The fourth step in developing for security is to employ security-testing techniques.

In the past, verification—ensuring a program did not fail—and validation—ensuring a program did what it was supposed to do—were the primary tasks a software development organization needed to address prior to release, Chelf said.

"[However,] the difference between verification/validation and security is that it is much more difficult to test for security," he said. "Testing to make sure the program runs correctly and does not fail is something observable. Testing to see if a certain failure could be exploited is much more difficult to observe."

Part of this stems from the fact that, when developing software with security in mind, you're developing against an adversary, Chelf said.

"This is a much different paradigm than simply trying to make your customers happy with features that work," he said. "And when working against an adversary, you must concern yourself with not only whether a system fails, but how exactly it fails, because that hacker will try every mode of failure he or she can to try to uncover the weakness in your system.

"The reality is that even if your application fails 99.9999 percent of the time in a secure way, some hacker out there likely will uncover that one-in-a-million failure mode to exploit your application," he said. "And that is very difficult to test for."

Step 5: Monitor the process.

Lastly, compliance with security policies should be monitored on an ongoing basis.

"Monitor compliance to security policies using an automated infrastructure," Parasoft's Kolawa said. "At a scheduled time each night, the automated infrastructure should retrieve the latest code modifications from source control and determine whether that code complies with the security policy. If a problem is found, the developer who introduced it should be notified within his or her IDE [integrated development environment] to promote fast remediation."

This step also includes security code reviews and maintaining security vigilance as applications move into production.

"No development project, no matter how well-designed or executed, will remain 100 percent secure 100 percent of the time if left to its own devices," said Andrew Zaikin, a security expert and project director at outsourcing specialist Exigen Services.

"Watch production, read production logs as they are being developed, and stay involved on a consistent and continual basis," Zaikin said.