Security and the Application Development Process

RFG believes incorporating application security protections into the software development life cycle early is essential for today’s application deployment scenarios, especially for Web based applications where security is much more challenging. Writing secure code is an aspect of quality assurance and must have ongoing attention rather than be an afterthought. IT executives should review application development processes and add or enhance security-related development practices, if their risk management analysis directs such action.

Business Imperatives:

• Writing secure code is one aspect of writing quality code. Security must be part of an ongoing process, because it cannot be added effectively at the end of production. In this way security is similar to testing, in that it can improve confidence in quality and reliability, but cannot prove them. Like testing, security should not be an afterthought and can be incorporated into any development environment and methodology. IT executives should ensure development managers take into account application security requirements up front and persuade developers to address them early and throughout the development life cycle.
• The best protection comes from a bulletproof, practical, rigorous, and scalable process that includes security as well as other clear requirements. It is essential to use non-development experts, either internal or external, with security experience and knowledge of the enterprise’s security infrastructure. IT executives and development managers should learn and apply those best practices, and work with security experts to ensure developers apply their knowledge.
• Security is not only an issue for in-house developed applications. Many security breaches occur through commercial software. Enterprises can and should apply and demand the same security requirements on commercial providers as used in-house. Contract provisions for third-party application developments should provide enforceable and effective protection regarding enterprise application security. In addition, patch management plays an important role in any application security program. IT executives should evaluate and oblige vendors to include appropriate security precautions in their development processes, and include security testing as part of any commercial product implementation, rollout, or upgrade process.

No one in IT needs to be told security is a problem in modern enterprise systems. The ease of intruding and wreaking havoc on corporate systems is all too tempting to those with bad intentions. Furthermore, deploying applications into complex target environments can make security scrutiny problematic. However, enterprises are taking aggressive steps to reduce the potential for security breaches. Any security plan for enterprises is incomplete without scrutiny of in-house developed applications in addition to commercial products. The security should also reflect the importance of the business application to the enterprise critical applications should be protected by robust security at all points to adequately protect enterprise information assets.

Tackling security in the application development process requires a holistic approach. Security in application development is a risk management endeavor because, while it can never be perfect, steps can be taken to lower security vulnerabilities in the development process. For most issues, one faces the choice of mitigation or elimination (it’s a matter of degree) and a process for making that determination needs to reflect the organization’s priorities and governance policies.

While trying to shore up security of the applications, other IT initiatives may work against it. For example, Web services are touted as an important element of enterprise connectivity and operations for the future. However, Web services using standards such as XML and the Simple Object Access Protocol (SOAP) may present new security challenges as they are used to “open up” applications and systems for easier access, use, and viewing. Web services also operate in a disconnected or loosely coupled environment where the many different points of access typically have no knowledge of each other. Consequently, security risks can appear at any time from many different areas that are not easy for IT security systems to detect.

Important IT initiatives, such as security in the development life cycle, logically separate into people, process, and product components. IT executives should develop business application profiles (BAPs) and user application profiles (UAPs) to identify the security risks for all enterprise applications. People need the proper skills and motivation to add security to their long list of responsibilities; these should be reflected in the BAP. Processes must reflect the intolerance of anything but the most complete integration and scrutiny of security in applications. The product dimension includes application assessment tools, testing tools, process management tools, and the whole range of application development tools that offer project management support.

Any security initiative should have the people, process, and product/services components backed up with executive awareness and sponsorship, as well as proper testing before rollout, to increase likelihood of success. Furthermore, any requirement should be reviewed for security issues, in addition to integration-oriented security issues. At the same time components or subsystems are specified their security vulnerabilities should be made explicit if possible.

Process First

In the absence of a bulletproof, practical, rigorous, scalable process, a number of steps may be taken to improve resistance to attack and mitigate risks. Most are common best practices for review of intermediate deliverables, including inspections, reviews, and walkthroughs. Some, however, are specific to identifying classes of potential threats and creating test scenarios to mitigate their risks.

The Common Criteria (CC) for IT Security Evaluation is from the Computer Security Resource Center of the National Institute of Standards and Technology (NIST). CC Version 2.0 became the international standard ISO 15408 in 1999 and provides a continuously updated set of evaluation criteria. The CC is explicitly methodology-independent and international in scope. CC should be used in the context of a modern (iterative, non-waterfall) approach supported by automated tools. It is ideal to use an approach based on the Unified Modeling Language (UML), such as the Model Driven Architecture (MDA) process developed by the Object Management Group.

Commercial products brought into the enterprise need security scrutiny as well. Determining a vendor’s internal security practices while developing code is a difficult endeavor. However, IT executives should ask hard questions of the vendors to get a sense of the vendor’s commitment to security in applications. Results of evaluation and testing of products by organizations such as the Common Criteria Evaluation and Validation Scheme for IT Security (CCEVS) are available for scrutiny. In addition, there are many sources of vulnerability information, including the CERT Coordination Center (CERT/CC). Other software security standards exist and can provide further guidance.

In addition, external access to applications and systems must be controlled. In the planning stages, analysts and developers must consider the potential users of applications and their security risks. The BAP and UAP should be referenced as the two key documents to help IT staffs to identify the security requirements for the end-to-end delivery of the application to its users.

Also on the process side, effective top-down security requires the availability of a corporate security policy that clearly sets the tone and direction for protecting information assets. A sound workable policy with a security architecture to back it up constitutes the foundation of application development security initiatives.

