2009 proved to be an interesting time for application security. Web 2.0 as we know it took off. People were jumping on the PCI bandwagon, rewriting their applications on more secure platforms, installing Web application firewalls and so on. But a lot of things didn't happen in application security that should have. This column explains what didn't happen in software security testing, quality assurance and protection against hackers last year.
We still didn't get developers on board with security.
After interviewing numerous developers and development managers in my work last year, I'm convinced that security's still not a top priority for them. Until we can get past developers not knowing about Open Web Application Security Project (OWASP) or claiming that passwords and SSL define application security, we've got some work ahead of us.
We didn't stress enough to QA testers that security is also part of overall software quality.
I've never spoken to a QA tester who actually performs security checks in his or her work, other than testing basic authentication processes and password controls. The general perception of security is that it's something that will come later. The focus is on features, functionality and general usability. As long as QA testers can ensure code is delivered as promised in these areas, they assume everything's good to go.
We can't overcome all IT pros' assumption that application security stops at development and QA.
With these common oversights and seeming lack of interest happening, it's easy to blame developers and QA testers as the main contributors to our application security woes. That mindset is not only shortsighted, it's dangerous. Application security involves a lot of other people as well, including network admins, DBAs, project managers, security managers, compliance officers and even those in product marketing. Also needed is the backing of management -- something that's absent all too often.
Management didn't buy into the value of integrating security up front.
Unless and until management gets on board and takes IT and security seriously, we'll continue to see application security-related mishaps. The most interesting thing I have trouble wrapping my head around is how management seems to listen to human resources, marketing and legal counsel, but not to those techie folks in IT. The IT people's voices aren't heard and just don't seem all that important to management.
We didn't get past the mindset of "compliance equals policies."
Unfortunately, many in management -- including a lot of compliance officers and in-house legal counsel -- believe that documenting what's supposed to be done in some basic policies is enough to cover things. What a joke! A lot of organizations aren't even halfway finished becoming "compliant" with whatever regulations affect them.
I understand compliance is a complex and costly objective, but that doesn't mean it shouldn't be taken seriously. I've actually seen businesses that are reasonably compliant in many areas of IT, but fall flat on their faces when it comes to keeping application security in check. I think this is related to the compliance and IT managers believing that application security is a development/QA issue and therefore outside of their scope. In fact, I still see organizations that are just now realizing the value of in-depth application security assessments. And many are doing it not because they're supposed to for compliance or contractual reasons but because their financial auditors are telling them they need to.
We didn't seem to find a way to fix the biggest vulnerabilities.
Have you noticed that the same old problems are still around? The Web Application Security Consortium's Web Application Security Statistics Project 2007 -- released in September 2008 -- listed these prevalent Web security flaws: cross-site scripting, SQL injection and information leakage. Although I'm not seeing as much SQL injection in my work, it's still a problem. On the other hand, cross-site scripting is cropping up everywhere. It's literally on every site I view. This is pretty unbelievable, given that cross-site scripting preventative measures and fixes are relatively simple. The fact is input is not being validated the way it should be, and phishing and malware exploits are worse than ever.
Vendors didn't promote the value of their security scanning tools well enough.
I thought that HP's acquisition of SPI Dynamics and IBM's acquisition of Watchfire in 2007 would really help push Web vulnerability scanning and source code analysis technologies to the forefront. I don't think they did. If anything the value of their tools has gotten lost in the corporate quagmire. I'm a big advocate of using commercial tools such as WebInspect and Acunetix Web Vulnerability Scanner on the penetration testing side and DevInspect and Checkmarx on the static source code analysis side. We just need more people who realize their value and are willing to invest in them.
We didn't realize the full potential of manual application security assessments.
As much as I like automated Web vulnerability scanners, they only tell about half the story. Unfortunately, too many people relied on them for 100% of their application security assessments; especially on the penetration testing side.
I truly believe that you absolutely have to use manual analysis techniques on Web applications, browser plug-ins, client-server apps and whatever if you're going to find all the security flaws. I can say with conviction that the biggest application security flaws I've come across have surfaced by me poking around as a bad guy would, uncovering flaws no automated scanner would ever find.
Who's feeling hopeful for 2009?
Despite my cynicism, I am hopeful and said so in my 2009 Web security predictions. Honestly I suspect 2009 might not be a lot better, given that money's even tighter now and priorities are shifting to basic survival mode. That said, I think it is important to know that a down phase in the economy often provides the perfect opportunity to -- finally -- get caught up on things left undone. Be it static source code analysis, black-box penetration testing, or simply meeting with the right people and stepping back to see just how application security can be enhanced, now's the time to start making things happen.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic LLC, where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and email@example.com.