Published on May 2, 2013
Insider attacks aren’t new. The very first sysadmin probably didn’t go rogue, but it wasn’t very long after him that the first one did. The reason these are among the most problematic attacks are obvious – these are the most trusted users, who, in order to be able to do their jobs, have a level of access and permissions that is much higher than other employees – even higher than the the executives who founded and run the organization. But in the last few years, as hacking has become profitable, political and even a key part of the clandestine intelligence operations of many nations, the temptations and incentives for IT technicians, administrators, engineers and architects to use their skills and permissions to commit fraud, theft and espionage are greater than they have ever been.
And, as responsible information security professionals, we spend a lot of time thinking about how to protect against this unique threat. Obviously, the nominal starting point, the network perimeter, isn’t important in this case – we don’t want to keep these users out, we just want to identify the ones that go bad, and prevent them from doing major harm. Since their job is to make changes to the network, install hardware and software, change configurations and facilitate other employees access to data and resources, it’s going to take a LOT of intelligence to understand the difference between a catastrophe and another day at the office.
But there’s another thing we need to think harder about – exactly who are these insiders? Oh, sure, we know about the IT people, the support techs, the database and application people. But in these days of distributed computing and virtualization, you can have servers running in data centers all over the world, many of which have techs that you’ve never met, never vetted and don’t even know their names. A comprehensive understanding of your organization’s infrastructure is critical, but if we were to be honest, that infrastructure can be so dynamic and fluid that it may be an utterly forlorn hope. And if we find ourselves, once again, addressing security problems AFTER they have occurred, we are still in that traditional reactive mode, cleaning up the mess after the criminals have left and that is only if we actually get to learn about the attacks.
The story of Eric Gunnar Gisse is instructive on this point. Just another mid-level admin at Hostgator, he installed a backdoor process on almost 2800 physical servers, representing an unknown number of web, application and database servers. Using the backdoor he installed a stolen SSH key, allowing him to then gain root access to any of those servers from anywhere in the world. We know about this, because he was caught and arrested, but it gives us an opportunity to ask a very specific question: Would our existing security infrastructure have detected Eric’s rogue activities before they became a problem?
One of the powerful capabilities of the Securonix security intelligence platform is in its ability to provide more accurate and fine-grained behavioral profiles and peer group analyses. If it had been running at Hostgator, for example, the installation of those backdoor processes would have been flagged as a suspicious outlier, and could have been investigated as soon as the activity began. And certainly the use of an unauthorized SSH key would have given away the game immediately. The lesson here is not that insider attacks are hard to detect – we already knew that. The important takeaway is that “insiders” may not actually BE inside, but might be anywhere on the globe. And the question about the sufficiency of our existing security stack needs to be answered with brutal honesty – Organizations must elevate their capabilities to support full actionable security intelligence such as the ones offered by Securonix.