Observed Secure Software Development Stages

A secure software development process cannot be built overnight. Organizations gradually adopt security activities based on factors like culture, customer demand, regulations, budget, and security incidents. Each organization adds security practices at different rates; however, most organizations do so in a predictable order. This common order is a reflection of how businesses today use trial and error to find an appropriate set of processes and practices to grow a secure development process.

This order can be broken down into six stages. While few organizations fit exactly within one stage or another, this model can be used to facilitate discussions about an organization’s current progress. The model does not seek to validate whether the six stages constitute an appropriate secure software development roadmap, instead; it simply describes a common progression observed in organizations today. Models like the Software Assurance Maturity Model (SAMM) and Building Security In Maturity Model (BSIMM) are more appropriate models for determining the proper direction of an organization’s secure development process.

Stage 1: Focus on Functionality

Initially, organizations are fairly ignorant of secure development practices. Computer science curriculum often does not include a class on security best practices or ways prevent cross-site scripting vulnerabilities. Developers are taught how to write code to satisfy business requirements.

Secure software development also isn’t high on executives’ list of priorities. Their focus is on producing innovative products or services, being first to market, and making net income goals.

Security usually does not become a priority until an incident occurs, whether a competitor has a data breach or the organization itself is hacked. Once this tipping point occurs, security dollars quickly become available. Organizations spend their new security budget on third-party application assessments, which provide an insight into the security posture of information technology assets.

Stage 2: Assessments Alone

Once an organization starts performing security assessments in response to a breach, it typically extends this activity for use as an approval mechanism. The organization requires sensitive or business critical applications to be assessed prior to new releases being deployed to production. This approach greatly reduces the number and severity of vulnerabilities in external facing applications; however, it doesn’t identify security weaknesses until after the application is fully developed.

Vulnerabilities that highlight a systemic weakness or architectural flaw will often result in project delays and unanticipated costs. Additionally, this approach does not train developers to implement code securely during the initial development stage.

After performing assessments as the only software security activity, the organization eventually realizes that a proactive approach is needed. They determine that issues should be identified early in the development process and opt for purchasing automated code review or penetration testing tools.

Stage 3: Ad-hoc Use of Security Tools and Activities

After providing automated code review or penetration testing tools to developers, organizations expect all their application security challenges to be solved. They tell developers that they need to run the tool on their code and fix all the issues. The organization’s goal is to have production ready software at the conclusion of the development process. The actual results of this approach vary.

Development groups composed of security savvy members usually see an overall reduction in vulnerabilities. The other development groups may only see a moderate impact. There are a variety of reasons this happens. The primary reason is that the tools can identify plenty of problems, but the developers don’t have the knowledge necessary to understand all the risks or to apply security best practice recommendations. Other challenges include the inability of automated tools to find business logic, authorization, and authentication flaws; inconsistent company procedures and checkpoints associated with running the tools; and no minimum standard set for acceptable risk levels.

Organizations also may adopt security activities such as threat modeling, secure requirements specification, and design reviews. These activities produce greater awareness of security issues facing applications, but the developers’ still lack the knowledge and experience necessary to really take advantage of these proactive security activities.

Stage 4: Application Security Training

The next logical step for organizations is to provide application security training to development groups. This comes in the form of in person classes, on-boarding training, and annual refreshers. The class content often includes a general background in application security, introduction to common vulnerabilities and attacks, and best practice approaches for eliminating preventing and remediating issues.

Application security training greatly improves developers’ ability to succeed at the organizations continued use of automated tools and third party assessments. Developers gain a common language to discuss application security concerns, can understand and address vulnerabilities in a timely manner, and the training can inspire developers to pursue additional research.

One aspect most organizations leave out is reinforcing and supplementing training with internal resources. Many developers receive training once a year in application security. After six months, most of the knowledge gained during the class is forgotten.

Stage 5: Creation of Resources, Formal Policies, Procedures and Standards

In order to ensure consistent use of security tools and activities, organizations choose to formalize the policies, procedures, and standards developed over the previous four stages. Criteria is created for evaluating the sensitivity or importance of applications, security activities are formally required for each of these categories, and security gates are put in place to ensure a minimum standard of security is met before software advances in the development process.

An internal application security portal is also created to make these policies and additional resources available to developers. These resources communicate information about standardized methods for addressing vulnerabilities in code, approved development languages and frameworks, and internally developed secure libraries and architectures.

