RAdAC

Is XACML Dead?

~ Ray Sinnema ~ 4 Comments

ripXACML is dead. Or so writes Forrester’s Andras Cser.

Before I take a critical look at the reasons underlying this claim, let me disclose that I’m a member of the OASIS committee that defines the XACML specification. So I may be a little biased.

Lack of broad adoption

The first reason for claiming XACML dead is the lack of adoption. Being a techie, I don’t see a lot of customers, so I have to assume Forrester knows better than me.

At last year’s XACML Seminar in the Netherlands, there were indeed not many people who actually used XACML, but the room was filled with people who were at least interested enough to pay to hear about practical experiences with XACML.

I also know that XACML is in use at large enterprises like Bank of America, Bell Helicopter, and Boeing, to name just some Bs. And the supplier side is certainly not the problem.

So there is some adoption, buI grant that it’s not broad.

Inability to serve the federated, extended enterprise

XACML was designed to meet the authorization needs of the monolithic enterprise where all users are managed centrally in AD.

extended-enterpriseI don’t understand this statement at all, as there is nothing in the XACML spec that depends on centrally managed users.

Especially in combination with SAML, XACML can handle federated scenarios perfectly fine.

In my current project, we’re using XACML in a multi-tenant environment where each tenant uses their own identity provider. No problem.

PDP does a lot of complex things that it does not inform the PEP about

The PDP is apparently supposed to tell the PEP why access is denied. I don’t get that: I’ve never seen an application that greyed out a button and included the text “You need the admin role to perform this operation”.

Maybe this is about testing access control policies. Or maybe I just don’t understand the problem. I’d love to learn more about this.

Not suitable for cloud and distributed deployment

CloudSecurityI guess what they mean is that fine-grained access control doesn’t work well in high latency environments. If so, sure.

XACML doesn’t prescribe how fine-grained your policies have to be, however, so I can’t see how this could be XACML’s fault. That’s like blaming my keyboard for allowing me to type more characters than fit in a tweet.

Actually, I’d say that XACML works very well in the cloud. And with the recently approved REST profile and the upcoming JSON profile, XACML will be even better suited for cloud solutions.

Commercial support is non-existent

This is lack of adoption again.

BTW, absolute claims like “there is no software library with PEP support” turn you into an easy target. All it takes is one counter example to prove you wrong.

Refactoring and rebuilding existing in-house applications is not an option

This, I think, is the main reason for slow adoption: legacy applications create inertia. We see the same thing with SSO. Even today, there are EMC internal applications that require me to maintain separate credentials.

The problem is worse for authorization. Authentication is a one-time thing at the start of a session, but authorization happens all the time. There are simply more places in an application that require modification.

There may be some light at the end of the tunnel, however.

Under constant attackHistory shows that inertia can be overcome by a large enough force.

That force might be the changing threat landscape. We’ll see.

OAuth supports the mobile application endpoint in a lightweight manner

OAuth does well in the mobile space. One reason is that mobile apps usually provide focused functionality that doesn’t require fine-grained access control decisions. It remains to be seen whether that continues to be true as mobile apps get more advanced.

Of course, if all your access control needs can be implemented with one yes/no question, then using XACML is overkill. That doesn’t, however, mean there is no place for XACML is the many, many places where life is not that simple.

What do you think?

All in all, I’m certainly not convinced by Forrester’s claim that XACML is dead. Are you? If XACML were buried, what would you use instead?

Update: Others have joined in the discussion and confirmed that XACML is not dead:

  • Gary from XACML vendor Axiomatics
  • Danny from XACML vendor Dell
  • Anil from open source XACML implementation JBoss PicketBox
  • Ian from analyst Gartner

Update 2: More people joined the discussion. One is confused, one is confusing, and Forrester’s Eva Mahler (of SGML and UMA fame) backs her colleague.

Update 3: Another analyst joins the discussion: KuppingerCole doesn’t think XACML is dead either.

Update 4: CA keeps supporting XACML in their SiteMinder product.

