Eric Friese

A couple of weeks ago I was a speaker at a seminar hosted by the ISSA Colorado Springs chapter. The idea was to talk to some federal guidance coming down the pipe, the 2013 National Defense Authorization Act if you haven’t heard. The rest of the talk was some basic steps to start a Software Assurance process.

In the beginning of the talk I had a timeline of some breaches and also important legislation. I mad e a comment about 2008 being an important year because of the Heartland breach. I mentioned the amount of records breached and, in passing, said that they had just passed a PCI inspection.

Boom. A hand shoots up and it’s a guy from the PCI Council. As he informed me, there are only 26 people on the Council responsible for forming the PCI-DSS. First of all, I should have left the seminar and bought a lottery ticket. He goes into a long comment about his frustration with speakers pinging PCI when it is just a security baseline. He was clearly upset with my comment, but it opened a good opportunity for my presentation.

I agreed with him that PCI does not equal security, but that’s the problem with legislation and standards. Once an organization achieves compliance, they feel like they’ve done enough. To the bean counters in Finance, it can be difficult to justify more spending that what is “necessary”. We as security people wage that battle every day, and it will continue.

At the time of the Heartland breach, there was zero in PCI-DSS focused on applications. Later revisions would change that, but only a little. The major point of presentation was that the latest NDAA has provisions requiring the Department of Defense to start securing their applications. That’s one small step for mankind, but one huge step for the DoD.

After getting off the stage, I was talking with a colleague about the PCI comment. He mentioned that is the exact reason he doesn’t use absolutes when speaking in front of groups. I can see the logic in that viewpoint, but if you use passive voice all the time your not authoritative. If you can’t say something authoritatively, you probably shouldn’t be on stage talking about it. Even though there was some tension for a second, it made people pay attention because it was interesting.

I had to catch a flight after the talk, so I didn’t get a chance to talk with the PCI guy. I would have liked to thank him for his comment and for helping me make my point. I probably could have explained my comment more to show I wasn’t attacking PCI-DSS directly…I was showing our reliance on compliance is completely dependent on the level of security provided by the standard.

Eric Software Security

When I first started learning .NET back in 2005, I bought an ASP.NET 2.0 in 24 Hours type book to get the ball rolling. .NET was my first managed language, so it all was pretty new to me. I had spent plenty of time writing in C/C++ and PHP. I didn’t care about security, I just wanted it to work. Fast forward a few years and I’m now a security guy. When I read how-to books now, I’m always looking for security vulnerabilities in sample code. This is a common problem and really starts new programmers on the wrong foot. I completely understand wanting to make sample code very easy to understand, but if we keep security an advanced topic, it never gets read. I’m guilty of reading 2/3rd of a programming book and then not finishing it because I want to go code. We need to build security into every step of our curricula just as we do our SDLCs.

This weekend I was looking at a Microsoft tutorial on MVC 3. They have a basic example of a HelloWorld app that echoes out a name from the GET request. When I saw them setting up the example, I quickly thought cross-site scripting.

I was surprised to see the HtmlEncode method there, well done Microsoft! While this function only partially fixes the problem (HtmlEncode from the HttpUtility class only HTML encodes certain characters, so XSS is still possible but difficult). Using the AntiXss library would have been better. They also don’t explain why they HTML encoded the output. A simple paragraph stating we do this to fight XSS and here’s a link for more info would have been good. Nevertheless, I was happy to see this. My hat’s off to you Microsoft.

Eric Software Security

There’s an interesting article on Threatpost’s Tumblr showing a graphic of 2011 attacks, their impact, and the attack type.

The data was taken from the latest Verizon Data Breach report for 2011, which if you haven’t read you should. Great stuff. There are a few observations to take away from this graphic regarding Application Security:

• SQL Injection is still popular
• Where are the other AppSec attacks?
• In many of the breaches, the attack vector is “Unknown”

SQL Injection is Still Popular

SQL Injection has been the long running king of many top vulnerability lists and there doesn’t seem to be any threats to the thrown. SQL Injection is no doubt one of the nastiest appsec vulnerabilities, but it’s sad that SQL Injection is still such an issue. SQL Injection isn’t new, it’s been around for a long time. Why can’t we kill this one bad vulnerability? Focus. Critical vulnerabilities do get the main focus, but our software assurance programs focus on holistic approaches. I think we may need to change that. Don’t stop the holistic approach, but as the AppSec community we should make 2012 the year that SQL Injection got it’s face stomped in. All AppSec people put a special emphasis on identifying and fixing just SQL Injection. If you’re reading this and you have influence over AppSec, let’s focus just on SQL Injection.

Where are the other AppSec attacks?

SQL Injection is the only pure AppSec attack vector mentioned in this graph. URL Tampering and “3rd Party Software” might have some AppSec context, but it’s hard to tell. We all know that there are a significant amount of application attacks. I’m curious to know if XSS was used in any of the phishing attempts. Phishing gets interesting when you can include a link to their company web site. Are we just missing those parts of the attacks? That leads me into:

In many of the breaches, the attack vector is “Unknown”

The amount of “Unknown” attack vectors here is a little troublesome. Of course, we have to assume some of the unknowns are because the attack vector hasn’t been announced. Some of them though are because our ability to monitor our infrastructure and applications is pretty low. Organizations have spent tons of money and time implementing firewalls, IDS, IPS, SIEM, etc yet we still don’t always know how the attackers get in. From the application security standpoint, I can honestly say our understanding of what’s going on inside of applications is very limited. Most developers think that log files are places to stick stack traces when something breaks. Log files should be so much more. They should log sensitive user activities, access to data, errors, and security events. After an attack, looking through error logs might tell us a little about how the attacker got access to data. It usually doesn’t tell us what data was compromised. We need more visibility into our applications so we can tell normal traffic from abnormal traffic, attack activity, and what data is being accessed.

Eric Software Security