Last week I had the pleasure to attend and present at the Security Zone 2012 conference in Cali, Colombia. First of all, I have to say that the Colombian people I met were friendly, warm and gracious. Edgar Rojas and his team did a great job of putting on the conference and making us feel welcomed. My travel partner Bryon Indriago of Security Innovation, who manages Latin America for us and speaks Spanish, made getting around easy and fun. It was a great trip.

Wendy Nather of the 451 Group and I presented together at the conference with me filling in for our CEO Ed Adams. Wendy and I talked about several topics in application security ranging from secure SDLC and Agile, to WAFs, to metrics like time-to-fix a vulnerability, at the end asking ourselves if application security is actually getting better. We presented in a two-person panel format asking each other these questions. In planning for the presentation we discovered a mutual love of Star Trek, so we also looked at these topics by imagining the different perspectives that would be taken by Captains Kirk and Picard if they were responsible for application security. Kirk represented the more hands on, action oriented CISO while Picard acted as a proxy for a more planning and managing oriented strategic CISO. It was great fun, well received and I want to publically thank Wendy for being great to work with on this and doing such a great job in the presentation. She definitely carried us!

My time at the conference and the questions we received at the presentation definitely opened my eyes to the state of information security in Colombia. The meetings we had in Bogota prior to the conference time in Cali also helped. Colombian IT security people are as aware and advanced in their thinking as any I have met anywhere in the world. They are clearly taking IT security seriously. More specifically there are people there beginning to take Application Security seriously and making great strides which is as much as you can say about anywhere in the world. If you are interested in this and another perspective, also see Wendy’s conference wrap-up posted on the Security Zone site above.

The only bad thing that happened on the trip (well, aside from some flight delays) was the fact that when checking out of the hotel in Cali, American Express denied my charge. This made for a harrowing 20 minutes at 6am trying to make an 8am flight which was the only flight out to the US on my airline. Thank you very much to the Intercontinental for taking a card imprint and letting us go. They handled it well and made a happy customer. I have since made sure they were paid.

This denial was despite the fact that I dutifully called and informed AMEX of my trip, and that a hotel charge on the last day of the trip should not be suspicious. What should be an easy charge to clear ended up a false positive in the fraud monitoring system that will likely lose American Express a 30 year customer with a lot of charging left to do. Their customer support when I called to talk about this didn’t help either, and that used to be one of their strongest positives.

This whole incident happening on the heels of the presentation got me thinking about false positives and WAFs. Wendy pointed out in our presentation that a vast majority of WAFs are deployed in detect only mode, and this kind of false positive is exactly the reason. Denying service based on a false positive can be worse than the risk of a false negative or an unblocked attack. This is yet another rationale that when possible, the application needs to be secure in itself rather than using anomaly detection to guess at what might be an attack. The application can know what it expects and service legitimate requests while blocking things that fall outside of its parameters. WAFs do have their place as I discussed already, but a WAF or other filtering or proxying technology has to guess, and that can lead to bad things happening. Like losing customers because you have security (or fraud detection) driving business processes instead of the other way around.