Previously I blogged about issues relating to decentralizing security models that support integration. The JASON Project on HORIZONTAL INTEGRATION: Broader Access Models for Realizing Information Dominance looks at the following problems to solve:
• Information flow to the warfighter is perceived by many to be — and we concur in this judgment — excessively constricted.
• There is no presently accepted paradigm for providing intelligence and other classified information to distributed homeland security consumers.
• The gap between the implicit risk/benefit calculations of the producer and consumer communities is greater than it has ever been.
• The status of sensitive information outside of the present classification system is murkier than ever.
There are several parallels in the challenges addressed by the DoD and the enterprise environment, and they all get back to how do you realistically deploy/manage/scale security in a large decentralized system. (hint: the answer is not centralizing security)
Sections 2.2 and 2.3 talk about classification. A lot of security is based on information classification (Confidential, Secret, Top Secret), but this is the easy part. The hard part is the distribution channel, because humans who actually consume the information, are horizontally integrated to other systems while information classification assumes a vertical model, enforced say by RACF or RBAC system.
Section 2.4 talks about usability and security
If, because of usability issues, relatively secure technologies are not used, then relatively risky behaviors are substituted. We are thus in a situation where aggregate risk would be lowered by the use of less-secure — but more useable — technologies.The following sections provide details that reinforce the above
The system is being distorted by operational needs. Underclassification of documents — often quietly justified as necessary for ease in transport- ing documents between meeting sites — is a well known practice.
Hey, why not use HTTP Basic Auth?
Under Missing Constructs in the Present System, the paper lists:
• A construct for implementing responsiveness to operational necessity.
• A construct for risk based on the type of access transaction.
This issue is present in enterprise security. Most systems are deployed as is or not at all. There is not generally a way to dial up or dial down security controls. Ideally, the security architecture should be layered to support a variety of controls that could be applied when necessary. If you think of how the credit card industry works, a given credit card transaction (or ATM transaction for that matter) is subject to numerous credit worthiness judgements in a very short time span. Also, the answers are boolean y/n, but the decision making process takes into account the shades of gray.
• A construct for auditing.
With all the new WS-* standards, we still lack WS-Audit. Can no one figure out a way to make money based on auditing standards? Is there no customer demand for this? Where is WS-Anasazi? One reasons credit card companes are able to deliver scalable services like those alluded to above is that they audit.
In the next entry, we'll look some of the recommendations. Part 3.