Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Operations //

Identity & Access Management

1/8/2015
04:30 PM
Connect Directly
Twitter
RSS
E-Mail
100%
0%

How NOT To Be The Next Sony: Defending Against Destructive Attacks

When an attacker wants nothing more than to bring ruin upon your business, you can't treat them like just any other criminal.

You know to include the threat of financially motivated cybercriminals in your risk profile. Done. But what about the ones who don't want money? The ones who just want to hurt you. How do you defend against and recover from attackers whose sole goal is to destroy?

Destructive attacks -- like the one at Sony Pictures Entertainment -- are personal. They're done by someone with a grudge: a disgruntled insider, an outraged hacktivist, a nation that sees the target as an enemy of the state.

Destructive attacks are also, in many ways, easier to do.

"If your only goal is to do damage," says Jonathan Sander, strategy and research officer for Stealthbits Technologies, "you don't need a lot of access."

As some security experts have said, the Sony attackers could have compromised the company with just a humble phishing message, then planted the wiper malware and let it take it from there. Malware is quite good at proliferating itself, so the hackers could simply sit back and watch. Watch as the malware deleted all the company's data and turned its hardware into expensive paperweights.

The Sony hackers opted to first burrow deeper into the network to access and exflitrate huge amounts of data -- intellectual property, regulated personally identifiable information, incriminating emails, and the details of the company's entire IT infrastructure. Instead of selling it, the attackers simply uploaded the whole lot to Pastebin where anyone could see it, damaging the company in another way.

Why and who? That's still up for debate. In the case of Sony, the US government's official word is that the attack was carried out by North Korea's cyberwar unit, in retaliation for Sony's production of The Interview, a comedy about assassinating North Korean leader Kim Jong-Un. Yesterday, FBI Director James Comey provided a bit of evidence supporting that assertion and Director of National Intelligence James Clapper went so far as to name a specific North Korean general. 

Others say that even if it was North Koreans, they might have worked with an insider. Last week, researchers at Norse Corp. asserted that a disgruntled insider was definitely involved. As Dark Reading's Kelly Jackson Higgins reported:

Interestingly, however, the FBI's statement specifically calls out North Korea for "theft and destruction" of data. Missing from that attribution is the initial intrusion into Sony's network and servers -- the phase researchers from Norse think may have occurred with the assistance of a former Sony employee with an axe to grind.

The example of a nation-state administering digital punishment for a Seth Rogan / James Franco movie is not likely to repeat itself -- so rather than trying to defend against such an attack, an organization is better served planning how to respond to a mega-destructive incident.

The threat of malicious insiders looking to stick it to their current or former employers, on the other hand, is all too common. Security experts say there are plenty of ways organizations can protect themselves against that.

 

The Malicious IT Insider

Businesses now have all sorts of tech rigged to detect intrusions and strange behavior, and issue alerts when something is awry. But what if the person receiving those security alerts is the very person causing them? The disgruntled IT security staffer is perhaps the worst threat of all. 

Sander says that organizations may contain a threat by managing user access privileges and "box someone in so that they can only do so much damage. Organizations are pretty good at doing that at the application level," but not at the data level, he says -- unstructured data in particular.

To do their jobs, IT staff do need administrator access to the IT systems / applications, but don't need to access the data, says Sander. "There's no reason an Exchange admin needs to read my email," he says. "And why should IT ever touch HR files?"

Companies think about prohibiting access to systems, but attackers don't want systems, they want  data. And attackers aren't stopped by your hardened tech, because they've got another way in.

"Hackers are usually focused on the user, not the system," says Gaby Friedlander, co-founder and CTO of ObserveIT, "but organizations are usually focused on the system, not the user. So hackers can go in through the front door."

Malicious IT staff have it even easier, because they're already inside. That's why Friedlander says that organizations need to protect themselves by constructing user profiles, and watching for behaviors that are suspicious for that user; not just relying on a list of static rules and red flags.

"The IT guys know those rules," says Friedlander. "They can easily bypass them."

The point, says Sander, is not to mistrust your employees. The point is to entrust them with all the access privileges they need to do their job, and no more.

John Gunn, vice-president of corporate communications at Vasco, adds that measures like behavioral analysis are important, because a happy insider today may not be happy tomorrow. "Even the right person can become the wrong person," he says.

