The He Got Game Rule

Guess what? The single most important book for security pros to read is not written by Ross Anderson, Gary McGraw, or Bruce Schneier, in fact it does not even mention security at all. No this is not some paean to a goddess of risk either. In fact its a book on integration.

@jeremiahg reminded me of this with his fine harvesting of this quote from BSI-MM: 

The best SSG members are software security people; but software security people are often impossible to find. If you must create software security types from scratch, start with developers and teach them about security. Do not attempt to start with network security people and teach them about software, compilers, SDLCs, bug tracking and everything else in the software universe. No amount traditional security knowledge can overcome software cluelessness.

About 6 years ago, a security manager at a client was asking me for some help. His dept had received some increased funding for security projects, and he needed some talent, but was having no luck. I read the job reqts and saw the problem immediately. The job requirement was filled with asking for years and years of security experience. What possible good would those skills do when the strategic problems at hand were integrating SAML into Weblogic apps, threat modeling in the SDLC, and building a STS??? Its hard to imagine a less applicable skillset than Network Address Translation rules on teh fierwall.

I call it the He Got Game rule. When Spike Lee was making the movie He Got Game about a burgeoning NBA basketball star, he had a choice. He could cast a Hollywood actor like Robin Williams and try to teach him to play realistic looking basketball. Or, they could cast a basketball talent like future NBA all star Ray Allen and teach him how to act. Spike Lee chose ray Allen because he quickly came to the conclusion that it was much easier to teach a basketball player how to act than to teach an actor to play basketball. Its the same in security, its much simpler to teach motivated developers how to threat model, how WS-Trust protocol works, and so on, than it is to teach even motivated security people who are operationally focused on how Websphere, Apache, Directories and other core software technologies are built.

So back to the book recommendation, if you are a security pro, and you think you can increase your hoop skills, first realize you have a high barrier to cross. Second, understand that the main problem we face in security is not clueless users, "bad" developers, or insufficient security protocols. These are simply constraints to design with. the real problem is security integration. So if your background is infosec and you want to step, then the book to read is "Enterprise Integration Patterns" by Gregor Hohpe and Bobby Woolf.

Rather than obsessing about the latest and greatest threat, its much more strategically important to sort out the logistics, constraints, and economics to distribute and scale out the security mechanisms and processes we have. Specifically how are they impacted by and how do they impact the message flows, endpoints, routing, transformation, and management. These patterns are aptly described and cataloged in Hohpe and Woolf's book and provide an important starting point for meaningful and useful security improvement over time.

Comments

[Adrian Lane]

If security professionals going into coding is the goal, heck yes! The are even more facets to this problem than what you describe. People who know security, who can think like a criminal, who have the level of skepticism and cynicism that it takes in this profession absolutely fail the typical HR acid test of "perky and eager to work for our team". Candidates barely make it in the door. More than that, most dev managers have no clue how to interview a candidates with a security background; what questions to ask, what skills and approach to problem solving to look for. On the other side of the coin, I find some types of security professionals are more readily adaptable to the structured and detail oriented approach to coding larger, more complex applications ... a lot of security researchers are excellent at ripping off a prototype, but kinda suck at more rigorous approach to object oriented programming, processes and disciplines. It's a mindset thing. Some are no-BS, "I don't need no stinkin' process" get to the heart of the matter kind of people, and others are rigorous and detail oriented obsessives. Feel free to disagree with my generalization, but I'd take a web app hacker for product strategy and a cryptographer for development rather than the other way around.

Good post and great recommendation, by the way.

-Adrian

[Gunnar]

Hi Adrian,

Its not about turning security people into coders, its about integrating security mechanisms. This means you have to understand software and data. Practically speaking, you have to understand the design issue it could be expressed by coding, but its more likely that it means config (one of the themes in EIP is applications are more configured than coded), architecture, testing, and so on.

A seat belt only work if its in the right place for the driver to use it. An airbag doesn't work if its on the outside of the car, it has to be in the steering wheel.

The time for defining abstract security policies and not anchoring them in concrete architecture is over.

Your point on HR is well taken, but I also know plenty of good developers who can fail at this, so we'll just have to work around this and tell the HR people who we are going to hire ;-P

[Andre Gironda]

as a webapp hacker-developer product-strategy-cryptographer like yourselves, i must say that design is a step for the "process" but the constant process of design throughout construction is what really matters: refactoring.

define it how you will, prototyping the best definition i've even heard so far, but without process you have nothing, albeit the process never has to come from up above. no lead developer, no product manager, no guidance ever need take place when in the dev shop surrounded by minds of pure dev expertise.

that means no cowboy coders, but only enterprise architects of the highest caliber. do these people read a book or two about patterns? no, sir, they have read all of them from bertrand meyer to david garland -- decades before the current time.

i must agree with gunnar that the best "on our security industry team" right now have got to be enterprise architects and lead developers. we've also got data classification experts and these things that most people forget about called "data owners" aka "customers". if only their voices could be heard.