To Bolster Software Security Development Capability: Look at How R&D Has Changed in the last 50 years?
While reading last week’s Economist, I stumbled on an article on Innovation (available without a subscription online). The article discussed how commercial entities have changed the way they fund R&D. They’ve fundamentally changed the structure of research and development groups–as well as their interaction. I began my Cigital career in the company’s research division and later moved into a purely operational role as “Consultant.” “Principal,” my current role, demands artful compromise between the two, so the article immediately caught my attention.
When a client asked about “Getting in front of AJAX from a security perspective…” this week, I connected dots between organizations’ need to innovate and the realities development require.
The big change: Big research labs (such as PARC, Bell Labs, IBM’s labs) have become extinct and hoping for “tech transfer” after stand-alone research investment represents a fatal chasm between “Research” and “Development” unlikely to be crossed… or improperly exploited even when crossed.
I see an analog for this in today’s software shops, especially pursuant of security. Right now, organizations don’t understand software security well enough to treat it as development. For them, it’s still research. While not science, in its strict sense, people don’t know much about software security. They’ll have to read, think, experiment, and be very creative before moving into a engineering/development mode.
That’s why my client said, “We want to get in front of AJAX…”; he, his organization’s software security guardian, sees a problem development can’t solve, and he doesn’t yet have the answers either. He needs a leap or two forward before he can communicate solutions to hard problems well enough to empower development to “build security in.” These problems include personal data protection, authentication, and even the very process by which his organization creates software. That’s probably why he called Cigital.
My client faces a common situation. Organizations drive their businesses, for the most part, reactively. Product companies react to customer needs (features, deadlines) and IT shops react to opportunities and risk the businesses they support face. Unless driven by compliance, publicized incident, or a similarly dramatic driver, these businesses’ development teams don’t react to software security’. As a result, development doesn’t possess engineering skill and experience in software security.
What to do about it: Organizations depending on innovation must 1) foster practical engineering (development) behaviors in those individuals with the horsepower for research and 2) embed them in development teams towards a practical end.
First, get qualified individuals. But, I’m not referring to wild-haired mathematicians. You probably already employ some of what you need in your org. I’m talking about your gifted individuals that attend conferences, avidly consume literature, and possess an advanced degree in computer science (or similar). These individuals frame the problem, hypothesize a solution, observe, then iterate.
This person probably has an uncanny knack for coming up with lateral approaches to your design problems. They may be a complainer–ineffectively shackled by their current position. A former mentor to me used to comment, “You seem to always have ‘just read something’ useful in every meeting I bring you to.” That’s what you’re looking for.
I like to focus on “Security Architecture,” so I look for these types in the Enterprise Architecture group (though, the do-nothing librarian type need not apply). Specifically, you don’t want someone that ONLY reads, or with no (or outdated) hands-on technology experience. We’ll call these people your innovators.
Second, embed these people IN development teams. Preferably, innovators should be ‘leased’ to the team solving the difficult problem: securing credit card data without increasing its (representational) size unduly, for instance.
As part of a development team, innovators should be held to a schedule and budget, like everyone else. I like the idea of managing them to a final delivery a release or two out, but with important constructive deadlines within the current release, showing progress. Managing these interim deadlines between “Hail Mary checkpoint” and “incremental main-line progress” depends on how ambitious the overall goal is.
I argue that organizations lose when they fund research with development project money directly or comp. (bonus) innovators with project metrics directly. Having these individuals report to someone else (shared services?) will allow them to focus on their technology goals. If their manager sits as a peer to those managing development, tough conflicts regarding project schedule and security program priority can be resolved reasonably.
However, that’s not to say that the development team shouldn’t participate in cost though a “tax.” After all, they do benefit from the extra horsepower applied to their project. Likewise, the researcher should be evaluated, in part, based on development project impact.
This approach naturally lends itself to a consulting model. You can hire someone or use your own internal team (which one of our clients does particularly effectively). First, make sure they’re qualified: exploiting code can be pretty easy and some consultants give bad advice generalizing quickly from something they’ve seen once. The “use POST not GET” advice OWASP gives serves me consistently as an example. I’ll cover this example and poor advice in a later post.
Beware the “’sploits-and-splash” failure mode. Embedded security resources must be constructive. Simply pointing out how not to do things doesn’t produce secure code faster and disenfranchises developers. Advice about how to pay and measure these individuals applies here. Instead, focus innovators on the tough design problem it will likely take two-to-three releases to iron out, and that might be useful on a whole class of products within a line of business. Make them responsible for producing a solution; not just pointing out problems in every product team’s smaller attempt at one.
Cigital believes in research, in the true sense of the word. We talk about the value a lab provides in each of our strategy meetings. We believe in practically applying more theoretical solutions in a consulting model as well. I believe injecting a research mentality, as a ‘thread’, into development serves as counter-weight to reactive mentality, helps solve software security problems, and gives the necessary horsepower boost to “build security in.”
I think you’ll find that architectural flaws your organization’s software exhibit require solutions “bigger than a single release” and set the stage for this topic nicely. The alternative? Fall prey to a purely engineering mentality making small incremental improvements that remove a single attack vector but leave the endemic flaw at large. This causes continual development churn and leaves the software exposed, ultimately.
Technorati Tags: ajax, software security, enterprise software security