Following the Wh1t3 Rabbit - Practical Enterprise Security

Enterprise Security organizations often find themselves caught between the ever-changing needs of the agile business, and the ever-present, ever-evolving threats to that business. At the same time – all too often we security professionals get caught up in “shiny object syndrome” which leads us to spend poorly, allocate resources unwisely, and generally de-couple from the organization we’re chartered to defend. Knowing how to defend begins with knowing what you’ll be defending, why it is worth defending, and who you’ll be defending from… and therein lies the trick. This blog takes the issue of enterprise security head-on, challenging outdated thinking and bringing a pragmatic, business-aligned, beyond the tools perspective … so follow the Wh1t3 Rabbit and remember that tools alone don’t solve problems, strategic thinkers are the key.

Rafal (Principal, Strategic Security Services)

Displaying articles for: January 2010

Law of Diminishing Returns

In economics, we call it the "diminishing marginal returns" - referring to a point where (in plain English) no matter how many more resources you throw at something, the returns become smaller and smaller.  What this translates to in IT terms is a point where no matter how much more work you do (either by adding manpower, automation, or process) you simply can't push the virtual needle any further.

What am I going on about?  I'm talking about the state of Information Security (Web Application Security) many companies are in right now.  Pause while that sinks in...


Many of the Fortune 100 customers I have had the pleasure of working with over the past 2 years are reaching a point in their efforts to secure their web applications where further effort is not going to yield the returns they're hoping for - and thus they can't push the risk needle any further... Let me give a concrete example.

Let's take a totally fictitious bank - Bank of Makebelievia - and their efforts to reduce risks due to their web application implementation.  They currently have ~1,000 applications down from >5,000 just 2 years ago due to an aggressive program to reduce and consolidate web applications.  The Information Security team has been the focus of the "security and risk reduction" program for the past 2 years, and they have made great headway into the SDL the bank uses to release web applications.  Currently InfoSecurity analysts are involved in the the planning (requirements stage), and post-production testing of web applications.  The problem is... they still have apps with vulnerabilities.

The bank has tried to add staff to its Information Security team but that hasn't really helped ... more coverage isn't reducing the web-borne vulnerabilities as much as they had thought.  Tools purchased had an intial monstrous impact - but now additional tools (or user licenses even) are just allowing more people to work on the problem.  All this additional resource usage (money and people) isn't actually helping to reduce risk much more than the previous state.  Bankf of Makebelievia is confused why they're not getting better returns on their security investment dollars.

The answer for this bank, as with many of the other institutions and organizations is not trivial and involves a deeper understanding over the actual problem.  Breaking the issue down completely into it's bare-metal one can come to the realization that the problem isn't really better coverage - but better understanding of the problem.

What I think has happened to this imaginary bank, and many other real-life organization is they have hit the capacity of their Information Security Teams' ability to analyze web applications.  Now, before you pick up that rock to throw consider this - InfoSec generally has very little knowledge of the actual application purpose and function.  That's right, I've talked about this before but in an average "waterfall" development cycle is (on average) 6 months.  5 months go into actual development... 1 month goes into testing (UAT, Functional, Regression, etc) and the InfoSec team gets a URL and credentials on the Friday before the app goes live Sunday morning.  You know you've been there... or are there right now.

When you break it down like that it's quite simple to see that the security team can't possibly test the full capacity of the application... they just don't understand it.  So what do we do about it?  Stay tuned ... that's in the next blog post!

Evolving Web Application Security - Q1, 2010 Edition

News Flash - In 2010 and beyond, finding web vulnerabilities will not be enough to be the best "web application security" tool

I'm betting you probably know that though.  As the market becomes commoditized (we're not there yet) the next big thing is to figure out how to actually help our customers decrease the real risks of their web presence.  Over the last several years (10+ for those companies that claim maturity) vendors have been besting each other on features, speed, accuracy and coverage.  I'm not trying to say those will be somehow less important, only to point out that those will be things you can't differentiate (enough) by anymore.  Look at the space for yourself and you'll see why - "anything you can do, I can do better" is the motto that's been prevalent for coming up on 5 years and it's not slowing down any.  Adding support for things like the "Web 2.0" client-side shenanigans is probably one of the only differentiators nowadays, which we do better than anyone else mind you.  You're guaranteed to find a button or widget you like better with one vendor, and a feature or another widget you like better with the other...  That being said - once all features and functions start to look the same where do you turn to make a choice on which product/vendor to base your company's success/security on?

