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.

Thanks for the comments. You have eliquently positioned your feelings and I appreciate the insight. Actually, I really liked your Matrix analogy in the midst of explaining your position.

I would like to clarify my position in the podcast that gave you the negative reaction though. To be clear I wasn’t meaning that “developers” don’t understand their own code. I was discussing how network appliance vendors aren’t able to understand Layer 7 security issues when they are trying to address the problem at Layer 3. As an example, there are firewall and IPS vendors who believe they can defend against attacks at Layer 7 without really understanding the application stack that is in question. More and more attack patterns are piercing these things because software people are finding better and better ways to circumvent their technical safeguards. This was the point I was trying to make.

I completely agree with you that respecting the understanding of the code by the development team is critical. Actually, I believe an outside security person will have a much tougher time understanding the implementation of code without a good relationship with the dev team, since they are the only ones that know the INTENT of the code in question.

Great feedback though. I wish we all could stop the bullets… or better yet… not need to.

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.