Sam was just another network engineer assigned to the server team at the hospital. Each engineer had two sets of credentials, one with and one without elevated privileges, and they had all been told not to use the one with privileges when just accessing the network or routine services such as email. But Sam always liked to do things his own way, and saw no point in wasting his time worrying about which login he used, thinking, “These security guys were always making a mountain out of a molehill.” Then one day, a massive outage took place that affected multiple systems and applications, and someone in finance was on fire because they couldn’t get payroll out, hell they couldn’t even access the payroll servers. Eighteen hours later, it was determined that the outage had been caused by someone (Sam) making unauthorized changes, downloading malware designed to capture employees’ data so it could be transmitted out of the network. More analysis discovered that Sam’s privileged account had been compromised through a phishing scheme, another risk that Sam had thought was overblown. Because the hospital’s privileged accounts were persistent, the hacker had plenty of time to execute the attack. Because they weren’t encrypted and there was no second factor associated with them, once the hacker had them, he had full access to them. The last thing that analysis showed was evidence of Sam’s dismissal of the risk and his reckless behavior that ultimately put the hospital at risk. It cost Sam his job. I’d like to say this is rare, that this is an outlier story of a really bad day, but the facts are it’s not.
What’s so amazing about access privileges being abused is that it is generally avoidable with a little common sense, discipline around process, patience, and a small investment in technology. We should not be compromised by the very people we trust to manage our enterprise. Privileged accounts are a double-edge sword that can slice in both directions. Necessary for keeping the hospital’s systems up and running and for implementing new services, but they can also be used for malicious purposes to cause significant damage and place patients at risk.
The first step to addressing this risk is to inventory the privileged accounts that exist on the enterprise, which usually exceeds the number of users organizations have. These accounts include privileged user accounts, like the ones compromised above, local admin accounts, domain admin accounts, emergency accounts, service accounts and application or database accounts. All of these accounts should be limited in number to that which are absolutely necessary and should be reviewed and disabled when no longer needed.
Step two is to educate any user who will have access to privileged accounts. Ensure that their activity can be audited when using these credentials by making use that no standard accounts have elevated privileges. Ideally every workforce member, to include those who might need elevated privilege to perform certain tasks, should only have one account and that account should not have elevated privilege. If permitted, those credentials should be encrypted at all times, both in storage and in transit across the enterprise. The notion that the bad guys cannot get on the network and therefore have access to the internal traffic should never be assumed.
Step three is to eliminate persistent elevated privileged accounts and associated passwords. Deploy a vaulting solution that requires a user needing elevated privilege to perform some legitimate task to have to first log in to the vault using strong multifactor authentication to check out a one-time account and password for the specific asset they intend to access. Enable session tracking/recording and reporting while that account is active. Make sure privileged accounts expire after a predetermined period of time. Periodically audit these accounts to identify users who do not check them back into the vault once they are finished with the task they were needed for.
Finally, implement multifactor authentication for elevated accounts, remote access and third-party service providers that have direct access to the enterprise or applications. Implement a gateway to enable third-party authenticated access, session tracking and to limit the actual access that the third-party has to those specific assets they are authorized to manage or administer.
The key concepts here are simple. Know what you have, inventory these accounts. Determine need, eliminate those that are not required and implement a process to periodically review all of them. Educate those who need them, hold them accountable for less than responsible behavior. Encrypt them whenever active or in use, make them harder to know. Require more than one method to authenticate, apply multifactor controls so that simply getting one’s credentials doesn’t earn you a ticket to do anything. Eliminate all standard user accounts with privileges,] and enable one-time accounts and passwords that are non-persistent using a vaulting solution. Require active monitoring and session recording any time privileged accounts are active. Protect your assets from untrusted environments, and apply additional controls for remote users and third-party service providers.
Will these changes require changes in process and expectations…absolutely. Will network admins have to spend a few extra minutes before they can make material changes to critical assets…yes. Will users accessing the network remotely or vendors be required to go through a couple of extra steps and a few more seconds when logging in…you bet. Is the wait worth the risk that is avoided…no question. Just ask Sam. If that was his real name you could. The point is don’t let a “Sam” victimize you. Get a handle on your accounts. Make it harder for hackers to get them.
