The ability to as-automatically-as-possible measure an application's surface area / attack surface should be one of the Millennium Prizes. Sadly, they only care about stupid problems such as does P=NP? Of course it does! For application security, this measurement can provide a comparable metric to the application's potential for security issues. Enough on that. I'm not trying to prove out an app's security this time. I want navel-gaze at our wonderful infosec industry.
An interesting byproduct of adequately measuring an app's attack surface, and to use the CMU researchers' verbiage, channels, methods, data and entry points, is that it provides a lot of scoping information on the application. No, no, no, I don't care about using this to guess the right amount of hours to assess an app (although that's possible). Rather, imagine if the client stated to a consultancy the following.
Client: "Hello Consultancy."
Consultancy: "Hello Client."
Client: "We have App XZY that has one channel of concern, with 15 direct entry points (methods that receive environment data)."
Consultancy: "Sounds good!"
[... time passes, consultancy is assessing application ...]
Consultancy: "Hello again Client!"
Client: "Hello again Consultancy!"
Consultancy: "We analyzed each of the 15 entry points and found the following. On average, each entry point used 25 different portions of the data, for a total of 375 data fragments [my word] consumed by the entry points. Out of these 375 data fragments, 200 were used in a conditional statement somehow, 100 were persisted by the application and 75 were reflected back to the user. We then examined each of those data fragments for appropriate validation and contextual encoding, if necessary. Blah blah blah XSS blah blah blah SQLi blah blah blah."
Client: "Wow! That's a lot of numbers that don't mean anything to me!!!"
Consultancy: "Oh, hold the boat there Mr. Client! You can start to use these numbers to measure the efficacy of other consultancies and tools. Of course that new Sprint you're about to do on your codebase will screw up all of these numbers. But, you can pay me to measure this again!"
Client: "Oh, I see. So, I can measure your work against another consultancy's work and see how closely you all got."
Consultancy: "Yeppers. So, when we leave here, you'll have at least an idea of what we did. You should then get someone else in the door to do an assessment on this app and see what they come up with. The sooner, the better, since you're pushing new code to QA this Friday."
So, yeah, measuring an app's attack surface down to how many data fragments exist (think HTTP parameters or header content for a web app) and how they're used can become a relative metric on the efficacy of consultancies, in addition to the many other benefits it provides. But, as I snarkily allude to above, it's fraught with issues, especially on the "freshness" of those measurements. I so wish magical tools did this. Our industry, and our client's appsec, would only benefit from it.
