Reading this title you are probably thinking what all these things may have in common. Contrary to your first impression they have much more in common than there seems to be. Please take two minutes to read this text and everything will be clear. And if you are planning implementation or you have already been using the GRC solutions – it should be obligatory reading for you.
At first – we can tell you something: This article is an introduction to a talk which will be presented during the Security Case Study conference. Paweł Kulpa from SilmplySec will take the floor as a speaker on 13 September 2019 at 13.10 – SCS PRO path. If you are going to attend the SCS, don’t miss him. If you weren’t planning to take part maybe this article will encourage you.
Let’s get to the point and start from the beginning, that is from quantum mechanics. Some of the readers probably know something about Schrödinger’s paradox. Generally speaking, it was a theoretical problem of Copenhagen interpretation of quantum mechanics regarding macroscopic objects.
Erwin Schrödinger demonstrated it on the example of a cat locked in the box. Apart from the cat, inside there was an unstable atom and some poison too. Prescinding from the “experiment” scenario the most important thing for us is the result, which means that until we look into the box, we do not know whether the cat is alive or not. If you are curious about the details, everything can be found online.
You may ask, however, what it all has to do with risk or employees? Almost 20 years in business of GRC have taught the SimplySec team that employees like the Schrödinger’s cat. We cannot judge whether an employee is crucially important of not and whether he poses a risk or not, until we check it. Unfortunately, we will learn it when it is too late. We will find it out only when we quit on him.
The more permissions an employee has, the more he can support our business. However, on the other hand, the more permissions he has the more he can harm us if he misuses them. Everything boils down to an old paradigm of passing to a new employee as few permissions as there are necessary to do his part of work. If you thinking now about the rule “need-to-know” it’s great because that is exactly what we are talking about. That rule applies also to permissions management.
On the other hand, however, we want to use the employees’ skills to the fullest extent, we want to involve them more in the company’s activities, and thus we give them more rights so that they can do it better. Here comes a dilemma: How many permissions are enough in the context of our present and future needs? The second question is: Which permissions involve some risk for an organization and which do not?
Instinctively, in this case, we want to support ourselves with some IT solutions. In fact, there are many systems out there which advertise themselves with a promise that they are able to calculate a risk concerning an employee and their permission. Some of them can even grade it. But what does it mean? What does it mean that an employee with their permissions is graded on the level of 30? What does this knowledge give us? Nothing. Until we compare them with another employee, we will not be able to determine whether that is a little or a lot.
What’s more, we can calculate it but how do we know whether given permission involves high or low risk? Quite often a so-called ‘ceiling method’ is used here. It means I look at the ceiling and say – this’s a high risk, and that’s low. The discretionary way of determining risk results from the fact that we have nothing that could help us to objectively assess, for example, the importance of a particular system for an organization. We can only rely on our own guesses, at least in the following way: this is a database, many employees use it, so it must be important. However, it is difficult to call it a reliable and precise method. It’s more like guessing.
And here comes an issue of tools which methodically, reliably and in an organized way can manage the risk. They can build a scheme beginning from a business process in our organization. It is important because the company can, in any case, indicate which processes are relevant to it. It can assess them, determine their value, often even in financial terms. Thanks to this, we can go further indicating which applications support a given process. Then we can indicate the systems connected with them. As a result, we acquire real and reliable knowledge that allows us to assess which permissions involving access to given systems carry a high risk.
At this point, we deliberately stop writing this article as we want to encourage you to listen to Paweł’s lecture at the Security Case Study conference. However, if for some reasons you are unable to attend, we are sure that Paweł will tell you more during an individual meeting. All you have to do is contact us, and we will arrange a convenient date and place for both parties.