Weick identifies some heuristics against which we can rate our capability to be reliable, in other words to respond effectively to experience and improve by it:
- How preoccupied with failure are you? Do you treat near misses as information for improvement or as evidence of your awesomeness as a security team?
- How much do you attempt to simplify? Do you solicit views from outside your security team?
- How sensitive are you to the whole operation? Do teams interact enough with each other to understand the other jobs being done and are able to form a whole picture of the operation? How much do you share a picture of the threat landscape with the people you are trying to influence?
- Are you committed to resilience? Do you invest in people's competence, especially in terms of informal contacts and networks that can be used to solve problems effectively?
- Do you respect expertise? Often a security team will feel that their expertise is not respected across the organization and that people do not listen. But even with a security team, does everyone know who has the expertise to respond to an issue rather than merely the hierarchical rank to do so?
In the case of the Columbia disaster, many of these questions yielded answers that pointed to a culture of hierarchy and deferred responsibility, "NASA's culture of bureaucratic accountability emphasized chain of command, procedure, following the rules, and going by the book....Allegiance to hierarchy and procedure had replaced deference to NASA engineers' technical expertise" CAIB report states.
The behavior characteristics of highly reliable organizations have great affinity with concepts actively promoted in DevOps oriented teams.
How high reliability today requires DevOps
I define technical reliability in a large enterprise as: The active solicitation of information that disproves rather than confirms organizational attitudes to security practice, infrastructure build quality and application performance and embeds these lessons in subsequent iterations of a system's deployment.
In order for an organization to be reliable from a security viewpoint therefore, we must embed security professionals in the process of designing, building and deploying applications, in a manner that is consistent with the behaviors listed above.
The practices below are pointers to how this might be done but also, without which, security professionals will continue to be reactive first responders rather than building an inherently safer more reliable organization.
Shift complexity left: Today, using tools such as Chef, we can write explicit tests for compliance with certain security controls. This means that these tests may be run and passed before production, but also that during the iterative development of a system that impact of new features on the security of the system may be well observed and discussed. A good example of this is in the application of CIS benchmarks by Joshua Timberman of CHEF here.
Sign up for Computerworld eNewsletters.