Ultimately, this results in the elimination of ad-hoc security activities and promotes consistent development of applications with fewer security vulnerabilities.

Stage 6: Secure Software Assurance

In the last stage, organizations tailor security activities and requirements to satisfy business goals and leverage efforts as a competitive advantage. Before an application is developed, a set of security requirements is established. For each security activity, the organization defines a test procedure and criteria for determining whether the application passes or fails the security requirement. Test results are recorded and reported across the application’s lifetime to form an overall picture of the application’s security posture.

Turn Application Assessment Reports into Training Classes

So you had a third party application assessment and you have a report 10 miles long. There are cross-site scripting, SQL injection, authentication, authorization, and every other kind of vulnerability under the sun listed. Your development team gears up and remediates issues, often using trial and error (patch, retest, pray, and repeat) to fix issues over several iterations. Eventually, all the vulnerabilities have been addressed successfully and you file the report away forever...

Stop Right There! There's an opportunity to use a real application within your organization to train developers to write secure code THE FIRST TIME! Here's how:


Taking the Time to Analyze Root Causes and Develop Standards

Now that the fire is out (the issues are fixed), let's take some time to understand how the vulnerabilities were created in the first place. Was it a result of missing output encoding practices, inconsistent page-level access controls, or some other issue? Gather a list of root causes that resulted in the identified weakness.

Next, use security experts or online resources, like OWASP, to find security best practice solutions for eliminating these vulnerabilities. Some great examples are the OWASP XSS Prevention Cheat Sheet or the OWASP SQL Injection Prevention Cheat Sheet. Finally, create a centralized application security portal or wiki that developers can access and add these root causes and best practice solutions as official company standards.

Bullet Points:

• Create a centralized application security portal or wiki
• As you analyze root causes and find security best practice approaches to fix them, add them as standards to the portal

Archive the Vulnerable Application Code for Later Use

After completing the third party assessment, you now possess real world vulnerability examples and a report that lists each issue, including the page and parameters vulnerable and a guide for exploiting them. This report and the vulnerable application will be a great learning tool to be leveraged later. Archive the vulnerable application code and any other related components. Make sure it is possible to restore this application to a working state within a test environment at a later date.

Bullet Points:

• Archive the application and related components to be deployed within a test environment at a later date

Conduct Developer Training

In the weeks before hosting a training course, generate developer interest by deploying the vulnerable application within a well controlled, internal, isolated, secure... you get the idea... test environment. Send application URLs and credentials to developers and tell them what classes of vulnerabilities can be found (refer to your assessment report). Encourage developers to test and discover security issues individually until the training class.

In the training class, go through each vulnerability class or root cause with developers. Demonstrate application security attacks against the weaknesses using the vulnerable application deployed to the test environment as a real world example. Once you have gone through each vulnerability type, ask developers to discuss other areas of the application they identified as vulnerable during the preceding weeks. After the discussion, have developers break up into groups to find any remaining issues. Give hints as the number of remaining vulnerabilities dwindles.

Once all the issues have been found by developers or demonstrated by the instructor, ask developers for methods of addressing each vulnerability class. Intentionally choose suggestions that are missing key security best practice concepts. Have developers come up to the presentation computer and code solutions on the spot; then, discuss reasons why the solution is flawed, and prove it with an example attack.

After going through a few proposed solutions, discuss the root cause that lead to the security weakness. Provide the best practice solution for eliminating the issue and preventing it in future code. Finally, show developers where they can access this company standard on the internal portal or wiki and have a developer implement the solution to fix the vulnerability on the spot.

Bullet Points:

• Generate developer interest in the training course by allowing them to hack the vulnerable application
• During the training course, discuss vulnerability classes, root causes, incorrect remediation solutions, security best practice based recommendations, and where to find company standards

Conclusion

Turning application security reports into company security standards and training courses is a great way to increase the return on investment for third party assessments. The suggestions discussed in the article above will greatly help developers succeed at writing secure code in future web applications. The process also uses meaningful real world applications to demonstrate the concepts and promote interest.

Some of these steps may require security savvy developers or security experts. If you would like assistance developing training courses, identifying root causes, or documenting security standards, please feel free to send me an email. I can be contacted at <My First Name>.<My Last Name>@gmail.com.

AT&T Acquires VeriSign's Global Security Consulting Business

We've been acquired! I am now an AT&T employee. Check out the press release here: http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=27183.

For a list of professional services offered related to security, see this page: http://www.corp.att.com/consulting/security/ (especially Application Security Services).