Redefining the insider attack
After all, how do we define the “inside” when most of our resources are stored outside of the local network, in some cloud provider’s data center? In the security space, an insider is generally understood to be someone who has valid (not stolen) credentials and is authorized to access particular systems or files. On an internal network, this would include users and IT personnel who have access to users’ computers and data for administrative purposes.
In the cloud, those same people would still be considered insiders (even when the systems and information to which they have access is residing in a different physical location – just as an employee who logs onto the company’s internal network from home or a hotel or mobile device is still an “insider”). However, we have to add a whole new and additional layer of insiders to the mix: those who work for the cloud provider and have physical or remote access to the servers and the data stored on them. This makes the prevention and detection of insider attacks even more of a challenge in a cloudified environment.
Sometimes an insider attack is perpetrated by someone who isn’t exactly an insider, at least at the time of the attack. A disgruntled former employee – whether of your company or of the cloud provider – who comes back to wreak havoc with your data after being fired would also generally be classified as an “insider.” This can happen even when everyone has been diligent about decommissioning the user accounts, if said employee happened to be technically savvy enough and premeditative enough to have installed back-door access while still employed with the organization.
Realities of the insider threat
An insider is, by definition, a trusted entity. We all like to think that those we trust are, in fact, trustworthy; it’s much easier to accept that a faceless, nameless hacker “out there” somewhere is malicious enough to infiltrate our networks and steal our information or bring down our applications than to think that it was done by someone in our own organization or in the company to which we entrusted our business. This natural tendency toward denial works to the benefit of malicious insiders since it means we won’t be as quick to suspect them.
Another reason that the insider threat is particularly insidious is because an insider usually has two things that an outside hacker usually doesn’t have as much of: time and knowledge. The insider has plenty of time to plan the attack, to think about different approaches, to poke around and discover where the vulnerabilities are, when an attack is least likely to be immediately detected, and so forth. An outside needs to get into and out of the network quickly before the “foreign” presence is spotted.
Ironically, although insiders have more time to leisurely go through files and find the “good stuff,” they often don’t need as much time as an outsider to get away with the goodies or cause the desired damage. The insider knows more about the company, the people who work for it and where the valuable data is most likely to be, and doesn’t have to waste time looking at files or slogging through systems that aren’t useful for his/her purposes.
Countermeasures for a two-pronged problem
In a cloud based infrastructure, we have to look at the insider threat as two related but slightly different threats that are addressed in different ways. When the insider is a member of the customer organization, the threat and its countermeasures are much the same as in a traditional data center environment. However, when the malicious insider is an employee of the cloud provider with administrative privileges, we have to take a different tactic.
A big problem is that it is very difficult to detect a breach on the client side, when the public cloud administrator has physical access to the servers and you, as a remote admin working for the customer organization, don’t. You might not even have any idea where the servers running your infrastructure are geographically located since some providers keep this information secret for obvious security reasons.
Encryption is the most common way to protect sensitive data, but it’s not as effective in regard to insider attacks. If the encryption key is stored in the cloud, it could be exposed to the cloud provider admins, and those who can physically access the servers would even be able to access the machines’ physical memory and discover information that is stored (decrypted) in RAM, including encryption keys that are stored in memory. One solution, when providers have multiple data centers in different regions, is to store the keys in a different physical location.
Of course, much more can be done on the side of the provider to help prevent insider attacks originating with their employees. These include a division of responsibilities and strict application of the principle of least privilege to provider admins, extensive logging and auditing of administrative actions and security tools that look for and detect patterns indicating suspicious activity.