Insights

Blogs

The Perils of Privileged Access

System Administrators are essential to ensure that our corporate systems continue to function as they should. They are the people who, behind the scenes, oversee access for the rest of us, monitor the environment to ensure that everything is running efficiently and fix things when they go wrong. They carry a lot of responsibility on their shoulders and they have the power to control entire systems, databases and networks and cause major disruption if they make a mistake or decide to cause deliberate harm. In addition, they have the kind of power that hackers covet! The challenge in controlling the risks of both the insider threat and external threats is to minimise the impact and/or opportunity whenever possible and to maximise the possibility of detecting and gathering evidence if an attack does occur. Many of the financial regulators explicitly demand these types of controls to minimise impact and opportunity.

Stay current on your favourite topics

Subscribe

Anyone with elevated privilege is a natural target for an attacker as highly privileged accounts allow a short-cut to compromising the security of a system or network. If a low-level account is compromised, the attacker will usually still need to find a way to elevate privileges before accessing any information of interest. Compromising a privileged account gives them this level of access immediately. Once an account has been compromised the controls in place to protect against an insider attack become the same controls to thwart an external attacker. Every major breach will almost certainly involve the use of an elevated privilege.

Minimising impact – is usually achieved through applying the principle of least privilege. This principle aims to limit the level and/or scope of power to only the minimum amount required to complete an activity. Privilege may only be granted to a limited number of assets or restricted to only a small sub-set of commands. In this way, if the payload in a phishing email is activated, for example, the resulting damage can be limited and/or contained.

Minimising opportunity – There are a range of controls that can be applied to minimise opportunity:

  • Strong authentication – even strong passwords are not good enough to protect highly privileged accounts and Multi-Factor Authentication (MFA) through smart cards or other devices and/or One Time Passwords (OTP) can avoid compromise of authentication credentials
  • Time of the privileged session should be restricted. This minimises the amount of time available to either a malicious insider or an external attacker who has hijacked the account
  • Access to Internet can be restricted during a privileged session. This ensures that any malicious code or links that are launched cannot communicate outside of the corporate network
  • Session monitoring – in addition to regular review of privileged access sessions, alerts should be set up to trigger on unusual or suspicious behaviour. Increasingly, some firms are looking to machine/deep learning to help to identify behaviour outside of usual activity for a given identity

Practical Approaches and good practice

Lock down shared accounts like root, oradba, sapadmin and application system accounts and store credentials away either in a safe or credential vault. Use of shared accounts like this should be in-extremis and always traceable to an individual. Where possible, any activity requiring elevated privilege should be through a personal (uniquely assigned to a person) identity.

Standing Access

With Standing Access, a given identity has an agreed set of privileges attached to the account on a permanent basis. Without any other control, this does not minimise impact or opportunity, although look at the dual account model and the restrictions below as an approach.

  • Single account

The administrator only uses one identity and that identity has elevated privileges. This should be avoided, particularly where the account has high privileges, as it doesn’t minimise impact or opportunity. If standing privileged access is required for these types of accounts consider a separate account for the privileged access. See below.

  • Dual account

Give system administrators two accounts: One identity with no additional privilege for normal use and one identity with the privileged access required for administrative activities. Remove Internet access from the privileged account and consider removing email access. This will help prevent accidental compromise from phishing and spear phishing as any email attachments or links to a harmful site will be prevented from launching code. Additional controls such as enhanced vetting, block leave and additional monitoring should also be considered. There is a lot of interest in the use of machine learning to monitor deviations from behavioural patterns to see if the account has been hi-jacked.

Temporary Privileged access

Many of the financial regulators are looking for this kind of approach, where access is not granted permanently but only when required for a specific task and only after appropriate authorisation. There are several ways to achieve this:

  • Elevate user’s standard account for a short period to carry out very specific tasks
  • Allow a delegated shared account to be used under controlled conditions (session monitoring, full auditing etc.) for a limited time
  • Run individual task only as a privileged command with elevated privilege (like sudo)
  • Fine grain (sub-identity) level access where a set of privileges is given for a role e.g. Level One application support