Advertisement

How To Secure an Organization That Is Under Constant Attack

~ Ray Sinnema ~ 1 Comment

Battle of GeonosisThere have been many recent security incidents at well-respected organizations like the Federal Reserve, the US Energy Department, the New York Times, and the Wall Street Journal.

 

If these large organizations are incapable of keeping unwanted people off their systems, then who is?

The answer unfortunately is: not many. So we must assume our systems are compromised. Compromised is the new normal.

This has implications for our security efforts:

  1. We need to increase our detection capabilities
  2. We need to be able to respond quickly, preferably in an automated fashion, when we detect an intrusion

Increasing Intrusion Detection Capabilities with Security Analytics

There are usually many small signs that something fishy is going on when an intruder has compromised your network.

For instance, our log files might show that someone is logging in from an IP address in China instead of San Francisco. While that may be normal for our CEO, it’s very unlikely for her secretary.

Another example is when someone tries to access a system it normally doesn’t. This may be an indication of an intruder trying to escalate his privileges.

Security AnalyticsMost of us are currently unable to collect such small indicators into firm suspicions, but that is about to change with the introduction of Big Data Analytics technology.

RSA recently released a report that predicts that big data will play a big role in Security Incident Event Monitoring (SIEM), network monitoring, Identity and Access Management (IAM), fraud detection, and Governance, Risk, and Compliance (GRC) systems.

RSA is investing heavily in Security Analytics to prevent and predict attacks, and so is IBM.

Quick, Automated, Responses to Intrusion Detection with Risk-Adaptive Access Control

The information we extract from our big security data can be used to drive decisions. The next step is to automate those decisions and actions based on them.

Large organizations, with hundreds or even thousands of applications, have a large attack surface. They are also interesting targets and therefore must assume they are under attack multiple times a day.

Anything that is not automated is not going to scale.

Risk-Adaptive Access Control (RAdAC)One decision than can be automated is whether we grant someone access to a particular system or piece of data.

This dynamic access control based on risk information is what NIST calls Risk-Adaptive Access Control (RAdAC).

As I’ve shown before, RAdAC can be implemented using eXtensible Access Control Markup Language (XACML).

What do you think?

Is your organization ready to look at security analytics? What do you see as the major road blocks for implementing RAdAC?

XACML Supports All Major Access Control Models

~ Ray Sinnema ~ 4 Comments

In a previous post, I talked about one of the most advanced access control models to date: Risk-Adaptive Access Control. In this post, I will put this in context by taking a closer look at a variety of access control models.

Access Control Defined


Access control is all about permitting or denying access requests. An access request occurs when:
a given subject tries to access
a given resource to perform
a given action in
a given environment.

The NIST Survey of Access Control Models

The National Institute of Standards and Technology (NIST) issued a report that identifies the following access control models:

  • Access Control Lists (ACLs) (subject, resource, action, N/A)
    The subject is either a user or a group. In some cases it can be an application.
    ACLs are hard to maintain when many users share privileges. For example, all developers should have access to the source code management (SCM) system. If the SCM is upgraded with a new feature that has its own permission, then the ACLs for all developers must be updated.
    ACLs are widely available, for instance in operating systems.
  • Role-Based Access Control (RBAC) (role, resource, action, N/A)
    Users are now generalized into roles, like developer.
    Roles are often not granular enough. For example, only the developers for product X should have access to the product X SCM. This can be fixed by introducing finer-grained roles, but that often leads to an explosion of roles. Sometimes there are even more roles than users in a system!
    RBAC is commonly available, for instance in relational databases.
  • Attribute-Based Access Control (ABAC) (subject, resource, action, environment)
    Everything is now generalized into attributes. Environment attributes, like the current time, are now also supported.
    Attributes are often used differently in different applications. For instance, one application may name the attribute for role role, while another may use role-id. Or one application may use an ID into a role table as the value of the role attribute, while another uses the role’s human readable name.
    ABAC is considered state of the art.
  • Policy-Based Access Control (PBAC) (subject, resource, action, environment)
    Attributes are now harmonized across all applications of the (extended) organization. For instance, the Core and Hierarchical Role Based Access Control (RBAC) Profile for XACML defines the URN urn:oasis:names:tc:xacml:2.0:subject:role for the role attribute.
    We’re just starting to see some PBAC implementations.
  • Risk-Adaptive Access Control (RAdAC) (subject, resource, action, environment)
    The environment attributes now take on a much more important role. In particular, dynamic risk levels are encoded as attributes.
    I know of no implementations of RAdAC, but I think we’ll start seeing them soon(ish), since they can help in the fight against Advanced Persistent Threats.

