Posted tagged ‘authorization’

Beyond RBAC and towards ABAC – Tales from Down Under

October 2, 2014

Axiomatics AU/NZ Road Trip – Part 1

My colleague, David Brossard and I recently completed a 2-week road trip to Australia and New Zealand where we toured with our local partner, First Point Global. The trip began with the local Gartner Risk and Security Summit followed by several customer meetings and workshops across the region. In a couple of blog posts, I will share a number of interesting topics that arose during our discussions of attribute based access control (ABAC). It’s always invigorating to hear how people react to the way we at Axiomatics describe ABAC business benefits, integration strategies, or updates about industry standards. There is always a new angle to understand, a different view of the business problem, or the realization that an issue discussed years ago remains unsolved for some.

In the following sections, I will explore the first set of topics that, I think, warranted additional comment. I invite you to add comments and share your own thoughts. Be on the lookout for the second and final installment in the very near future.

Business vs. Security Rules

How do I determine the difference between a business rule and a security rule? Remarkably, this question came up during 3 consecutive customer meetings during our tour. It is not unusual for this question to come up, but it does not typically happen so frequently. When you think of it, ABAC systems are different than many other identity and access management (IAM) technologies because the integration points are close to, or within, business applications. Therefore, application developers may be familiar with or have experience with business rules engines, such as Drools.

At Axiomatics, we recently published a blog post comparing Drools to XACML (the Extensible Access Control Markup Language standard). There are a number of similarities in the approaches, which gives rise to the question. Ultimately, the answer will boil down to an individual organization’s or development team’s preferences, but there are some characteristics that should help guide the decision:

  • ABAC systems are stateless and therefore should not be used to change state in a business application. The stateless nature of ABAC systems enable ease of scale, high availability, and ease of configuration. Caching is used to enhance performance, but not to maintain state of user or resource records. In contrast, some rules engines, such as Drools, can be used in a state-full manner. That is, the state of the engine changes based on rules it has executed in the past.
  • ABAC systems based on XACML are rules engines that are optimized for access control scenarios whereas business rules engines are obviously optimized for business scenarios. In this respect, business rules engines have a language that is even more expressive than XACML.
  • Interoperability and the use of an industry standard language are significant advantages for ABAC systems. The XACML policy language and request/response format offer customers vendor independence and out of the box integration with third party products. For example, it is common to connect an API/XML gateway to an XACML-based policy server.
  • Auditability of an application environment is much easier to achieve with an ABAC system as policy analysis tools can be applied to the policy language to determine what access users have, who can access particular resources/functions and specifically answer the “who has access?” questions. Policy analysis can address the question of “what can happen” as opposed to examining audit logs to see “what did happen”.
  • Speaking of audit and auditors, ABAC provides a level of visibility into the effects of the access policies that is not generally available from business rules engines. What matters is to give the right people the relevant knowledge about what is being done within the authorization system. Keep your authorization policies about critical, sensitive aspects of your business processes. Use business rules however for the rest. A good example is the rule as to whether you mail a paper copy of a bill to a customer or use an e-bill instead. That’s clearly not sensitive and not something an auditor would care about.

IT Entitlements vs. Business Attributes

This topic is somewhat parallel to the business rules vs. security rules issue just described in the previous section. I’ve meant for a while to write a longer post on the topic, but this brief section will have to suffice for the moment. I must credit my long time friend and mentor, Eliot Solomon, for helping to shape my thoughts in this area.

When you consider legacy access control models based on techniques such as roles or groups, they are predominantly constructed on what I like to refer to as “IT artifacts”. In the past, these IT artifacts, consisting of group lists, permission sets, profiles, stored procedures, database table views, etc., were an attempt to map business authorities to technical system capabilities in order to provide access control capabilities. Today, a great deal of IAM investment is dedicated to the care and feeding of these legacy IT artifact models via user provisioning (to automate the joiner-mover-leaver process) and access governance (to certify appropriate access levels).

ABAC offers an opportunity to directly use business attributes, instead of relying on an extra layer of costly IT data. For example, data related to financial clients such as branch office assignment, primary banker, location, products purchased, and so on are business attributes stored in the business application’s database. ABAC policies can use the business attribute data as variables in the access rules, thereby directly enforcing business, security, or risk requirements. At Axiomatics, we believe ABAC is a much more specific and effective methodology for implementing access policies because you remove a layer of indirection out of the equation.

The Brittle Nature of Legacy Applications

Another important topic that arose during discussions was the fact that applications with entitlement logic tightly bound within the application are brittle, costly to modify, and unpredictable when changes are made. When does this become an issue – of course when normal changes occur in the business side of the house that require changes to the application. Few applications are constructed perfectly with modular routines that are insulated from impacts to changes in other components. Application owners are seriously concerned about the true impact of changing code for access policy changes and have to deal with a certain amount of unpredictability in these situations.

