Software security for developers

Secure software development means consideration in every phase. Here are 9 key software security principles plus practical advice from a developer's point of view.

By Mark S. Merkow and Lakshmikanth Raghavan, authors of Secure and Resilient Software Development

September 27, 2010 — CSO —

Software is ubiquitous, even in places you wouldn't imagine. Software is so seamlessly interwoven into the fabric of modern living that it fades into the background without notice. We interact with software not only on home or office computers, but in our routine everyday activities—as we drive to the office in our cars, as we buy things at the supermarket, as we withdraw cash from an ATM, and even when we listen to music or make a phone call.

Just as software is everywhere, flaws in most of that software are everywhere too. Flaws in software can threaten the security and safety of the very systems on which they operate. The best way to prevent such vulnerabilities in software is to proactively incorporate security and other non-functional requirements into all phases of Software Development Lifecycle (SDLC).

Drawing on the best practices from our book Secure and Resilient Software Development this article summarizes some key activities required for integrating security into your SDLC and offers some recommendations and advice for implementing your own secure software development program.

We have also written a companion article on software security from the perspective of managing the application development process, looking at valuable concepts from OWASP's CLASP methodology and tools for building developer awareness.

Security Activities in the SDLC—An Overview

Security begins from within

The only reliable way to ensure that software is constructed secure and resilient is by integrating a security and resilience mindset and process throughout the entire software development life cycle (SDLC). From the earliest days of software development, studies have shown that the cost of remediating vulnerabilities or flaws in design are far lower when they're caught and fixed during the early requirements/design phases than after launching the software into production. Therefore, the earlier you integrate security processes into the development life cycle, the cheaper software development becomes in the long haul.

Many of these security processes are often just "common sense" improvements, and any organization can adopt them into its existing environment. There is no one right way to implement these processes—each organization will have to fine-tune and customize them for a specific development and operating environment. These process improvements add more accountability and structure into the system too.

Also see Security Testing of Custom Software Applications, excerpted from the authors' 2010 book Secure and Resilient Software Development, on CSOonline.com

Figure 1 provides a high-level overview of the fundamental security and resilience processes that should be integrated into the various SDLC phases, from requirements gathering to deployment. Each process yields its own findings, and recommendations are prepared for appropriate changes to design, architecture, source code, use of third-party components, deployment configurations, and other considerations to help you to better understand and reduce risk down to an acceptable level. Here you will find guidance on practices that you should consider implementing in each phase of the SDLC:

[Figure 1—Security in SDLC]

SDLC Phase Zero - Developer Training

Even though training does not fit directly into any particular SDLC phase, it plays a very important role in improving the overall security and resilience of developed software. Training should be a prerequisite for anyone who has a role anywhere in the software development environment. All developers and other technical members of the software design/development/test teams should undergo security training that explains the responsibilities of their role, establishes the expectations for their part for security and resilience, and provides best practices and guidance for developing high-quality software.

Training is most effective when it is custom-made to focus on the area of expertise/interest of the target audience (developers, QA, project managers, etc) and includes organization-specific processes, terminology, and practices.

SDLC Phase One: Requirements gathering and analysis

[Security in the Requirements Phase]

The key security and resilience activities during the requirements gathering and analysis phase are intended to map out and document the nonfunctional requirements (NFRs) for the system under development. It is vital to have these ready before the translation of business requirements into technical requirements begins; designers need to understand the constraints they are expected to face and be prepared to answer the call for security and resilience, as well as other NFRs. To be effective, business systems analysts and systems designers should be sure they are very familiar with the environment in which they are operating, by reviewing and maintaining their knowledge about:

• Organizational security policies and standards
• Organizational privacy policy (which may have varying requirements in different places)
• Regulatory requirements (Sarbanes-Oxley, HIPAA, etc.)
• Other relevant industry standards (PCI DSS, ANSI-X9 for banks, etc.)

NFRs are then mapped against the critical security and resilience goals of:

• Confidentiality and privacy
• Integrity
• Availability
• Non repudiation
• Auditing

Finally, these security requirements are prioritized and documented for subsequent phases.

• Print

• Security Testing of Custom Software Applications
• PCI Application Security: Who's Guarding the Data Bank?
• Source Code Analysis Tools: How to Choose and Use Them
• How to Evaluate (and Use) Web Application Security Scanners