1 Raindrop: Decentralization and "Good Enough" Security

Lots of security people like to blame developers, technology, and implementations for security problems. It is true that poor code, inadequate protocols, and insufficient QA all conspire to create the current security situation we inhabit. But there is a more foundation level disconnect also at work. Consider some of the most successful businesses in the current economy, and now consider their business model. Most businesses are in the business of decentralization and pushing decision-making control and power out the edges of the organization. This may be done through combinations outsourcing, off shoring, specialization, innovation, and so on. Hundreds of thousands of people make their primary living selling things on Ebay, but they are not ebay employees. Insurance companies have large field offices with indepedent agents. The point is that lots of very successful businesses are predicated on decentralization.

Now let's consider security architecture. How many times have you heard a security architect say "if we could just centralize X" our problems would go away? Guess what buddy, your business is not going to centralize everything any time soon, and they REALLY are not going to centralize just so you can roll out your Access Management suite or whatever. A lot of time and gajillions of dollars has been wasted by people trying to paste a centralized security model onto a decentralizing business. One of the reasons that Federation, for example, works so well is that it is a security technology that is designed for a decentralized deployment environment, because SAML helps you communicate security information across boundaries..

Ross Mayfield on the De-Centralized Intelligence Agency:

This week I participated in a workshop with the CIA on blogs and wikis. What was fascinating was not just that the participants included Clay Shirky, David Weinberger, Jerry Michalski, Eugene Kim, Marcia Conner and Jay Cross. The agency perhaps has the greatest to gain from adopting social software, but also has the greatest hard coded structural barriers (need to know) and a culture that reprimands against participation. Nevertheless, an Intellipedia and blogging at all levels in the organization is burgeoning. There is a shared understanding that these tools, with the right practices and change in culture could transform intelligence from a manufacturing model that delivers reports to a complex adaptive system where intelligence is a conversation with decision makers, an inherently counter spin

It is easy enough to replace the intel-crats in the story above with enterprise bureaucrats. The wrong kind of structural barriers are harmful to business, and they also harmful to security. Butler Lampson stated in his talk at Usenix Security last year that in his view the principle of least privilege has done more harm to computer security than anything else. He gave the example of a review that he and other industry experts did of US military field security. What they found was that US military field level security was far worse than best commercial practice. The reason, in his opinion, was the NSA crypto culture of "it is either perfect or it is broken" and of course if it is "broken" it doesnt get deployed.

So what is "good enough" security? Federation would be one that would certainly answer the bell in today's world. A recently declassified document from the JASON program office takes a similar tack
HORIZONTAL INTEGRATION: Broader Access Models for Realizing Information Dominance.

Abstract

Horizontal integration refers to the desired end-state where intelligence of all kinds flows rapidly and seamlessly to the warfighter, and enables information dominance warfare.

This goal is, of course, the same notion in the business world of pushing decision making out to the edges. Security protocols and access control models should empower not restrict an individual's ability to function. Speaking of the emerging needs of today's soldiers:

These soldiers have high expectations for warfighting technologies in general, and information technologies in particular. The consumer of intelligence is no longer an O4 “behind the green door.” She is an E4 behind the (camo-) green door of a humvee — and it is moving.

Consider a field level broker or agent where the business context, perhaps dictated by fluctuating conditions such as interest rate, re-insurance, market movements, etc. is moving yet decisions are made on the edge. So the question is one of integration and distribution of information to the edge, not about bringing everything into a centralized mode. When you do that you are in deployment engineering logistics world, and as Napoleon discovered the fifth element that you need to account for is actually mud.

Some problems to solve:

Information flow to the warfighter is perceived by many to be — and we concur in this judgment — excessively constricted.
We need new technologies for acquiring, merging, and delivering the
information faster and in a more useable form; and we also need new in-
formation security constructs so that the full value of the information can
be realized by delivering it to the broadest set of users consistent with its
prudent protection. We must also change a culture in which the logically separable roles
of “content producer” and “content protector” have become completely en-
tangled, and in which “knowledge is power” is too frequently mutated to
“withheld knowledge is power.”

Again a completely separate way of thinking about security protocols, instead of centralized solutions. The question is: how to distribute, not how to restrict.

• There is no presently accepted paradigm for providing intelligence and other classified information to distributed homeland security consumers.
This refers to both first responders (police and fire chiefs, etc.) and also
to local government officials with other operational responsibilities (mayors,
city managers, power and water officials, etc.).

These are the rocks that many an integration project has washed up on from a security perspective.

• The gap between the implicit risk/benefit calculations of the producer and consumer communities is greater than it has ever been.
Users see an overly rigid, out of date, bureaucratic structure of informa-
tion classification and originator-controlled distribution; and an individual clearance process that is glacially slow, and under which large numbers of
fighting men and women are, in practical terms, unclearable.
Information producers, and others charged with information protection,
perceive nearly insurmountable new challenges to information security, fueled
by burgeoning computer networks, new RF technologies, and newly capable
foreign intelligence adversaries.

Risk management is a forward looking, growth oriented approach, not a cya approach.

• The status of sensitive information outside of the present classification system is murkier than ever.
Certain work-arounds to the present system result in classes of infor-
mation whose protection level is uncertain. “Sensitive but unclassified” data
is increasingly defined by the eye of the beholder. Lacking in definition, it
is correspondingly lacking in policies and procedures for protecting (or not
protecting) it, and regarding how and by whom it is generated and used.

The perimeter in an SOA is the document, not the network. The security model is defined by the security constructs in the document, not the network firewall. In the next post, we'll look at some more ways to elaborate and apply these goals.

Update: Part 2 continues this thread...

Comments

Perhaps part of the solution is an increased focus on server security. We've seen the emergence of client and network security solutions; yet the servers themselves (that once existed safely behind the perimeter) are now in the cold more than ever. Thanks for an excellent column.

GReg

Posted by: Greg Ness | October 10, 2006 at 10:13 AM