GoCloudy Blog

Just like accountants have to keep company invoices organized in files and save them from the sun and moisture, IT admins should take good care of logon events and diligently keep them on a big server in an armored dark room. Who knows when and how they might come in handy.

Storing logon events alone is quite a big deal considering the amount of data you have to cope with. But in this post I want to touch on an even more challenging aspect of this – making sense of logon events, which as it turns out can save you from a lot of trouble.

There was a case study published by the Verizon security team that was called on site of one unnamed critical infrastructure company in the US to conduct an investigation of very strange VPN server activity originating from China. As it turned out it was an unnamed employee referred to as ”Bob” who was lazy enough to outsource his work from his office in the US to someone in China and not smart enough to do it in a very straightforward way – ship his RSA token so that outsources could get access to the company’s network on Bob’s behalf.

Giving Bob a credit, his business model has been undetected for several years. The guy is described as “Mid-40s software developer versed in C, C++, Perl, Java, Ruby, PHP, Python, etc. Relatively long tenure with the company, family man, inoffensive and quiet. Someone you wouldn’t look at twice in an elevator”.  So while he was watching cat videos on Reddit in his earned spare time developers in China were checking in the code of an internal application. We can only guess how much review that code received from Bob and how much room was left for introducing malicious code that could have been exploited.

But how did the company not detect for so long this side business of Bob that might have put it at great risk of security exposure?  And how could it have been detected? Logon events are a key. Obviously, Bob was logging to the same corporate network as guys in China he paid to do the job. Obviously, those two events happened to coincide in time more than once. Would not two logon events coming for the same employee ID from different IPs at the same time have looked suspicious to an IT admin had he received report at least once a week? It surely would!  And after reading those reports he’d be one step to tracing down where exactly those logon events were coming from – just take a closer look into the VPN logs.

You might wonder if there is a technology you can rely on to bring similar incidents to your attention and possibly prevent them from happening. Web search results will promptly suggest a battery of SIEM vendors that boast automatic security incident detection and resolution. Although it might pay off for most common patterns of attacker’s behavior, incidents like this one would usually go unnoticed by SIEM. The only practical way to battle those today is to put the right forensics analysis tools in the hands of a human being and let the combination of technology and human brain find the needle in a haystack.

Dell InTrust is a perfect example of such technology. Unlike traditional SIEM solutions it zeroes in on interactive analysis of diverse event data, capturing all aspects of user activity. Thanks to its revolutionary event compression and indexing you can easily sift through billions of event records in a matter of seconds. What is more important is that you won’t have to seek advice of event log experts every time you encounter an unfamiliar event. InTrust and its integration with Dell ChangeAuditor lets you speak the simplified event log language: who did what, when, where and from what workstation.

This is just one of the examples that shows how strong forensic analysis and rich event data specifically around logon activity can save companies a lot of money and even protect its IP. In my next blog post I’ll continue on this topic and share another lesson we learned from the trench.

The post was originally published here.

Tags: auditing, event logs, logons, security breach, Verizon

This entry was posted on February 12, 2013 at 6:25 am and is filed under Auditing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.