LOCK IT UP

... Keys to Better Security

October 2006

I ran across an interesting news release from Symantec the other day. Symantec had a Market Research company do some research into Application Security and how organizations were implementing Application Security into their development processes. The results were interesting, though not very surprising.

The research was done by a company called Applied Research for Symantec. They took a sample of 400 US based Developers. So, right off, this indicates a focus on US organizations. I say this because I've worked with a number of Canadian and European organizations and the focus on security is slightly different depending on different regions. Keep that in mind with regards to the numbers from the Survey.

The encouraging thing that comes out of the Survey was the following:

- 93% thought security was more important today than three years ago
- 74% thought security was an important aspect of the Development process
- 70% said their employers emphasized the importance of application security

But the big numbers that jump out at me were:

- Only 29% said security was ALWAYS a part of their development processes.

That’s huge! In other words, the security processes that are being followed are probably ad hoc and not in structured manner. That being the case, you need to take care to perform due diligence on any software that you are receiving, whether from a Service Provider or from a Vendor, to make sure that the applications are written securely.

Other numbers of importance that came out of the survey were:

- 12% said security had priority over delivery deadlines
- Only 40% have had formal security training
- 1/3 had not yet included security in their QA processes.

So, even if security is considered important, it’s not at the same level of importance as getting a product out the door. I would suggest that arguing about the cost of fixing vulnerabilities in process is probably cheaper than fixing vulnerabilities once the product is out the door. If you change the argument away from Security vs Productivity towards one of cost benefit, you’ll get better results in terms of integrating security into your processes.

Also, I’d much rather see some sort of Application security in place, even if the training isn’t that good than nothing. As the processes evolve, the security level should improve. So training being at 40% is not necessarily a bad thing. Sure it would be nice to have formal training but we’re in an industry that requires we learn as we grow so there’s no reason why you can’t pick up a book and read a better way of doing things.

The last thing I see from the results of the survey is that there is a growing understanding of the importance of the SDL and that there is a need to incorporate security into the development processes. But I also see an inertia to making that change, which is not surprising since change always takes time. And remember that the thought process was always that security was the concern of Infrastructure, not Apps Development. As we see that change, we will see the continued adoption of SDLs into the Apps Development processes and security will become integrated to rather than standing apart from the application development process.

Neil R.

Posted at 11:54 AM  Permalink |

Once you’ve made sure that your application has been written in a secure manner you have one last step to occur. You need to ensure that the Application that is located in the Production environment is the one that you have approved. In other words, you need a mechanism to ensure that Applications aren’t changed without going through a proper Change Mgmt process. That process would be Code Signing

I’ve come to believe that there are actually two types of Code Signing that people refer to when they talk about Code Assurance. In one case, they are talking about Code Signing where applications that are distributed from a single location have a certificate associated with them in order to prove to the receiving Workstation of the Application that it is coming from a certified source. The second type is when a Hash is taken of an Application and then the Hash is stored in a secure location to compare against the approved Application in the case of an Audit. It’s this second one that is important for all Applications and I will refer to this one as Code Hashing.

Think of Code Hashing this way. You’ve gone through the SDL and done all the work needed to create an Application without vulnerabilities. You move the Application into the production environment and then a Developer thinks of a possible change to the Application that might improve it. It’s only a small change, so what’s the harm? Well, that small change may create a large hole. If you have hashed the Application and then you check the Application Hash on a regular basis against the Production Application, you will know if the approved Application is what is sitting in the Production environment.

This gives you a higher level of assurance that the Application is what has been approved than Code Signing. All Code Signing does is say to the receiver of an Application that the Application came from an approved source. It doesn’t say whether the Application was checked for security and whether controls were in place to prevent changes to the Application outside the Change Control processes. So, in short, Code Hashing is needed for all production applications where as Code Signing is needed for Applications that are passed from one location to another.

If you were to look for a Code Hashing tool, look for something that simply hashes files. Don’t get Code Hashing tools confused with Code Signing tools. One such tool that you could use is MD5Deep. You can find this tool at Sourceforge at the URL http://md5deep.sourceforge.net/ . But look for a Hashing tool used by some sort of authoritative source. The reason why I mention MD5Deep is that is a Hashing tool created by the US Airforce.

Anyway, one last step that I highly recommend that you do prior to putting an Application into production is to create a Hash of it and ensure that it is stored in a secure location with auditable processes that are used for access it. This way you finish off the SDL with a last step of assurance.

Neil R.

Posted at 04:51 PM  Permalink |

When most people think about Application Security, they don’t think about a Security Development Lifecycle. What they think about is Testing Applications after they’ve been written to see if they’ve been written securely. Nice idea but, if you’ve been keeping up with this blog, you understand the need for the full SDL. That said, it’s now time to actually talk about Application Security Testing.

There are two types of Application Testing that you need to keep in mind when it comes to Security; Automated and Manual. As you can probably guess, Automated Testing involves using tools that are out in the market place where as Manual Testing involves someone actually sitting down and actually going over the code.

I can just hear you saying “Why would I do manual reviews of code when an Automated tool is much more efficient?” My answer to that is this – Just because something is easier doesn’t make it better. If you talk to the different Tools Vendors, they will say that their tools will catch all of the vulnerabilities that they find. But if you talk to the major Application Vendors (eg. Microsoft, Oracle, etc.) you will get a different answer. The rule of thumb that I go by is that Automated Tools will catch in the area of 30% of the vulnerabilities that are in the code. Scary, huh?!?

