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
New Best Practices for Secure App DevelopmentThe 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.
The u3d plugin 126.96.36.19909 (aka plugins\U3DBrowser.fpi) in FoxitReader.exe in Foxit Reader 188.8.131.5226 allows remote attackers to cause a denial of service (out-of-bounds read) or obtain sensitive information via a U3D sample because of a "Read Access Violation near NULL starting at FoxitReader...
The u3d plugin 184.108.40.20609 (aka plugins\U3DBrowser.fpi) in FoxitReader.exe in Foxit Reader 220.127.116.1126 allows remote attackers to cause a denial of service (out-of-bounds read) or obtain sensitive information via a U3D sample because of a "Read Access Violation starting at U3DBrowser+0x00000000...
The u3d plugin 18.104.22.16809 (aka plugins\U3DBrowser.fpi) in FoxitReader.exe in Foxit Reader 22.214.171.12426 allows remote attackers to cause a denial of service (out-of-bounds read), obtain sensitive information, or possibly have unspecified other impact via a U3D sample because of a "Data from Faul...