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.

Partner Perspectives  Connecting marketers to our tech communities.
3/11/2016
03:05 PM
Scott Montgomery
Scott Montgomery
Partner Perspectives
50%
50%

Who Took The Cookies From The Cookie Jar?

The indictment of five Iranian hackers three years after the fact raises the question: Is naming them a worthwhile part of the threat defense lifecycle, or is it a meaningless distraction?

This week, the US Justice Department announced an indictment has been prepared for five Iranian hackers allegedly responsible for the breach of systems at a small Rye, NY, water dam. This development prompts two lines of thought at Intel Security:  Is this after-the-fact attribution, also called “name and shame,” a worthwhile part of the threat defense lifecycle, or is it a meaningless distraction? 

Let’s try and explore both sides.

Attribution Helps

Information security and privacy practitioners have been long warning against the potential impact of Internet-driven attacks against critical infrastructure such as the recent incursions into the Ukraine power grid where 80,000 were without power for six hours. There was also the foundry incident in Germany where a cyberattack inflicted greater than $1 million in physical damage to the facility. Our growing dependence upon Internet-enabled devices to ensure operational efficiency and reduce costs has created opportunities for our critical infrastructure to be subjected to remote manipulation and disruption.

The Justice Department indictment will name five hackers who “probed” the Bowman Avenue Dam using a cellular modem attached to the dam’s sluice gate. The DoJ “naming and shaming” indictment drew dozens of top-tier publications and networks to respond within hours of the news, thereby raising public awareness that our use of the Internet potentially increases critical infrastructure risk. 

In theory, this in turn creates a teaching moment, so while respecting the need for operational efficiency that the Internet offers, as a society we become more mindful that enabling that efficiency must be tempered with security and privacy considerations.

Attribution Is Irrelevant

Who took the cookies from the cookie jar?

Iranians took the cookies from the cookie jar!

Who, me?

Yes, you!

Couldn’t be!

Then, who?

If someone has taken your cookies from the cookie jar via the Internet, knowing who it was after it’s long over doesn’t help you at snack time.    

Reflecting upon the length of time it took to determine attribution to Iran, Sen. Steve Daines (R-Mont.) commented, “It is downright shameful that it has taken President Obama three years to denounce Iran for a malicious cybersecurity attack on our country.”

Partisan rhetoric aside, what is the actual value derived three years later? The attackers can deny involvement as digital attribution is a difficult thing to prove.  The attribution doesn’t make any other critical infrastructure networks any more secure, the indicted are unlikely to ever be arrested or prosecuted, and a titillating headline serves only to distract us from the core problem:  It is extremely likely that other critical infrastructure networks around the world are just as vulnerable as the Bowman Avenue Dam. 

This is akin to a driver taking his eyes off the road to look at the car crash that caused a highway traffic slowdown -- he has become inherently part of the problem by not focusing on the task at hand.

Is there a happier medium? 

At Intel Security, we believe these teaching moments should be focused on keeping our eyes on the road.  Knowing who bad drivers are may help you avoid a future crash, but it isn’t paramount immediately after you’ve just been wrecked. You’ve got different problems to resolve. 

Let’s look at this particular situation from the teaching moment standpoint:

  • Why was the control system for the sluice gate connected directly to a cellular modem? 
  • Could the control system be separated from the Internet by a firewall? 
  • Could strong authentication mechanisms be employed rather than using a fixed password? 
  • Could the modem itself be configured in a way that either limits who could connect or how its services are advertised to the Internet? 

Most importantly, could we create a checklist that other technically limited critical infrastructure organizations could use to avoid their own disaster at snack time?

Scott Montgomery is vice president and chief technology officer for the Americas and public sector at Intel Security. He runs worldwide government certification efforts and works with industry and government thought leaders and worldwide public sector customers to ensure that ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
jeancharles
50%
50%
jeancharles,
User Rank: Apprentice
5/5/2017 | 11:48:05 AM
thank's
Why not !!!
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25596
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. T...
CVE-2020-25597
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. Howeve...
CVE-2020-25598
PUBLISHED: 2020-09-23
An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar...
CVE-2020-25599
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory a...
CVE-2020-25600
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains...