GDPR has forced us to look into the various layers of security applied around businesses. Classify our data and ensure there are sufficient mechanisms in place to protect it. There are however a group of select people who will always have access to most of,  if not all of the data within a company. The IT and system administrators. They need this access to fulfil a function of their job. However this access can also be considered as a threat within itself.

 

Hence with all the changes being done to achieve GDPR compliance we also need to mitigate the threat of the human IT department. Those people who we call to fix our IT problems and can do so remotely by logging into our machines, let alone the servers and the location of our databases. Now I want to be clear, all the IT professionals I met in my life are highly professional people who would never even think of damaging their reputation by abusing this power. Alas though they are human and mistakes can happen. They are also the easiest to blame when something goes wrong. “We didn’t do anything your IT must have changed something in the settings!!” Sounds familiar?

 

We need to have solutions in place to protect the admins we have come to rely on so much. Solutions to audit configuration changes for example. I want to be able to prove that my IT department did not change the settings or whatever the client is claiming. This argument applies as well to technical support members of a company who might have access to client systems for support purposes. When something does not work as expected, clients tend to get irate and let’s face it, are not always in a reasonable mood. As such we need to have audits and tracking to be able to categorically prove that our employees did not abuse this access.

 

We also need to ensure that any unnecessary access to systems is removed. This sounds quite obvious. However, have you ever encountered this scenario?  Employee Smith has been assigned a special one off task, which in order to complete needs to access information from system Z. The task is completed, time has passed but somehow the access has never been revoked. Employee Smith has never accessed the system again, is a trusted employee and has acted in the best interest of the company. As security professionals however we need to remove this access to ensure the Mr. Smith, does not access the system accidentally.

 

Before you scoff at ‘access the system accidentally’, let me assure you this is not difficult. How many of you have bookmarks for system URLs that you needed to work with at some point in time? How many click on the remember my credentials tick box when signing in? A simple misplaced click on the wrong bookmark would be all it takes to put both the data at risk as well as the unsuspecting employee. So even if you think you have your access rules and inventory covered, please do take some time to go through it on a regular basis. Employee’s remits and tasks change all the time. The systems I needed access to today, may no longer be required tomorrow.

 

In the event that a one off access is required this can of course be granted. Just be sure, dear administrators, to ask for a time period, deactivate after this period has passed and DOCUMENT it. Document the:

• employee requesting access,
• the system,
• the level of rights given,
• who approved the request,
• who granted the request,
• when was access revoked and
• who revoked the access.

As admins you need to protect yourself. As compliance officers we need to ensure you are protected. So bear with us when we come with a lengthy detailed and seemingly bureaucratic process. We’re not just trying to protect the company, we’re also trying to protect you. It is your job, technical geniuses, to tell us how all that bureaucracy can be automated so that we can get out of the way.

 

Would you like be notified when new posts come out? Drop us a note via the contact us section and we’ll add you to our mailing list.