Closing Security Holes with Application Scanners
Before unleashing sites and software, these products will spotlight code that can leave you vulnerable
- By Chris DeVoney
Good fences make good neighbors. Strong parameter security makes criminals look harder. Collectively, we have succeeded somewhat with our fences and now must continue the incremental gains on our PCs and other endpoints. If an ounce of prevention is worth a pound of cure, application scanners may provide a ton of security cures.
The basics can never be abandoned in our security struggles, but our parameters and immediate layers should be well secured. Firewalls, intrusion detection, anti-virus, lock downs, network access controls, SIM/SEM—all of these represent hardened layers to attackers yelling, "Show me the money."
The problem is that cybercriminals have the resources and inclination to attack the next frontier: applications, and when the hackers hit the jackpot, it's payday.
Traditionally, we associate security scanners with ports, patches, and system vulnerabilities. Those scanners fill an important role, informing us of open ports, improperly configured infrastructure, and missing software,, helping us identify the gaps that can be exploited by the mischief makers.
These security scanners, however, do not stop two other threats. The first is the betrayal of trust when a contractor or employee puts malicious code into developed software. The second is when someone writing code or scripts creates the hole and shoots themselves, and our security effort, in the foot.
With increase in outsourcing and contract programming, any CISO knows the added risk of compromised code. In some cases, the potential negative impact isn’t worth the cost of increased scrutiny. Certain programs are nevertheless too important, either because of line-of-business impact or national security (think weapons systems or air-traffic controls), to allow any level of trust.
Consider that major applications use millions of lines of code. It takes just a couple to open a back door or plant a time bomb. Although human eyes can analyze errant instances, those eyes are simply too imperfect for such a task. The bulk of the process requires automation.
The second case is when good coders do dumb things. Just ask Microsoft: the company has suffered a record run of buffer overflows in their products. A boundary isn’t checked, a value isn’t screened, a default is never tested, and hungry hackers hunting for the slightest misstep relish their find.
For many years we have had program development tools that help us perfect our code, from source-code formatters to complier diagnostics to semantic library call checkers. Code checking then moved beyond the rules of a language into real-world use.
An Ounce of Prevention
Ounce Labs makes the Ounce 5.0 security scanner. The product works with a range of MS languages including VB.Net, C, C++, and C#, and supports Java. The product looks for malicious code and "dumb" code that leaves the application open to attack. It goes far beyond simple buffer overflows; it looks at every entry and exit for data I/O. Ounce 5 can even be set to squawk when the data in a transaction is using weak encryption or no encryption, both contravened by the Payment Card Industry (PCI) standards.
In fact, much of Ounce 5’s analysis is tied to PCI, and flaws are listed with Common Weaknesses Enumeration (CWE) models. By following CWE, the report card from a scan can be used to assure that contractual requirements (such as "no security flaws") have been met by parties.
Ounce runs about $1,500 per seat annually or $2,750 plus maintenance per seat perpetually (these are MSRPs). This type of product gets used by a limited number of people in an organization, such as acceptance auditors, security members of a development team, partners in a boutique contract security firm, or members in a global services company. Ounce has all of these as customers.
The product is efficient in chewing through source code, running 48 million lines of code in four hours. That speed is important in any of those environments.
Simple Web site, five bad lines of code, and now it’s an inadvertent accessory to fraud. While pursuing several Web sites owned by Fortune companies, I found a few Web pages similarly vulnerable.
A simple Google search will turn up dozens of open-source scanners for Web site code, including one for PHP. It’s the knowledge that such scanners are available and that such pre-deployment checks are necessary, no matter how trivial the Web site, that’s missing.
Code vulnerability scanners for applications and Web sites must be part of our security DNA. Obviously, stakes vary. The consequence of a back door in a missile system isn’t necessarily the same as a hole in a Fortune 5000 human resource system, but the respective impact is huge. Leaving a hole in any Web site is playing an international version of Russian roulette—provoking exploitation by a literal Russian and not easily explained away. It’s time for businesses and institutions to get serious about application security scanning.