Welcome back! Here is Part 2 of the Axiomatics road trip to Australia and New Zealand. As mentioned in Part 1, the trip was loaded with interesting conversations and here are five more topics that warranted some additional commentary:
Business Analysts are the optimal policy authors
“Who writes the policies” is often a question we are asked by customers who are new to the ABAC approach. Every organization is different, but generally the answer is a combination of people who are familiar with the technology or who represent the business/application areas. I believe similar collaborations occur when implementing other IAM technologies, such as user provisioning or user authentication. In ABAC systems, the access rules are typically very specific to the line of business applications that are integrated. Therefore, the person writing the access rules must be very aware of the business, security, risk, legal, or privacy constraints for that particular application or business unit – IT personnel normally don’t fit this archetype. Rather, a business representative provides important input or, ideally, a person with business analyst skills should be able to complete the bulk of the policy authoring task.
Legacy security models for database content
Axiomatics recently introduced a product to filter database content, based on centrally defined and managed access policies. During the course of describing this new product, we learn about the current practices for protecting database content. It turns out that organizations have a bevy of techniques and workarounds that are somewhat analogous to the RBAC and group models used elsewhere in the organization. These techniques include stored procedures (most prevalent), customized table views, web services that call specific stored procedures, application specific code that call specific stored procedures, and others. More recently, we even heard of a customer that has a dedicated group that performs custom data extractions and manually redacts or masks data.
The above techniques suffer from some of the same limitations associated with legacy RBAC approaches. Namely, they are costly to construct and maintain, are user centric rather than resource centric and, more importantly, don’t provide the flexibility or granularity of access required in modern data sharing and collaboration scenarios.
Pre-masking data
It was very interesting to learn of one scenario where an enterprise customer preloaded a customer database with masked data in one column – and the unmasked data in a separate column. Access to the clear text or masked columns were controlled by which stored procedure was called by the application. By preloading the masked data, system performance was optimized instead of masking data as it is being returned to the application.
Bring Your Own Identity (BYOI)
BYOI, or Bring Your Own Identity, is a topic that came up during conversations with one organization that is working to build an identity proofing and credentialing service. The idea is that clients who are issued high assurance credentials would be able to use the credential at multiple internet properties. Said another way, if a user is proofed an issued an authentication credential by a well-trusted provider, they should be able to “bring” this credential to other sites.
I first wrote about BYOI in a blog post back in September of 2008 – you have to use the wayback machine (screen shot included here for convenience) to find it at this point. It’s great to see this idea catching on and to see constructive discussions about re-using high value credentials. To date, we have seen the most re-use of lower value credentials, such as Facebook.
Privacy requirements: country specific
We’ve seen privacy become a primary authorization requirement in the past year or so and this was strongly reaffirmed during our trip. Banks that operate in multiple jurisdictions are increasingly pressured to uphold country-specific privacy laws and regulations. For example, certain countries require that bank customer files and information can only be accessed by bank employees of the same citizenship or that are domiciled in the same country. These privacy rules are in addition to the business, security, and risk rules and other regulations the financial institution may be implementing.
With an ABAC system, it is much easier to incorporate region- and country-specific access rules. In an ABAC policy, rules can enforce all the security or privacy rules required because of the policy language used under the covers. In essence, you have a programming language at your disposal which is specialized for access control scenarios. Furthermore, policy analysis can be performed to validate that the correct controls are in place.
Analyzing Identity 