My Access Management Rant.
Dammit, Rothman set me off again. His notes from the RSA keynote highlighted several stabs in the dark at the evolution of access management:
At first they are focusing on the network, something near and dear to my heart. It needs to evolve. Right on. No one is going to rip and replace (except maybe for a greenfield location). The slide talks about a “trusted zone” and an “untrusted zone.” IPSec is the technology they’ll use.
[...]
“Policy, not topology.” Hmmm. That’s interesting, especially given mobility and the fact that most companies can’t assume they control the networks that their users will connect over.
[...]
They use IPv6, IPSec, and store everything in Active Directory. Individual policies based on USER, not where the user is.
[...]
Securing data at rest and motion. How? Rights management. Arghhh. The world is not ubiquitously Microsoft, so how does their flavor of rights management help me with that? Applications are also part of the equation. NSS (No Shit Sherlock). They “trust” the program and application? I don’t buy it. Applications can be broken, trojans and rootkits installed at the hardware level to complicate things. I don’t know I trust it.
This goes on and on. Here’s the way I see access management.
We don’t need user-centric access management or data-centric access management or network-centric access management. We don’t need “zones.” We need CONTEXT-BASED access management. (You read it here first. I’m coining the term. Unless someone else has already; I haven’t bothered to Google it yet.)
Access policy decisions are a matrix. They’re based on:
- Who the user is proven to be.
Identification, authentication. We’ve been here before.
- Which organization the user is affiliated (officially) with.
This makes a big difference in access decisions. Internal employee, contractor, business parter, former-employee-now-part-time-consultant, the list goes on and on. This organization affiliation drives the decision on who APPROVES the access for this user, and sometimes the roles, but not always.
- Which hat the user is wearing currently.
Users have multiple roles. They might be affiliated with one organization but act on behalf of several different ones in the context of data access. This happens a lot more than you think, and it’s almost never properly acknowledged. The worst offender is the developer who has to create dozens of test accounts so that he can test it wearing different “hats.” You’re probably thinking, “No, we support roles for users.” Focus on the DEVELOPER. Which “role” have you given HIM? You gave him the highest level of access, right? Because the only account that gets to wear multiple hats and change context within the system is usually the administrator.
- Where the user is currently (geographically).
We make hidden assumptions about the security environment in which the user is operating based on whether they’re at home or in the office (or at Starbuck’s, or at their friend L33T H4X0R’s house, or whatever). We also make hidden assumptions about the platform the user is using based on their geographical location, which isn’t necessarily linked and needs to be split out:
- Which platform and tools the user is currently using.
Right about now, some reader out there is jumping up and down, screaming, “NAC! NAC!!” Yes, this is where we talk about NAC, but not as a method of automated DoSing of your users. I would much rather use an SSL VPN policy and put a virtual condom around the user to protect him from his platform than just block the platform (and therefore all his access).
On a much higher level, there are two ways in which breaches can be detected. They appear as:
- An authorized user, coming in from the “wrong” location. (Usually referred to as an external attacker.)
- An authorized user in the “right” location, doing the “wrong” things. (Usually referred to as an insider.)
It’s all about context. And we need to make our context decisions more visible and flexible than we’re currently doing. Otherwise we’ll never truly get a handle on access management.
Posted by shrdlu on Tuesday, February 06, 2007
(4) Comments • Permalink •
