Application security policy and process pulls your story together in writing. This is important for communicating with stakeholders such as customers, prospects, and executives as well as simply getting everyone in the organization on the same page.
Policies are promises and these promises come with a cost; it is important that the policies are aligned with what the organization actually plans to do rather than what it hopes to do. A natural consequence of this is that the policies may disappoint some stakeholders.
A Process or a Policy?
Often there is a choice. A Process describes how to do something, typically with well defined start and completion. A Policy is a simpler statement of what will be done. You can always annotate a Process with information to lock down policy, but that will wind up obscuring the policy. Factors to consider include:
- Do you really need a process? Processes are called for when you want to make sure something is done the same way each time. A good example is in incident response where you need fast action and you don’t want people to have to think through actions that can be defined up-front.
- Who is your audience? If the audience is a stakeholder they are probably more interested in your promise to do something than the mechanics of how you do it.
- How complicated is your organization? If you are trying to define something for many different development teams working on as many products you may want to define a process to avoid having the wheel repeatedly reinvented.
- Is the workflow automated? If so there is little point in defining a process that simply summarizes that automation
- Is your security program subject to external audit? If so what will it take to satisfy the auditors?
Processes and Policies.
The following are some example process and policies as a starting point. Your processes and policies will evolve over time. A new process or policy may be introduced to respond to a specific need or event. Old policies and process should be periodically reviewed with an eye to updating or obsoleting as indicated.
Response to Known Vulnerabilities
This will describe your policy for addressing new vulnerabilities as they come to be known. In most cases these vulnerabilities will arise as a result of 3rd party software that is used. The typical response is to release a new version of the system (possibly via a patch) that eliminates the vulnerability. What everyone is interested in is “What is the timeline to address vulnerabilities of different severities?” Other responses are sometimes possible; for example temporary work-arounds or attempts to explain why a particular vulnerability is less severe in the context of your system.
Response to Vulnerability Identification
What do you do when a 3rd party identifies a vulnerability? There is a substantial industry of individual “security researchers” and firms that spend time trying to identify new vulnerabilities in released software. Often they are looking to monetize this information in some fashion. There are several possibilities including:
- Using public acknowledgement to help market a security business offering
- Accepting a documented bug bounty
- Selling the information to the highest bidder. Possibly starting with the software developer
You need to make a number of decisions. Will you publicly acknowledge and/or pay a bug bounty? What are your conditions and what is the timeline? Are you willing to consider a negotiated price? Does this policy apply to customers and users or just to external 3rd parties? How do you respond to known or obvious identifications? How much of this are you going to make public up-front?
Response to Security Incident
What do you do when one of your systems is compromised? The details depend on the nature of your systems, but the following should be considered:
- Capture of forensics to characterize the compromise. How did it happen? What information if any was lost? How long did it last? Can we tell anything about the culprits?
- Mitigation. Stop the attack by one means or another.
- Recovery. Getting the system safely back on line for users
- Interactions with customers and possibly legal authorities
- Updating software and/or system configuration to mitigate
- Roles and responsibilities. Who does what – both for your organization and any 3rd parties you interact with?
Scanning
When do you perform security scans of your system and how are the results of those scans managed? There are 3 possibilities from a timing perspective:
- Periodically during development
- At release time
- Periodically after release
The right answer is probably all three. The results of the latter 2 should be archived and be “generally available.” In other words not some sort of tightly held secret; any customer can generally run the same scans. Your stakeholders will also be interested in understand exactly what scanner(s) you run and how they are configured.
Training
Characterize the secure application development training that you do. The following should be considered:
- What is the general nature of the training?
- Who is required to take the training?
- How often is the training refreshed?
Vulnerability Notification
Does the organization provide outbound notification of known vulnerabilities? There are a number of things to consider:
- When to provide the notification. For example, only after a patch is available?
- Who is notified? Everyone? just bonified customers? Possibly some trusted stakeholders are notified early?
- What is the notification mechanism?
- Are certain types of vulnerabilities excluded?
- How much information is provided with the notification?
Detailed Security Posture
A detailed security posture will document things that must be done (e.g. sanitize all input from a web browser) or must not be done (e.g. never use Open SSL version 1.0) Many books, web sites, and conferences cover the details of building secure systems. The security posture is a vehicle for calling attention to certain aspects of that body of information while possibly customizing it.
Secure Development Process
A development team can expect to be asked to describe their secure development process, so you might as well describe the process up front. This description is summary of key elements of the entire secure development program and also a vehicle for calling attention to aspects of the development process that explicitly addressed by other process or policy statements. For example the use of static analysis tools.