LOCK IT UP

... Keys to Better Security

August 2006

One of the first things that I came to understand is that looking at Application Security requires looking at the entire Software Engineering process rather than just one area, such as the Testing and Review phase. As a result, my advice to you is to develop a full Secure Development Lifecycle (SDL).

A good example of this would be the Microsoft SDL. Yes, I know, I praised Microsoft on its security! But the development of the SDL that Microsoft uses is important to how it has been able to reduce (though not remove) the number of vulnerabilities that are in its products. All I'm saying is that you need to take a similar approach in developing an interative SDL.

So, when you look at creating a SDL, what do you need to think about? Well, the earlier in the Software Engineering process that you integrate security, the better. That means starting with the Business Requirements that are driving the creation of the solution. You need to be able to link the security requirements to the business requirements, otherwise why integrate security?

After dealing with the Business component, you then get to the Architecture phase. This means that you have to have to translate the security requirements into the actual architecture. If you design the solution improperly, it doesn't matter how well it's coded, there will still be holes in the solution. There are a couple of steps that you need to consider in this phase; the front end of the Architecture needs to plan for the Threats that the solution will see and the back end of the Architecture needs to have a Design Review to ensure that the solution is designed securely.

Once the Architecture is designed properly, you move onto the Development stage where the actual code is written. Most of the articles you see about Application Security focus on Code Writing since improperly written code is the primary source of vulnerabilities. But if you take a 'Big Picture' view, you are able to reduce the issues associated with poorly written code. An example of doing this would be using standard libraries that have been vetted from a security point of view. If you use and reuse the same library, the security review is done on the library rather than the 'custom' code, thus reducing your review costs. But, in any case, you need to include a Code Review in your Development phase activities.

Typically, the next phase after the Code Writing is the Testing phase. This phase is probably the most controversial in that there are two views on Testing; Automated and Manual Review. If you talk to many Code Reviewers, they will say that Automated Testing will not catch all the vulnerabilities and poorly written code. But if you look at the cost, you have to consider the Automated Testing simply from a cost/benefit basis. I would recommend that you use a combination and the amount of manual review needs to be based on those original Business Requirements gathered. If the solution is a simple little DLL that isn’t available to anything of import, then the amount of manual review can be minimal. But if the solution is a mission critical application, then a full Manual Code Review to catch ALL issues is probably required.

At this point, your solution is probably ready for Production. But you need to take into consideration the Assurance aspect of the application that you just secured. How do you know that the application that is sitting in Production is the same application that you approved to be put into production? You may want to consider some sort of Code Signing or keeping a copy of the approved Application stored so that you can prove that the Application in Production is the one that you approved.

So, as you can see, there’s a lot of specifics in the Software Engineering cycle that need to be addressed. And I didn’t even talk about things like Best Practices, Policies and Standards, and Checklists which are more of a Project level or Enterprise level activity. I will go into further depth in each of these areas in future blogs.

Makes you feel like you’re going Deep Sea Fishing, huh?

Neil R.

Posted at 12:43 AM  Permalink |

When I started thinking about writing this Blog, I asked myself what type of information could I provide to everyone that would be interesting? Could I provide Web Services Security information? Could I write about the correct way to code a function? Could I go into specific technologies around Application Security like XML Firewalls and Federation?

Then, when I looked back at what I had been doing over the last few years in Application Security, I realized that the primary thing that I’ve been preaching was the need for the PROCESS to be done properly. Secure the Application Engineering process, provide the proper guidance to the Application Architects and Developers, ensure that the Code was tested with Security in mind and the end result is a much more secure Application.

So that’s what this column is going to go into. I’ll write about creating a Secure Development Lifecycle, which will go into Best Practices, Tools, Checklists as well as the experiences that I’ve seen go into those activities. I’ll write about how your organizations can leverage different pieces of information, whether they are commonly available Whitepapers or Commercially available tools. But, most importantly, I’ll provide you information that will help you ensure that the applications that you write, whether they are for internal use or for external sale, are written in a secure manner.

In essence, I will follow the old axiom: "Give a man a fish, and he eats for a day. Teach a man to fish, and he eats for a lifetime".

So, prepare to learn to fish. And, hopefully, you’ll be able to start fishing safe in the knowledge that you are doing so securely.

Neil R.

Posted at 06:28 PM  Permalink |