Blameless post-mortem: The role of the blameless post-mortem in building resilience into software teams can't be exaggerated. Although identification of the person responsible is important, if we assume that people seek to do their best we need to find out why they were unable to act safely. Our preoccupation with failure in DevOps is rooted to this idea.
Full stack development:Conway's Law is alive and well in most large enterprises. The creation of process, hierarchy and bureaucracy (see the Columbia example) makes it very difficult to gain a whole picture of a system and makes it all too easy to ascribe an issue as 'somebody else's job.' Within DevOps teams, the boundaries between silos is broken down, creating a more efficient information flow but also a more transparent approach to security and the various trade-offs made during development.
Product orientation: Many organizations espouse agile ideas while still perpetuating a project-centric view of the world. This is not a terminal problem; the agile principles will drive great value within this context. However, when the 'system' of which we require everyone to have a clear understanding is a product (i.e. something consumed by the customer) and our accountability is for that product we make decisions differently. An analogy would be the difference between being responsible for the heat resistant tiles on the shuttle versus seeing the success of the shuttle voyage as your focus. As an engineer you do the former to enable the latter rather than doing the former without regard or understanding of the latter.
Software is eating the world: Marc Andreesson's quote is now a truism. If we can code infrastructure and applications, we can code tests for these too. This means that we can begin to code compliance. In other words, we can write code that defines, sets and tests a system's 4 S's;
- state (enable SELinux?),
- sequence (authenticate before action),
- supervision (set logs to verbose for 3 third party logins) and
- scope (no global log access to Swiss log data)
Small batches: Here's the catch. All of these rest on one fundamental idea that you can't get it right first time ever. So the development of a platform that enables you to iterate and improve functionality (including security) in small increments over time is crucial. It improves the fit of your product with the customer certainly but from a security perspective, there is no point being sensitive to change if you can't act on it.
Fast iteration is key to embedding/applying the lessons we learn in the things we make. If anything, this is the 'hedgehog concept of modern business'.
But as security professionals we need to 'know many things' being responsive to changes in the threat space but also to the applications we seek to secure. The best way of achieving this is to begin to see and contribute to projects/products that we work on as needing to be 'highly reliable'. The behaviors that this approach embodies makes everyone responsible for the long-term success of the product... and that also means its security.
Sign up for CIO Asia eNewsletters.