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.

Was U.S. Government's Stuxnet Brag A Mistake?
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
6/9/2012 | 9:55:53 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
I see both sides to this. In the long run, I am not sure leaking the information matters all that much in terms of national security because many people already assumed the U.S. and or Israel was involved due to the complexity of Stuxnet, its purpose and the fact that there were so many infections in Iran. There certainly is value in keeping capabilities a secret, but I am not sure the discovery of Stuxnet in and of itself (as opposed to recent leaks) wasn't enough to get Iran to ramp up its cyber capabilities the way they have.
Brian Prince, InformationWeek/Dark Reading Comment Moderator
User Rank: Apprentice
6/9/2012 | 6:10:55 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
Obama wants to BLOCK FREEDOM!
User Rank: Apprentice
6/9/2012 | 6:10:01 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
The fact that Stuxnet was injecting commands into the PLC and masking that it was doing so was evidence that it was designed, not for espionage as everyone had believed, but for physical sabotage. The researchers were stunned. It was the first time anyone had seen digital code in the wild being used to physically destroy something in the real world. Hollywood had imagined such a scenario years earlier in a Die Hard flick. Now reality had caught up with fantasy.

GǣWe were expecting something to be espionage, we were expecting something to steal credit card numbers; thatGs what we deal with every single day,Gǥ Chien recalls. GǣBut we werenGt expecting this.Gǥ

User Rank: Apprentice
6/8/2012 | 1:24:23 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
Your comments read like a lot of descriptions I've read elsewhere when speaking of Gen X - so where's the surprise? I will work only if on my terms and with my equipment, I will work only if I can follow my twitter feeds and Facebook, I will work only if we have a matrixed org and multiple bosses so noone actually controls what I do,...
User Rank: Apprentice
6/7/2012 | 9:54:03 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
For starters, the apparent supporters of an administration that outed a CIA agent as revenge for her non-partisan husband's telling the truth about issues related to WMD in Iraq, absolutely unconditionally putting at risk the lives of dozens of operatives throughout the middle East for the "crime" of supporting our interests, probably know a great deal about living in glass houses.

Let's ignore that ranting and look at the hot air du jour from DC. There's an assumption that the Obama administration as an administration is taking personal credit for this in an election year move. It's a given that the critics have just as much electioneering behind their intentions as Obama may have.

My sense is that the "bragging" is for external consumption. Hey you keep going forward we have ways of stopping you and we're not afraid to use them.

As to whether that kind of swagger and bluster is helpful, harmful or neutral there's surely room for debate. It was no secret to anyone that we were involved in developing Stuxnet but its details were not commonly known. If in the process of trying to intimidate Iran we give away any hints that technologists with lesser intentions can use, that will be no good thing.

Let's just hope that things get evaluated at that level in a discussion that's constructive, designed to move us forward not to tear down. I'm not holding my breath that we as a nation are capable of that nowadays.
User Rank: Apprentice
6/7/2012 | 6:59:15 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
I disagree with the conclusion. As the author points out, I think we all knew that the teams involved in creating Stuxnet were the U.S. and Israel because the DNA of the code indicated two teams, huge resources, and significant understanding of the control software for Iran's centrifuges. The prime suspects with those kind of resources and motivation would be Israel and the U.S. So, I would think that would be enough to provide any of the benefits cited in the article--leaving only downside to revealing all of the ingenious details of the exploit. Trumpeting it as a political accolade for the Obama administration's street cred on national security is amateurish in the extreme. Besides, it is pretty clear that, because of the time this took to develop and deploy, it didn't even start during the current administration. So, leaking this AND taking credit for it reveals not only a disregard for classified operations but also an egregious lack of integrity. And it shows our leadership as naive, self-centered, and infected with massive amounts of hubris to put politics ahead of protecting the details of a highly secret operation. Maybe the author thinks that naming the members of the Stuxnet development teams so they can be targeted by Iranian operatives would be even more helpful in building up our reputation as super genious cyberwarfare powers.
User Rank: Apprentice
6/7/2012 | 5:54:12 PM
re: Was U.S. Government's Stuxnet Brag A Mistake?
I guess we needn't be surprised when stones rain through the shattered roof of our glass house. But if there is any blame, give that to Bush. (The disclosure must be his fault, somehow.) However, if there is any credit, give that to Obama. (He's got mad hacking skilz.)

I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
PUBLISHED: 2023-03-27
Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.