Attacks/Breaches
9/19/2011
03:24 PM
John Foley
John Foley
Commentary
Connect Directly
LinkedIn
Twitter
Google+
RSS
E-Mail
50%
50%

7 Lessons: Surviving A Zero-Day Attack

Pacific Northwest National Laboratory CIO Jerry Johnson takes you inside the cyber attack that he faced down--and shares his security lessons learned.

When Pacific Northwest National Laboratory detected a cyber attack--actually two of them--against its tech infrastructure in July, the lab acted quickly to root out the exploits and secure its network. PNNL then did something few other cyber attack victims have been willing to do. It decided to talk openly about what happened.

The lab's CIO, Jerry Johnson, last week provided a detailed accounting of the cyber attacks. Speaking at the IW500 Conference in Dana Point, Calif., Johnson described how intruders took advantage of a vulnerability in one of the lab's public-facing web servers to plant a "drive-by" exploit on the PCs of site visitors, lab employees among them. For weeks, the hackers then surreptitiously scouted PNNL's network from the compromised workstations.

Simultaneously, a spear-phishing attack hit one of the lab's major business partners, with which it shared network resources. This second group of hackers was able to obtain a privileged account and compromise a root domain controller that was shared by the lab and its partner. When the intruders tried to recreate and elevate account privileges, this action triggered an alarm, alerting the lab's cybersecurity team.

Within hours, the lab made the decision to disconnect its network in order to sever the hackers' communications paths and contain any further damage. Over the July 4 weekend, while the rest of us were grilling burgers, PNNL's security team conducted cyber forensics, reconstructed the domain controller, re-imaged systems, and restored network services that had been taken off line.

[ Want more lessons learned from InformationWeek 500 winners? See 20 Innovative IT Ideas To Steal.]

Who was behind the attacks? That's one question CIO Johnson won't discuss. But it's worth noting that Dept. of Energy facilities were reportedly targets in the series of cyber attacks known as Operation Shady RAT that were carried out against more than 70 companies, defense contractors, and government agencies over the past few years. Based on the available evidence, some experts have speculated that those attacks originated in China.

At the IW500 conference, in a session titled "Anatomy of a Zero-Day Attack," Johnson was candid about how the lab responded to the intrusions. He also shared the following list of lessons learned from the experience:

1. There's danger in multi-level security environments. The lab had a well-protected IT security perimeter, but the attacks made it through anyway. An advocate of "defense in depth," Johnson is putting increased emphasis on protecting the data itself.

2. Purge legacy, minority technologies. The Web server in the first attack was based on a little-used technology at the lab, Adobe ColdFusion. Such out-of-sight, out-of-mind technologies are inherently vulnerable because they don't get the same degree of attention as an organization's primary platforms.

3. Monitor cybersecurity events 24 x 7. Advanced persistent threats like those that hit PNNL are just that--persistent--and require constant vigilance. Across federal government, agencies are investing in "continuous monitoring," with a goal of obtaining a near real-time view into the status of computer system security.

4. Maintain a core forensics capability. If your network does get hacked, security teams must be able to reconstruct events and assess the damages. What you learn can help prevent a relapse.

5. Include a senior project manager on your response team. Responding to a breach requires not only attention to detail and carefully coordination, but an ability to engage top management at a moment's notice and, if necessary, escalate decision making.

6. Be prepared to call for help, and don't wait. You may need to bring in security experts, business partners, law enforcement, or other outsiders. At PNNL, Johnson alerted the public affairs office, in order to prepare for the inevitable media inquiries.

7. Have an emergency communications continuity plan. When PNNL pulled the plug on its network, the hackers lost their ability to inflict further damage. Unfortunately, the decision also meant that lab employees lost network services, including email and voice mail. Be prepared for that eventuality by sharing cell phone numbers and alternative email address in advance.

As Operation Shady RAT and a similar cyber attack on Google and other companies demonstrate, the risks are complex and growing. Johnson agreed to talk about it as a way of helping other organizations bolster their defenses. For that, he deserves a tremendous amount of credit. Secrecy is the norm in the wake of a cyber attack, but openness will lead to better preparedness.

Join us for GovCloud 2011, a day-long event where IT professionals in federal, state, and local government will develop a deeper understanding of cloud options. Register now.

John Foley is editor of InformationWeek Government.

To find out more about John Foley, please visit his page.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3341
Published: 2014-08-19
The SNMP module in Cisco NX-OS 7.0(3)N1(1) and earlier on Nexus 5000 and 6000 devices provides different error messages for invalid requests depending on whether the VLAN ID exists, which allows remote attackers to enumerate VLANs via a series of requests, aka Bug ID CSCup85616.

CVE-2014-3464
Published: 2014-08-19
The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) 6.2.0 and 6.3.0, does not properly enforce the method level restrictions for outbound messages, which allows remote authenticated users to access otherwise restricted JAX-WS handlers ...

CVE-2014-3472
Published: 2014-08-19
The isCallerInRole function in SimpleSecurityManager in JBoss Application Server (AS) 7, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 6.3.0, does not properly check caller roles, which allows remote authenticated users to bypass access restrictions via unspecified vectors.

CVE-2014-3490
Published: 2014-08-19
RESTEasy 2.3.1 before 2.3.8.SP2 and 3.x before 3.0.9, as used in Red Hat JBoss Enterprise Application Platform (EAP) 6.3.0, does not disable external entities when the resteasy.document.expand.entity.references parameter is set to false, which allows remote attackers to read arbitrary files and have...

CVE-2014-3504
Published: 2014-08-19
The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Dark Reading continuing coverage of the Black Hat 2014 conference brings interviews and commentary to Dark Reading listeners.