Trends in Access Control Model Evolution

If you look closely at this mostly chronological development of access control models, you’ll find the following trends:

  1. Access control becomes more fine-grained
  2. Access control becomes more policy-based, less ad-hoc
  3. Access control becomes external to applications

XACML Supports All Major Access Control Models

The eXtensible Access Control Markup Language (XACML) is an OASIS standard for ABAC. Since ABAC is a generalization of RBAC, and RBAC is a generalization of ACLs, it’s not surprising that XACML can handle all of those access control models. Furthermore, PBAC is technically just ABAC. The PDP doesn’t care what attributes are used, or how they are named. Nor does it care whether does attributes represent dynamic risk levels, as in RAdAC.

So the conclusion is that XACML supports all the major access control models. This makes XACML a future-proof technology. It will easily accompany you on your journey to a more sophisticated access control model.

Risk-Adaptive Access Control with XACML

~ Ray Sinnema ~ 2 Comments

Risk-Adaptive Access Control (RAdAC) is an advanced access control model where access decisions depend on dynamic risk assessments. In this post, I’ll show how RAdAC can be used in the fight against Advanced Persistent Threats (APTs).

Before I make that point, let me start off with a simple illustration of RAdAC in action. Then I’ll show how to implement RAdAC using eXtensible Access Control Markup Language (XACML).

Risk-Adaptive Access Control Demo

I’ve built a simple demo around RAdAC, which Jeroen van Rotterdam showed at EMC World 2012. Here’s how it works.

In the default situation, the threat level is at green, and the user is able to see and edit a document:

Green

However, when the threat level goes to yellow, the user is no longer able to edit the document:
Yellow

Finally, when the threat level goes to red, the user can’t even see the document anymore:
Red

Using XACML to Implement Risk-Adaptive Access Control

The demo may be simplistic, but it is a fully working system based on XACML. And, not unimportant from a software development perspective, it was very easy to build.

Remember the XACML architecture:

Given this architecture, all we need (from a technical perspective) to support RAdAC is a Policy Information Point (PIP) that looks up the dynamic risk attributes (environment oval in the above diagram). Once we have that, these attributes can be used in access control policies like any other attribute (subject-id, role, resource-id, action-id, etc, etc.)

In the demo, the threat level is set by clicking the traffic light. In the real world, a PIP would be connected to an Intrusion Detection System so that it can calculate the value of the threat level attribute.

The nice thing with an access control architecture based on XACML, is that no software needs to be updated to support RAdAC. All we need is to hook up the Policy Decision Point (PDP) to a PIP that calculates the threat level. You could go finer-grained as well, and split the one threat level attribute into several, if that’s what your access control policies require. How you write your policies has no impact on your applications, since the PDP and PIP can be re-used across all applications in your organization.

Risk-Adaptive Access Control and the Fight Against Advanced Persistent Threats

I think it won’t be long before we’ll start seeing implementations of RAdAC, since it can be a big help in the struggle against APTs.

With RAdAC, we make decisions up front about what to do in the event of an intrusion, and formalize those decisions in automated access control policies. Then when a security incident occurs, we can focus our energy on getting the intruder off the system instead of on protecting our information assets, since that will already have been taken care of.

What do you think? Is your organization interested in solutions like these in the fight against APTs? Please share your thoughts in the comments.