Tuesday, May 19, 2009

Secure Development Jump Start

Creating a secure development process for an organization is a huge undertaking. There is a tremendous array of options for getting started and no certain metric for determining how long it should take to adopt the process. Some of those options include:
There are some components that all of these processes agree on. Executive level support is a must and security training is required (each process differs on the amount of training, however).

In companies with a small number of developers that have been there for a long period of time, it may make sense to dedicate a large amount of time and money to make them both developers and security experts. For organizations with a large number of developers or high developer turn over rate, it may be more cost efficient to simply provide security awareness training and a set of policies and coding standards to follow.

In any of these situations, several steps you can take to jump start a secure development process for your organization are listed below. It is assumed that your organization values and desires to develop secure code.
  1. Create a policy document addressing application security.
  2. Create a secure coding standard stating the organization's established, secure method for carrying out specific functions.
  3. Provide security awareness training.
  4. Provide training that specifically aims to introduce developers to the application security policies and secure coding standards for the organization.
These steps should fit in to any future secure development process and do not require organizations to spend any security budget dollars on tools. These steps are a starting point and should be joined with a larger, strategic process once the appropriate research and planning is performed.

Application Security Policies

An application security policy document should provide statements or policies that are as specific as possible. A statement such as "All applications should use sufficiently strong cryptographic algorithms" does not provide a developer with enough information to select a secure algorithm. Instead, a statement such as "ACME Bank Corp standardizes on the use of SHA256 as a secure symmetric cryptographic algorithm" should be used.

Other examples include:
"ACME Bank Corp requires all database queries to use parameterized queries or prepared statements. Dynamic or concatenated SQL is prohibited. The ACME Bank Corp secure coding standard provides examples of parameterized queries or prepared statements."

"Untrusted data should be properly output encoded before being included within a web browser page. The appropriate encoding method should be selected based on the context in which the data is being included. The secure coding standard provides example contexts and methods."

The authors of the application security policy document can get policy ideas from resources such as:
OWASP Top 10
2009 CWE/SANS Top 25 Most Dangerous Programming Errors
OWASP Guide Project
ASP.NET 2.0 Check List
ADO.NET 2.0 Check List
.NET 2.0 Check List

Secure Coding Standard

Developers should be able to use the secure coding standard document as a reference guide for writing secure code. The standard should provide the developer with enough information to know when and how to apply a particular code example. An entry such as the following is a good starting point:

Parameterized Queries and Prepared Statements

Addressed Application Security Policy: Parameterized Queries or Stored Procedures, Section 2.1.3
Prevents: SQL Injection
References OWASP Top 10, CWE/SANS Top 25, Security Guidelines: ADO.NET 2.0, OWASP Guide
When to Apply: Anytime an application queries an SQL database
Code Examples:

.NET Parameterized Query, SELECT Statement (example taken from http://msdn.microsoft.com/en-us/library/ms998264.aspx#pagguidelines0002_sqlinjection)
using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
DataSet userDataset = new DataSet();
SqlDataAdapter myDataAdapter = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",
myDataAdapter.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myDataAdapter.SelectCommand.Parameters["@au_id"].Value = SSN.Text;

.NET Parameterized Query, UPDATE Statement


.NET Parameterized Query, INSERT Statement


Java Prepared Statement, SELECT
String sql = "SELECT * FROM movies WHERE year_made = ?";
prest = con.prepareStatement(sql);
ResultSet rs1 = prest.executeQuery();
Java Prepared Statement, UPDATE


Security Awareness Training

Security awareness classes are typically used to introduce developers and managers to the types of vulnerabilities found in applications as well as the impact of those issues. When a developer sees for the first time that an SQL injection attack on SQL Server can be used to read arbitrary files and execute DOS commands, a light bulb seems to come on inside their head and they realize they really do need to pay attention and prevent these vulnerabilities.

While these classes often do not arm developers with the proper tools and knowledge for preventing vulnerabilities, a well written application security policy and secure coding standards document should be a great start.

Application Security Policies and Secure Coding Standard Training

Following a security awareness class, it is beneficial to provide a more targeted training opportunity for developers. This course should be focused upon going through the organizations application security policies and coding standards to ensure all developers are aware of these resources and understand how to use and apply them. Following the course, developers can be held accountable for applying the examples in the secure coding standards to their projects.

Process Improvement

It is likely that an application security policy and secure coding standard document will not include all the possible vulnerabilities that could be introduced into a web application. As new issues are identified as part of an assessment, peer review process, or threat model (these steps are usually included within a complete secure development process), additions should be made to both documents. These additions should reflect the organization's recommended approach for developing code without introducing the newly identified flaw. The organization should also periodically review application security concepts and new additions to the policies and standards document with its developers.

No comments: