As a Security Consultant, I have the privilege of witnessing many application security programs. I see programs that work great, are healthy, and handle risk management very well. Then there are programs that have either missed the mark completely, or are healthy but have some maturing to do.

In this blog I’ll be focusing on organizations or development teams that use a more traditional “waterfall” style approach to application development. I’ll attempt to identify traits of a healthy application security program in order to provide ideas for programs that could use some maturing. If your organization uses a more modern “agile,” “iterative,” or “kanban” style of development we will address those specific challenges in Part 2 of the series.

I’m sure many of us have heard that successful application security programs engage security from the get-go, before any actual code is written. I can tell you from experience, this is true. Before we continue down this path of what makes a good application security program, let’s first make sure we understand what a good application security program will NOT guarantee:

  1. Even good application security programs still have some bugs that get through. There is no guarantee that all vulnerabilities will be caught.
  2. No single model will work for all situations, though there are components that should be included in every program.
  3. No program is perfect, nor is a good application security program set up just once and forgotten about. Consistent and intentional improvements are necessary.

The following list provides a high-level view of program components that I’ve seen first-hand, that work well in successful application security programs.

  1. Top-level support. Trust and support from the top of the executive chain of command is imperative.No program should ever be considered successful without support from top leadership.
  2. Culture of sharing, trust and support. A corporate culture that understands business risk and the importance of managing that risk, and that has impeccable interdepartmental relationship-building practices, is essential. Application security programs often involve several different departments. Developers, project managers, network engineers, systems administrators, systems architects, and security personnel, all need to work together to see the Software Development Life Cycle (SDLC) through to completion. A lack of trust between key players can introduce unnecessary inefficiencies into a project.
  3. Developer security training. I’ve seen programs where the application security team trains developers on the OWASP top 10, and includes specific code examples for common application vulnerabilities. This usually works well when using application security staff to perform training. Otherwise, there are plenty of options for third-party secure development training and application security staff training programs.
  4. Continual training for the application security team. This is a must to keep up with constantly changing technology and attack techniques. Continual training on soft skills is also helpful to maintain items 1 and 2 from the list above.
  5. Standards and policy documentation (along with minimum baseline configurations). Having well-written, easy-to-understand standards and policies, and making them easily accessible, can be extremely helpful in aiding developers and infrastructure teams in implementing secure practices. These documents should be reviewed at least annually, and quarterly if possible, based on resource availability.
  6. Process for handling and approving exceptions to standards/policies. No application completely follows all corporate standards and policies. To handle these cases, strong application security programs must have a way of handling exceptions. Typically this means the project team needs a plan for remediation in place, and the application security team and its leadership enforces a strict timeline for remediation.
  7. Effective documentationthrough each phase of the SDLC. It is absolutely imperative for development and infrastructure teams to create detailed documentation for every part of the application and application infrastructure. It is equally important that the application security team reviews all documentation from the start of the project. Some successful programs even go as far as requiring security sign-off for each phase of the SDLC before moving onto the next. Sign-off comes when the application security team makes sure each phase complies with the standards and policies in place, and doesn’t introduce unnecessary vulnerabilities.
  8. Security group engaged in design phase and throughout the entire SDLC. From the start of the project until release, the application security team should review all documentation involved in developing the application with the hopes of identifying security risks in each phase of planning and development.
  9. Dynamic and static code analysis. This phase aims to identify vulnerabilities using mainly automated tools and perhaps manual code review. Dynamic analysis includes automated application layer vulnerability scanners. Static analysis includes automated tools and can include manual analysis if resources are available.
  10. Application penetration assessments (enhances the dynamic and static code analysis and includes the infrastructure hosting the applications). Besides just vulnerability scanning the application (dynamic analysis), a full penetration assessment should also be performed against the application and its supporting infrastructure. This is necessary for a more accurate risk assessment.
  11. Security/CISO sign off before any application goes live. Once the application security team has signed off on all phases of the SDLC, they will provide feedback on approval/disapproval of the application up to their manager. The manager will then sign off and pass to the CISO for a sign off, or will disapprove and delay the application release until fixes are implemented and retested, or until exceptions are assigned and approved.

This list will help to mature your application security program, but your organization needs to be diligent in keeping your program healthy. A third party can perform a penetration assessment on the released application as an extra check for any vulnerabilities that were missed. I highly suggest going this route to give your organization that extra step of risk identification. At the very least, review your application security program annually and mature it as necessary to handle organizational growth.

NTT Security can help develop an application security program for any organization. To find out more, reach out to NTT Security here.