itmanagement.earthweb.com/erp/article.php/3665146
|
By Sandra Gittlen March 13, 2007 Defining Parameters To start, Lucenius and his team created parameters inside the automated tool for all code that matches the companys regulatory commitments as well as safety practices. We check to see if were in compliance, are we making sure Social Security Numbers dont get through, etc. Were taking defense in depth to the code level, he says.
His security team then ranks the flaws they find. We prioritize flaws against business practices. We might find a flaw, but if there is minimal impact, it might not be as urgent to fix it, he says. For instance, if a vulnerability is going to cost a million dollars to fix but is only expected to cost a thousand dollars in losses, then it might not rank as high as something else, he says. He also uses the trending tools to show which developers need a closer watch. If you have developers that keep putting code in that doesnt belong or leaving things open, then you can get them more training, he says. Sometimes just knowing that the code is going to be carefully reviewed makes the developers more careful. They now call me and say Im writing this code, how can I make it more secure? he says. SOA Friendly Source code analysis tools are also a good safety net for companies looking to implement service-oriented architectures, which reuse libraries of code. Jack Danahy, CTO of Ounce Labs, says automated tools understand how the code will interact with their current applications. People want to know the holes that are created when they connect services to their networks. You can now see what types of input or requests can affect your program, he says. The tools can also be used as a benchmark for outsourcing contracts. Whenever you buy a piece of code or deal with outsourcing application development, part of your contract should be that the code is reasonably secure, says Brian Chess, chief scientist and co-founder of Fortify Software. With automated tools, you can give your vendors guidance in terms of your security requirements and then test against those requirements, he says. Both Lucenius and Todd say that code testing has to continue after a product has been released. Every time the code is elevated to a live server we test the entire application. This is important because changes to code can cause problems, Lucenius says. And its just as important to circle back with developers on what flaws have been found so they can update their code libraries, he adds. But as helpful as the automated tools are, Lucenius warns they still require some manual oversight. They have some problems dealing with non-compile languages such as PERL, JavaScript and HTML. They often work well on the backend then miss something in the HTML. Thats hard when our applications are written in many languages, he says. |