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.
| Broken Access Control | Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions. |
| Broken Account and Session Management | Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities. |
| Buffer Overflows | Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components. |
| Command Injection Flaws | Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application. |
| Cross-Site Scription (XSS) Flaws | The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user. |
| Error Handling Problems | Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. |
| Insecure Use of Cryptography | Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. |
| Remote Administration Flaws | Many web applications allow administrators to access the site using a web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site. |
| Unvalidated Parameters | Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application. |
| Web and Application Server Misconfiguration | Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box. |
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.