What if, work with me here, what if a vendor could offer you web application security software that actually ... worked with ... the rest of the software in your enterprise.  Not just that loose interpretation of integration where you can perform manual XML extracts re-entry ... no I'm talking about full-on work-together-ness here.  I'm betting that kind of harmony would catch your attention.

For so long software was silo'd meaning that your help desk software, server management/monitoring software, vulnerability scanning software, bug tracking software and so on all had different vendors, business owners and silos where they performed their tasks.  This led to tremendous over-spend, IT maintenance complexity which then of course led to big problems.  The fix for this is to try and buy your enterprise software from a single vendor... which wasn't possible until recently.  Without going on about HP Software & Solutions' acquisitions, I will simply say that being able to provide a customer with a vast majority of their enterprise software needs is an epic win for both sides of this equation.  How does this apply to security?

Allow me to draw you a mental picture.  Let's pretend you're the CISO of a large enterprise which employs a formal structure for development, testing, release, and yes, security.  Each of these silos has their own software tools, practices and manpower.  What you traditionally couldn't do is flow data easily between them.  Vulnerability data.  Fix recommendations.  Requests to test/re-test.  All these things wouldn't easily be tracked between these different groups which undermined the whole idea of removing vulnerabilities and drove up costs due to re-work, lost productivity and of course... frustration.

I firmly believe your enterprise software should work together, like a finely synchronized rowing crew, to get information back and forth across tools easily and in a sane manner that enhances productivity.  Software security after all, is part of software quality, and software quality has well-established principles, tools and processes!

There are 3 pillars of software quality ...

  1. Does it function?

  2. Does it perform?

  3. Is it secure?

None of those 3 things is less important when it comes to quality.  If a web app is secure but doesn't perform then it's a business loss.  Same goes for any of the other sides of the quality triangle... none of those 3 pieces can cease to be important.  This is where the commoditization/differentiation of security tools conversation hits an apex.

In order to truly appreciate the power of converged web application quality tools one must first come to grips with the fact that those 3 pillars mentioned above are each equally important.  Once that's confirmed as true, the next thing to do is figure out how to make them work together.  This is the next "big thing" in web application security.  Whether you're "Web 2.0", web services, old-school web apps or what-ever you deploy your organization will need to ensure performance, functionality, and security.  Doing this can be quite the daunting challenge without a toolkit that helps your teams work in synchronicity and report defects, vulnerabilities and failures to the same central console for tracking and remediation - not to mention metrics collection!

When the QA engineers, Security analysts, managers, project managers can all use the same tool(s) to view how an application is coming together it's a huge win for your organization.  Include into that mix the ability for a tool like AMP to interact with other parts of your software enterprise and you have a ginormous win!  Another great scenario one of our customers has envisioned is having their applications continuously scanned and re-scanned in production.  Given that they have 15,000+ applications it's almost an impossible feat to do manually - but through he magic of automation the AMP suite they have can do just that.  Adding another element of automation - AMP opens a help desk ticket in their ticketing system (by doing a web-services call to their help desk software server) when it finds a critical or high-level vulnerability.  The help desk then assigns that ticket to an analyst who investigates the issue determines whether it's real or not and assigns a developer to fix it.  When the developer feels he/she has fixed the issue a request to re-scan is sent to AMP which then (still without much user intervention) re-scans the application.  If that application vulnerability is now gone, the ticket is closed and the system has a proven metric for resolving vulnerabilities discovered in production with a resolution time, audit trail and all the goods that make this a truly powerful solution!

This type of scenario is where "web app security software" is going.  If your vendor of choice can't make your business this intelligent...maybe it's time to switch?

About the Author(s)
Follow Us
Twitter Stream

Community Announcements
HP Blog

Technical Support Services Blog

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation