Development Life Cycle: When to Secure Your Process

By | May 8, 2006

When it comes to software security, the general perception is that including technologies such as firewalls, intrusion prevention systems, and malware protection throughout the software development life cycle is all that’s needed to keep information secure in the end product. However, these technologies are mostly reactive in nature and don’t prevent the vulnerabilities in the first place.

Also, at the development level, there’s a lot of talk about testing for buffer overruns, validating user input, using the principle of least privilege, and so on. These are certainly solid practices, but there’s still a considerable gap when it comes to getting to the root of software flaws – the development process itself.

Web application security is extremely complex and constantly changing and there’s more to it than just technical controls. Whether it’s commercial or in-house, any type of code from firmware to client-server programs to Web applications can benefit from a solid and proven development process. A solid development process throughout the software development life cycle will not only ensure proper expectations are set within the team, help reduce development time, and improve quality, but it can also help make major software security improvements along the way. This all may seem too idealistic, but it can be done. As a result, both in the short term and the long run, software security flaws can be drastically reduced and organizations can lower their dependence on technical safeguards working reactively to cover up the true problem.

There are six common weaknesses in the software development life cycle that lead to vulnerable code, and inevitably, security exploits.

Not understanding the long-term consequences of a weak security process – Certain software security flaws may not be quite so obvious. It may take several software revisions before they’re discovered. Other software security flaws may not show up for years. Regardless, they’re still being baked in which create long-term problems. Much of this can be traced back to weak security processes throughout the software development life cycle, such as not performing threat modeling, not establishing and following software security standards, and using the proper testing tools to uncover software security weaknesses.

Business goals conflict with security during each phase – Regardless of what anyone in development, product management, or marketing says, there’s still less focus on software security and more focus on delivering feature-rich applications that can deliver as close to everything-to-everyone as possible. Throughout the software development life cycle – from planning to ongoing maintenance – time is of the essence in each phase. Time to market drives the majority of projects, and quite often during time crunches, security oversight occurs, sloppiness ensues, and otherwise solid code is placed on the “back burner” to be fixed later.

Viewing security requirements in the wrong context – Product managers, developers, and customers alike are not always aware of the actual and potential software security issues during the software development life cycle. This often leads to the “we have/require a layered defense – a firewall, user authentication, and file access controls – what more do we need” mentality. Software security goes way beyond these reactive controls. Like the architectural and environmental intricacies associated with a land developer planning a new neighborhood, security vulnerabilities must be understood and controls must be made part of the software during the initial requirements phase of the software development life cycle. Likewise, similar to the foundation and framing of a house, if software security is not integrated up front in the design “blueprints” of the software, it can be very difficult and expensive to go back and make changes once the building begins.

Not developing with security in mind – Once requirements are established and projects are in full swing, it’s common for developers to get back to what they know and do best (writing code) and not focusing on software security throughout the software development life cycle. Quite often, the only focus is on the bare minimum security controls and not integrating security with the big picture goals of the project. This can be due to a lack of security education on the part of developers but can also be attributed to lack of security buy-in, unclear security requirements, or a general lack of project leadership during the software development life cycle.

Glazing over security during testing – Many software security controls operate independently as individual components and should be tested as such. Furthermore, flaws may only be obvious during the early unit testing stages. However, software security testing is often “saved” for later in the software development life cycle – during integration testing or post-implementation reviews – thus allowing flaws or inadequate controls to be overlooked. Likewise, integration testing can highlight flaws in interrelated components that might not readily show up during unit testing. It’s therefore important to ensure that security testing using the proper static analysis and penetration tools be performed during each testing phase of the software development life cycle, as well as once the software is implemented.

Not using the right security testing tools – It’s one thing to develop with security in mind but quite another to use professional tools discover flaws during the software development life cycle that may otherwise be difficult or impossible for humans to find. Proper security testing tools used during threat modeling, coding, QA, and subsequent penetration testing processes are essential for looking at the big picture context as well as drilling down at a granular level to root out security-related problems at every possible phase of the software development life cycle.

Fortunately, there are software products available that can help you solve these problems without slowing aggressive project schedules. The application assessment software available today targets both developers and testers. Many developer products are integrated with popular IDEs, such as Microsoft’s Visual Studio .NET, and many security testing products are integrated with popular testing platforms like Mercury.

There is some work to do, however, in setting management goals. It is management’s responsibility to mandate secure applications. Vulnerabilities in software security must be treated like any other software defect. Smart development organizations know that it makes financial and organizational sense to do it right the first time, at the beginning of the software development life cycle.

Resolving problems in the development process and integrating security every step of the software development life cycle is much easier said than done and the business risks and costs must be balanced with rewards. However, it’s clear that strengthening the software development life cycle, possessing the right security testing tools, and placing software security higher in the priority list is an excellent and invaluable long-term business investment. Integrate such improvements and make small changes over time. This will lay the groundwork for a streamlined development process long term. You’ll be there before you know it.

Leave a Reply