Recertification in dynamic authorization systems

28.07.2011 by Martin Kuppinger

Access Governance tools are becoming standard in IAM infrastructures. However, they mainly focus on “static” access controls, e.g. the entitlements granted to a user based on roles and other paradigms. Recertification is supported by these tools, and the solutions are maturing quickly. Thus, that part of Access Governance is easy to solve.

However, the next wave is coming with the increasing success of tools which are commonly called Entitlement Servers or Policy Servers. I tend to call them Dynamic Authorization Systems because they authorize based on rule sets and attributes at runtime. While the rules are set, the attributes are changing. I’m a strong believer in these tools and in XACML als the underlying standard for communication between the different modules and in heterogeneous environments.

But: What about Access Governance for these environments? Some of the Access Governance tools support that to some degree, allowing to pre-evaluate some business rules which use defined roles or attributes. However, many rules – especially business rules like “users of the life insurance backoffice with the role xxx and the defined constraint for signing payments up to 50,000 € are allowed to sign that type of claim” are out of scope. There is some support for testing such rules for example provided by Axiomatics.

However, I don’t see a solution which provides integrated Access Governance for all types of entitlements. Given that Dynamic Authorization Systems gain momentum, its just a matter of time until auditors will ask for such solutions. These solutions should, like modern Access Governance tools, support the lifecycle management for the policies including approvals, auditing and analysis, and the recertification of such rules. That is more complex than what is done today. But, without any doubt, we will need this soon.

It will be interesting to observe who becomes the leader in that market. The vendors in the market of Dynamic Authorization Systems themselves? The Access Governance vendors? New startups?

By the way: The topic isn’t that new – look here.


How to deal with Data Sprawl? Could a sticky policy standard help?

21.07.2011 by Martin Kuppinger

Data Sprawl appears to me to be one of the biggest challenges in information security. And, by the way, Data Sprawl is not an issue that is specific to Cloud Computing. It is a problem organizations are facing day by day.

What happens when data is extracted from a SAP system? One example: a CSV (flat) file is created with some data from the HR system. This file is delivered to another system, in best case using some secure file transfer. But what happens then? That other systems processes the file in some way or another. It might export some or all of the data, which then ends up in yet another system. And so on…

The point is: Once data leaves a system, data is out of control.

The problem is that this might happen not only with one CSV file but with 100’s of them. And dozens of systems exporting and importing that data. Governance is difficult to implement. You can define a process for allowing exports. You might defined even rules for the use of exported data. You might review the exports regularly – are they still needed? However, reviewing what happens with the data at the target systems (are the rules enforced?) is pretty complex. But there is, up to now, no technical solution to solve that problem.

Things become even worse with Data Warehouse and Business Analytics. Data frequently ends up in large data stores and is analyzed. That means that data is combined, sometimes exported again, and so on. How do you keep control? Implementing Access and Data Governance for Business Analytics systems is a big challenge, and auditors frequently identify severe risks in that area – which is no surprise at all.

Another scenario is PII in the Internet. If we give some PII to some provider for some reason, how could we ensure that he doesn’t give that PII away? No way, I’d say. We might use special eMail addresses or faked information to track back some abuse of PII, but that’s not really a solution.

So what to do? Short term, it is about implementing processes which at least try to minimize Data Sprawl and the associated risk, like mentioned above. These processes and policies are far from perfect. That helps internally, but not for PII.

We might use (very) long-term technical solutions like homomorphic encryption and other technologies which are developed around the “minimal disclosure” approaches to address some of the issues. We then might use an approach like Information Rights Management which works not no a document basis but on an attribute basis. But most of these things will help us sometimes in the future, if ever.

But what about defining a policy standard which is sticky to the data? A standard which describes how data could be used? If systems support this standard, they could enforce it. That would be about having such a standard and allowing exports at least of sensitive data only to systems which support the standard and enforce the policies. If data is split up, the policy has to be sticky to all parts (as long as it applies to all parts). If data is combined, policies have to be combined – the intersection of the policies applies then.

Such an approach has limitations, because it will first of all need some people to define the standard. And, like with all standards, it is about the critical mass. On the other hand: Virtually every organization has the problem of Data Sprawl and lacks a valid answer to the questions which are asked in the context of Data and Access Governance. Thus, there is a real need for such a standard. From my perspective, the large vendors in the markets of Business Applications (e.g. ERP, CRM, and related systems), of Business Analytics, and of all the ETL and EAI applications are the ones who should work on such a standard, because they are the ones who have to support it in their systems. And they should start quickly, because their customers are increasingly under pressure from the auditors.


Critical success factors for IAM projects

13.07.2011 by Martin Kuppinger

This is sort of a “back to the roots” post, but for some good reason. I’ve done several advisories and customer calls recently, and in some of them it became obviuos that companies tend to miss some of the critical success factors for IAM (Identity and Access Management). Some of the projects are still too technology-focused. So I’ve put together some key success factors for IAM projects. These are not that technical, so you won’t read things like “support the cloud”, because that should just be a result of the requirements analysis.

Requirements: Understand the requirements of Business and IT – of both! And look at what might become requirements soon, so the obvious trends (like Cloud Computing, like the increasing regulatory compliance pressure even in not-that-heavily regulated industries). Knowing the requirements helps in defining the right architecture and in slicing the big elephant of IAM into smaller pieces, e.g. projects you can handle successfully.

Architecture: IAM is more than only provisioning, even while provisioning still is an important element. But oeverall, architectures are increasingly modular, providing more flexibility, better integration with other pieces of IT, and the ability to serve new requirements quickly when needed. So, look at the architectural options you have today and don’t focus on the classical architectures only.

Context: IAM is one element of IT, and one piece of your Information Security framework. It has to interface with Service Management and with other Information Security technologies, as well as with the entire GRC (Governance, Risk Management, Compliance) stack. So don’t look at IAM without understanding how it fits into the big picture.

Policies, Processes, Roles: Does your organization have well-defined policies for IAM? Does it have well-defined processes? And how about business roles, defined by the business? If any of these elements is missing, important input for your IAM deployment is missing. The policies define what you have to do and what to do first, the processes are about your implementation of provisioning and Access Governance (and more) – not even to speak about roles. The good news is that businesses better understand the need for these and are more willing to actively work on these topics then some years before.

Team: For sure it is always about having the right people – the ones who understand technology, the ones who understand business, and the ones who connect both sides.

Service focus: Last but not least it is about having a service focus. IAM is one service IT provides, as part of Information Security. It has to be user-centric, focusing on the services the users (from business and IT) require. That includes integration points to your service management environment.

You might define other ones – but these are the ones I find most important from my experience.


© 2015 Martin Kuppinger, KuppingerCole