As an ingredient of development of secure code, patch management efforts must be inherent in enterprise security strategies. To ensure that all necessary patches are deployed in a timely and cost-effective manner, IT executives should develop application risk assessments and patching procedures that include change management, integral audit, and notification steps. Development managers should be involved in these activities to ensure their concerns and constraints are accounted for, so they fully understand patch status (including, when possible, clear identification of all patches made by date, individual, and time) when upgrading or rolling out new applications.

Standard best practices, such as review of intermediate deliverables, including inspections, reviews, and walkthroughs for software development also aid in ensuring secure applications. IT executives should ensure the proper level of knowledge and, where possible, proper implementation of standard methodologies and tools for the software development life cycle.

New technologies are often the source of security vulnerabilities unless they are reviewed carefully to uncover all potential security weaknesses that must be addressed. Web-based applications are more widely deployed, and while they provide easy access they also present security holes. Developers are not entirely knowledgeable of these vulnerabilities and often leave openings in their applications. Common examples of security vulnerabilities in Web applications are shown in the figure below. IT executives and development managers should be sure developers have proper training on new technologies and their security vulnerabilities.

Source: Open Web Application Security Project (OWASP)

The summary point of the process discussion is that development teams should focus on security before concentrating on features. While business pressures often encourage the opposite, a narrow focus on meeting feature requirements typically leads to not only security problems but also general quality issues with applications.

People

There are three main issues around people with regards to building security into applications. One is the issue of internal or external personnel intent on doing damage. The second people issue is getting the developers to effectively use the processes. Third, proper security knowledge must be available to development teams so that they can implement adequate security mechanisms.

Establishing an application security plan requires IT to identify the risk factors presented by the applications deployed and the users accessing them. IT executives should develop business application profiles (BAPs) and user application profiles (UAPs) to identify the security risks for all enterprise applications. IT executives should then address each of the security risk factors presented by those applications, and develop security-focused action plans to address each risk area. Likewise, development teams should understand the security plan and enforce it in their practices. Furthermore, the plan should also be audited by an external group on a frequent basis to verify compliance.

While one can assume that application development people are inherently motivated to produce their best work, it helps to make this an explicit part of their evaluation criteria to reinforce the desired behavior. This is similar to human resources issues encountered when an enterprise decides that reuse should be encouraged, although the cost to develop reusable components is hard to justify to project managers who don’t reap the rewards directly. Likewise, the cost and effort to build secure systems must be factored into development plans and spread across the entire organization that will see the benefits, which are rarely visible at the project level. There must be a baseline level of security that covers the enterprise and is amortized to everyone. Higher levels of security can and should be charged back as needed to the appropriate lines of business (LOBs).

Essential, then, is a long-term view that explicitly ties development team compensation to meeting defined security goals. This is difficult in IT environments with high personnel turnover, so the alternative would be to make the link indirectly through product metrics like the Common Criteria that act as a proxy for secure code (that is, meet the metrics to make the bonus). In addition, development staff must have proper security training and other security staff ought to be involved in development projects throughout the life cycle. Proper staffing for security is critical, not only for development security initiatives but also for any enterprise.

Products and Services

The product dimension for security includes process management tools, testing tools, and other application development tools that offer project management support. These include enterprise development suites as well as project management solutions. Development suites should contain security controls to create security mechanisms or access standard security components. In addition, vulnerability assessment services and tools are available.

Some vendors maintain security assistance for developers. Microsoft Corp., for example, while often in the news for security vulnerabilities of its products, hosts the Microsoft Security Developer Center. This site contains various approaches to finding security code defects during the development process. Microsoft Press also published a book on the topic Writing Secure Code, Second Edition by Michael Howard and David LeBlanc.

IBM Corp., for its part, maintains information about secure coding including articles, education, events, and project information in its developerWorks Security section. Recent perusal of this source shows an extensive source of articles on security related to development of applications using CGI, cryptography, Java, Linux, macros, Web Services, Wi-Fi, and XML. In a regular column on the IBM site, “Secure programmer: Developing secure programs,” David Wheeler of the Institute for Defense Analyses authors this first article that introduces the “basic ideas of how to write secure applications and discusses how to identify the security requirements for your specific application.” Such sources can help developers begin to think about security in coding and provide baseline direction for addressing the knowledge challenge.

Firms such as Cigital, Inc., Guardent, Inc., HBGary, LLC and SecureSoftware, Inc. offer relevant services ranging from application reviews to managed security services with disaster recovery capabilities. Such organizations have experience addressing software security challenges in a variety of enterprises and typically bring tested approaches and methodologies for building secure software, including software architecture reviews and source code audits. Cigital and SoftwareSecurity experts wrote the book “Building Secure Software: How to Avoid Security Problems the Right Way” and in it assert that software is at the root of all common security problems.

In summary, writing secure code is an essential part of improving the overall technology security situation. However, preventative measures that can be taken in the development process are overshadowed by reactive measures executed after deployment. This mentality needs to change, and enterprises doing software development should embrace security requirements early and often in the software development life cycle.

RFG believes writing secure application code is an integral component of the overall enterprise security architecture. Unless application requirements are identified up front it is difficult for the development process to implement the required levels of security. The lack of application security requirements and associated poor security focus in the development process can cripple business application security leading to significant revenue loss and perhaps liability claims from anyone impacted by this oversight. IT executives should review application development processes and direct development teams to build in security, rather than consider it after the application deployment.

RFG analyst Ron Exler wrote this note. Interested readers should contact Client Services to arrange further discussion or an interview with Mr. Exler.