In the healthcare industry, those practicing in the field must take the Hippocratic Oath and swear to uphold specific ethical standards. This standard helps promote the idea of “do no harm” and healthcare practitioners take this oath very seriously. But what about the Information Technology industry? How do we ensure that those we give ultimate power to in our organizations are not abusing their power and are acting in the best interest of the company?
There is nothing similar to the Hippocratic Oath for systems administrators, network engineers, or security analysts. Although we would like to hope that throughout our interview processes and background checks, we are hiring morally upstanding folks, there really is no overall ethical oath that professionals in Information Technology subscribe to. The majority of us will respect ourselves enough to hold high ethical standards, but even still there are some who won’t. So, how can we ensure that our employees are not abusing their access?
Are Log Files and SIEM Enough?
You may argue that you have logs, you have a SIEM, if anything were to happen, you could pour through your logs and build a forensic timeline to answer the who, what, when, where, and how. However, this is after the fact, after the damage has already been done. Wouldn’t it make more sense to put safeguards in place to prevent the damages from occurring in the first place?
Think of it in terms of your primary bank. You have both your checking and savings accounts in there. Maybe you have some CDs, a HELOC, and a mortgage with them as well. Would you be comfortable if any of the tellers could simply walk into the vault by themselves with no surveillance and no safeguards and do whatever they like under the presumption of trust? Would it be acceptable for the same teller to be able to modify your account information on your mortgage, HELOC, etc. without a second set of eyes and an approval process? I would hope your answer is a resounding “No.”
Evade Privileged Access Abuse
We need to start putting surveillance, approval processes, and alerting around our privileged access in our environments. Think about how many individuals in your environment have some type of elevated access. This is not only in the scope of your Domain Administrators, but also the DBAs in your environment that have access to the databases that hold your company’s most sensitive records. How do you know that none of the folks you’ve hired, and trust with your data, are not abusing their power? Especially when the same individual that could access that “Finance” directory on your file share can, at the same time, disable logging and remove all evidence of any nefarious activity?
Here’s an example of how abuse of privileged access could play out: ACME, Inc. just hired a brand new Systems Administrator and, as part of the on-boarding process for that team, the new-hire has been given a secondary account with domain admin privileges. ACME has a SIEM, and all of their servers have agents on them to forward logs to the SIEM. One night, after a long troubleshooting session, the new hire feels underappreciated and wants to know the salaries of other employees at ACME. Knowing full well about the SIEM, they first stop the services of the log forwarding agents on the file servers and domain controllers. They then grant themselves access to the directory in which the salary data is stored and make a local copy to a USB. They then delete all logs on the fileserver(s) and domain controllers for the timeframe in which he was snooping. Finally, they enable the agents again and walk out the door with a USB full of ACME’s salary data. Honestly, are your SIEM administrators going to notice that the next day? More than likely not.
Imagine the same scenario, but with a Privileged Access Management (PAM) solution in place. The new Systems Administrator has no idea what their password is to their domain admin account, and they must check it out prior to escalating privileges. Once checked out, anything the Systems Administrator does with their RDP/SSH session is recorded and stored in an encrypted format. That alone would deter most from continuing with the efforts of scraping salary data; however, if one were feeling foolhardy and decided to continue, the session recording would have full evidence of everything they did. To take it a step further, one could even configure the PAM solution to require an approval for checkout. Thus, management would get a request for escalation of privilege and must approve before the new Systems Administrator can move forward. These policies would go a long way to deter privilege abuse, and the session recording features are just another tool in your forensics arsenal.
Control, Verify and Monitor Access to Mitigate Risk
Think about how many admins you have in your organization who at any time could carry out the first scenario I described without any types of checks and balances. Is your corporate data and reputation something you are willing to risk on hopes that everyone will always be happy and always do right by the company? To take that a step further, do you trust the contractors and vendors that come in for one-time installs enough to not control and monitor their activity? It comes down to due diligence, and in the realm of privileged accounts, we need to control, verify, and monitor access to those accounts. Otherwise, at any moment, one of your employees could be wreaking havoc, planting logic bombs, or stealing sensitive company information, and you wouldn’t know until the damage has already been done.
[su_box title=”About Kyle Bubp” style=”noise” box_color=”#336588″][short_info id=’83974′ desc=”true” all=”false”][/su_box]
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.