I blogged parts 1 and 2 about issues relating to decentralizing security models that support horizontal integration of security models. Parts 1 and 2 mainly dealt with the problems, the problems should be familiar to anyone who has tried to scale security in a distributed system. Section 3.1 lays out the goals, including:
2. It should be risk-based, and measurably so. 3. It should be agile and extensible, accommodating variable risk acceptance and shifting coalition partners. 4. It should enable incentives for information sharing. 7. Its decisions should be auditable. 8. It should recognize qualitative distinctions between different kinds of secrets (e.g., tactical vs. strategic)
9. It should be capable of being implemented incrementally.
These are all themes that enterprise information security shoudl embrace, because they align well with business goals and are necessary in most distributed systems. Risk management is the best lens from which to infosec. Many security personnel continue to view security architecture as analogous to jails, but you know what? Not much commerce happens in prison. The kind that does is black market and it specifically routes around security controls. Sound familiar? As they say in Minnesota: ya sure, ya betcha.
Incremental adoption, and the ability to layer on security iteratively instead of big bang style projects is likewise a necessary condition for successful deployment. Again this aligns with how software development is done, the trend from RUP to XP to Agile is towards lighter and lighter weight processes with more iterations. The more the security architecture dictates massive access management suites the less it is going to fit into that kind of mode, and the less it will deployed. As Duke Ellington said, "It don't mean a thing, if it ain't in the build dist".
The paper offers three guiding principles for building a new system.
1.
When risk factors can’t be measured directly, they can often be plausibly estimated (“guessed”); and subsequent experience can then be used to derive increasingly better estimates. This can be formalized in various ways, for example as an updatable Bayesian belief net.
2. Establish an acceptable risk level. As a nationwe can afford to lose X secret and Y top secret documents per year. We can afford a Z probability that a particular technical capability or HUMINT source is compromised. If we set X,Y,Z, . . . all to exactly zero, then all operations stop, becauseall operations entail some nonzero risk. What, then, are acceptable rangesof values for X, Y,Z and a long list of similar parameters? Even better, roughly what values would optimize our operational effectiveness in the long run, when today’s security breaches show up not simply as harmful in theabstract, but as actually imperiling future operational effectiveness?
3. Ensure that information is distributed
all the way up to the acceptable risk level. This is a very fundamental point. We have been living with systems that try to minimize risk. That is the wrong metric! We actually want to maximize information flow, subject to the overall constraint of not exceeding the acceptable risk levels set according to principle number 2, above. This means that instead of minimizing risk, we actually want to ensure that it is increased to its tolerable maximum (but no higher).Regarding points one and two, I have blogged many times about a risk and metrics-centric approach to your information security program. See the MetriCon Digest for some specific ideas on how to accomplish this. The point I love in this paper is #3 "Ensure that information is distributed all the way up to the acceptable risk level", what a great concept. If you do your risk management properly, this should be a great enabler, everything else is security by obscurity in some sense. It does turn least privilege on its head.
Section 4.2.4 discusses NetTop
NetTop, an NSA project, is a technology for virtualizing machines and networks at different security levels onto a single hardware platform. The NetTop user has a single desktop or laptop machine, and has the ability to open windows on “virtual machines” at different security levels. Each virtual machine has its own operating system (e.g., Windows XP or Linux), and runs as if it were on a physically separate machine, connected only to the appropriate level of classified network.
If you combine this approach with where SOA and Web Services and where it is going, the virtualization approach should be inherent in how services are bound together. For example a Security Pipeline Interface such as a XML Security Gateway in front of your web service. Otherwise, as Richard Thieme says we will be functioning according to an increasingly obsolete trust model. ...NetTop pushes the MSL solution out of the wiring and onto the desktop. In a NetTop solution there are still (in this hypothetical example) five separate classification levels, all kept separate; but there is only one physical infrastructure, and one machine on the desktop...In NetTop, SE Linux runs in a particularly secure mode, without an IP stack (the point of entry for remotely hacking ordinary computers).
The virtualization concept is important across the board in an SOA. From the user's desktop where Microsoft is making cardspaces as a way to support multiple identities to enterprise services buses and orchestration services that aggregate services, transform data, and route content based on widely varying policy requirements. the ability to virtualize endpoints in separate policy domains is a fundamental element. Section 4.3 gets to the bits on the wire - risk tokens. In a phase 1 risk token, the token allows for example: 1 token = risk associated with one-day, soft-copy-only access to one document by the average Secret-cleared individual.
This example associates risk with a token predicated on length of time, type of access, and access rights of the individual. I am quite fond of the notion of a risk token. Risk tokens would be represented in an SOA by SAML assertions (SOAP or browser-based federation) and WS-Security tokens (attached to XML documents). The WS-* stack takes this one step further with WS-Trust, which provides a framework for moving the token around on a network, and exchanging them for other risk tokens. This integration, which allows for say a Windows client authenticating off of AD to exchange risk tokens and make authentication and authorization SAML assertions to Java based web services provider, allows for the security model to truly scale across technical and organizational domains. Next, in phase 2 tokens, there is a subtle but important change "In Phase 1, tokens were denominated by “risk”; in Phase 2, they must be denominated by “harm.”" Several major espionage cases have shown a systemic weakness in the present security system, namely the fact that individuals are most often treated as either “fully trusted” (cleared) or “full untrusted” (uncleared). That is, trust is treated as a discrete, not a continuous, variable. A major reason for this is that a down-transition between these two states — revoking someone’s clearance — is so drastic an action that line managers, and even security managers, try to avoid it at almost any cost. The Aldrich H. Ames case is a particularly famous, and perhaps egregious, example of this phenomenon. This trusted v. untrsuted anti-pattern is immediately recognizable in enterprise security. The risk model that we have posited for a tokenized system (both Phase 1 and Phase 2) provides, in effect, a continuously variable level of trust. The
individual manager, therefore, is never faced with an all-or-nothing decision about whether to seek suspension of an employee’s security access. Instead, the manager has clearly defined, and separable, responsibilities in functional (“getting the job done”) and security (“work securely”) roles.
The manager’s security responsibility is simply to ensure that relevant facts known to him about an employee are also known to the risk model. The manager is not the only source of these facts, and he or she is not a “cop.” But it is reasonable to require that managers report, according to objective criteria, security-related factual information about their employees. They will be more likely than now to do this knowing that the effect of such information will be incremental only, and not likely to trigger anything as drastic as the revocation of an employee’s clearance (as it might today). The manager’s functional responsibility is to manage his or her unit’s tokens wisely. If the risk model assigns a high risk to one particular employee, then the cost of transactions (access to classi "it is reasonable to require that managers report, according to objective criteria, security-related factual information about their employees." Assertion-based access control anyone? What differentiates phase 1 and phase 2 tokens is that phase 2 tokens map back to the object. In this case we get to the point where SAML and WS-Security reach their limit. At this point we need to look at XACML to deal with mapping decisions back to the object resource. James McGovern has been beating the XACML drum, and in the area of phase 2 token concept XACML really pays off. The XACML mapping of the subject to authorized resources, conditions, and actions allows for the security policy to be applied to the subject as well as the representation of the object. One example of this in the real world at railroad crossings, normal cars pass straight over the tracks as long as the gate is open and the light is not flashing. School buses, because of their cargo, stop and perform additional visual checks before proceeding
NetTop instantiates and extends the concept of Multiple Signal Levels (MSL), rather than Multi-Level Security (MLS). MSL is the concept, fully accepted by the information security community, that different security levels can share the same physical hardware infrastructure, as long as high-grade cryptographic techniques are used to keep the differing levels completely separated, even when they are in the “same wire.” Indeed, MSL is today’s way of doing business in long-haul network transport. The encrypted text output of an NSA-approved crypto device is (generally) unclassified. It can, as a rule, be mixed with ordinary unclassified traffic, and sent over unclassified military or civilian channels
Thanks for also beating the XACML drum. In my conversations with other enterprises they are also starting to see its value...
Posted by: James | October 15, 2006 at 10:23 AM