Showing posts with label system security. Show all posts
Showing posts with label system security. Show all posts

Tuesday, October 13, 2015

A Leapfrog Enterprise Security Strategy

Recently I was quoted in an article on newly reported, but somewhat old, breaches.  In the report I was quoted as suggesting that these breaches suggest that security has fallen behind and that, just in order to catch up, we need a "leapfrog" strategy.  This post will suggest what such a strategy might contain.

Mine would start with strong authentication close to the users, i.e., at the end point. Strong authentication will start with privileged users and move to all employees. We have known about the limitations of passwords and what to do about them for thirty years. It is way past time to get on with it. Going forward, the end point of choice will be the mobile computer, colloquially referred to as a "smartphone."  This device already contains powerful sensors that can be used for authentication of claims to identity.  Apple Touch ID and Samsung Face Unlock are simply early examples of what can be done.  These are quick and easy to use and, in combination with possession of the device, constitute strong authentication.  

My strategy would include reducing the number of privileged users, the reduction of their privileges, and accountability for the use and exercise of privileges. It would include involving two or more people in the exercise of sensitive but rarely used privileges. We have too many privileged users and too little visibility into how those privileges are used.
It would include the automatic notification of the subjects of records and the owners and managers of accounts of all use, changes to, or transactions against those records or accounts. If we are to detect breaches on a timely basis, we must increase and improve transparency and accountability.
It will include isolating e-mail and browsing from mission critical and other sensitive systems and data. The intelligence is clear that many, not to say most, compromises begin by duping the users of these two applications.
It will include end-to-end end, end-point to application, not perimeter, not operating system, encryption. We cannot continue to operate large enterprise networks as flat spaces, as spaces in which any system may address any other system in the network.
It will include restrictive, i.e., "white list only," granular access control close to the applications and data. It will probably include access control at every layer, e.g. between the application and the database, between the database and the file system.
These measures are neither expensive nor disruptive. Google has demonstrated that even strong authentication can be flexible and convenient. They can be implemented in parallel. There are vendors recommending them and with products and services to implement them.
This is an "off-the-top of my head" list; I am sure I have omitted something important. However, it is informed by fifty years of thinking about this problem. I am sure that many of my colleagues have measures not on my list but which they would include in a leapfrog strategy.

Thursday, February 11, 2010

Bears, Brigands, and Dragons

A Fable

In medieval times, the populous was terrified of dragons. Everyone knew someone who knew someone who had seen one. Many knew someone who knew someone who had lost a relative to dragons.

However, when they built the castle, usually in stages over decades, getting stronger with time, they always stopped long before the castle became dragon-resistant, much less dragon-proof. After all, dragons are awesome creatures; they are very strong and they fly. How high would the walls of the castle have to be to keep the dragon from just flying over?

So, they built their walls to resist bears and brigands. They fully intended to get around to resisting dragons but it was so expensive that somehow it never got done. After all, bears and brigands were much more numerous than dragons.

In modern terms, we would call the dragon strategy, risk acceptance. This is sort of like our strategy for greater than Richter 7.0 seismic events and greater than Saffir-Simpson Category V storms. Needless to say, the watch mounted the walls everyday, with their bows and arrows, ready to repel the dragons, but they never saw any.

Every twenty years or so we have a massive power blackout, embracing multiple states and tens of millions of homes, and lasting for several days. It is usually the result of multiple simultaneous failure of a highly unlikely number of components. The media and the politicians scream "There be dragons. Why weren't you prepared?" The industry says mea culpa and promises to do better next time.

Actually they do do better the next time. They raise the walls. They replace older components with new ones that have a longer mean-time-to-failure. They add redundancy so that they are better able to tolerate component failures, and they automate the response to component failures. Of course, all of this ads cost. Long before the mean-time-to-failure of the system reaches infinity, they stop.

In fact, in about twenty years, their best efforts will be overwhelmed once more. The knee of the curve that plots mean-time-to-massive-failure against cost seems to be at about twenty years. I have now lived through three such blackouts and hope to live to see a fourth. Mitigating it will be expensive but not as expensive as preventing it.

No matter how high we build the walls, the damned dragons just fly over.