As stated in a previous entry, I'm going to break down some of the [nameless] case-studies I've got in my notebook over the last several months.
As a note, if you read one of these and think it's you... feel free to tell me if I've missed a point or two.
A few weeks ago I had the pleasure of talking to a very intelligent security lead for a major us-based company that deals with *a lot* with your personal, credit and medical information. What I found out as we started talking about application security and their approach to it - was that this particular person was very interested in actually securing their web applications whereas the business was just happy to check the PCI and HIPAA boxes and move on. The classic problem ensued - how does this security leader successfully implement a security program when his or her business has absolutely no interest in doing "the right thing" but instead is interested in doing the "right now" thing? I know this isn't really a revalation to anyone because this is a common problem. What makes this case unique to me is the context of this problem, namely - where it's occurring. I wish I could simply tell you the company but that would be almost completely irrelevant.... the only thing that's important here is that this problem exists.
So now we're faced with a problem. IT Security wants to drive better code, no doubt there. Development only cares about release cycles being faster and "more streamlined" so naturally this means that tools aren't an easy sell, and there is a large QA organization that load-tests and moves on. Yikes. Interestingly enough, there is a thing to be learned here, my security lead contact is approaching this brilliantly and I wanted to document this for the benefit for you, the other readers.
We've all heard someone say (and if you've been to a seminar of mine, you've heard me say it) that a security program isn't just implementing tools and checking a box. While I whole-heartedly agree with that, there are approaches where someone who is strapped for cash, manpower, and security intelligence can kick-start their security program by implementing some basic SDLC [Software Development LifeCycle] -integrated security tools. This is one of those approaches, I'd love to hear your comments either privately or via this blog.
The organizational structure is quite unique... the Security lead currently does not report to the head of IT, instead he or she reports under the legal/compliance branch of the company. Interesting situation wouldn't you say? That pretty much absolves the security team of operational duties and challenges... you would think. Not so much but there's definitely leverage to be gained there, I assure you. The security team is leading the charge on application security as a result of a PCI initiative (shocking) which is driving "check-the-box" exercise to implement some tool or process and move on. These are challenges a large number of the readers of this blog can sympathize with.
In order to get things going, this organization has chosen to work with a "kick-start" type approach which builds a security program starting with what would appear to be the blunt end of the security stick. By implementing an enterprise "scanning" tool (in our case, AMP + WebInspect) to identify the *immediate needs* which exist in the production environment among the mission-critical web applications, they are goingn to use those metrics to demonstrate the need for a larger-scale approach to security web applications (there is much more to this, but this is the simple version). Using a combination of tools and professional application assessment services to demonstrate the immediate need the security leader can then use "right now" money which comes from the PCI Compliance budget to accomplish a basic check-mark for PCI and demonstrate a need for a long-term, SDLC-integrated security program. Collecting data and turning it into security intelligence (read: information) will make this component of the approach successful. The side-effect of this approach is that it uses money slated for a short-term fix to accomplish that plus plant a seed which will hopefully sprout into a full-scale enterprise security program in the future.
As part of the initial purchase of licenses (tools, just tools) the security leader is also purchasing other pieces which further integrate into the enterprise SDLC, and plan the seeds of security among the different departments (development and QA) which traditionally have no interest in security. While it's in their best-interest to produce secure code (development) and identify security defects (QA), departments outside security don't traditionally think "security"... so these tools can demonstrate how simple it can be to produce secure code with minimal effort.
Voila! Long-term strategy... which then starts to sprout policy, process, and education to create a real enterprise-grade web application security program. The program is *not based* on tools, but is built off of a foundation that bootstraps from some tools to get the initial gears moving. Like I've said all along, the program won't be built around tools - but the tools can be used to help kick-start a program that otherwise would have little chance of getting off the ground. I feel very confident that this particular security leader's approach will be successful, and may even get him or her promoted :)
* This is a specific case-study. If you'd like to hear more about how this potentially applies to your company, or how you can get help kick-starting a security program within your security-agnostic organization... pop me an email directly and I'll be happy to open a discussion.
Posted
09-09-2008 2:01 AM
by
RafalLos