This customer had a massive application written in ASP classic. Since it was in ASP classic it had massive numbers of SQLi vulnerabilities. Everything from Blind SQLi to the always fun SQL statements in the URL. The customer said this application was roughly 250,000 lines of code with SQL hardcoded throughout. The reason the customer had called WhiteHat is because they where working on a big deal with a potential client and this client was asking for a security report on the application. They where also in the early phases of rewriting the application in .NET (yeah) with an estimated completion date 1.5 years out.

After seeing our report (100+ SQLi and 300+ XSS) and after a protracted developer battle(yes XSS is not good) they where left with two not good options.

1. Lose the customer.
2. Stop the rewrite and spend a few months digging through old code to fix these issues

Now from a business point of view neither of those makes sense. At the time we where in the WAF hater camp but we saw that in this case it made total sense. The customer deployed a WAF, configured it using our vulnerability data, and was able to mitigate the risk in about 3 weeks.

Bottom line and what people continually fail it understand is that every current solution on the market today has its short comings. In security everything does. Is there one magic network solution that will prevent all network attacks? No. You have spent a ton of money protecting your network infrastructure. Let’s take a quick look at the list of things you probably have spent money on today:

1. Firewalls
2. IDS/IPS
3. Network Vulnerability Scanning
4. AntiVirus
5. Configuration and Patch Management
6. Database Scanning
7. Database Encryption

Guess what, none of that protects you from the rush of SQLi, XSS, and other web based attacks. All that money and you still have big gaping holes.

To properly attack the Web Application Security problem you should be doing all of these things:

1. Secure coding practices
2. Source code review
3. Black box testing
4. Web Application Firewalls
5. Developer Training
6. Configuration and change management

The reality today is that people underestimate the size of the problem and therefore do not have the budget to do all these things. You can stretch those budget dollars pretty far with an open source scanner and mod_security (software cost $0). WhiteHat is not that cheap but we are very cost effective, combined with mod_security you can go a long way. Need a more robust solution, WhiteHat + F5 can scale to 1000 of web sites in a very cost effective manner. WhiteHat and our WAF partners can knock items 3-5 off your list while you go work on getting your coding practices in place. Even after you get those practices in place you are still going to find vulnerabilities and having that “instant” mitigation ability is very comforting.

Robert over at cgisec sees the light as well. He has managed and is currently managing web site security for some of the largest most frequently attacked web sites on the planet.

Post from: Grumpy Security Guy

The Business Case for WAFs + Testing

1. Understand that you have been caught.

Spitzer quickly understood that the cards where stacked against him and decided denials and platitudes where not going to work for him. Perhaps as a former prosecutor he knew how strong the case was against him. If you are dealing with an incident it is important to understand that excuses for poor security are not helpful right now and dealing with the task at hand has to take top priority. Also do not try to deflect by making up stories of honeypots, false alarms, or “really it is not a problem” statements.

2. Get out in front.

Maybe it is just because I am on the west coast, but it seemed like as soon as I heard the story I also heard that he had a press conference. This is a pretty quick response. In this case he probably knew it was coming since The New York Times probably gave him a courtesy call. You are not going to be that lucky so you will be playing catch up but it is important to respond quickly and decisively.

3. Don’t give up the ghost.

Spitzer’s first press conference was masterful. He admitted everything and nothing at the same time. This is when a good PR person can prove invaluable to the Incident Response Team. You want to acknowledge the problem, give concert steps you are taking, and buy time to get all your ducks in a row. If you are dealing with a large leak of credit cards for example you are going to need some time to figure out just what the heck is going on, who is effected, and what your response is going to be all while waiting for law enforcement to get out of the way.

4. Use the time you just bought.

Assuming you did #3 reasonably well you now have some time to figure out how you are going to respond. If you have law enforcement involved your hands are probably somewhat ties as they are going to want to control the flow of information. One area law enforcement is not going to get involved with is how you are going to respond to your customers. This template seems to have already been written, credit monitoring for a year and some gift cards. You can do better!

5. Cut your loses.

At some point you are going to need to get back to work and put this incident behind you. If the police are not involved this should probably be sooner rather than later. I have seen companies sink a lot of time and effort into trying to catch the person when there is little chance of getting anything out of it. I worked several cases where I tracked the attacker back to some non-US country that is practically impossible to get anything done and especially if it is just you and not the feds. There is some joy in finding out who did it but your time and money      is generally better spent finding out how it happened and correcting the the issue then finding out who. The who is most times irrelevant (unless it is an insider of course).

Post from: Grumpy Security Guy

5 Lessons on Public Disclosure From Elliot Spitzer