eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Most organizations have a formal risk management process in place. Many have already ranked their applications based on answers to questions such as: “How critical is the application?”, “Does the application touch certain sensitive data?” and “Is there a Web-facing component?”
However, organizations tend to struggle with the ability to quantify
First, it ensures that you are covered for your compliance requirements with respect to application development. Second, it provides a mechanism for measuring application security within the same risk management framework you’re already using. And third, it allows you to create more secure applications, which will reduce the risk exposure of your business and minimize the “VaR” (Value at Risk) that is managed by your applications.
Step 1: Prioritize Applications
Starting with a pilot application provides a baseline from which to grow. Many organizations will change the risk ranking of an application after it has gone through a security assessment. There are two reasons why this is done: either because they have become aware of vulnerabilities in an application or, just as often, they remain aware of vulnerabilities that are already protected against (via a compensating control that had already been put in place).
Conducting an analysis of existing software development processes allows you to construct a gap analysis, as well as identify specific activities in the SDLC that need to be improved with respect to security. It also helps determine if the application development team, whether they are in-house or outsourced, understand the requirements and policies to which they are being asked to adhere.
The second component of this stage is to measure the security quality of a pilot application via a code review and/or penetration testing, which provides a baseline from which to measure improvement.
Step 2: Construct Guidelines
The next step is to construct high-level security guidance for team members. This is driven by the gap analysis performed in Step 1 and is mapped to your specific security policies. Many organizations already have these high-level guidelines in place, as they may have been adapted from an industry “standard” such as ISO 17799 or OWASP. The challenge with adapted standards is that they provide no context for your organization, and are either very vague ( ISO) or limited (OWASP).
The best approach is to adopt and roll out security guidelines that are specific to your organization and software development process. You need to include “gates” so it is clear when (and why) a project is allowed to be passed on to the next team member and phase of the SDLC. It is irrelevant whether your applications are built internally or outsourced. Once you have guidelines defined for each team member and role (such as architect or developer), you can “outsource” the development phase quite easily. It doesn’t matter if the development team exists physically or logistically, as long as they are held to the defined security and design requirements.
Step 3: Define Corporate Standards
The next step is to detail those guidelines and tie them into your information security policies, data classification standards and any regulatory initiatives to which you must comply (such as PCI, Sarbanes-Oxley Act or Health Insurance Portability and Accountability Act). The purpose of this step is to create corporate standards for secure application development. Many requirements, such as PCI, require that you adopt and document “industry best practices for secure application development.” That is precisely what this step is intended to achieve.
As with all good security standards and policies, you need to create easily understandable and implementable procedures for those policies. This includes policy “translation”-the ability to bridge the gap between business risk policies and how they are interpreted and implemented by the software development team or teams.
Step 4: Train Your Teams
Once you have built your policies, constructed your corporate secure coding standards and provided procedures for implementation, you need to give your people the training they need to implement correctly. Training should not be limited to technical training for your development team. Managers, business analysts and internal auditors or security assessors also need to be trained. A good curriculum will include 100-level “awareness” training, as well as 200- and 300-level courses for roles such as manager, business analyst, architect or developer.
Step 5: Identify Tools and Metrics
The identification of appropriate tools your team will use should go hand-in-hand with the training. It is important that you select the right tools for defining, developing and testing your applications. It is also crucial that you choose tools for security guidance and integration into your existing workflows and risk management procedures.
No program can be successful without the ability to measure its progress. Therefore, the definition of metrics is critical. Context is extremely important. You need to select metrics that are meaningful to you and your organization. A common metric is “Security Requirements Coverage”-how many of your active projects are meeting 75 percent or more of the defined security requirements. However, there are many other metrics suitable for your organization’s objectives. Be sure to spend some time determining what they should be.
Prior to Security Innovation, Mr. Adams held senior management positions at Ipswitch; VeriTest, a division of Lionbridge Technologies; Rational Software (now IBM), Logistic Solutions; MathSoft; Foster-Miller; and two U.S. Army Research Labs. He earned his MBA degree with honors from Boston College, and has B.A. degrees in Mechanical Engineering and English Literature from the University of Massachusetts. Ed Adams can be reached at eadams@securityinnovation.com.