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.

Risk

10/13/2009
10:17 PM
George V. Hulme
George V. Hulme
Commentary

RAND: U.S. Should Not Prioritize Cyberwarfare

The think tank RAND came out with an Air Force funded paper that concludes spending money on operational cyberwarfare is a waste of budget. I agree.



The think tank RAND came out with an Air Force funded paper that concludes spending money on operational cyberwarfare is a waste of budget. I agree.InformationWeek's J. Nicholas Hoover covered the report in his story, Cyberwar Readiness Recast As Low Priority:

"Operational cyber war has an important niche role, but only that," the report (.pdf) states.

At best, cyberwarfare operations "can confuse and frustrate operators of military systems, and then only temporarily," the report notes. "The salient characteristics of cyberattacks--temporary effects and the way attacks impel countermeasures--suggest that they be used sparingly and precisely. Attempting a cyberattack in the hopes that success will facilitate a combat operation may be prudent; betting the operation's success on a particular set of results may not be."

I've always considered cyberwar attacks (I'm taking state-backed attacks here, not so much of the rogue nonsense that passes for "cyberwar") to be incremental to physical confrontation: knock out a nation's communications abilities, blind their radar, choke their access to the Internet. Most all of these objectives are best, and most swiftly met, by dropping old fashioned bombs. Also, and this is no small point, the means and methods of cyberwar are already well known and well understood: denial-of-service attacks, breaking crypto, sniffing network traffic, unleashing malware to run wild and disrupt systems, corrupting data, and so on. Military toolsets will be little more than variants on what is already rapidly available on the Internet.

As a nation, we will be better served by getting our act together with a real, substantive strategy to secure the critical infrastructure we so essentially rely: the power grid, financial systems, communications, transportation, and other critical infrastructures.

Unfortunately, such efforts have languished (May 29, 2009: Cybersecurity Review Finds U.S. Networks 'Not Secure') for far too long (September 16, 2002: The Right Balance).

My friend Dr. Christophe Veltsos, in his Dr. InfoSec blog culled a salient quote from the report that speaks directly to my opinion:

Cyberspace is its own medium with its own rules. Cyberattacks, for instance, are enabled not through the generation of force but by the exploitation of the enemy's vulnerabilities. Permanent effects are hard to produce. The medium is fraught with ambiguities about who attacked and why, about what they achieved and whether they can do so again. Something that works today may not work tomorrow (indeed, precisely because it did work today). Thus, deterrence and warfighting tenets established in other media do not necessarily translate reliably into cyberspace. Such tenets must be rethought.

The second part of the quote, as anyone who tracks IT security knows, is all too true. It's difficult to determine the actual source of attack, as attackers are prone to launch their attacks from systems the U.S. Government will never be able to analyze. Why attack from your home country when you can infiltrate systems in China, Russia, Iran to launch your attack? Also, vulnerabilities and exploits in applications and operating systems that work today, may not work tomorrow: upgrades, patches, or completely changing the system will require an over-haul of the attacker's toolbox.

So it's the first part of the quote where we should focus, as a nation, our efforts. That's shoring the vulnerabilities in our critical national IT infrastructure -- power, financial networks, transportation systems, communications -- so that they are resilient from attack.

It's not too much to expect from our government, is it? That it ensures we've built a strong house before we start planning how to knock down those of others?

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Inside North Korea's Rapid Evolution to Cyber Superpower
Kelly Sheridan, Staff Editor, Dark Reading,  12/1/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-29565
PUBLISHED: 2020-12-04
An issue was discovered in OpenStack Horizon before 15.3.2, 16.x before 16.2.1, 17.x and 18.x before 18.3.3, 18.4.x, and 18.5.x. There is a lack of validation of the "next" parameter, which would allow someone to supply a malicious URL in Horizon that can cause an automatic redirect to the...
CVE-2020-5675
PUBLISHED: 2020-12-04
Out-of-bounds read issue in GT21 model of GOT2000 series (GT2107-WTBD all versions, GT2107-WTSD all versions, GT2104-RTBD all versions, GT2104-PMBD all versions, and GT2103-PMBD all versions), GS21 model of GOT series (GS2110-WTBD all versions and GS2107-WTBD all versions), and Tension Controller LE...
CVE-2020-29562
PUBLISHED: 2020-12-04
The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.
CVE-2020-28916
PUBLISHED: 2020-12-04
hw/net/e1000e_core.c in QEMU 5.0.0 has an infinite loop via an RX descriptor with a NULL buffer address.
CVE-2020-29561
PUBLISHED: 2020-12-04
An issue was discovered in SonicBOOM riscv-boom 3.0.0. For LR, it does not avoid acquiring a reservation in the case where a load translates successfully but still generates an exception.