Secure Software – A New Term Coined !

I find myself often having to explain in more detail (than I felt was necessary) when using the following terms – application security, secure software, writing secure code, hack-resilient applications or any combination of these.To some it was debate about it being more than just buying and deploying a bunch of tools, be it scanners (static or dynamic, vulnerability or code), firewalls (network or web app) or anything else that had a hint of security – aka “the technology” To others it was all about policies, standards and procedures, patterns, practices and governance frameworks with little to no relevance on the technical implementation of security – aka “the governance”. Seldom, it would be about the first line of defense – “the people”. Every now and then, it would be about defined processes (policy checking, security requirements generation involving abuse case/threat modeling, security code review, security testing, vulnerability assessments, penetration testing, exception management, and sign-offs) through the life cycle of software development from envisioning to stabilization – aka “the processes”.

So going forward, I plan on using the term – SD³LC, that stands for Secure By Design, Default and Deployment Life Cycle, a term coined from SDLC (Systems Development Life Cycle) and SD³ (Secure By Design, Default and Deployment)
Let me explain – SD³LC
Secure by
Design (complying to governance),
Default (relevant technology) and
Deployment (security aware people)
Life Cycle (defined processes)

In other words, Secure Software = SD³LC

Security Policies in the Application Development Process

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.