Business Requirements: The SDL driver.

Typically, when you start putting together an Architecture, you start off by gathering the business requirements that are driving the project. In the case of Application Security, this isn’t any different.

But in the case of Application Security and a Secure Development Lifecycle, what you are talking about is the level of security that needs to be integrated into the Software Engineering process AS WELL AS the security features of the project. Let me differentiate the two areas.

Security features are those things that you want to have built into the product. Say you want to have the ability to integrate with a LDAP repository as well as audit logging and Enterprise Security Event Monitoring. These are security features of the project or application. But Application Security in association with the SDL goes into the level of security activities that are involved in the Engineering process. And it’s this second type of Application Security business requirements that I want to talk about here.

When you do your Business Requirements gathering in association with SDL, you are looking at the criticality of the application itself. You want to be asking questions like “Is this application going to be Internet facing? Is it a Mission Critical application? How many users will be using this application?” You then want to assess the application both from a Security perspective as well as a Privacy perspective. The results of those questions will determine the extent you will critique the different phases within the SDL.

So take the example of the Mission Critical application. If this application fails, you have major issues such as financial impacts, reputation impacts, and possibly core business impacts. As a result, you can’t afford for the application to be breached. Based on this, the level of effort you want to put into your Architecture Review is much higher. The level of code review goes up and the Application Testing requirements may move from automated testing to a full manual review.

The same goes with a simple DLL. It may be a simple code change in a small file that is only accessed by systems and doesn’t interact with any sensitive information at all. If this is the case, do you really want to go into a full blown architecture review? Will automated testing work for you?

All this is driven by your Business Requirements back at the start of the Engineering process. What you find there drives the rest of the SDL and the level of security you put into designing the application.

I would recommend that you do the following. Create a standardized Security Impact Assessment process/checklist that is used for all your Application development and have either your Business Owner or Architect fill it out (it should take <1 hour to fill out if done properly). Have the Assessment output be in a format where the Application has 3 or 4 levels possible levels of criticality (eg. Low, medium, high). As part of your SDL, you drive the next steps in the SDL based on the measured criticality. By standardizing the process, you can link the SDL activities to Enterprise Policies and ensure that personal opinions are kept out of the process.

Remember, Business Requirements may not be the sexy part of the Application design or Application Security but it all has to flow from this area. Without it, you’re just guessing as to what you need to do in the rest of your SDL.

Neil R.

Posted at 08:16 AM  Permalink