Article on German Steel Mill Attack “Inside Job” is Just Hype

On Sept 9, 2015 an article posted on Industrial Safety and Security Source ran with the headline “German Steel Mill Attack: An Inside Job”. The first statement of the article states “The attack on a German steel mill last year was most likely the result of an inside job” – this is blatantly false. There simply isn’t a lot known about the attack as Germany’s BSI have never publicly released follow on details about the incident after their 2014 report nor has the victim. There is no way to assert any theory as being “most likely” and unfortunately this article used what has become a common practice in our industry – anonymous sources and other false reports.

As an example, the article tries to link Havex to the incident without any proof. In talking about the malware it states: “Trojanized software acted as the infection vector for the Havex virus, according to sources interviewed by ISSSource.” The problem with this is that there was no reason to use anonymous sources here or act like this is a revelation. It is well known through the analysis of actual samples that Havex used trojanized versions of software. No sources are needed to reveal what is revealed by a simple Google search. But it makes the story seem more mysterious and tantalizing to use such sources.

The article then compares the steel mill attack to Shamoon claiming that “former CIA officials” claimed the attack was also an insider threat. It directly follows this by stating that an anonymous congressional source had a suspicion that an employee at the steel mill on the payroll of a foreign government was responsible. Following this as a quote from an individual stating “I have heard indirectly that the attack was attributed to the Russians.” And of course following this there is talk of “cyber war”, more anonymous CIA officials, and references to the cyber attack on the BTC Turkey pipeline in 2008 – which the author of the article failed to realize has already been proven as a false story. Reports need to realize that incident responders with first hand experience, engineers and personnel on site during the incident, or people directly involved are impressive sources – “senior intelligence officials” or “congressional sources” are far from impressive – they are some of the most removed personnel from what happened, especially in an ICS incident, and thus the information they have is very likely unreliabile.

Statements in the article such as an anonymous CIA official stating “In all likelihood, it was the Havex RAT that was the culprit, but we lack proof of this” should have killed this article before it went to print. Anytime all the sources in an article are using gossip, rumors, and admitting there is no proof – it’s time to realize there’s nothing to publish.

The reason for me writing this blog about this though is that there are a large number of people in the industrial control system community who will read this article. In many cases it will be their only insight into this story. And not only will they be misinformed about the steel mill incident but they’ll also now believe the BTC pipeline story was real. There is a real threat in industrial control system community – the threat of hyped out and false news stories misleading the community.

Hype has a lasting effect on any community. In the ICS community it pushes folks to not want to share data that we need to understand the threat in fear that it will be twisted into click bait. It encourages organizations to invest resources against threats that aren’t real instead of the numerous well documented threats and issues in the community that do need invested in. It forces non-security community members to tune out everyone in the security community when they realize they’ve been misinformed. The ISSSource article is not the first or worst case of hype seen in the community but it is another addition in a long line of articles that threatens good discussion, measured responses, and proper resource investments that could otherwise help ensure the safety, reliability, and security of infrastructure.

This post originally appeared at RobertMLee.org.