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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
Various resources are available to help you enhance your software development life cycle, and in turn, produce higher-quality, more secure applications long term. The following papers and standards cover both information security and secure coding and offer insight, principles, and processes that you can integrate immediately to improve software security:
- NIST Special Publication 800-64-Security Considerations in the Information System Development Life Cycle
- NIST Special Publication 800-27-Engineering Principles for Information Technology Security
- NIST Special Publication 800-55-Security Metrics Guide for Information Technology Systems
- ISO/IEC 12207:1995-Information technology-Software life cycle processes
- ISO/IEC 17799:2005-Information technology-Security techniques-Code of practice for information security management
- Microsoft’s Trustworthy Computing Security Development Lifecycle paper
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.
Caleb Sima is the co-founder of SPI Dynamics, a Web application security products company. He currently serves as the CTO and director of SPI Labs, SPI Dynamics R&D security team. Prior to co-founding SPI Dynamics, Caleb was a member of the elite X-Force R&D team at Internet Security Systems, and worked as a security engineer for S1 Corporation. Caleb is a regular speaker and press resource on Web application security testing methods and has contributed to (IN)Secure Magazine, Baseline Magazine and been featured in the Associated Press.
Kevin Beaver founder of Atlanta-based Principle Logic, LLC is an independent information security consultant, author, and speaker. He has over 18 years of experience in IT and specializes in performing information security assessments. Before starting his own information security services business five years ago, Kevin served in various information technology and security companies.
