02:13 PM
Becca Lipman
Becca Lipman
Slideshows
Connect Directly
Facebook
Google+
Twitter
RSS
E-Mail

7 Unusual Behaviors That Indicate Security Breaches

Breaches create outliers. Identifying anomalous activity can help keep firms in compliance and out of the headlines.




Here is a rather uncontested statement: In the world of cyber security there are many things that can go wrong.

Some breaches are intentional, other accidental. A case in which an employee unwittingly discloses confidential information, or is working from an infected machine may look similar to the actions of employee who has gone rogue by uploading or downloading inappropriate data.

Regardless of the cause of the behavior, determining if a behavior is normal or not normal is important to catching a variety of security breaches.

Skyhigh Networks compiled real-world examples of behaviors that security teams identified as several standard deviations outside of normal activity.




104,338 tweets from 1 day from 1 IP address. In this instance, a bot was exfiltrating data from a bank 140 characters at a time.

One bank was taken aback by the discovery of malware sending out sensitive information through Twitter - 140 characters at a time. The account was created as a window to send tweets to a machine that presumably stitched the information together. To anyone following the account, it would have looked like gibberish.

In this instance no employees were out of line, and the malware was responding to outside forces.


A retail employee uploads 4.5 GB of files to Kanbox before the employee leaves the organization

Kanbox, a high risk file sharing service, may not be on the radar of security teams.

Rajiv Gupta, CEO of Skyhigh Networks explains in this case an employee was sending out information to an unknown file sharing service that was not blocked by the company. He had gone rogue, and planned to leave the firm. "He had taken out confidential data he knew the company didn't want to him to have, which is why he chose to use unapproved and unmonitored channels."

In this instance, security teams may have noticed the significant size of data being transmitted from the firm.


A single authenticated user at an energy company tried to connect to GoToMyPC 11,101,872 times in a week.

In some cases an infected machine will try to find ways to get information out, but the door is locked. In this example, an infected machine tried to connect to GoToMyPC, a screen sharing service typically used by support staff, over 11 million times. "This is an indicator that it wasn't a human being, says Gupta. "It's probing at the defenses looking for a way to get out."

This bears resemblance to the earlier (and more successful) Twitter example in which malware found an unblocked escape route.


A single IP address at a healthcare company attempts to connect to Facebook, which was blocked, 3.8 million times.

In a healthcare company that blocks employees access to Facebook it is not unusual to see someone make an occasional log in attempt. If they try to do it several times in a week they might be a bit slow on the uptake, but even they had to acknowledge something was unusual when a single IP made 3.8 million attempts in a single week.

In this case some malware was finding its intended exit closed off but continued to try.

The interesting thing here, adds Gupta, is that while it's important to look at the behaviors behind unauthorized information that is successfully sent, it's equally important to look at what didn't get out. In this case, the malware was identified and extinguished.


A manufacturing employee has 188 uploads totaling 48.7 GBs in 1 day to Ryu Share. The data is sent to a Drop Zone outside of the company's jurisdictional location.

This use case requires some attention to detail. For a company that authorizes the use of Ryu Share, an employee sending out 48GBs may not be entirely suspicious, as it could be a large file. However in this instance the average employee sends only a few megabytes a day, making 48.7GBs a noteworthy outlier.

In this case it was due to an employee who had gone rogue, but this behavior could have also been linked to an innocent mistake, an account comprised, or indication that a machine has been infected.


65 KB upload to open source code repository leading to loss of proprietary IP.

Source code in financial services is usually highly proprietary, which helps explain why in 2013 Goldman Sachs criminally charged its ex-programmer for stealing computer code.

He had sent himself 32megabytes of code from Goldman's HFT system to a German source code repository. Debates continue if the programmer's intentions were malicious (probably not), but in the eyes of Goldman the practice of uploading source code was not only bad, but the site it was sent to, SourceForge, has terms of conditions not at all aligned with corporate policy.

In SourceForge, the terms and conditions state all quotes submitted must be certified as an OSI-Approved License. Once uploaded, the code is now open source regardless of how the employee intended its use. "He didn't read the terms and conditions," explains Gupta. "He just wasn't aware they were so onerous."

 

Becca Lipman is Senior Editor for Wall Street & Technology. She writes in-depth news articles with a focus on big data and compliance in the capital markets. She regularly meets with information technology leaders and innovators and writes about cloud computing, datacenters, ... View Full Bio

Comment  | 
Email This  | 
Print  | 
RSS
More Insights
Copyright © 2017 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service