The rediscovery of information security
This blog has been due for quite some time. Ever since new privacy regulations have come into play, data breaches in (online) information systems have been in the news prominently. As far as I am concerned, the problem is not so much that those systems are no good, but rather that the decision-making authority for granting access is very often wrongly allocated. This has its roots in earlier times when ICT departments developed the organization’s systems. But that doesn’t mean it should still be that way in the present. On the contrary, business operations (the “business”) must regain control. And it may be necessary to take alternative paths. The world has changed, business processes change continuously and the way we share information changed as well.
In the past, a system was built to manage data, where someone is given an account for using that system and where an administrator assigned the rights to that user. That led to enormous fragmentation of accounts in different systems in order to run processes. Today we do this differently. We buy new cloud-based services and provide people with a single Azure account with single sign-on access to all those services and data.
But then things still go wrong …
We may have gotten rid of that account management and password management, but access is still not resolved.
The reason for that is that we still think in terms of people, systems and services. We buy a system or a service to help our employees with our processes. But that is no longer scalable. Just try to grant access to business partners, customers and suppliers. There is a great temptation to do this in traditional ways, to protect our information in a traditional way. Access management from the perspective of accounts and systems is not scalable.
That has to change: “who” is not scalable!
We must no longer just use the traditional frameworks, but we have to start with the processes and the data that are processed. No longer thinking about who may have access to processes and data (“who” is not scalable), but why, under what conditions someone should have access to use the secured information. And then we arrive at the core of information security: we need to secure the information, not the users. On what grounds can someone use a process or an information element? And that can be anything. These can be competencies of the users (junior versus senior), the confidence level of the person (e.g. from a reliable partner, with multi-factor authentication), business rules regarding conflicts of interest (someone is not allowed to handle their own object data, e.g. their own expenses) or a key control like segregation of duties (if someone has performed task 3, that person may not also handle task 4).
So this is not about: Who are you, what is your role, what is your profile, what are you allowed to do. It’s about: why should you be allowed to do this. It is a reverse question. Of course, we still need to know who did what, but that’s just standard logging and monitoring, we already know how to perform logging.
So back to basics, securing information.
Most traditional systems are not really made for securing information. There are more bottlenecks than data breaches resulting from clumsy access facilities. In the long term, we have to return to securing information, because we may not even know our users anymore. And this will be sooner rather than later: just have a look at opening up API’s and machine2machine communication.
The solution might emerge from using a Zero Trust Architecture. Accounts no longer exist in those environments, there is only access. As a result we must separate identity and access. And that means that we grant access based on access policies. Using all kinds of attributes other than just usernames and roles. Attribute Based Access Control, Policy Based Access Control instead of Role Based Access Control.
For more background I would like to refer to this nice article by Mary McKee.
IDPro is the professional association of Identity & Access professionals. SonicBee is a partner of IDPro and actively contributes to the development- and sharing- of knowledge within the field. Mary’s article is a valuable contribution to the field!