Security and the need for user account auditing

by   05.03.2016   Auditing


Massive data breaches often work the same way. The hacker gains access by exploiting a software security weakness or installing malware through phishing links. Then the hacker grants themselves elevated access so they can login to a database directly. Often this is done with stolen credentials, using user ids that are shipped with software, or brute password dictionary attacks against systems that do not lock accounts when this happens.

This means there are two items that you should add to your security monitoring in addition to all the other actions that you are already taking:

  1. users gaining elevated access
  2. what users with elevated access are doing

This simple and logical idea is often overlooked by companies who focus too much on the tools and not the end goal of protecting data. They spend lots of money and time installing and configuring firewalls, intrusion detection, and anti-malware systems – But software of that type is by no means full-proof. All a hacker needs to gain access one failure which is why it makes sense to focus on data protection as well.


Instead of simply looking to block hacker programs, it is necessary to monitor user accounts. How to monitor what users are doing is a different topic altogether. Here we explain why it is important to monitor changes in user access and how you can do it.

If a hacker is going to steal an entire database, they would need to log in to the it and dump the tables to a format they can send out to themselves using ftp or any similar tool. Alternatively, they could write a program to export records one at a time. Only privileged accounts can do this so it is necessary to audit who gets this access. When someone gets that access it should kick off an alert for the security team when there is no corresponding approval transaction.

SOX and HIPAA regulations require that a user is not to be given access to a system without documented approval – this is called certification. This access is supposed to be taken away when the user either no longer needs it, possibly due to a change in their role, or they leave the company.

The only way to ensure that someone has given approval to prior to a user actually gaining access is to use some kind of integrated identity management system (IDM). If someone is given elevated access, and does not have corresponding approval, it could indicate a hacking attack. Not all of this can be automated – but much of it can be. Either way there is certainly a need to audit access.

Identity Management

We know that not all companies have an Identity Management (IDM) system that actually works. Projects to install these often fail to meet expectations because they have made the scope too large, such as enterprise-wide. But at a minimum companies should have manual procedures or an automated solution to control access to the most important systems. For this discussion, let’s call whatever you have, or plan to have, the IDM system and then explain what it is supposed to do.

In the IDM system there is a system of record, known as the authoritative source. It is usually LDAP or Active Directory. Then there are workflow processes to route approvals to whomever grants access. Connectors automatically create the accounts and assign the proper roles in the target systems based upon the approvals. Of course all of this can be manual too to the same effect, as long as the company follows written procedures rigorously, including documenting access.

Regarding deleting access, there needs to be a roll off procedure. Since all of that is executed in the HR system, there needs to be a link to the IDM system that is either automated or manual. Otherwise there will be accounts floating around that a hacker can use when someone forgets to delete or disable it.

The Audit

Assuming that you have some kind of certification system, you will need to monitor changes in user permissions and match those up with approvals. Flagging changes in privileges can be automated by monitoring logs. Log monitoring can be difficult, but you can simplify it by looking only for specific events.

Having found that someone has been granted access to the database, it is necessary to check the IDM system. Checking the IDM system will have to be manual if that kind of interface does not exist. You can obviously reduce this burden by installing a system that matches approvals with events, i.e., an automated user audit.

Block Local Accounts

An IDM system will never work if users are allowed to circumvent it. Users cannot be allowed to create accounts outside of the authoritative source. That means, for example, that Linux needs to use LDAP and not allow local users. But implementing this policy might not work on devices like firewalls where there is no API to create users. In this case you can replace appliances with software defined networking where access is controlled with the cloud operating system. That should be a short term goal if you are not doing it already. For other systems that cannot connect to LDAP you can still use IDM to document who is supposed to have approval. Even a hardware firewall generates a log when someone grants access.

So, we know that a user needs elevated access to a database to be able to export and steal it. If a hacker has stolen the credentials of an administrator account, it is very difficult to detect. The best way to stop this from happening is to use two-factor authentication for humans and certificates for service accounts. But the least you can do is follow up and check to see if there a corresponding approval when someone is given elevated access. If this approval is non-existent then it is likely that you have been the victim of a hack. If you find yourself in that situation, it’s time to have the whole team jump onto forensics and start reviewing to see if anything has been stolen. You may find that you have to engage a forensics partner if you do not have the skills or resources in house to do it. You should probably have someone on standby anyway, even if you use less than their full managed security services.

About authorWalker Rowe is a freelance programmer and tech writer.

Lepide® is a Registered Trademarks of Lepide Software Private Limited. © Copyright 2018 Lepide Software Private Limited. All Trademarks Acknowledged.