Time For A New Security Model (?)

Earlier this week I received an email from Justin Somaini, former CISO of Yahoo! and Symantec.  If you haven't had the pleasure of talking with Justin and you get the opportunity, I urge you to do so.  He's a brilliant, rock-solid security professional and an all-around Good Human Being :)

Justin has just taken on the new role of Chief Trust Officer for box.com, a company that markets itself as offering secure cloud-based file sharing solutions for home and for business.  In his new role, Justin is starting a dialog with security professionals around the need for a new security model.  Justin's initial blog post lays out what I call the classic ROI versus Luddite argument that security professionals find themselves in regularly.  Specifically:  new cloud based technologies offer companies the ability (among other things) "to remove legacy tech debt and enable services in a faster development and release cycles" whereas security professionals are still trying to "extend our 'enterprise' to devices as they traverse the Internet."

Admittedly, I have some problems with this characterization.  While I agree conceptually with where (I think) Justin wishes to go, the presentation of the problem in the aforementioned fashion fails to spend time asking why security professionals operate in this fashion;  indeed, the lack of root cause analysis tends to perpetuate the myth that security professionals "just don't get it" and just don't want to get it.  For most of us, this couldn't be further from the truth.

Typically, introducing innovative technologies into an enterprise environment takes one of three forms from a security perspective:

1. The Afterthought Model.  The technology team has already made a buy decision and at the nth hour (or later) has brought the security team to the table.  The security team is now forced to try and fit the square peg technology into the round hole of security -- in many cases, in a way in which the technology was not designed to operate.  In the end, the security team must either (a) reject the technology and be blamed for lost ROI, or (b) jerry-rig an unsustainable solution which reduces the efficacy of both the technology and the security infrastructure.  A lose-lose proposition all around
2. The Risk Acceptance Model.  The security team informs the technology team that there is additional risk associated with the new technology.  While the risk is beyond normal parameters, the security team is perfectly willing to allow the technology withn the environment if the additional risk is acknowledged and accepted at an appropriate level within the organization.  In many organizations this dialogue perpetuates a weeks (months?) long kabuki dance as the technology team (a) questions the risk calculus; (b) tries to get the vendor to persuade you that your perception of risk and/or the new technology is incorrect; (c) the vendor struggles to demonstrate that it has appropriate security controls and processes to mitigate the risk; and/or (d) the company leadership asks the security team to "find a way" to implement the new technology without addition of any additional risk inthe environment.
3. The Standards & Options Model.  This is the model under which I prefer to operate.  The security team outlines a clear set of controls and standards that are clearly articulated and clearly defined for the levels of risk/criticality associated with the technology.  Included with those standards are securty architectural patterns which demonstrate the preferred (but not the only) method of meeting thse control requirements.  When a new technology is introducted, the criticality is assessed and a set of required security controls is layered onto the technical requirements.  The security architects work with the technology team and the vendor to ascertain how the technology meets these standards...only to find that, in many cases, security has not been appropriately layered into the technology.  In the rush to innovate, the technology company focused primarily on operations as opposed to security...and basic requirements cannot be met in any reasonable fashion.  

I admit freely that I am generalizing about technology vendors as well as  technology adoption models...but I think that most of us would agree that we have been in one of the three aforementioned buckets at some time in our security careers.  While this does not abrogate the need for security professionals to keep an open mind re: new technologies as well as to remain abreast of technological improvements which occur, it remains difficult (though not impossible) to embrace innovation and new technologies in an environment where ROI and technical debt reduction is not balanced against acceptance of risk  by the enterprise and/or innovative accomplishment of security objectives by the technology vendor out there.

Time for a new security model?  No.  The model for security has been and needs to remain the appropriate balancing of risk versus return within an organization.  Time for a new security implementation model?  Maybe.  If there is an alternative implementation schema that provides appropriate levels of trust; balances liability and risk; and achieves the appropriate level of accountability and efficacy re: security, then we should explore if not embrace such a model.  

If there is a vendor/technology out there that can assist in providing such solutions, we should definitely listen...but vendors and technologists need to understand their roles in this dance as well.  ROI without security is a flawed calculus.  Vendors who sell innovation without security are setting their customers up for failure and delaying (if not eliminating) adoption of their products.  I applaud Justin's call for a dialogue and discussion...but he needs to bring the other members of the vendor-security-technologist triad to the table if he intends to succeed.

My two cents...