A few weeks ago I was sitting in a meeting room waiting for the folks who would be listening to me talk about App Security to come in. As people funneled into the room I overheard 3 QA guys talking about "understanding the application"... to which one of the security guys looked at them funny and said "we do black-box testing, we don't care to know the application".
Whoops, you fail.
It's not just that these security guys were going to be missing a huge chunk of the application- which they likely will - but it's in their ignorance of the actual application logic and flow that they will fail entirely. Thinking about that, and how to fix the problem, brought me back to DFDs and how useful they were to me when I worked on web application security testing back in the day. You know, I just don't think people just don't do enough intelligence gathering before diving into an application security test. Understanding the beast is fundamental to conquering it, and security folks have have a disctinct advantage over "hackers" (usually) because they have access to the actual inner-workings of the web applications they'll be testing. Being able to build, read, and understand a DFD is so fundamental to web application security testing that I'm putting together a new paper which will be released later this month (in collaboration with Richard Baker).
DFDs (Data-Flow-Diagrams) are so fundamental to understanding web applications (and any application or system) that I honestly can't imagine someone sitting down to test a web app without having a DFD in front of them. Of course, let me make sure I put it out there that this is mainly valid for internal testing teams but if you're an external tester and can get your grubby little hands on a proper DFD for the app... you can celebrate a little!
First, in case you're reading this and wondering what a DFD is - here is what the WikiPedia tells us about Data-Flow Diagrams:
DFDs are particularly valid for penetration testing because you have a black box in front of you which takes in, processes, stores and often returns data. It is in the understanding of that flow-model that you can begin to find potential weaknesses in the application. Testing randomly through the application may get you some results but knowing where to test (where data is processed, stored and returned) will yield crucial nuggets of knowledge for focused testing.
On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.
I turned to some industry experts (the analysts) and got a few good quotes - namely this one from Michael Montecillio...
"Data Flow Diagrams (DFD's) are an invaluable aspect of an application security strategy. DFD's allow organizations to target their strategies to properly address high priority aspects of their applications. Furthermore, remediation efforts can be prioritized based on the visibility of different segments of an app. based on the mapped information found in DFD's." ~Michael Montecillo, Principal Analyst, EMA Security and Risk ManagementIf a DFD is so fundamental then why don't the people who do penetration testing and AppSec use these ingenious devices more? See... Michael's though directly reflects why I think this issue needs more attention - people just don't know/get it.
Can you draw a DFD? Do you know what the various shapes mean? Whether you're a novice, or a self-assessed Certified ASS (Application Security Specialist, ASS for short)... you'll want this knowledge.