Short answer: in most cases, absolutely not. Tools alone do not make an application security program successful. In fact, I'd go as far as saying that taking a tool-centric approach to any security program is doomed from the start. Let me explain why with a "purely hypothetical situation."
All too often I've run across organizations that have deep enough pockets to run a very tight ship, yet somehow fail miserably. This evening we will pick on the Federal Government sector. Most groups in the Federal or DoD space have to budget several years in advance to procure actual consultants or contractors to perform a particular subset of services. However, at the end of each fiscal year they fight over huge pots of money. Those that are fortunate enough to justify why they have a rightful claim to some of the funding often go out and spend a considerable amount on tools and other software solutions that they hope will serve as a band-aid for another year or so.
Here is a scenario that ends up unfolding time and time again: Agency A purchases a few licenses for a web vulnerability scanner and a source code analysis tool. Meanwhile, they expect their same mid-level (maybe even "senior") security teams to perform this work properly without any training, hands-on experience, or in-depth knowledge of what they are up against. Armed with new and expensive tools but lacking knowledge of fundamentals, best-practices, etc etc they begin scanning everything. And scanning. And scanning. And scanning. At some point a savvy developer bursts his/her bubble and says "Everything in this scan report is a false positive. Did you verify them first? Did you tune your rules or did you just use the default rules?" The "security" team member responds with "Tune what? Why and how would I verify the results? I'm not a developer. That's your job."
The outcome is that 1) The development team has absolutely no respect, trust, or faith in the security team 2) The security team feels disgruntled at the lack of appreciation for their tireless scanning efforts, and 3) The organization somehow feels invincible in the end because they had no "real" issues to deal with other than internal bickering....even though there were likely thousands of actionable issues that were overlooked. Not to mention severe gaps in their development processes, organizational policies regarding anything and everything related to good application security practices, and ultimately any sense of their true exposure to risk. Therefore, why bother to put forth additional time and effort in building and maturing an application security program. They haven't been attacked. No critical issues were proven to exist. And even though they develop systems critical to our national infrastructure, they aren't a target (really?). Everyone wins, right??
Wrong.
-Jack
5 comments:
Jack - I couldn't agree more! In fact, even though I work for a vendor that SELLS web app sec tools I *always* emphasize people, policy, practice first before you dive in and start buying stuff... The likelihood that a tools-driven program will succeed is next to zero in my professional experience.
I've written about it on my HP "Following the White Rabbit" blog over and over and over...
Thanks for spreading the truth!
Hi Jack
I know what you're saying but I think you're missing the point on where to buy tools.
Some problems for you:
#1 I have a really smart applications security guy. I give him tools so that he can go faster and stronger.
#2 I have a really smart applications security guy. I give him a helper person who doesn't have the skills but can run a tool to do some of the simpler tasks to make the good guy go smarter and stronger.
#3 I have a couple of mediocre applications security guys. I buy tools to give them a more reliable process and output--maybe between the 2 of them they're equal to a good appsec guy and a tool. I know it's not perfect but I either can't find or afford a good appsec guy.
#4 I have somebody who is good at the OS and network threat and vulnerability game. I don't have budget for more headcount in my shop. We don't have a ton of custom apps, so I give that guy "other duties as assigned" and give him a tool to help his knowledge gap.
Maybe what I'm saying here is that you're making a classic mistake in assuming that most of the worker population are appsec rocket scientists.
I just don't see the volume of people with the skills, and the only answer that I have sometimes is to buy the tools and then get my people into training.
But yeah, it's a crap approach. =)
@Raf- maybe we should put together a talk one of these days.
@Rybolov- In order:
1- Your application security guy that has granular knowledge that can bridge the gap between technical and process-driven requirements isn't the issue here. If this is a massive organization and they are laying the groundwork for a successful security initiative while using automation to make the technical portion more efficient, this isn't an issue.
2- That's fine. Just means you have even more resources than in #1. The ultra-sharp guy can do the heavy lifting and mentor the junior guy. You are in even better shape than in #1 here.
3- Now we are running into issues. Can you truly not find a good appsec guy, or has your talent pool been limited to only a subset of what is actually out there? Were you given a budget of only 70-80k for a security guy and 100k for tools? Do you think this works better if you are able to splurge another 30-40k for the right guy, and buy less scanner licenses?
4- Rather than augment with a long-term position, why not split the resources between bringing in a temporary external set of eyes, training for your OS/network guy, and tools as required?
I know some Saas/cloud security service advocates would look at this and say "why not just go that route??" Which sort of brings us full-circle again.
Jack - I've seen this time and time again where organizations buy tools thinking that their job is done. The work has only just begun.
The largest challenge I see is the disconnect between the purchased tool and how it accomplishes the business goal. Without the proper process, ownership, advocacy by senior management, etc. tools often become shelfware. Companies rightfully don't want to invest too heavily on being experts at these tools because it's not their core competence -- but they need some help!
Post a Comment