Jump Servers

Jump servers are hardened servers that are in a segregated network zone, if the credential vault and/or session management server are on a jump server the environment can be made very secure. The SA will connect to the jump server with normal (non-elevated) privileges and then launch a privileged session with all the necessary controls from there.

Captive Shell/Portal

Automate tasks in scripts and allow them to be launched from a captive shell or web page. This technique is very useful for regular operations commands where low level staff have a need to run a small set of commands with elevated privilege

Joiner-Mover-Leaver

Ensure that movers and leavers have elevated rights removed as soon as possible when roles change. Many of the segregation of duties failures in the past have been due to old privileges not being removed when no longer needed/appropriate.

Training and Awareness

By the very nature of the work that they do, System Administrators are usually very technically savvy but they are not always trained in Information Security. Regular awareness training to educate them about current and emerging threats can help to ensure that they aren’t trapped by some of the more advanced techniques that malicious actors are using.

Be pragmatic

Implementation of these controls is never easy, particularly in large scale enterprise environments. There are process, engineering and behavioural challenges. Striking the right balance between level of control and workability can be very difficult to get right. While all these controls are necessary to mitigate both the insider and external threats, spare a thought for that poor overworked and unappreciated system administrator who must work with these controls. One good example of the practical challenges is to consider the difference between elevated privileges required for a change versus an incident. In the change example, all the target hosts/environments can be listed in advance and access granted accordingly. For an incident, this can sometimes be harder to specify as the incident may not be confined to one host and during investigation other access may be required. Time is also likely to be a factor. So, emergency processes may be needed with suitable compensating controls. Explain the risks to the operational teams and why the controls are important and look for their feedback on how best the controls can be implemented while minimising the impact to their work. As always, ultimately controls work best when they make it easy for people to do the right thing and hard for them to do the wrong thing.

Stay current on your favourite topics

Subscribe

STOP PRESS:
Just as we were sending this blog out for publication, an attack of the new strain of Petya ransomware hits the news. One interesting aspect of Petya that is different to Wannacry in that the payload requires local administration rights. Best practice would be to not allow local administration rights to standard users but it has become common not least for developers in many organisations. Home users will often use accounts with local admin rights as the default account. Anyone with local admin rights will be vulnerable to an infection from Petya and infection of one machine on a network makes the whole network vulnerable to propagation.

Examples

San Francisco Municipal Transportation Agency

In November, 2016San Francisco’s public railway system, known as Muni, was infected with malware over the Thanksgiving weekend; this resulted in locked kiosks and computers and two days of free rides for passengers until the system went back online on the Sunday, the attack was not targeted it was an attack known as a “spray and pray.” In this type of attack, links to malware are sent out to many prospective victims and in this case an IT admin at the transportation agency allegedly clicked on the link and unknowingly downloaded the malware files.

Walmart 2005/6

The Wal-Mart intrusion first came to light on Nov. 5, 2006, when the company’s IT security group was brought in to investigate a server crash.

A single server crashing amongst all Walmart’s servers would ordinarily be a routine event. But this one raised alerts as someone had installed a password-cracking tool, onto the system, the server crashed when the intruder tried to launch the program.

The IT security team found that the tool had been installed remotely by using a generic network administrator account and that the hacker had reached the machine through a VPN account assigned to a former employee. The account had not been disabled after the employee had left the company.

Kansas City March, 2008

On Aug. 13, 2007, Harold James Boomer pleaded guilty to unauthorised computer intrusion. Boomer admitted that during his last day at MTC, he created an administrator user name that was set up to give him complete administrative access to the network, and to monitor the e-mail accounts of key MTC employees. He also installed hacking software on MTC’s systems that gave him access to MTC’s customers’ data.


Would you like to know more about our work?


The author

Graham Fletcher

Graham Fletcher

Associate Partner, New York

Graham, a Certified Information Systems Security Professional (CISSP), has over 30 years diverse experience in IT, specialising in IT Risk and Security project leadership. He is the firm’s competency lead for Technology Risk & Information Security.

graham.fletcher@citihub.com