With ABAC, the authorization process is logically separated and external to the application code itself. Changes in access rules, therefore, also are implemented outside the application. Such an approach greatly diminishes unpredictability and risk during ongoing change and maintenance cycles. Advanced policy analysis also provides visibility into the impact on changing access policies for a given environment, which increases confidence that the system will operate as expected.

Real Time Settlement presents new challenges in Financial Services

Historically, banking transactions were cleared or settled after being subjected to a waiting period that could be as long as 2 days or more. Much of the delay was due to manual processing steps in the past – think about check sorting and clearing processes. Automation has eliminated the need for this waiting period and it is now possible to immediately process and complete many banking transactions in real time. While streamlining transaction processing, automation is eliminating a window of opportunity where banks had time to re-examine higher risk transactions – whereby fraudulent transactions were rolled back instead of being finalized.

With ABAC, we are seeing banks looking to incorporate risk analytics directly into the authorization service. Risk scores can be used as another attribute to determine if an attempted transaction is approved or not or placed into quarantine for further analysis. If the risk score is above a threshold, the transaction can be stopped or quarantined.

All manner of risk analytics are implemented by or available to financial services firms. Adaptive authentication systems score the assurance level of the authentication step. For years, credit card systems have implemented analytics technologies to spot fraudulent transactions. External service providers also provide APIs for banks to receive additional analytics. It is possible to use any of the above or a combination of analytics in the ABAC system to lower the risk of fraudulent activity in real time banking systems.

Affect change without changing the application!

A common question about implementing ABAC systems is, “do I have to change my applications?” In many cases, the answer is “no”. We strive to be non-intrusive to existing applications and the best way to accomplish that goal is to utilize a proxy that is external to the application. This approach is most successful with applications that are exposed via APIs or web services – or by implementing ABAC at the database.

In the case of API integration, we see many enterprises that are building new applications or retrofitting legacy applications with API or web services interfaces. This is a natural integration point for an API or XML gateway solution, which also easily integrates with the ABAC authorization service – without requiring changes to the application itself. The gateway is able to inspect the API or web service payload and construct an authorization request that is processed by the ABAC service.

For databases, a SQL specific proxy intercepts access attempts to retrieve content from the database. A SQL oriented ABAC service processes the request and rewrites the select statement on the fly so that it conforms to centrally defined security rules. The result is that only authorized content is returned to the calling user or application.

Stay tuned for Part 2 where the topics will be:

  1. Business analysts are better suited for authoring access policies
  2. Legacy security models for database content
  3. Pre-masking columns in a database
  4. Bring Your Own Identity (BYOI)
  5. Country specific privacy requirements

Talking about authorization w/ Gunnar Peterson

June 10, 2013

It’s always great to catch up with Gunnar Peterson and discuss the latest in externalized authorization. There was quite a bit of ground to cover since our last blog post series and here is the transcript:

Gunnar Peterson:
The thing that strikes me about XACML and ABAC is that its really different from other security standards. Usually when we talk about an authentication or crypto protocol, we talk about strength, threat models, and the strength of the security service itself. It’s inward focused. It seems to me that the value of XACML and ABAC is really in the use cases that they enable. It’s outward focused, and unlocks value through new kinds of services. What kinds of use cases have you seen recently where XACML and ABAC are enabling companies to build things better?

Gerry Gebel:
You are correct to point out that XACML feels different from other identity and security standards. XACML is inwardly focused on the application resources it is assigned to protect through the use of its policy language – there isn’t just a schema, token format or DIT to work with.

There are a couple of recent customer use cases that I’d like to briefly describe as they are typical of the kind of requirements we see. In the first case, the organization holds a lot of data for customers in different industries and they wish to provide access to different slices of data via a combination of APIs and web services. In this case, its API access primarily for mobile devices and web service for other client applications. Specific business rules dictate what data customers can view or what APIs/web services they can call. Integrating an XACML service at the API/web services gateway layer is a non-intrusive way to implement the right level of data sharing and enable new business models for the organization.

The other case study example is for an organization that is building a new data hub service, where certain users can publish data to the hub and others will subscribe to the feeds. Due to the sensitive nature of the information, granular access control was important for the new service. In this case, the designers wanted a flexible policy-based model to control access, rather than hardcoding it into the application.

GP:
Interesting use cases, let’s drill down on these. First as to the gateway – I am a fan of web services gateways, they are a no brainer for implementing identity, access control, dealing with malicious code and so on. Authorization (beyond coarse grained) requires a little bit more thought. How have you seen companies approach getting the right level of granularity to take advantage of the XACML Policies at a gateway level? In other words, given that a gateway has less context than the application layer, what is the hook for the policy to be able to intelligently make authorization decisions outside the app as it were?

GG:
You are correct to point out that you can only make as granular an access decision as the context that is provided to the policy decision point (PDP). In this case, the call from the gateway to the PDP may just contain something like: subject: Alice, action: view, client_record: AD345. The PDP can enhance the situation by looking up more information about Alice before processing the access request – her department, role, location, etc. In addition, the PDP can look up information about the client record – is it assigned to the same location or department as Alice. With this approach, you can still make pretty granular access control decisions, even though you don’t have a lot of context coming in with the original access request from the gateway.

