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?

Scott Montgomery, VP and CTO-Americas & Public Sector, Intel Security

March 12, 2016

3 Min Read
Dark Reading logo in a gray background | Dark Reading

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?

About the Author

Scott Montgomery

VP and CTO-Americas & Public Sector, Intel Security

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 technology, standards, and implementations meet information security and privacy challenges. His dialog with the market helps him drive government and cybersecurity requirements into McAfee's products and services portfolio and guide Intel Security's policy strategy for the public sector, critical infrastructure, and threat intelligence.

With more than 15 years in content and network security, Montgomery brings a practitioner's perspective to the art and science of cybersecurity. He has designed, built, tested, and certified information security and privacy solutions-including firewalls, intrusion prevention systems, encryption, vulnerability scanners, network visibility tools, mail and web gateways, strong authentication tokens, embedded systems, and more. Prior to its acquisition by McAfee, Montgomery ran worldwide product management and corporate strategy for Secure Computing, designing and building products like Sidewinder (now McAfee Firewall Enterprise), Webwasher (now McAfee Web Gateway), and Ironmail (now McAfee Email Gateway).

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights