It’s not exactly been a banner year for the Windows brand. Microsoft released Vista in early 2007 only to be met with a lukewarm reception from both the enterprise and personal computing markets. Dell is also ramping up efforts to offer a Linux alternative to Windows for customers purchasing new computers from the store.

It’s not just the private sector, however, that is displaying hesitancy to upgrade to Windows Vista. Government agencies such as the Federal Aviation Administration have publicly acknowledged the fact that finding alternatives to Microsoft products, such as Linux-based operating systems and Google’s Premier Apps office suite, is becoming a higher priority.

The FAAs efforts in this regard seemed to have worked their way up the pipeline, as now the Department of Transportation, the entity under which the FAA is affiliated, has officially prohibiting upgrades to Windows Vista, as is the National Institute of Standards and Technology.

Here’s an excerpt from a January DOT memo documenting the rational behind such a decision:

Based on our initial analysis (from internal recommendations and analysis provided by Gartner Group), there appears to be no compelling technical or business case for upgrading to these new Microsoft products. Furthermore, there appears to be specific reasons not to upgrade including:

·    The cost of performing the upgrade (hardware/software upgrades, application upgrades, labor for planning and implementation, etc.)

·    Previous version compatibility concerns regarding Office 2007 suite components (primarily Word)

·    The protracted FY07 Continuing Resolution (CR) which limits available funding

·    The more to the new Headquarters DOT building that would be competing with the same IT expertise required to support the migration to any of these products

So, not only are these government agencies effectively banning the implementation of Windows Vista, but they are also preventing users from upgrading to the latest versions of Microsoft Office and Internet Explorer, a move that the top brass in Redmond can’t be too thrilled about.

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.