What Kind of Training is Important?

I was reading an article recently by Dave Ladd of Microsoft about security education vs. security training and it got me thinking about a conversation I had with Gary McGraw the other day.

We were discussing whether Ajax really represents a new attack vector. Gary was discussing the flaws as they relate to developers not understanding that they are pushing state to the client and that most of them don't understand the vulnerabilities of the client-side state they are creating.

I argued that the same is true for many web developers who don't have a firm grounding in technology fundamentals and use tools such as Struts for web development. Tools like Struts and other MVC web architectures abstract developers from how the web actually works are pretties it up for them in frameworks that let them pretend they are writing client-only applications. Most of the flaws that something like Ajax presents are just a new twist on "don't trust the client."

On the one hand this technique is amazingly productive from the developer point of view. They can develop according to well known ideas, constructs, and let the frameworks handle the fact they we're dealing with the web, HTTP, DNS, etc. Ideally developers shouldn't have to understand every bit of the technology stack they are using to get their job done.

The problem comes when these frameworks and this developer mentality meets the world of security. In security the fundamentals of the technologies being used actually are important, do determine what a developer can do, and expose vulnerabilities that a developer has to specifically understand in order to avoid.

When we think of training people on web application security we usually start from security first principles, but we don't usually start from technology first principles. We teach developers threat modeling, security requirements analysis, attack vectors, etc. What we often forget to teach them though are some of the technology fundamentals about the tools they are using.

I can't even begin to count the number of discussions I've had with web developers who don't understand HTTP basics, what the protocol actually looks like, what cookies really are, how browsers handle them, etc. They don't understand TCP/IP, DNS, ethernet, etc.

Without the basic understanding of things like the HTTP protocol, the fact that it truly is stateless, how cookies help graft state on top of it, and so on, a developer can't possibly hope to do a realistic job of threat analysis against their application. And if they aren't responsible for any of the low-level parsing of that type of data, they are never going to properly frame the discussion based on first principles.

When it comes to security education vs. security training, I'd prefer to start with the basics so that everyone is speaking the same language. As such, I think any good training program on security will include either formally, or informally, a number of sessions on technology fundamentals.

At most of my previous employers we started brown-bag lunch sessions to do basic knowledge transfer to everyone. Things like DNS-101, HTTP-101, Crypto-101, TCP/IP-101, and so on. We found that almost everyone with a desire to do the right thing and learn either attended if they didn't know the material, or was interested enough to ask questions afterwards to make sure they were up to speed.

These sorts of informal education sessions are invaluable for building credibility of the security folks, spreading knowledge throughout an organization, and creating a culture where knowledge is valued and respected.

Doing classes like these also helps with the security training you want to do as well. Once a sufficient number of folks are versed in the same basic vocabulary, its a lot easier to teach the advanced concepts and expect that they can apply their new background knowledge to more advanced things like threat modeling.