GP:
Right, so its case of Roles are necessary but not sufficient?

GG:
Roles are usually only part of the equation and certainly not adequate on their own for granular authorization scenarios.

GP:
Here is one I wrestle with – naming. On the user Subject side its pretty simple, we have LDAP, we have AD, and everyone knows their user names and log in processes, but what about the resource side? Its seems less clear, less consistent, and less well managed, once you get beyond URL, URI, ARN and the like. What trends are you seeing in resource naming and management; and how does this effect XACML projects?

GG:
Indeed, naming conventions and namespaces for subject attributes are prevalent and are lacking for other attribute types, in particular for resources. One approach to address naming for resources is to publish an XACML profile, whereby you can establish standard names for at least a subset of attributes. We see this being done today in the Export Control and Intellectual Property Protection profiles. Some firms in the financial services industry are also examining whether XACML profiles can be defined to support certain cross tim interactions, such as trade settlement.

Otherwise, ABAC implementers should approach this task with a consistent naming convention and process to ensure they end up with a resource namespace that is manageable to implement and operate.

GP:
I had always looked at XACML as something that helps developers, but it appears to have a role to play in areas like DevOps too. I have seen a few examples where XACML services delegate some administrative functions, such as spinning up Cloud server instances, and lower level configuration. For decentralized environments where admin tasks (which are very sensitive and need to be audited) can be handled by different teams and even different organizations this kind of granular policy control seems like a very good fit. It gave me a new perspective on where and how XACML and ABAC might fit, have you seen these types of use cases?

GG:
Normally we are dealing with application resources, but we have had cases where IT uses XACML to control access to DevOps kinds of functions. As you have pointed out, the XACML policy language can be quite useful in a number of areas where granular access control is important.

GP:
Developers and security people fundamentally lack good (read: any) testing tools for authorization bugs. Static analysis and black box scanning tools are all the rage (and server a useful purpose in security bug identification), when you scan your app they can find all manner of SQL Injection, XSS and other pernicious problems, but at the same time you can cut those same tools loose on an app that’s riven with thousands of authZ vulnerabilities and they will often come back green! I am pretty sure this is a major factor contributing to the numerous authorization vulnerabilities we see.

I think even just a first cut, 1.0 implementation with XACML and ABAC is an huge leg up towards formalizing some of the authZ structure so that real test cases can be developed and run. This makes it simpler for the developer to avoid authZ mistakes since they can continually test against a defined policy instead of dumb scanning against something where your tools cannot differentiate between what’s authorized versus unauthorized states. What are your thoughts on authZ testing?

GG:
We get a lot of questions about testing the policies in an ABAC system and there are many ways to address this requirement.

1. At the policy authoring stage, there is the requirement to perform initial unit testing – does this policy I am writing operate the way I expect it to? We provide this simulation capability so you don’t have to run the application to see outcome of a policy and it includes a trace facility so you can explore exactly how the policy was evaluated (this is a big help in debugging policies as well). Unit tests can be captured in scripts for future use, such as when the application or access policies change.

2. Positive and negative test cases: You are correct to point out that developers can test against a defined policy, such as: cardiologists can view and update records of heart patients. We refer this as a positive test, that is, does the policy allow doctors that are labeled cardiologists to view heart patients’ medical records? But there are other conditions to test for that may be characterized as negative tests. For example, given a set of ABAC policies, is there any way a non-cardiologist can update a heart patient’s record? For these kinds of scenarios, you can build additional test scripts or use an advanced policy analysis tool.

3. Gap analysis testing: Another advanced function is to test for any possible gaps in the policy structure. But again, as you pointed out, having a specific set of access policies to test against makes the process easier. In this manner, you could test for separation of duty scenarios that violate policy: is there any combination of attributes that permits a user to create and approve a purchase order?

GP:
In my opinion, there are concrete benefits from being able to make more granular authZ decisions, audit policies and configure rather than code authZ, but as a security guy the testing piece all by itself is a game changer. This is just such a big gap in so many systems today and a large source of “known unknown” kind of bugs, ones that can be but often aren’t found and closed.

Ok last question – is XACML dead? This is your cue to tee off.

GG:
Far from it. I’ve witnessed a significant increase in demand for XACML solutions over the last few years, the OASIS technical committee <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml&gt; is actively working on new profiles (after version 3.0 of the core spec was formally ratified earlier this year), and seen new vendors enter the market. There is a big emphasis to further improve the standard for consumption by the developer community, a key constituency if the industry is going to escape the cycle of hard-coding authorization inside applications. Some of the standardization efforts worth noting are profiles to define a REST interface for the authorization service as well as JSON encoding of the XACML request and response formats. These two enhancements should greatly broaden the appeal of the XACML authorization standard. Further, Axiomatics recently joined the OpenAz <http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page&gt; project to help update and improve this developers’ API.