For all of these reasons, appropriate separation of duties is essential. An insider with all the keys to the castle is an enormous threat. An insider who only has a key to the castle datacenter is less of a threat.

Replication of duties is also important. If there's only one guy receiving security alerts, and he goes rogue, nobody finds out he's up to no good. If there are two or three people receiving those alerts, the chances of detection are much greater. Sander points out that a smaller company may not have the manpower to do that, but they should if they have the resources to do it. 

Compounding the problem, says Friedlander, is that incident alerts are not always provided with enough context or forensic evidence, so the department "deals with it as an IT problem, not a security problem." The helpdesk may "solve" suspicious activity by simply resetting a password, without investigating why that password needs to be changed. 

Mind you, none of these measures necessarily prevent the destruction of hardware -- deploying wiper malware, shooting servers with a machine gun, or throwing all your back-ups onto a bonfire. However, they do make it more difficult for a malicious insider to damage a company by deleting or disclosing essential corporate data.

 

Respond and Rebuild

Incident response after a destructive cyber attack -- particularly one at the scale of the Sony super-mega-ultra-destructive one -- may need to be approached more like a physical disaster (flood, explosion, etc.) than a digital one.

When Hurricane Sandy (AKA Superstorm Sandy) hit New York City and New Jersey, buildings were destroyed, lives were lost, roads were closed, and power and telecom lines were down for weeks. During that period, government workers in New Jersey were communicating through an emergency radio system. They were sitting in their cars, updating emergency info on government websites via their personal mobile phones, plugged into car chargers.

Replication of duties were important too, so that essential functions could be still be conducted, even if the usual point person was without power, or in a hospital or evacuation center.

Although the Sony incident was not a disaster of that caliber, it did present some of the similar challenges. It left the company without client machines, email, VoIP, or any of the other usual communications technology.

Further, when a cyber incident occurs, fingers may be pointed, eyebrows raised, and questions asked about whether a malicious insider was involved. Was it a disgruntled ex-worker who has left more timebombs? Is that person still within the company? 

That's a scary proposition. Sony really needs to rebuild from scratch, since every detail of their IT infrastructure was publicly exposed. If one of the culprits could still be working within the company, do you want to involve them in the rebuild process? Or should that all be outsourced to a third-party without a dog in the fight?

"Frankly the only difference is a matter of culpability," says Sander. If there's another devastating destructive attack, do you sue the service provider or chop off heads inside the company? "You can make a case for either."

As for the post-incident public relations, "You can see the pattern," says Gunn. "'We're investigating a possible breach,' which means they know they've been hit." Then they confirm they were compromised, in a manner that was completely unprecedented. "'It wasn't our fault! It was like a meteor hitting!'"

 

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
1/9/2015 | 9:11:26 AM
Re: because...
Super analysis, Sara. Your analogy about aproaching destructive attacks more like a physical disaster (flood, explosion, etc.) than a digital one is really apt. And what happened to Sony presents an object lesson in what needs to be in place to support essential services while the damage is being contained. 
McDaveX
100%
0%
McDaveX,
User Rank: Strategist
1/9/2015 | 5:32:24 AM
because...
Every attack was "unprecidented". Even if its the third time you were compromised by the same unpatched bug. :)
<<   <   Page 2 / 2
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-9717
PUBLISHED: 2019-09-19
In Libav 12.3, a denial of service in the subtitle decoder allows attackers to hog the CPU via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c has a complex format argument to sscanf.
CVE-2019-9719
PUBLISHED: 2019-09-19
A stack-based buffer overflow in the subtitle decoder in Libav 12.3 allows attackers to corrupt the stack via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c misuses snprintf.
CVE-2019-9720
PUBLISHED: 2019-09-19
A stack-based buffer overflow in the subtitle decoder in Libav 12.3 allows attackers to corrupt the stack via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c misuses snprintf.
CVE-2019-16525
PUBLISHED: 2019-09-19
An XSS issue was discovered in the checklist plugin before 1.1.9 for WordPress. The fill parameter is not correctly filtered in the checklist-icon.php file, and it is possible to inject JavaScript code.
CVE-2019-9619
PUBLISHED: 2019-09-19
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.