One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it. Snowden may be the most well known of these types of incidents, especially in the US.
Related to this is the ex-Insider. Someone who used to work for you and no longer does. They also know where the data is, what controls you have, and may know passwords to access the data. When someone leaves, can you be sure that their access to data has been revoked?
A recent story can highlight what happens if a privileged insider is let go, but his access not fully revoked.
So how can we defend against this sort of malicious ex-Insider?
Network access
If you can’t get access to the network in the first place then it’s a lot harder to attack servers and services!
This person gained access via a VPN. It’s not stated, but looking at the indictment it seems as if this person had a company Cisco Linksys router; likely this was preconfigured to connect to the corporate VPN automatically, and this was disabled
- Lesson: Ensure all remote access solutions for an ex-Insider are terminated immediately. If this is a user based VPN where the user needs to enter their username and credentials then ensure those credentials are terminated; if this is a device based VPN then ensure the device’s access is revoked.
Now a truly malicious person could have planned ahead and created their own backdoor network; eg a process on a server that makes outgoing tunnel requests via the web proxy, or a piece of software installed on a secretary’s desktop, or even a small device that plugs into the network (these can be so small now that they can plug in to a desktop port, and the real desktop PC plugged into that, and if you’re not looking carefully then you’ll never spot it). There are lots of ways that remote access malware can work; your malicious ex-Insider could use any of these.
So although we can control the front door, we can’t always determine if there’s a rogue backdoor. So we need further protection
Connecting to a server
Personal accounts
Typically you need to provide a credential to login to a server! If “Jim” wants to login, he’ll normally login with the “jim” account. So we need to make sure that Jim’s account is deleted. Many regulatory authorities use the word “immediately”, but in practice this may be triggered by the HR system and processed in batch overnight. However you need to have a manual process to perform emergency removals just in case that batch process is too slow. This, of course, means you need a good Identity and Access Management (I&AM) program. Whether you use Active Directory (and hook your Unix machines into that) or LDAP or even distributed password files, doesn’t matter; you need to manage them
- Lesson: Delete ex-Insider personal accounts ASAP
Shared accounts
Even if you delete Jim’s account, does he know the passwords for any
other accounts? Does he know the root account password? You better
change that. What about the oracle account? sybase? The account
your application runs under? Your router admin passwords?
These non-human “functional” accounts are a common weak point. They’re all privileged accounts, but the password is commonly shared amongst team members. If you have a good I&AM program then you may be able to change these passwords… but are you sure you know where they all live?
Ideally these accounts should have passwords stored in a password vault, requiring a “break glass” process if any human ever needs to know them; this process will change the password within a few hours of a human being told what it is.
Alternatively a “privileged access” gateway may be used; this can use the vault to automatically log a user in (using the user’s own 2FA credentials) and audit their activity. Now no human ever needs to know the password.
- Lesson: Stop sharing passwords for functional accounts. Use a good privileged access management program to ensure that the ex-Insider’s knowledge expires quickly.
Alternate credentials
Not all login access is done via passwords. A common alternative is to use SSH public key authentication. This brings in a new set of challenges. Our malicious ex-Insider may have planned ahead and added his keys to another person’s account. Now, when Jim is terminated, he can use these keys to login as Harry. As far as the system is concerned, this is Harry. Deleting Jim’s account doesn’t help, now!
- Lesson: Ensure any alternate authentication tokens are properly managed. If you’re using SSH public keys then you may want to look into a key manager solution to ensure that “rogue” keys haven’t been added.
Local “rogue” accounts
Related to rogue credentials, we may also have rogue accounts! It’s not too unusual for a lazy SA to create a second privileged account (“jimroot”) which he can access, bypassing the privileged access management system. They justify this to themselves as an efficiency gain (it is!) but it shouldn’t be allowed. However our malicious ex-Insider may also have planned ahead and created some of these accounts.
- Lesson: A full I&AM system must also be able to track and audit any local accounts created outside of the central tool. They should be handled appropriately (deleted? disabled? brought into central control?) and shouldn’t be allowed to be kept uncontested.
Control systems
Typically environments also have non-PC/non-server environments. You may have IP telephony; your door access systems may be network connected; your building temperature control systems may be networked; your industrial control systems may be networked (see Stuxnet). Many of these systems can’t be controlled the same way as your servers and desktops; they’re not smart enough to hook into centralised systems or may have low-entry PINs that are shared. Such systems should be firewalled off from the main network and protected by strong “jumphost” servers, which may require 2FA to ensure the authenticating user has permission to access the device (and also log their activity)
- Lesson: Weaker devices should be network segregated and protected.
Summary
I’ve only covered a small subset things that can be, and should be, controlled. By focusing on this area (I&AM, Privileged access, jumphosts) we can mitigate a lot of the risk of an ex-Insider. At the same time we’re also mitigating the risk of a current insider attack because we’re handling privileged access at the same time!
This isn’t to say we shouldn’t also have additional controls in place around server changes (stop a malicious insider from planting bad code), network access controls, external gateway monitoring (web proxies; DNS servers; etc). There’s a lot that can be done there as well.
The number one control is to stop an attacker from getting a foothold on your network at all. However if that does happen (and it will happen) then we can make sure that we have secondary controls, such as proper I&AM systems, to limit the attack - especially from an ex-Insider.