Building an Application Security Program from Scratch: Part 1

So You Want to Build an Application Security Program

It’s the start of a new year, which means it might be time to take a look at where your current security program stands and how you would like to see it grow. When considering a comprehensive security policy portfolio, many enterprises briefly mention, or even entirely neglect, application security as an important piece to their InfoSec realm. In this blog series, I will outline the stages of starting an application security program from scratch. I will discuss drafting supporting policies, designing a program to support those policies, gathering buy-in, growing the service, and measuring progress. As each enterprise’s culture is different, this series should act as a guideline rather than a set of immutable rules, although the intent remains.

Expanding Your Current Portfolio

In order to design and implement a successful program, necessary work must be done to create a solid foundation on which you will be basing your decisions. Without appropriate policies, standards, and procedures, you will lack consistency, accountability, and auditability. Before even considering a tool-set, policies and standards must be created which will help guide the direction of a growing application security portfolio.

Most new security standards should fall easily into your current security policy portfolio without much need for modification. However, a more specific Application Security Policy should be considered down the line as the program matures in order to more easily expand the portfolio. Below is an example of where new application security standards might fit into an established security portfolio:

Data Protection Policy

  • Data Classification Standard
  • Encryption Standard
    • Data-at-Rest Encryption Procedures
    • Data-in-Transit Encryption Procedures

Access Control Policy

  • Password Construction and Management Standard

Logging, Monitoring, and Auditing Policy

  • Audits and Review Standard
    • Static Code Analysis Procedure
    • Dynamic Analysis Procedure
    • Penetration Testing Procedure

Infrastructure Hardening and Vulnerability Patching (Operations) Policy

  • Secure Configuration for Network Appliances Standard
    • WAF Configuration Procedure
  • Application Secure Coding Standard
    • Language-specific Coding Procedures
  • Application Testing Standard
    • Static Code Analysis Procedure
    • Dynamic Analysis Procedure
    • Penetration Testing Procedure

Fitting it In

Data Classification Standard

In the context of application security, classification should help developers determine how to handle data throughout their application. For example, the Application Security Standard may reference the Data Classification Standard by stating that no Personally Identifiable Information may be cached within the browser. Additionally, the standard should address how certain pieces of data may be displayed, masked, transmitted, or omitted from the application entirely.

Encryption Standard

Referencing the Encryption Standard goes hand-in-hand with the Data Classification Standard. For each level of data classification, there should be language describing how that data should be stored, if storing is allowed. Where this standard is extended is in the realm of application-specific data such as passwords. The Encryption Standard should contain approved hashing algorithms which can be pointed to by the Application Security Standard when discussing password salting, hashing, and storage.

The Application Security Standard should also address how data should be handled in-transit. Considering the Data Classification Standard, for example, all pages behind authentication should be transmitted via HTTPS using an approved encryption cipher. Further, this part of the standard should outline how traffic is to be sent between the application and other backend services such as databases or web-services.

Password Construction and Management Standard

Although password expiration requirements most likely won’t exist within a web application, much of the Password Construction and Management Standard should be applicable to application security. Requirements for construction and history should follow the approved standard, but the Application Security Standard may extend this by providing guidance for password reset procedures. Consider addressing such procedures concerning secret question/answer pairs or the use of email as a means of communicating temporary passwords or reset links. Additionally, this standard should address initial or temporary password generation as well as the lifetime of validity for either.

Audits and Review Standard

This standard should be concerned with the “when” and not the “how” of scanning. Depending on the development environment, internal requirements, compliance obligations, or other factors, some methods of vulnerability testing may be more important than others and should be prioritized accordingly. Additionally, frequency and remediation SLAs of each audit should be outlined within this standard. For example, a standard which determines the frequency of penetration testing may depend on whether or not the application is publically accessible or interacts with sensitive data.

Secure Configuration of Network Appliances Standard

If a web application firewall is utilized in your enterprise, its configuration should be addressed within a procedure underneath the Secure Configuration of Network Appliances Standard. This procedure should include what rules must be enabled by the WAF as well as how developers may submit deviations for that ruleset. Additionally, the process with which the development- and production-level rulesets are synchronized should be outlined here.

Application Secure Coding Standard

A standard which outlines how applications are to be developed securely must be established and integrated into the portfolio. Further, a procedure for each relevant development language should be created which outlines how the standard is to be achieved. For example, the standard may state that all user-supplied input must be sanitized. A corresponding procedure would outline, in technical terms, how sanitization is to be accomplished in Java, for example. Without concrete guidelines as to how code is to be written, it becomes difficult to enforce vulnerability remediation SLAs outlined in the Auditing Standard.

Application Testing Standard

Unlike the Auditing Standard, the Application Testing Standard provides guidelines on how each type of test is to be performed. Where the Auditing Standard is used to determine what applications are assessed at what frequency, this standard outlines the method with which these assessments are to follow. For example, the Auditing Standard may dictate that a web-facing application which processes credit cards must be pen-tested annually. The Application Testing Standard would then outline who is responsible for the testing and with what level of rigor or scope. Each corresponding procedure should then outline how these tests are to be carried out, such as application-specific functionality to be tested.

Wrapping Up

By designing standards which apply specifically to application development and maintenance, you are laying the groundwork for a successful application security program. Rather than starting with a brand new portfolio, finding ways to integrate application security into current standards may help reduce friction and potential roadblocks. This post outlined the general structure and explanation of important new standards, but it is by no means set in stone; your organization may dictate more or less. What is important is that you start thinking about how a new program can work hand-in-hand with the work you’ve already done. Part II of this series will discuss the standards in greater detail and provide further examples of language and format.

Discover why security operations teams choose NetSPI.