Analyzing Identity

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

This entry was posted on October 2, 2014 at 10:08 am and is filed under ABAC, Authorization. You can subscribe via RSS 2.0 feed to this post's comments.

Tags: ABAC, authorization