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)

Hybrid Analysis - The Answer to Static Code Analysis Shortcomings

Hybrid Analysis - The Answer to Static Code Analysis Shortcomings

    Given my previous article and the buzz it generated (both for and against the ideas I set forth)... I needed to hurry-up and write the follow-on article for "Static Code Analysis Failures".  I've had so many conversations with people about Hybrid Analysis, and "why static code analysis fails" I've come to realize a few things, and wanted to share more of the base for my mindset...

  • Definition: Most of the folks I've spoken to (developer to security "expert") have a mis-guided idea of "static code analysis".  With that in mind, here is the definition from the Wikipedia...

Static code analysis is the analysis of computer software that is performed without actually executing programs built from that software (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code. The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding or program comprehension. 

  • Concept: The whole reason we (security professionals) have pushed to get a security tool into the "development" part of the SDLC is that it's easiest to fix defects when the code is still being worked on and built.  We all know patching is a recipe for disaster, no one will argue that - so the idea in itself was sound.
  • Evolution: As the evolution of security marches on we have seen the evolution of "static code analysis" move forward as well.  The concept of the traditional white-box testing strategy has gone from sending your code to a human being who would read it, line-by-line and provide an analysis of that code to programs which are essentially smart enough to build the code, trace "source-to-sink" and build data flow models and attack vector simulations. I am writing to contend that we have moved on in the next step of the evolution.  Building the code and doing a "source-to-sink" trace with simulated attack scenarios is no longer good enough. (more on this in a minute)
  • Comprehension: It seems a few folks have missed the point of what I was talking about.  I'm not saying that this type of testing (white-box, source-analysis, whatever you call it) shouldn't be done.  Quite the opposite my friends - "code analysis" is vital to the success of any good security SDLC.
  • Solutions: Everyone quickly jumped on my case to defend whatever tools their company makes or uses... but I think I did my best to not attack any particular tool or vendor... hrmmm...

    OK so now let's talk about what the answer to this whole mess of analyzing web-borne code is going to be.  How will we, as security professionals, continue to be relevant to developers and the roots of the Software Development LifeCycle?  I tell you that the future lies in what I can only call "Hybrid Analysis".  This isn't a term I've developed, in fact, the term can be attributed to the developers of a certain software tool which is now distributed and built by the HP ASC group (to which I belong).  Without turning this into a marketing pitch, I want to explain to you why the leap I made in the above bullet-point titled "evolution" is valid, and why you should care.

    I love the quote I put in my first article so I think it's worth repeating... "Machines do not execute source code, they execute machine code"... absolutely true.  So when people used to work with source code we can now understand why they only got the answers part of the time.  Yes, I fully realize most modern source-scanners "or white-box scanner" tools don't just grep through code, as someone suggested at a blog posting that quoted me.  In fact, I'll go out on a limb and say that to grep through the code for "vulnerabilities" is about as effective as anti-virus and IDS (both pattern-based recognition)... there are so many permutations of the bad/malicious that those tools are inherently broken.  Anyway - to get back on track, I want to talk about this term "hybrid analysis".

    What is Hybrid Analysis?  (And more importantly, why do you care?)  Hybrid analysis is the culmination and what I feel is the inevitable cross between white-box and black-box testing.  I'm not sure if "gray-box" is the proper term or not, so I'll just keep using Hybrid Analysis for the sake of not mixing things up.  Hybrid analysis analyzes the byte-code that a source-compiler generates and builds your standard "source-to-sink" data-flow model but then moves beyond the limitations of that approach by taking that "knowledge" of the application and submitting it seamlessly into a (modified) black-box scanner built into the solution.

    Picture it - you have the blueprints of the bank vault, so you can try all the ways to theoretically break into the vault, then you hand those theoretical attack plans to a grunt who takes your information and goes and actually tries each of those attack vectors with multiple permutations and attack parameters to make the score and break in.  That my friends, is the proverbial Holy Grail of application security testing.  Data-modeling will only get you so far, before you have to actually try the attack to make sure it really works.  Now, given the many parameters involved, for example, external libraries, compiler behavior, and so on that influence the way code actually behaves it's conceivable that you can accomplish this feat I've described without the hybrid analysis approach (the modified black-box scanner) ... but then I think you're looking at an incredibly complex and almost AI-driven analysis tool... and I simply don't believe that technology exists or will exist.  I'm the kind of person that has to see something being broken before I'll believe it's real.  Give me the proof.

    If you take the hybrid approach - the proof looks you in the face each and every time.  As a nice side-effect you can virtually forget false-positives!  Source code scanners are infamous (notorious even!) for generating a lot of false-positives.  This has always been one of the many reasons developers argue against using these tools.  But what if you could offer your developers a way to eliminate those false-positives with little or no human intervention or double-checking?  If you're still skeptical, I'll be happy to have someone from our team demonstrate how this type of approach works, yes - we have it exclusively in our toolset.

    So let's recap.  Here are all the ways that Hybrid Analysis will save the world (joking):

  • Reaches well beyond modern "source-to-sink" data-flow modeling for vulnerability detection
  • Addresses 3rd party components by reflection (analyzing byte-code or IL of DLLs, JARs, etc)
  • Provides a real validation of the theoretical attack scenarios that the above step generates
  • Virtually eliminates false-positives!  This is a nice side-effect of testing using the Hybrid Analysis method
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