Recently, John Steer who works with a good security friend of mine, Mark Curphey (a.k.a. SecurityBuddha, Visionary, OWASP Founder, ex McAfee VP of application security consulting and now Microsoft ACE Team Leader) wrote a interesting and good article entitle Security Policies in the Application Development Process.

John Steer writes - The role of a security policy is to define what needs to be protected and how it will be protected. In the application development lifecycle, the security policy instructs designers and developers on what the security features need to be and how they must be implemented.

I couldn’t agree more with John, but with just a little to add. Most organizations have a policy but don’t go as granular to defining an Application Security “Policy”. When they do, it is usually a Application Security “Standard” and if you are lucky, they would have, more granular documents that make up the Application Security “Procedures”. In fact, Policy documents are generally very generic with little to any definitive instructions. This is usually the case to prevent rework of the policy upon change in the business or in information systems and technology. Definitive instructions find their place in Standards or Procedures.

An example of an Application Security Policy, Standard and Procedure (when it exists) would be
Policy – Personally Identifiable Information (PII) must be protected
Standard (Application Security) – When transmitting or storing PII, it needs to be encrypted or hashed
Procedure – When storing PII, use NIST approved AES (Rijndael) encryption with at least 256 bit key strength. For more information see link 

The fact remains that whether your organization just has a Policy (or) Policy + Standard (or) Policy + Standards + Procedures, they ALL need to address security in application development. The problems lies, when that is not the case.

John’s entire article can be read here and I would recommend that you do.