“Applications today are at such a great size and complexity that doing a manual review isn’t always practical and you want to be able to be as thorough as possible. With automated source code analysis, you can cover a lot of ground,” says Lucenius, who is based in Wilmington, Del.
Source code analysis tools, such as those from Fortify Software and Ounce Labs, help companies ferret out vulnerabilities in applications as well as spot areas where developers might need more security training.
|
Related Articles |
|
|
The Golden Rule Of Business Technology Investments How To Avoid An IT Project ‘Death March’ Virtualization: Xen vs. Microsoft vs. VMware
|
Many companies use the automated tools not just for internal applications, but for those developed by outsourcers. “We want to make sure there are no backdoors left in our code by any developers,” Lucenius says.
Sprawling Code
Andreas Antonopoulos, senior partner at New York-based Nemertes Research, says this mission is becoming increasingly more difficult for companies. “Code is no longer self-contained in one computer or even in one application. It can be distributed across the network and therefore is far less deterministic. There is a greater opportunity for code errors to creep in and make systems more exploitable,” he says.
While many IT organizations are stretched too thin to do frequent source code analysis, Antonopoulos says compliance, security and performance issues are pressuring them to be more diligent about code reviews. Letting bugs make it to the desktop is costly in terms of time, money and credibility, he says.
“If you can fix a flaw at the design stage it’s ten times cheaper than trying to do so at deployment or once it’s made it into the headlines. As you go through design, architecture, coding, testing, quality assurance and production, it gets progressively more expensive to fix a bug,” he says.
Lucenius agrees. Because JPMorgan Chase falls under numerous regulatory bodies, code analysis has to be central to the company’s security plan. “A good code review will generate a report that shows you what you need to do to make your applications more secure. Then you can say to regulators this is more secure than it was and it’s getting more secure every day,” he says.
Regulatory Requirements
For Matthew Todd, chief information security officer at Financial Engines, in Palo Alto, Calif., the automated tools have also provided a safeguard against regulators and other potential liabilities. “Legal action can be quite a bit more severe if vulnerabilities are found and a firm has failed to do penetration testing or code review. It’s not sufficient to have just one of these. You need a multi-step strategy in place,” he says.
Financial Engines, a benefits service provider, creates its own customer-facing applications. “We’re concerned about SQL Server injections and other related vulnerabilities,” he says.
Todd uses Fortify Software’s source code analysis tools throughout the development process. “You should have security practices in place from the birth of an idea through every release. We introduce secure code analysis at the product specification point and take it through to release,” he says.
At JPMorgan Chase, the mantra is the same. Lucenius contends that source code analysis is only as effective as your overall strategy to deal with vulnerabilities. “You can’t just do a casual review of your applications. Something has to come out of it,” he says.
Defining Parameters
To start, Lucenius and his team created parameters inside the automated tool for all code that matches the company’s regulatory commitments as well as safety practices. “We check to see if we’re in compliance, are we making sure Social Security Numbers don’t get through, etc. We’re taking defense in depth to the code level,” he says.
|
Related Articles |
|
|
The Golden Rule Of Business Technology Investments How To Avoid An IT Project ‘Death March’ Virtualization: Xen vs. Microsoft vs. VMware
|
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 doesn’t 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 ‘I’m 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 it’s 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. That’s hard when our applications are written in many languages,” he says.
