Cigital

A good podcast, as always.

I wanted to comment on something that Dana said. I’ll paraphrase as, “the thing that developers don’t understand is that we understand these systems better than they do.” Gary followed this up with an matrix analogy. I really like what Gary said, I have a negative reaction to what Dana said–probably because he said it so quickly not because he doesn’t understand it.

Security guys have an interesting problem–whether they’re external consultants or internal resources. Regardless of whether or not the software in question is a software product (like Oracle)or is being written in order to support a line of business (like a financial website) that software’s Development team will understand their software better than we (security folk) do, contrary to what Dana suggests. Macroscopically, there’s just too much of their code for us to grok. They’ve been working on it day-in and day-out for years–we haven’t. They understand the code’s role in business workflows–we don’t fully. Focusing on a very small aspect/module of the code, we may begin to understand one aspect/module more deeply than they do, true. But, the real value we provide, IMO, is understanding the properties and side effects of what’s underneath their code–that’s what matters. For a security person, it’s essential that he/she understands how compilers organize method calls or buffers in memory, how runtimes load and store class and type definitions, what checks are done by compilers, classloaders, verifiers, and finally, in-runtime security managers? For the same reason that developers understand their code better than we do, these things are often invisible to them: the developer remains focused on workflows and features–not what’s underneath them.
It is in this light that Gary’s analogy is most apt.

M: “Some rules can be bent, others can be broken.”
N: “What are you saying, that I can stop bullets?”
M: “When you’re ready, you won’t have to.”

By getting underneath the application’s functionality, you can simply change the rules on which the application relies. After that, all bets are off. It’s no wonder that the Developer can’t protect against attacks–the attacker isn’t abiding by rules or conventions the Developer believes to be hard-and-fast.

In summary: break or bend the rules as necessary to exploit or test software–but always respect the Dev. team’s understanding of their code/problem. There’s a level on which you understand it better than them, but there are certainly levels on which their understanding exceeds your own. You’ll need to tap them in order to understand the rules’ well enough to bend or break them.

—-
John Steven
Technical Director; Principal, Software Security Group
Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F http://www.cigital.com
Software Confidence. Achieved.

Yes,

I fully agree with the position from which you followed up in the comments as well. I’m going to have to listen to the podcast again and see if I just missed that message.

Very cool podcast though man.