Home > Security

Computerworld - When you're in charge of a company's security, you have to actively seek out its weaknesses and then determine how to shore them up. That's what I've been up to lately, as an an offshoot of my efforts to harden the DMZ.

Globally, we have about 40 servers in our DMZ. I'm fairly confident that they are locked down, patched and protected with anti-malware software. I'm also fairly confident that the DMZ firewalls are properly configured to minimize our exposure. What I am not confident about is the security of the applications residing on those servers. We have too many Internet-facing apps that haven't been properly vetted by me and my team. Part of the problem is that during the past couple of years, our company has made several major acquisitions without conducting security due diligence.

Prodding me to action was the recent rash of hacks, most of them owing their success to poorly architected Web-based applications. Each quarter, I have a budget line for "penetration and vulnerability assessments." Because our physical security program is extremely weak, I've been spending that money on physical penetration testing. But that has become an exercise in paying someone to tell me things I already know. For example, I didn't really need to spend $20,000 for a consultant to tell me that he could create a fake company badge and piggyback behind someone else to gain access to our facilities. So this quarter, I decided to spend the money on a third-party assessment of our Internet-facing applications.

Right off, the consultant found that an e-commerce application would allow a customer to obtain software without paying for it just by modifying a URL. Since the problem is so similar to one I myself warned about in my recent article about enterprise search, it was very embarrassing.

The assessment also revealed that in another of our Web-based applications, someone could intercept and then manipulate password-reset traffic to change a customer's password. Ouch!

Yet another application runs on top of a popular social collaboration platform, allowing users to share documents. The environment is open, meaning anyone can join and share information or download our product documents. The ugly discovery was that anyone could download a document, make changes to it and then upload it back to the same location with the same name. This could prove disastrous if changes were made to our products' specs. Fortunately, this issue was remedied with a simple configuration change -- but again, it was embarrassing.

Another problem was found in an application that has been capturing customer information without SSL encryption. We've been doing a good job of encrypting the initial log-on page, but the rest of the application wasn't encrypted.

There was good news as well. Our applications didn't seem to be susceptible to SQL injection, which has been a factor in many recent attacks.

On the other hand, we were susceptible to many variations of cross-site scripting, another popular method of attacking companies.

I'll be presenting the results of this assessment to the various application groups. After that, I'll strip out the good stuff and prepare a remediation tracking spreadsheet that describes each issue (with reference to the appropriate section of the comprehensive assessment report) and lists remediation recommendations, due dates and the person responsible for eliminating the problem. The spreadsheet will make it easy for me to tell at a glance the status of each issue.

And, of course, I'll be briefing our application team to ensure that we don't make the same mistakes as we develop or acquire other applications.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Join in the discussions about security! computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.