Emergency Access at 2am? Don’t Wake Me Up, Please!

Emergency Access

There’s a tricky little process with an innocent-sounding name, and it’s something that goes on in your organization far more frequently than you’d imagine. Can you guess what it is? It’s called “IT Access” (AKA “Emergency Access”) – and auditors love it.

When IT employees–or anyone who doesn’t require continuous access to production systems–need urgent access to them, there’s a process they have to go through in order to do so.

They put their name on a web page titled “Emergency Access,” state a reason for needing the access and are given immediate and timely access to the sensitive production system.

There, they can fix a bug, install software updates or check on a simple end-user issue, such as why a report can’t be printed. In order to prevent cases of unauthorized activity, such as the IT employee using this privileged access to transfer money to his personal bank account, the process includes thorough monitoring capabilities and alerts regarding sensitive use.

Ensuring Secure IT Access Can Be Complicated

The problem here, is security. In most organizations, you’ll be faced with resistance from two groups of people when trying to implement Emergency Access: IT personnel and the security team, headed by their manager, the CISO.

IT personnel will resist this process because it forces them to request access each time they need it. Until recently, they weren’t required to ask anyone for this access. Now, they suddenly have to fill out a form, wait for multiple approvals and only receive access once these are made.

As is to be expected, this change will annoy some people.  If the requirement comes from the audit team, however, it’s easy to handle resistance. You can simply say, “Well, this is the auditor’s requirement for complying with SOX laws; we have nothing to do with this.”

The second group is harder to handle. Security teams will always insist on “authentication”: verifying that the person who requests access is really the employee and not an imposter (i.e. hacker). They’ll also insist on getting a flow of approvers for each access: from the person’s direct manager, up to a data owner and finally the CISO, himself.

They’ll claim that if you want to grant broad access to anyone, it should be examined very thoroughly and be well-monitored. It is true, of course; the only concern is the amount of hassle involved and how negatively it will affect day-to-day operations.

If someone needs to wait an entire day in order to be granted two hours of emergency access, isn’t that counterproductive?

Too Much Security Can Create Security Holes

Many times, we’ve witnessed honest IT employees looking for alternatives to the standard emergency access process because it was too complicated. Nobody wants to wait a day for a 2-hour window to perform an urgent task, and nobody wants to be in charge of waking up the CIO (who was listed as an approver) at 2am to check an urgent problem with an end-user case in Japan.

Here are a few examples we recently discovered for bypassing the standard process:

  1. Using a legitimate account to perform the job. In this case, the IT employee will say to a colleague, “Hey, can I use your account for couple of minutes, I just need to check something for our user in Japan and I don’t have time to wait all day for approval.” The colleague, who also understands the hassle of waiting and the urgency of the task, will allow his IT colleague to use his account, which of course is not the correct procedure.
  2. Using an unsecured interface account. Some of the accounts being used for data interfaces are granted with very broad permissions (e.g. SAP_ALL) and IT people know this. We often witness usage of interface accounts (batch accounts) to perform tasks in dialog mode by real employees, instead of their intended purpose. When we investigate the case, it turns out that the cause was good and honest, but the employee was pressed for time.
  3. Using programming methods to achieve high levels of authorizations in productive systems. Although this sounds like a real hack, we witness IT personnel (most of them are programmers) who use internal function modules and software procedures to raise their own permissions in SAP, perform the task and then set the permissions back to normal.

All the above situations can be monitored on a 24/7 basis.

Creating a Viable Alternative

The first step in implementing a good IT access process that people will use correctly is to understand that an over-complicated process might miss its intended purpose.

The process should be secure–but not too secure–and it should answer thorough audit requirements, while remaining as simple as possible. This way, employees will actually use it and you’ll still be covering any unnecessary security loopholes. You always have to think about the end user and balance the needs between simplicity, complexity and audit.

Also, when you’re happy with the results and people seem to use the process successfully, don’t forget to keep an eye on usage statistics to see if people are using it continuously. From time to time, you should verify that the process is still as simple as possible and that usage isn’t decreasing. A strong, functional process in place means less resources spent on day-to-day operations, higher level of security and less preparations for your upcoming audit.

Want to hear more about implementing a solid emergency access procedure?

Share With Your Network

Share on facebook
Share on google
Share on twitter
Share on linkedin