Glaring gaps in network security, II

Last week we wrote about how glaring gaps in network security may be discovered by specialized penetration tools. As good as automated tools are, they are not a panacea, Chris Nickerson, CEO of Lares Consulting, Nickerson told Sandra Gittlen of Computerworld. 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 Corp. in Sudbury, Massacusetts, 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% 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. He says, however, that IT should avoid pointing fingers at Web coders and instead insert themselves into the process to ensure that applications are deployed safely.

It took some very public scandals, including a takedown of the government’s Web site and published descriptions of vulnerabilities in the voter registration site, for the Commonwealth of Pennsylvania’s IT team to be able to free up the budget for penetration-testing tools and beef up security for its Web development practices. “In government, there’s a big push for e-government and that’s great because we should be giving citizens access to resources. But there’s not enough testing of these new Web applications before they are deployed, and yet they have a huge door called Port 80 that’s not secure,” says Robert Maley, the commonwealth’s chief information security officer. Maley, who came onboard almost three years ago, says he had been pushing for increased penetration testing of all systems but was told the technology and human resources required were too expensive. He was able to squeak a few dollars out of the budget to buy an automated tool and train his team to run it against the government’s 80,000 endpoints and 100,000 business partner connections. Earlier this year, five portal Web sites were breached with a SQL injection launched from China. The government’s main Web site was down for six hours, making local and national headlines. Maley used his penetration-testing tool to do a post-mortem on the attack and shore up any other holes. Then, a month ago, the commonwealth came under fire again when someone published a vulnerability in the voter registration database that allowed citizen data to be viewed. “That bad press was the final thing I needed to eliminate any pushback and to create a sea change in the culture here,” he says. Although there is still not enough money to bring in outside consultants, Maley is working closely with his own security team to test application code in development and in production and to train developers on security practices. “We have checks and balances on everything we do now,” he says; “for instance, before a site goes live, we do penetration testing against the hardware, software, operating system and application itself.”