Risk
2/28/2010
01:08 PM
50%
50%

Tech Insight: Preparing Your Enterprise For Cyberwar

Recent attacks prove you don't have to be in government or maintain a critical infrastructure to be a target. Are you ready?

Is your organization ready for a cyberwar?

If your answer is no, then you're not alone. CNN's broadcast of the Cyber Shockwave simulation helped to demonstrate that major government agencies in the U.S. aren't ready to even find the source of such an attack, much less defend against it. And many organizations that play a role in critical infrastructure are even less prepared than those agencies.

You're also not alone if you think a cyberwar probably won't affect your organization. Many enterprises believe that if they aren't directly involved in banking, utilities, or critical infrastructure, then they won't be involved in a cyberattack. But even in the politically motivated attacks we've seen so far, there has been collateral damage. Most recently, theAurora attacks against Google and U.S. companies demonstrated that no company is safe from becoming a target.

McAfee's fifth annual "Virtual Criminology Report" asks the question, "Is the 'Age of Cyber War' at hand?" There's no doubt we're at the brink of that age -- if it hasn't already begun. The simple act of doing business with a targeted company or nation could mean attackers take aim at you tomorrow.

So what should your organization do to prepare? The first step is to have a strong disaster recovery and business continuity plan in place. Being ready to withstand a disaster is good business, noted Scott Borg, director of the U.S. Cyber Consequences Unit, in the McAfee report. Well-prepared businesses stand to gain considerable market share, and "their reputations will emerge from the crisis in better shape than businesses that were less prepared," he said.

Surviving an attack that's part of a widespread cyberwar -- or even a smaller, focused hacktivist campaign -- requires more than just being sure your data is safe and your systems can be resurrected at another site. It's critical to develop a strategy for preventing attacks that are designed to penetrate your perimeter and gain access to sensitive information -- a lesson often learned too late.

Many of the recent politically motivated attacks could have been prevented with existing security tools and controls -- if they were properly implemented. For example, the Aurora attacks targeting Internet Explorer were designed to exploit IE version 6. Unless these were test machines that should have been on a highly restricted network, a good patch management program might have mitigated the effects of the attack.

But patch management is only part of the answer. Aurora also involved zero-day exploits. Shortly after the suspected original exploit code surfaced, new code was developed and released by security researchers that could be used against newer versions of Internet Explorer, bypassing some of the recommended protections. Still, solutions like host-based intrusion prevention systems (HIPS) and application whitelisting could have helped prevent the exploit, or at least a systemwide compromise.

Antivirus vendors have been incorporating HIPS-type of protections into their enterprise antivirus products for several years. Some of those features include preventing new executables from being written to common system directories, buffer overflow protection, and blocking network communications from certain executables.

Working together with patch management, AV, and HIPS, application whitelisting can prevent unauthorized executables -- such as those associated with cyberattacks -- from running. The rules can be based on path, file hashes, certificate, a repository of known goods, or other variables, depending on the solution. Combine application whitelisting with advanced AV, patch management, and HIPS, and you have an extremely powerful defense.

Of course, there are standard "best practices" we should be performing to protect our networks, and any of these could also help against advanced attacks. But the issue always comes down to security versus productivity and functionality. The sad truth is that users almost always end up having more privileges and access than they need, making them an easier target. Far fewer threats would affect your users' systems if they had to prove a business need before they were allowed to access the Web.

Ultimately, it comes down to limiting your attack surface and protecting what's left. When you can do that effectively -- and still being productive -- then you're in a good position to weather possible cyberwar.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2184
Published: 2015-03-27
Movable Type before 5.2.6 does not properly use the Storable::thaw function, which allows remote attackers to execute arbitrary code via the comment_state parameter.

CVE-2014-3619
Published: 2015-03-27
The __socket_proto_state_machine function in GlusterFS 3.5 allows remote attackers to cause a denial of service (infinite loop) via a "00000000" fragment header.

CVE-2014-8121
Published: 2015-03-27
DB_LOOKUP in nss_files/files-XXX.c in the Name Service Switch (NSS) in GNU C Library (aka glibc or libc6) 2.21 and earlier does not properly check if a file is open, which allows remote attackers to cause a denial of service (infinite loop) by performing a look-up while the database is iterated over...

CVE-2014-9712
Published: 2015-03-27
Websense TRITON V-Series appliances before 7.8.3 Hotfix 03 and 7.8.4 before Hotfix 01 allows remote administrators to read arbitrary files and obtain passwords via a crafted path.

CVE-2015-0658
Published: 2015-03-27
The DHCP implementation in the PowerOn Auto Provisioning (POAP) feature in Cisco NX-OS does not properly restrict the initialization process, which allows remote attackers to execute arbitrary commands as root by sending crafted response packets on the local network, aka Bug ID CSCur14589.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.