Let’s go back to the Impact Assessment that should be done at the beginning of your SDL and remember that it is supposed to drive the level of security that you carry with you through your development process. If the application you’re dealing with has a low criticality (eg. A small dll that doesn’t affect Information in any way), you may not even want to do any testing. But if you have Applications that need testing, then you want to determine what level of security testing you want to go with. If that rule of thumb of 30% is okay for the criticality of the Application you are working with, then go ahead and just use the Automated Tools out there. But if you need a higher level of assurance, I would recommend that you use both the Automated Tools and a manual review.

So, the next obvious question is “How long does it take to do a manual review?”. I once had a conversation with a gentleman that has a lot of knowledge in this area and he said that any of his code that he had written 10 years ago would take a lot longer to review than his code of today. In other words, it depends on how good your Developers are at writing secure code. Just goes to show you how important training your Developers is – you can get a ROI based on the length of time it takes to manually review the code.

So what type of Application Security testing do you do? Well, there are two primary types of testing. The most common one is what is commonly called Penetration Testing. This is when the Application has been compiled and a “Black Box” test is done on the Application. The problem with referring to this as Penetration Testing is that Security professionals use the term Penetration Testing for any type of SECURITY testing of an entire environment, not just the Application. The results include things like Server configuration, network configuration, and Application vulnerabilities. As a result, for the Application Development team, this type of testing reveals information that they really shouldn’t care about specific to the writing of the Application. I would like to promote using the term “Runtime Testing” with regards to Application Security Testing so that the focus is solely on the Application.

The second type of testing is Static Code testing. This is done on the actual code prior to compilation and reads the actual code. This type of testing is also commonly referred to as “White Box” testing since the testing has full access to the inner workings of the Application itself. This is also the area where you can most effectively combine Automated testing with Manual review of code.

If you combine these two types of testing (Black Box & White Box), you should have a pretty good picture of how secure the written Application has been written. I would recommend that you create a standard process for both the automated and the manual testing so that you can have repeatable processes to follow and try to improve upon. And try to document any improvements on a regular basis.

Anyway, remember that Application Security Testing is NOT the only thing that has to occur to ensure that Applications are written in a secure manner. Testing and Manual Review occur at the end of the SDL and is the last chance you have to catch vulnerabilities in the Application before it moves to Production. Using Testing as a component of a properly run SDL means that the number of vulnerabilities found at this stage of the SDL should be much lower (and thus have a much lower cost to fix) than if you only do Application Security Testing alone.

Neil R.

Posted at 03:40 AM  Permalink |

Once an Architecture is done, it’s time to review it to make sure it covers all aspects of the Threats and Risks that the Application needs to deal with. But how thoroughly the Architecture gets reviewed is based on the person that is doing the reviewing. How well I review the Architecture is different from how well a novice would review the Architecture. And that’s where Checklists come in.

Now I don’t want to give the impression that Checklists are the end-all and be-all when it comes to Architecture reviews. A lot of Security activities is simply a case of continuous improvement since there are always new techniques being found in the wild for attacking applications. But by updating Checklists that are used for reviewing Applications, you are able to raise the baseline checking that is done on the Architecture.

So, what checklists should you use? Well, the first thing to remember is that the entire SDL that you are following is driven by the initial Impact Assessment done in the Business Requirements stage. That means that you need to understand the level of security associated with the Application that is being reviewed. If it’s considered a low priority application, then the level of scrutiny that you put into the Architecture review doesn’t have to be as stringent as a mission critical application. The first step is to understand the level of security that the SDL process needs.

Next, remember that you don’t want to look at just the one phase of the Software Engineering process (Architecture design in this case) but, rather, take into consideration everything that has been done to date within the SDL. I’ve already mentioned the Impact Assessment done during the Business Requirements phase of the SDL. So what comes next? That’s right, what we’ve been talking about during the last two blogs: the Threat Model.

What came out of the Threat Model are the Threats and Risks that are associated with the Application and which the Architect needs to make sure are taken into consideration in the design. The Threat Model is where you get your first set of checks. If the Architecture doesn’t mitigate the actual Threats and Risks that were determined in the Threat Model, why even put together a Threat Model in the first place? The Threat Model creates the checklist that is specific to the Application under review and details the Business drivers that are the reason why we do the SDL in the first place.

Now, you’re probably saying “But what about some simple checklist that I can give everyone involved so that we can speed up the process?” Be careful! Just because some process is easy doesn’t make it the correct way in doing things. But say you never did a Threat Model and now you want to review an Application design. What checklist would you use?

Assuming you haven’t created a standardized checklist for your organization, there are a number of sources that you can go to in order to find recommended checklists. Some of them are:

- Eindhoven University of Technology = http://wwwis.win.tue.nl/2M390/rev_des.html (Note: This is probably the best Architecture Review checklist I’ve seen – most are focused on Code Review)
- Open Group = http://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/clists/sec.htm
- Microsoft’s Architecture and Design Review = http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/CL_ArchDes.asp?_r=1
- INTERPOL = http://www.interpol.int/Public/TechnologyCrime/CrimePrev/companyChecklist.asp (Note: This checklist includes organizational checks as well as Architecture)

Remember that you need to have a Process in place for the use of the Checklists. The process is what the Architecture Review is about. The Checklists only facilitate the Review, they don’t replace them. Plus, remember that you need to review the Architecture with an open imagination AFTER you use your Threat Model checklist and your Standard Checklist. There is always the chance that there is something missing from your checklists. But, by dealing with these areas, you should be able to make sure your Architecture is secure.

Regards,

Neil R.

Posted at 11:59 AM  Permalink |