Not as SOX-y as they thought they were

Chris Nickerson, security services lead at consulting firm Alternative Technology, is also amazed by the simplicity of most hacks -- especially in this era of compliance, which should demand tighter controls. In fact, he says when he was sent to do testing at a Big Four company, he was able to immediately gain full administration access to all the organization's applications.

"This was a company that had maintained they were Sarbanes-Oxley compliant for several years. Yet I had control of the business within the first 20 minutes. I could actively change general ledgers and do other critical tasks," he says.

He also has found problems with companies that claim to be in compliance with the newer Payment Card Industry (PCI) standard. "I've had people who have spent millions of dollars on security to say they are compliant, and I walk in and pop open their main credit card processing system within 10 minutes."

The problem, he says, lies with compliance rules themselves. "The government has narrowed the scope of compliance so much to make it cost affordable that it overlooks a lot of things that are real-life security vs. paper security," he says.

He encourages his clients to focus on two technology tasks: managing patches and hardening their operating systems. "You should always make sure you're up to date on patches and turn off ports and services you're not using."

Nickerson is also a fan of automated penetration-testing tools, such as Core Security's Core Impact. "I like to show people, through the use of software like Core Impact, how easily I can get through their whole network. I even let them drive the tool so they can see how someone with zero knowledge can attack them. That's usually when they realize security is something they have to do," he says.

He recommends that even after the initial testing is done, organizations continue to use the automated penetration tools to audit their environments to pick up problems with new applications or configuration changes.

Baby, you can ... drive my car? (uh-oh)

But as good as automated tools are, they are not a panacea, Nickerson says. He uses a combination of penetration testing and manual hacking to show users how easy it is to blend social engineering and network vulnerabilities to gain access to high-stakes data.

For instance, he says he once showed a luxury-car dealer that by mixing information gleaned from a phishing scam targeted at his clients and holes in the back-end architecture, he could potentially pull cash from the customers' bank accounts. "That's worse than if I told him I could steal $100 million worth of cars because that's his reputation," he says.

Brad Johnson, vice president of security consultancy SystemExperts, agrees that IT teams should expect penetration-testing teams to use both automated and manual tools to assess their environment. "With the automated tools, you could tell if someone ran a scanner against your firewall. But Web servers pose a bigger challenge," he says.

He adds that Web security is one of the biggest problems facing IT teams because developers are under tremendous pressure to get code out the door. "Often, developers are more concerned about functionality than the people who would abuse that functionality," he says.

He points out that there are myriad places where data being processed through a Web application can be corrupted, including at the browser level, between the client and server, at the front-end server, back-end server and during storage. Rarely do organizations test the security of data at each of these points before the application is deployed, Johnson says.

For instance, Johnson did a penetration test on a small banking institution and found that they included user IDs as part of the bank account URL. A hacker only needed to change a bit of the URL to access another bank account.

Unfortunately, this situation is not unique, he says. "Well over 50 per cent of the Web applications in production that we test can perform cross-account actions such as logging in as user A and looking at data reserved for user B, or executing functions that only user B is authorized to do. This is just bad access control enforcement," he says.

However, he says that IT should avoid pointing fingers at Web coders and instead insert themselves into the process to ensure that applications are deployed safely.