Phishing: Electronic Social Engineering

Was Ronald Reagan thinking about Phishing when he uttered one of the most famous sayings in history … read more

(ISC)2 Launches New Software Security Certification – CSSLP

(ISC)2 brand new certification to address security holes in software development – arriving on scene is the CSSLP – Certified Secure Software Lifecycle Professional.

OWASP AppSec India – Keynote and Training

OWASP AppSec India Keynote on Application Security Trends and Challenges
OWASP Training on Advanced Threat Modeling

Keynote at OWASP India 2008 – August 20th, 2008

Representing (ISC)², the global leader in security education and training as their Software Assurance Advisor, I will be delivering the keynote address on Application Security Trends and Challenges in OWASP India 2008.

If you plan to attend or you will be there, come by and say hello.

Dates – August 20th, 2008 @ 9:00 -10:00 a.m.
Venue – India Habitat Center, New Delhi
More Information, click here

Software without Seatbelts

Would you buy your dream car without seatbelts? Didn’t think so … Then why should you settle for software without seatbelts … read more

Diagnosis: TMI Syndrome; Patient: Your Web App

If presenting the information is not properly protected, Web applications can suffer from TMI Syndrome (TMIS). When Web applications suffer from TMI Syndrome, they divulge more information than is necessary, unsolicited or otherwise. Not too wise …

The Road Less Traveled – Software Security from Shakespeare, Jungle Book and Nature …

What do you think Shakespeare had to say about Software Security? What does an naked motorist have to do with Confidentiality? What does the Jungle Book character Baloo have to say about Security Essentials (The Bear Bare Necessities of Life security)? What does the African Wildlife have to do with Security Concepts? What does pH have to do with Security? and more …

SD3LC – Secure By Design, Development & Deployment @ TRISC

In the current day and age, the chief drivers for software development projects are meeting business requirements and deadlines. Security is generally an afterthought for software development projects. Incorporating security from inception is more cost effective.This session will address the various security controls and activities associated with each phase of the software development lifecycle (SDLC). The controls and activities include but are not limited to; modeling use/abuse cases, threat modeling, security code review, security testing, etc.

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.