In the last entry, I responded to dashboard initiatives and organizations’ attempt to measure. Examples focused on vulnerability-detection because a lot of software security expenditure has as well.
Some practitioners, as well as software security managers, have realized that a focusing only on uncovering the problem won’t get it fixed. They’ve begun to document secure sample code, construct secure-development frameworks, and even harden existing open-source frameworks in order to make secure application development easier. This trend cuts across those IT shops supporting non-software businesses (such as finance, insurance, gaming, and the like) as well as software vendors. Let’s look at the 2nd surprising finding from SAMM data gathering, as published in Gary’s InformIT article:
8. Secure-by-default frameworks can be very helpful, especially if they are presented as middleware classes (but watch out for an over focus on security “stuff”).
Secure-by-default frameworks for aiding in development are absolutely my favorite part of software security. Not only do they make sense as part of any program, they represent an essential corner-turn from a hopeless attempt to keep developers abreast of what they’re doing wrong to the downward push towards the finish line by helping developers release better software. In 2001, plainly sick of documenting and demonstrating the same vulnerabilities over-and-over again in meetings and reports, I begun to talk about, seek money for, and outline what such a framework might look like for use of Servlets in the Java EE platform. Frankly, sometimes it’s just plain easier to describe how to do something correctly than it is to conceive of pen-tests or static analysis rules that will find all instances of vulnerability, some omission, or an incorrect implementation.
But, I’m not the only one that’s been climbing this hill: A broad range of approaches to constructing such frameworks are visible within my own client base.
Some organizations have taken their cue from what the network and host security guys have done in their own spaces. These software security groups see software security as a mapping between vulnerability and the need for control. This drives two sets of behavior:
With regards to the software they build, these organizations tend to strive towards having some central engineering team (or a particular development group) provide a ’security control’ that they can plug in for each vulnerability. This has had two effects in my experience:
- The ’security framework’ ends up as an amalgam of functions designed in very point-solution fashion. For example OWASP ESAPI’s addCSRFToken() method. (see code)
- ‘design review’ becomes a checklist activity in which security folk (playing the role of auditor) walk through a list of features they expected to include, such as those API calls described in #1 or at a higher level the inclusion of a particular security package: IE: “You’ve used ClearTrust for authentication–right?”
With regards to the software, infrastructure, and COTS these organizations purchase, they tend to apply a modified checklist (such as #2) during acquisition, and then–in the case in which they’re acquiring a security component itself–add it to the checklist for future reviews.
There are benefits to this level of framework creation/use (namely, it raises awareness of the problem, standardizes solutions making compliance easier to gauge, and does in fact place some useful functionality in the hands of developers they might have otherwise omitted or bumbled themselves).
However, I think this approach misses the mark for several important reasons.
Others build their security frameworks from scratch. Convinced that their organization is different enough to warrant their own unique approach they set to construction. Some organizations cull framework material from ‘centers of excellence’ within their organization: development teams that have already done a great job at something like demanding authentication and invalidating sessions. Others architect the security framework centrally, construct it, and then deploy it mandating development teams integrate with it as they continue otherwise normal maintenance of their apps.
There’s intrinsic benefit and difficulty to a purely bottom-up or top-down approach. If an organization goes purely bottom-up, their difficulty lies in coordinating and architecturally cohering different teams’ widgets into a common framework. The strength they can rely on is buy-in: developers are hard-pressed to complain about what they and their peers have written. The top-down approach lacks buy-in and (at times) practicality, but often enjoys a coherent unified design.
Early in ‘07, I wrote on a model for mixing the two approaches successfully.
Whether executed top-down, bottom-up, or through some compromise, I like this approach better than the one I described above. My biggest issues with it are:
- It can become a political monster, especially if top-down
- Being overly unique (ala: “not-invented here” or “I’m a snowflake” pathologies) can be damning
The more top-down an approach is, the more likely developers are to balk at mandates for the framework’s use. “Pfft, but that won’t work the way we built our app.”, they’ll lament. If you hear that, prepare for a deluge of exception forms. ;-)
So, how are people overcoming limitations of an ineffective feature-centric audit-model and the pains suffered from inventing their own framework from scratch? By, “meeting the developer on ‘their side of the river’”, as it was once said to me.
When a developer sits down to write or maintain a web application, they’re doing so within a very rich platform already. The .NET platform has well-integrated set of tools from the webserver up to application-support functionality provided by a single vendor: Microsoft. The Java EE platform focuses on open standards, and as such has a bevy of open-source packages that support the lower-levels of the stack that Sun provides. Simply put: a developer writing a Java EE web app is already conforming to the Servlet framework, if not the Struts, JSF, or some other MVC package. They know the platform’s packages, they’re already using them, and there are tons of great books, tutorials, and examples out there.
This is their side of the river. Demanding they build on top of those packages, but integrate with another package–for the sake of security alone–is folly.
A better answer to creating one’s own security framework–and I’ve seen this in play in more than one organization–is to secure a framework the developers already know. This:
- Maintains current platform design idiom - If Spring is ‘the right design paradigm’–great, you’re using with without having to have invented it;
- Allows consideration of the framework’s threat model - It’s easier to secure a system you know the design/deployment model of, than it is to write ‘the perfect’ security feature in a vacuum;
- Maintains transparency, as best as possible - Those securing the framework can place implementation ‘under the hood’ allowing developers to call functions as normal;
- Moves security ‘lower in the stack’
- Reduces integration points for developers
To me, these advantages are overwhelming. Showing the benefits of faithfully maintaining the underlying framework’s design could be the subject of its own entry entirely and–I feel–places the nail in the coffin of those arguing that security can be represented simply as features. I’ll defer that for now however.
Fixing problems instead of identifying them? Security guys getting traction by helping developers write code and get it out the door faster? Meeting them within the realm of the frameworks they’re already using: hardening their configuration, implementation, and deployment? This works?
Not surprising ;-)
) but we would like to certify a security baseline for web applications and help companies getting a more secure application.
