IRONGATE Malware – Lessons Learned for ICS/SCADA Defenders

June 2, 2016

I first posted this blog on the SANS ICS blog here.

 

FireEye uncovered a new piece of ICS malware that they released today and their way of approaching it both to the public and in pre-briefing to the media has been outstanding. The malware is not in the wild, is not a threat to the industry, but offers lessons learned and I believe the FireEye/Mandiant team’s handling of it deserves a good nod. This blog post will explain the background context to the malware, the details of the malware with my thoughts, and why it is important.

Background
On April 25th I noticed the S4 European agenda noted that Rob Caldwell of the Mandiant ICS team would be doing a presentation on new ICS malware. I posted the blog here with some thoughts on what this meant for the community. Personally, I’m excited about DigitalBond’s inaugural ICS conference in Europe (the long running S4 in the US and Japan has always been a valued contribution to the larger community). I will offer one small critique though that is not meant to be negative in tone. The DigitalBond website lists that the malware is in the “wild”; the ICS malware that Mandiant released details about this morning, titled IRONGATE, is not in the wild, in my opinion. “In the wild” does not have a strict definition so I don’t think DigitalBond did anything wrong here, they were being extremely good stewards of the community to bring this information forward but when I consider malware “in the wild” I look for something actively infecting organizations. I was fortunate enough to exchange messages with Dale Peterson, who runs DigitalBond, and his understanding of the importance of the malware while avoiding hype matched my own. Shortly stated, he is spot on with his approach and I’m looking forward to the presentation on the malware at his conference. It is important to keep in mind though that this malware is more of a proof-of-concept or a security research project but still important. I will cover these details in the next section though.

After posting my blog I was able to get some insight into the malware from the Mandiant team under an embargo. I normally wouldn’t talk openly about the “behind the scenes” discussions but I want to call attention to this for a very heartfelt kudos to the Mandiant ICS team. I’m not a journalist and in no way could help the FireEye/Mandiant public relations (PR) effort with regards to the malware they were releasing. Like it or not this kind of PR has value to companies and so capitalizing on it is a big motivation to any company. But they wanted to run their analysis by me for outside critique. This is a lesson many companies would benefit from: no matter how expert your staff is it is always valuable to get an outside opinion to ensure you are defeating biases and groupthink. Luckily for both the Mandiant team and myself I was excited about their thoughts. They called attention to why the malware was important but were careful to note that it is not technically advanced, it is not an active threat, and that there should be caution in overhyping the malware itself.

Details on IRONGATE
IRONGATE is the name for a family of malware that the FireEye Labs Advanced Reverse Engineering (FLARE) team identified in late 2015. The malware targets a simulated Siemens control system environment and replicates the type of man-in-the-middle attack seen in Stuxnet. The man-in-the-middle attack allows it to record normal traffic to a PLC and play it back to an HMI. It has a number of decent capabilities like anti-Virtual Machine checks and Dynamic Link Library (DLL) swapping with a malicious DLL. In many ways it looks like a cool project although not technically advanced. The most important aspect of the malware itself is that it shows the interest and understanding of impacting ICS by the authors. The full report by FireEye has a good coverage of the malware. Moving past the technical paper though there are a few key points to extract out about the malware itself. The following is my analysis and should not be considered definitive:

  • The malware is the payload portion and not the delivery mechanism; the delivery mechanism has not been identified and likely does not exist. The malware looks to me as a research project, penetration testing tool, or a capability developed to test out a security product for ICS networks. This means it is standalone and I do not believe we will ever see it or a derivative in the wild although we may see the tactic it displayed in a different capability by different authors in the future
  • The main portions of the malware are written in Python and Mandiant identified the malware by searching VirusTotal. While the discovery of the malware was in 2015 the malware was submitted through the web interface (not automatically through an API) in Israel in 2014. The combination of a manual upload, the malware not being in the wild (e.g. actively infecting sites), and the tool being written in Python against a simulated environment makes me think that the malware is a penetration testing or security product demo tool and not a proof-of-concept for a capable adversary. Generally speaking, APTs do not normally write tools in Python and submit them to VirusTotal
  • The malware’s attention to ICS and its focus on mimicking capabilities present in Stuxnet reinforced what many of us in the community knew: ICS is a viable target and attackers are getting smarter on how to impact ICS with ICS specific knowledge sets. The unique nature of ICS offers defenders many advantages in countering adversaries but it is not enough. You cannot rest on the fact that “ICS is unique” or “ICS can be hard to figure out” as a defense mechanism. It is a great vantage point for defenders but must be taken advantage of or adversaries will overcome it.

With what appears to be a bit of downplaying the malware the question remains: is this important and why? The answer is: yes it is important.

Why Is This Important?
I’m personally not a huge fan of naming malware, especially malware not in the wild, so I will admit I’m not crazy about naming this tool “IRONGATE” but this is the state of the industry today and I would expect the same out of any security company. The malware is not in the wild and in my opinion looks more to be a research tool than it does a bearer of things to come. So why is it important? Simply put, we do not know a lot about the ICS specific capabilities and malware in the community. In other words: we do not have much insight into the ICS threat landscape. We often have overhyped and inaccurate numbers of incidents in the community (Dell’s 2015 review stating there were hundreds of thousands of ICS cyber attacks) or abysmally low numbers (the ICS-CERT’s metrics of ~250 incidents a year which are primarily reported from the intelligence community and not asset owner themselves). Somewhere in between those two numbers is the truth pertaining to how many cyber incidents there are each year in the ICS community. A much smaller portion of those incidents are targeted espionage, theft, or attacks. And yet we only know of three ICS specifically tailored pieces of malware: Stuxnet, HAVEX, and BlackEnergy2. Over focusing on the malware instead of the human threats who intend harm is a mistake. But malware is still the tool of choice for many adversaries. So learning about these tools and the tradecraft of adversaries is extremely important. Yet we are lacking insight into those data sets. This makes the IRONGATE malware more interesting in the ICS community than it would be in an IT security discussion.
Here are, in my opinion, the three most important takeaways from this piece of malware.

  1. The malware was submitted in 2014 to VirusTotal and no security vendor alerted on it. Against dozens of security products none flagged this as malicious. It was written in Python, had a module titled scada.exe, and was obviously malicious yet no product flagged it. If ICS related malware is sitting in public data sets undiscovered by the vendors who focus entirely on detecting malware then you can be sure that there is malware in ICS environments today that we have not even begun to identify and understand.
  2. The Mandiant ICS team at FireEye released a number of pieces of technical information such as MD5 hashes and sample names for the pieces of this malware family. Although I disagree in calling them indicators of compromise (IOCs) because nothing was compromised, the technical details are an important exercise. With this information, could a standard ICS organization search through the network traffic and host information for matches against this malware? I would state that the significant majority of the industry could not. That’s a serious issue. This is likely researcher malware or a pentesting tool and we as a community could not search community-wide for it. Although I’m a huge advocate of the amazing work being done in the industry today we are simply behind where we need to be. If we cannot search our environments for possible pentester malware we’re playing in a different league to find the top capabilities of foreign intelligence teams.
  3. Nothing displayed in this capability or any capability we have seen to date (Stuxnet, HAVEX, and BlackEnergy2 as well as non-targeted capabilities such as Slammer and Conficker) would be undetectable to a human analyst. We need security products in our environments although we cannot rely solely upon them. Those passive defenses that rule out the Conficker infections and ransomware malware are important to rule out noise that human analysts shouldn’t be focusing on. But at the end of the day it must be human defenders against human adversaries that secure the ICS. That active defense approach of monitoring the ICS and responding to real threats is required. Nothing about the capabilities to date would have bypassed human defenders. The harsh truth is many organizations simply are not looking at their ICS networked environment. The harsh truth is that as a community we are not where we need to be today but the inspiring reality is that we can change the industry quickly by countering threats in our environment by empowering and training our people to do so.

In closing, I would caution the community to not overhype IRONGATE. The Mandiant ICS team did not overhype it nor should journalists. It could be a resume generating event to go to your management and claim that the malware itself is a reason for security investments at the company. But this is still an important find. Going to decision makers and ICS organizations and simply asking: “How would you find this if it was in your network?” is an important question and exercise. Hype is not needed to show why this is worth your time to discuss and counter. Ultimately, as we consider this malware and capabilities like it we as a community will move to better understand the threat landscape and counter the capabilities we have not discovered yet. Defense is doable – but you actually have to do something, you cannot just buy a product to place on the network and claim victory.

 

 

Hype, Logical Fallacies, and SCADA Cyber Attacks

May 25, 2016

For a few years now I’ve spent some energy focusing on calling out hyped up stories of threats to critical infrastructure and dispelling false stories about cyber attacks. There have been a lot of reasons for this including trying to make sure that the investments we make in the community go against real threats and not fake ones. This helps ensure we identify the best solutions for our problems. One of the chief reasons though is that as an educator both as an Adjunct Lecturer in the graduate program at Utica College and as a Certified Instructor at the SANS Institute I have found the effects of false stories to be far reaching. Ideally, most hype will never make it into serious policy or security debates (unfortunately some does though). But it does miseducate many individuals entering this field. It hampers their learning when their goals are often just to grow themselves and help others – and I take offense to that. In this blog I want to focus on a new article that came out on the blog at the Huffington Post titled “The Growing Threat of Cyber-Attacks on Critical Infrastructure” by Daniel Wagner, CEO of Country Risk Solutions.  I don’t want to focus on deriding the story though and instead use the story to highlight a number of informal logical fallacies. Being critical of information presented as facts without supporting evidence is a critical skill for anyone in this field. Using case-studies such as this are exceptionally important to help educate on what to be careful to avoid.

Misinformation

Mr. Wagner’s article starts off simply enough with the premise that cyber attacks are often unreported or under-reported leading the public to not fully appreciating the scope of the threat. I believe this to be very true and a keen observation. However, the article then uses a series of case studies each with factual errors as well as conjecture stated as facts. Before examining the fallacies let’s look at one of the first claims which pertains to the cyber attack on the Ukrainian power grid in December of 2015:

“It now seems clear, given the degree of sophistication of the intrusion, that the attackers could have rendered the system permanently inoperable.”

It is true that the attackers showed sophistication in their coordination and ability to carry out a well-planned operation. A full report on the attacker methodology can be found here. However, there is no proof that the attackers could have rendered that portion of the power grid permanently inoperable. In the two cases where an intentional cyber attack caused physical damage to the systems involved, the German steel works attack and the Stuxnet attack on Natanz, both systems were recoverable. This type of physical damage is definitely concerning but the attackers did not display the sophistication to achieve that type of attack and even if they had there is no evidence to show that the system would be permanently inoperable. It is an improbable scenario and would need serious proof to support that claim.

Informal Logical Fallacies

The next claim though is the most egregious and contains a number of informal logical fallacies that we can use as educational material.

“The Ukraine example was hardly the first cyber-attack on a SCADA system. Perhaps the best known previous example occurred in 2003, though at the time it was publicly attributed to a downed power line, rather than a cyber-attack (the U.S. government had decided that the ‘public’ was not yet prepared to learn about such cyber-attacks). The Northeast (U.S.) blackout that year caused 11 deaths and an estimated $6 billion in economic damages, having disrupted power over a wide area for at least two days. Never before (or since) had a ‘downed power line’ apparently resulted in such a devastating impact.”

This claim led to EENews reporter Black Sobczak to call out the article on Twitter which brought it to my attention. I questioned the author (more on that below) but first let’s dissect this claim as there are multiple fallacies here.

First, the author claims that the 2003 blackout was caused by a cyber attack. This is contrary to what is known currently about the outage and is contrary to the official findings of the investigators which may be read here. What Daniel Wagner has done here is a great example of Onus probandi also known as “burden of proof” fallacy. The type of claim that is made is most certainly not common knowledge and is contrary to what is known about the event. So the claimer should provide proof. Yet, the author does not which puts the burden of finding the proof on the reader and more specifically anyone who would disagree with the claim including the authors of the official investigation report.

Second, Daniel Wagner states that the U.S. government knew the truth of the attack and decided that the public was not ready to learn about such attacks. He states this as a fact again without proof but there’s another type of fallacy that can apply here called the historian’s fallacy. In essence, Mr. Wagner obviously believes that a cyber attack was responsible for the 2003 blackouts. Therefore, it is absurd to him that the government would not also know and therefore the only reasonable conclusion is that they hid it from the public. Even if Mr. Wagner was correct in his assessment, which he is not, he is applying his perspective and understanding today on the decision makers of the past. Or more simply stated, his is using what information he believes he has now and is judging the government’s decision on that information which they likely did not have at the time.

Third, the next claim is a type of red herring fallacy known as the straw man fallacy where an argument is misrepresented to make it easier to argue against. Mr. Wagner puts in quotes that a downed powerline was responsible for the outage and notes that a downed line has never been the reason for such an impact before or since. The findings of the investigation into the blackouts did not conclude that the outages occurred simply due to a downed power line though. The investigators put forth numerous findings which fell into four broad categories: inadequate system understanding, inadequate situational awareness, inadequate tree trimming, and inadequate diagnostic support amongst interconnected partners. Although trees were technically involved in one element it was a single variable in a complex scenario and mismanagement of a difficult situation. In addition, the ‘downed power lines’ mentioned were high energy transmission lines far more important than implied in the argument.

Mr. Wagner went on to use some other fallacies such as the informal fallacy of false authority when he cited, incorrectly by the way, Dell’s 2015 Annual Security Report. He cited the report to state that cyber attacks against supervisory control and data acquisition (SCADA) systems doubled to more than 160,000 attacks in 2014. When this statistic came out it was immediately questioned. Although Dell is a good company with many areas of expertise its expertise and insight into SCADA networks was called into question. Just because an authority is expert in one field such as IT security does not mean they are an expert in a different field such as SCADA security. There have only been a handful of known cyber attacks against critical infrastructure. The rest of the cases are often mislabeled as cyber attacks and are in the hundreds or thousands – not hundreds of thousands. Examples of realistic metrics are provided by more authoritative sources such as the ICS-CERT here.

Beyond his article though there was an interesting exchange on Twitter which I will paste below.

1

 

 

 

2

 

3

 

 

In the exchange we can see that Mr. Wagner makes the argument “what else could it have been? Seriously”. This is simultaneously a burden of proof fallacy requiring Blake or myself to provide evidence disproving his theory as well as an argument from personal incredulity. An argument from personal incredulity is a type of informal fallacy where a person cannot imagine how a scenario or statement could be true and therefore believes it must be false. Mr. Wagner took my request for proof of his claim as absurd because he believed that there was no other rational explanation for the blackouts other than a cyber attack.

I would link to the tweets directly but after my last question requesting proof Mr. Wagner blocked Blake and me.

Conclusion

Daniel Wagner is not the only person to write using informal fallacies. We all do it. The trick is to identify it and try to avoid it. I did not feel my request for proof ended up being a fruitful exchange with the author but that does not make Mr. Wagner a bad person. Everyone has bad days. It’s also entirely his right not to continue our discussion. The most important thing here though is to understand that there are a lot of baseless claims that make it into mainstream media that misinform the discussion on topics such as SCADA and critical infrastructure security. Unsurprisingly they often come from individuals without any experience in the field to which they are writing about. It is important to try to identify these claims and learn from them. One effective method is to look for fallacies and inconsistencies. Of course, always be careful to not be so focused on identifying fallacies that you dismiss the claim too hastily. That would be a great example of an argument from fallacy, also known as the fallacy fallacy, where you analyze an argument and because it contains a fallacy you conclude it must be false. Mr. Wagner’s claims are not false because of how they were presented. The claims were not worth considering because of the lack of evidence, the fallacies just helped draw attention to that.

Detecting the S7 Worm and Similar Capabilities

May 8, 2016

I first posted the following on the SANS ICS blog here

An article came out on May 5th titled “Daisy-chained research spells malware worm hell for power plants and other utilities” with the subtitle of “World’s first PLC worm spreads like cancer”. Having been on the receiving end of sensationalized headlines before I empathize with the authors of the research. Regardless of the headlines, the research, performed by Ralf Spenneberg, Maik Brüggeman, and Hendrik Schwartke, is quality work highlighting different methods of propagation and infections inside of control networks. However, before any alarmism sets in let’s look at this research and what it might mean as well as trivial methods to detect it.

The Worm

The researchers put out a great presentation and paper showing exactly what they did to create and test the worm. In short, the worm impacts Siemens SIMATIC S7-1200v3, although with some modifications the method would not be limited to Siemens or this version of PLC, and utilizes the S7 protocol to propagate without requiring the industrial PC. The authors put forth that the infection routine could be introducing an already manipulated PLC or if introduced through the PC it could then run wild without further use of the system. After a PLC is infected it starts scanning the network for TCP port 102 for the S7 protocol to identify the SIMACTIC PLCs. It scans the network through initiating and closing connections at incrementing IP addresses until it finds its targets and infects them. The researchers put the diagram below in their paper to show the process.

PLC Infection Routine

This research is valuable for a lot of purposes but I want to highlight two reasons I think it’s interesting. First, the worm was written in Structured Text and utilizes the PLC and S7 protocol against itself. The researchers use native commands and functionality which I believe will continually be a theme in ICS intrusions and attacks; there is a lot of value in reducing the reliance on custom code or malware when native functionality serves the purpose. The second reason is that all the communications it puts out should be easily identifiable by anyone watching their ICS network.

Detecting the Worm

The most difficult part of detecting threats in the ICS is getting access to the data. The era of dumb switches and a lackadaisical approach to logging needs to be stamped out; but the remnants of it serve a significant challenge. However, after getting access to the network data there are a lot of opportunities afforded defenders. In the case of the S7 worm it would be trivial to detect for anyone familiar with their ICS network.

In a modification of the Purdue Model for ICS architecture, shown below, we can see that good architecture would require the control network, where the S7 devices would exist, to be segmented off from the Internet and outside connections. Connections to the supervisory level should come through operations support and DMZ networks. All of these are potentially very static but the control devices level should be extremely static. I.e. your PLC shouldn’t be Tweeting anything or updating its Facebook status; it’s easier to spot changes here than it is in an enterprise business network.

purdue

The researcher’s worm requires the S7 protocol and it also requires the scanning of new IP addresses on TCP port 102. Even if the worm is modified to have very quick or very slow scan cycles they should all be easily detected. Many SIMATIC PLC environments will use PROFINET to communicate for device to device communications and rely mostly on S7 for configuration and interaction with the Totally Integrated Automation (TIA) portal. There should be a relatively predictable pattern of the PROFINET and S7 communications. It usually gives ICS networks a “heartbeat” that can be observed with the open source tool Wireshark. See below for a PROFINET network where the tool’s “IO Graph” feature (found under “Statistics” in the toolbar) has been selected. Changes to this observable heartbeat such as large spikes or dips in data should be investigated and would reveal increased scanning or command use in the environment.

Wireshark IO Data

Likewise, again just using Wireshark you could use the “Endpoints” feature (again found under “Statistics” in the toolbar) to identify what IP address and TCP or UDP ports are in use. This method easily identified the TCP port requests that the ICS scanner in HAVEX performed and here it would be trivial to identify connection attempts to numerous IP addresses that do not exist on the PLC network segment. Below is a picture of the same PROFINET capture from above. Your network will look different but ICS networks, especially in the control device level, are much smaller and static than traditional IT networks. Take advantage of that.

Wireshark Endpoints

Do a Health Check

At every ICS on the planet defenders should, as a bare minimum, do health checks of the network. In networks with unmanaged infrastructure put in a tap during a maintenance period and gather packet capture. Even if you only are able to do this once a year you will at least be able to identify issues ranging from misconfigured devices to worms like the one in this research. Utilize free tools such as Wireshark to just be aware of what your ICS looks like. Learn what normal looks like and hunt for weird. You’ll be amazed at what you find.

Sustainable Success

You should make the case for managed infrastructure in your ICS and do port mirroring to gather packet captures continuously. These networks do not have a large amount of data and you can gather a lot of packet capture for a small investment in storage space. From there you can learn what the ICS should look like normally and write whitelist styled intrusion detection system rules. There are many awesome professional tools that can help the security of your ICS but for this example you do not need any “next generation” tools; simply using tools such as Snort, Bro, and FlowBAT inside of the Linux distribution SecurityOnion can return huge value for continuously monitoring your ICS.

Ideally, you will have someone (maybe you!) that can perform the tactics I teach in my ICS515 course such as network security monitoring to constantly hunt for threats in your ICS. But if you do not at least you have the data to routinely go back and see if anything is wrong in the ICS or if something goes wrong you can have the data to determine the root cause and apply the appropriate mitigations. And if you ever call in an incident response team just having this data available will significantly reduce the cost and time associated with the response effort.

One other thing the S7 worm highlights is the communications going on inside the S7 protocol. Many defenders simply do not know what is going on inside their ICS protocols. In fact, many ICS protocols are poorly implemented or understood and its an area where much more research is needed. The community must do better with understanding the ICS protocols. Today, detecting changes is trivial through simple methods like Wireshark Endpoints. But the threats are evolving and defenders need to know what commands are being sent across their ICS network. Today, do health checks. Whenever possible, implement continuous monitoring and network security monitoring methodologies. Moving forward, look to deeply understand the ICS protocols and communications.

Closing Thoughts

The S7 worm is good research that highlights what can be done in the control network. But it’s not a worm from hell nor is it some unstoppable capability. The S7 worm is trivial to detect, but few are looking. The worm does however help raise awareness and for that the researchers deserve a lot of credit. For mitigations, ICS defenders should have copies of the logic running on their control devices digitally hashed and stored off of the network. Remediation with good backups is a much less difficult process than remediation without backups.

Regardless if this specific capability is realistic to your environment or not the takeaways are the same: detecting these types of capabilities only requires a minimal amount of effort once data collection is done. There are a lot of mitigations and defenses you should be putting into place but at the very least monitor your environment. If you are not collecting data from your control level you should be, when you move to monitoring the data you collect you will be significantly contributing to the safety and reliability of the ICS.

 

Fourth Sample of ICS Tailored Malware Uncovered and the Potential Impact

April 25, 2016

I first posted this piece on the SANS ICS blog here.

 

I looked at the S4 Europe agenda which was sent out this morning by Dale Peterson and saw an interesting bullet: “Rob Caldwell of Mandiant will unveil some ICS malware in the wild that is doing some new and smarter things to attack ICS. We are working with Mandiant to provide a bit more info on this in early May without doing the big reveal until S4xEurope.”
For those of you that don’t know, S4 is a conference run by Dale Peterson and this is their European debut (the other versions are in Florida and Japan and are staples of the ICS security conference scene always having hard hitting and top notch presentations). As a trusted conference, S4, and friend, Dale, I give a higher bit of credibility to anything that comes out of there than your typical conference. Add that to the fact that the Mandiant ICS team has a number of extremely credible voices (Rob Caldwell, Dan Scali, Chris Sistrunk, Mark Heard, etc.) this is even more interesting and credible.

Let’s break down what we know and why this is potentially very important.

Background on ICS Tailored Malware
To date there have been exactly three ICS tailored malware families that are publicly known. The first was Stuxnet which contained modules to target the Siemens’ systems at the Natanz facility in Iran and cause physical damage to the P-1 centrifuges. Second, there was the Havex malware used in the Dragonfly campaign (aliases include Energetic Bear and Crouching Yeti) that had a module that specifically searched for ICS specific ports (such as 102, 502, and 44818) and later more importantly an OPC module. Lastly, there was the BlackEnergy 2 malware which contained exploits and versions for GE’s CIMPLICITY and Siemens’ SIMATIC environments.

Why Haven’t We Seen More?
Most of us understand that ICS environments make for great targets especially for nation-state and APT styled actors. The ability for military posturing, political leverage, espionage, and even intellectual property theft make enticing targets. Yet, the numbers simply do not seem to align with the fear that many folks have about these environments being targeted. The question always comes up: why don’t see more ICS intrusions? I do not claim to know for sure but my running hypothesis is that it boils down primarily to three areas:

1. We do not have a lot of visibility into ICS networks. Many of the threats that we are aware of we know about due to vendors releasing reports. These vendors traditionally have end point security solutions and anti-virus in the networks that report back information to them. This allows the vendors to “see” tens of thousands of networks and the threats targeting them. In ICS we do not have these same products in scale and many are disconnected from the vendors (which is ok by the way and sometimes preferable). That combined with a lack of understanding of how to monitor these environments safely and interact with them creates a scenario where we don’t see much. Or in short, we aren’t looking.

2. Most malware families tend to be criminal in nature. APT styled malware is not as common in the larger security field. There simply isn’t as big of a motivation for criminals to make ICS specific malware families when ransomware, botnets, etc. work just as effectively in these environments anyway and they represent a smaller portion of the population. This is similar to the old Mac vs. Windows vs. Linux malware debate. One of the reasons we see more Windows malware is due to pure numbers and not because it’s less secure. There is more motive for criminals to write Windows based malware usually. For the APT styled actors, targeting ICS can be important for military and intelligence purposes but there isn’t as much motive to actually attack or bring down infrastructure outside of conflict scenarios; just to learn and position. I have my suspicions that there are a great number of ICS networks compromised with a large variety of ICS specific malware out there and we just haven’t seen the impacts to begin looking (see point #1).

3. ICS specific knowledge sets are rarer making it more difficult to create well-crafted and tailored ICS modules. The typical “cyber team” for nation-states are pretty good at Windows based environments but down in the lower ICS networks it requires system specific knowledge and engineering skills to truly craft something meaningful. This knowledge set is expanding though meaning we will definitely see more and more of these types of threats in the future.

Why is the Mandiant Discovery Potentially Important?
The claim that Mandiant has found a new ICS tailored piece of malware is important for a few reasons.

First, I have a good amount of respect for the Mandiant ICS team and if they say they’ve found something ICS specific I’ll still require proof when the time comes but I’m more inclined to believe them. Knowing the team members though I’m confident they’ll release things like indicators of compromise (IoCs) and technical knowledge so that the community can independently verify the find. This is great because many times there are claims made, even by trusted companies, without any proof offered. My general stance is that no matter how trusted the company is if there isn’t proof (for example the recent Version claim about the water hack) then it simply does not count. The community has been abused a lot with false claims and proof is required for such important topics.

Second, given that there have only been three ICS tailored malware families to have a fourth is incredibly interesting for the research both into the defense of ICS but also into the threat landscape. Understanding how the intrusions took place, what the targets were, and extracting lessons learned will be very valuable to both the technical and culture challenges in this space. It remains to be seen exactly what Mandiant means by “ICS specific” although I have messaged some trusted contacts and have been told that the agenda point isn’t a misprint; Mandiant claims to have found tailored ICS malware and not just an ICS themed phishing email or something less significant. Although I never wish harm on anyone from a threat and defense research perspective this is an amazing find.

Third, it bodes well for the ICS security industry as a whole to start making some more positive changes. There have been many ICS security companies around for years (security and incident response teams like LoftyPerch, independent consultants and contractors, red teams like Red Tiger Security, etc.) and even some dabbling by larger companies like Kaspersky and Trend Micro (who both have contributed amazing information on the ICS threat landscape). But the Mandiant ICS team in a way represents a first in the community. Mandiant, and its parent company FireEye, is a huge player in the security community. For years the Mandiant team itself has been widely respected for their incident response expertise. To have them come out and make a specific ICS team to focus on incident response was actually a big risk. It is common to see ICS products and services but many of the startups struggle much more than the media and venture capitalists would let on. Mandiant’s ICS play was a hope that the market would respond. To have the team come out with a fourth specific ICS tailored malware family bodes very well for the risk they took and with the appropriate coverage while keeping down hype this could be very important for the industry and market writ large. Of course the customers always get a big vote in this area but it could mean more folks waking up to the fact that yes ICS represent a target and yes the security community can calmly and maturely approach the problem and add value (again, please no hype, wallpapers, and fancy logos though for exploits and malware).

But Aren’t Squirrels More Damaging to the Grid?
I gave an interview to a journalist for a larger piece on squirrels and cyber threats with regards to the power grid and I believe it warrants a discussion in this piece’s context. The common joke in the community is that squirrels have done more damage to power grids than the US, China, Iran, Russia, UK, etc. combined. And it’s true. It is often stated by us in the industry to remind folks that the “OMG Cyber!” needs to calm down a bit and realize that infrastructure operators on a daily basis deal more with squirrels and Conficker than APT styled malware. However, we should not equate the probability of attacks with the importance of them. As an example, let’s consider the recent DHS and FBI report on the risk to the U.S. electrical infrastructure.

I have a lot of love and respect for many of the FBI and ICS-CERT personnel I’ve worked with. I can only describe most of them as extremely passionate and hard working. But, the claim that the risk of a cyber attack against U.S. electrical infrastructure was low was upsetting to me because of how it comes across. On the heels of the cyber attack that impacted the Ukrainian power grid the report seemed to downplay the risk to the U.S. community. It stood in direct contrast to Cyber Command’s Admiral Rogers who stated that “It is only a matter of the when, not the if we’re going to see a nation-state, group, or actor engage in destructive behavior against critical infrastructure in the United States.” He was specifically talking in context of what happened in Ukraine and the importance of it. As the head of both the NSA and the U.S. military arm for cyber it is appropriate for Admiral Rogers to have a good understanding of the foreign intelligence and foreign military threat landscape. For the DHS and FBI to contradict him, even if unintentionally, seems very misplaced in what their expertise and mission is; and this leads back to the squirrel comment.

It is not as important to think of probability with regards to destructive attacks and ICS focused intelligence operations. When a community hears of a “low probability” event they naturally prioritize it under other more high probability events. As an example, prioritizing squirrels over nation-state operations based on probability. The problem with doing that though is that the impact is so much more severe for this “lower probability” scenario that the nation must prioritize it for national security reasons. Telling the infrastructure operators, who really defend the grid not the government, to stay calm and carry on is directly competing with that need although the message should admittedly always avoid hype and alarmism. Mandiant coming out with the fourth variety of ICS tailored malware helps highlight this at a critical point in the debate both among infrastructure operators and policy makers.

Conclusion and What to Do
We won’t know exactly what the ICS tailored malware is, what it’s doing, or technical knowledge of it until Mandiant releases it. It could be a dud or it could be extremely important (knowing the Mandiant team my bet is on extremely important but let’s all remain patient for the details before claiming it to be so). However, infrastructure owners and operators do not need to wait for the technical details to be released. It is important to be doing industry best practices now including things such as network security monitoring internal to the ICS. The other three samples of ICS tailored malware were all incredibly easy to identify by folks who were looking. Students in my SANS ICS515 ICS Active Defense and Incident Response class (shameless plug) all gets hands on with these threats and are often surprised at how easy they are to identify in logs and network traffic. The trick is simply to get access to the ICS and start looking. Or in other words: you too can succeed. Defense is doable. So do not feel you need to wait for the Mandiant report. It is potentially very important and technical details will help hunt the threats but you can look now and maybe you’ll spot it, something else, or at the very least you’ll get familiar with the networks you should be defending so that it’s easier to spot something in the future whether its APT styled malware or just misconfigured devices. Either way – the most important ICS is your ICS and learning it will return huge value to you.

The Problems with Seeking and Avoiding True Attribution to Cyber Attacks

March 4, 2016

Attribution to cyber attacks means different things to different audiences. In some cases analysts only care about grouping multiple intrusions together to identify an adversary group or their campaign. This helps analysts identify and search for patterns. In this case analysts often use made up names such as “Sandworm” just to group activity together. To others, attribution means determining the person, organization, or nation-state behind the successful intrusion or attack; this latter type of attribution I will refer to as true attribution. There are many issues with true attribution that I want to explore here. However, there are also those that have pushed back on analysts exploring motives to an attack that I also want to call attention to. When dealing with attribution analysts should avoid the extremes: using true attribution inappropriately or being too hypersensitive to perform analysis and explore motives. Good analysts know when to seek true attribution and when to avoid it.

To explore these concepts I will look at true attribution at the tactical, operational, and strategic level of threat intelligence. While these levels should not be seen as a static category it will help shape the discussion. Tactical threat intelligence often deals with those folks who do the day-to-day security such as performing incident response and hunting for threats in the environment, operational threat intelligence refers to those personnel who work to identify adversary campaigns and often focus on aspects such as information sharing and working through organization knowledge gaps, and the strategic threat intelligence category I’ll use to refer to those personnel that sit at senior decision making levels whether it be executives or board of directors members at companies or national government officials and policy makers.

True Attribution at the Tactical Threat Intelligence Level

In my opinion, true attribution at the tactical threat intelligence level is only harmful to good security practices. Trying to identify who was responsible for the attack seems like a good idea to help shape security practices. As an example, an analyst who thinks that China is in their network might begin looking for intellectual property theft and try to shortcut their effort to identify the adversary. But think about that for a moment. Because our hypothetical analyst thought China was in the network, they have begun to look at the data in front of them differently. In this case, attribution has led our analyst to the land of cognitive bias. Cognitive biases are especially dangerous when performing analysis as they bias the way you think – and analysis leans so heavily on the human thought processes that it can lead us to inappropriate conclusions. Now, instead of keeping an open mind and searching for the threat in the network our analyst is falling prey to confirmation bias where the analyst is looking at the data differently based on their original hypothesis that China is in the network.

This begs the question though, if the analyst has nothing else to go off of shouldn’t they look for the tactics, techniques, and procedures of China in the network as a starting place? In my opinion that is the role of those often funky sounding made up campaign names or intrusion set names; this is what others sometimes call attribution but not true attribution. An analyst that thinks they know what “China” looks like really only knows previously observed activity. If I tell you to think about what China would be doing in a network you might think intellectual property theft. If I tell you the threat is Russia you might think of cybercrime or military pre-positioning. If I say Iran maybe you think about data destruction. The problem is, that thought process is tied to previously observed activity and it’s also going off of the assumption that previous true attribution you’ve heard is correct. Even if we assume all the previously true attribution was correct though analysts have only ever heard of or seen some of the campaigns by adversaries. Russia has teams that are interested in intellectual property theft just as China has teams that are interested in military pre-positioning. We are biased in how we view nation-state attribution based on campaigns we have seen before and it is difficult to take into consideration what is unknown. The better tactic is in identifying patterns of activity such as “Sandworm” and thinking to previous observed threats tactics, techniques, and procedures as a starting place in how we search the network for threats. Then tactical level threat intelligence analysts aren’t biased by true attribution but can use some element of attribution to learn from threats they’ve observed before while attempting to avoid cognitive biases.

True Attribution at the Operational Threat Intelligence Level

At the operational threat intelligence level the use of attribution needs to fit the audience. Operational level threat intelligence analysts should always attempt to serve as the bridge between the strategic level players and the tactical level analysts. When using the observations and information from the tactical level to translate to strategic level players there can be a role for true attribution, which we will explore later. When translating the observations at the strategic level and operational level to the tactical level though true attribution then again becomes dangerous. The way threat intelligence is positioned should be determined by the audience consuming it.

Consider this: an operational level threat intelligence analyst has been asked to take the campaigns observed in the community and translate that information for the tactical level folks to use. The indicators of compromise and security recommendations that the tactical level personnel should use are independent of attribution. The security recommendations and fixes are based off of the observed threat to the systems and vulnerabilities not the attribution; or said another way if you have to patch a vulnerability you don’t patch it differently if the exploit was Chinese or Russian based.

However, that same operational threat intelligence analyst has been asked to identify the threat landscape, the observed campaigns in the community that are relevant to the organization, and make recommendations for strategic level players that can influence organizational change. Here, the analyst may not be able to prove true attribution based off of observed adversary activity but it is in their best interest to identify patterns and motives to attacks. As an example, if there have been a number of campaigns recently that align with the motives of Chinese actors targeting the analysts’ company the recommendation from the operational level analyst to the strategic members might have them take into consideration how they interact with and do business with China. Here the analyst should use language to structure their assessment that the observed threats are Chinese based such as “high confidence”, “medium confidence”, and “low confidence.” Language such as “it is definitively China” should be avoided. Ultimately analysis is based on incomplete data sets (consider the difference between inductive and deductive reasoning) and the provided information is just an assessment.

At the operational level of threat intelligence analysts should be mindful of their audience and be open to putting forth good analysis based on observed activities, threats, and motives without being definitive on true attribution.

True Attribution at the Strategic Threat Intelligence Level

Strategic level audiences often heavily care about true attribution but not always with good reason. Government leaders and company executives want to know their threat landscape and how it might shape how they conduct business or policy. That is a good thing. However, strategic level players should be careful not to use true attribution when it’s not required.

As an example, if the organization is facing security challenges and is consistently having intellectual property stolen they need to look at the security culture of the organization and the resource investments needed to increase security and minimize risk. This inward look at the culture and security investments should usually be independent of true attribution. The tactical and operational level impacts are going to be the same whether the previous culprits were China, Iran, Russia, or the North Pole. However, if the organization is taking an outward approach to doing business or policy making they may need to consider true attribution. Because true attribution is usually based off of assessments and not usually definitive it should usually be approached as a continuum.

To look at true attribution especially for this level of threat intelligence I highly recommend two resources. First, a paper by Dr. Thomas Rid and (soon to be Dr. – congrats Ben!) Ben Buchanan titled Attributing Cyber Attacks. This paper will get you into the right mindset and understanding of attribution for the second paper I would recommend by Jason Healey titled Beyond Attribution. In Beyond Attribution, Jason Healey discusses the concept of responsibility as it applies to attribution. In short, a nation-state has responsibilities with regards to cyber operations especially if they might have been conducted from within its borders. At one side of the scale, a state can take an approach of prohibiting attacks and actually help other nations when an attack has begun. On the other side of the scale a state actually conducts the attack and integrates their attack with third-party proxies such as private companies for hire or hacktivists.

Analysts should be mindful of this spectrum of state responsibility, as Jason calls it, when considering true attribution and the nature of intelligence assessments. It is difficult to have true attribution and true attribution can be harmful to tactical level security. However, identifying motives in attacks and understanding the spectrum of state responsibility to attacks should be considered at the strategic level so that we are not so hypersensitive on the topic of attribution that every adversary gets to operate without consequence.

Case Study: Cyber Attack on the Ukrainian Power Grid

Let’s take these concepts and apply it to the cyber attack on the Ukrainian power grid. If you’re unfamiliar with the case you can read about it here. In this case, I have been very careful about my wording as I know there are multiple audiences that see my quotes in media or read my reports. On one hand, I teach a threat intelligence course and an ICS/SCADA active defense and incident response course at the SANS Institute. In this capacity most of my audience is tactical and operational level personnel. For those reasons I have often tried to reinforce that attribution in Ukraine doesn’t matter for them. Identifying indicators of compromise to hunt throughout the network, preparing the network to make it more defensible, and applying lessons learned from the Ukraine attack are all independent of true attribution. True attribution simply doesn’t matter for how we apply the lessons learned for security at those levels.

However, I also deal with strategic level players in my role in academia as a PhD student at Kings College London and as a Non-Resident National Cyber Security Fellow at New America where I work with policy makers. For this audience, it is important for me to note that definitive true attribution has not been obtained in the Ukraine attack and may never be obtained. However, in considering Jason’s spectrum of state responsibility we have to look at the attack and realize the potential motives, the larger geo-political setting, and analyze if there are any courses of action strategic level personnel should take. In my opinion, I doubt the Russian government itself carried out the attack. However, the attack on the Ukrainian power grid did not fit any apparent financial motives and the motives aligned with various Russian based actors; whether those are private companies, hacktivists, or senior government officials. Therefore, it is in my opinion and in my analysis that strategic level players should look at the elements of attribution that link to Russian based teams and consider Jason’s spectrum of state responsibility. Even if Russia had nothing to do with the attack there should be an investigation into whether or not it occurred from within their borders. If the attack is state-ignored it sets a dangerous precedent. Senior policy makers in other nations should under no circumstance jump to blaming Russia for anything. However, they should look for international cooperation and potentially an investigation as this is a first-of-its-kind cyber attack on civilian infrastructure that led to a power outage. There is a line between espionage and offense; that line was crossed in Ukraine and we must be careful of the precedent it sets.

Conclusion

In conclusion, true attribution is highly abused in the information security community today. Many organizations want true attribution but do not know how to use it appropriately and many private companies are quick to assign definitive attribution to attacks where they simply do not have the appropriate data to support their conclusions. True attribution makes media headlines and the motives for companies to engage in this activity are significant for that reason. Claims of true attribution do increase international tension; not as significantly as some would assume but they are individual data points to policy makers and national level leaders. However, being hypersensitive about true attribution enforces a culture in this field where nation-states can ignore responsibility such as investigating attacks or policing their borders as is normal in international law and policy in any other domain other than “cyber.” There is a balance to be struck. Knowing how to strike that balance and when to use attribution in the form of group names with no state ties or true attribution in the form of an evolving assessment will help the threat intelligence community move to a more mature point where tactical, operational, and strategic level players can all benefit.

 

*Edit 3/6/2016*

I had a good discussion with some colleagues around this post and wanted to add two points.

  • Richard Bejtlich had a really good blog post on the value of attribution and breaks it down in a number of useful ways. His blog post pre-dates mine but I failed to reference it the first time. It can be found here. I would recommend it as it’s a great read and doesn’t take long to work through.
  • Two peers, Mark and Tim, made a case for tactical level true attribution that I think is actually an interesting one to consider. I would argue that most tactical folks shouldn’t consider true attribution and that it’s highly highly abused and resource intensive with little value in the wider community today. That being said, Mark made the point that in a resource constrained environment it might be a useful factor in prioritization. As an example, if you have a lot of phishing emails or malware samples to look at and you need a place to start, true attribution could be of value as that starting point as long as you try to defeat any biases later on. The reason this could be of value (credit to Mark and Tim on this point) over just attribution of groups is: if you have data that is of use to specific countries (think F-35 fighter aircraft intellectual property being of value to China and Russia more so than Niger) using that information as a starting point and prioritization of your searches could be useful. This also touches on the topic of crown jewel analysis combined with threat intelligence; for anyone interested in that subject check here.  This to me gets closer to the operational level than the tactical level and I would expect operational folks to translate these concepts into a usable form for tactical level analysts instead of expecting them to start this process – but I can see the case for why this would be useful at the tactical level and would agree that it’s an interesting one to consider.
  • (Thanks to the peers that took the time to discuss their thoughts with me. Discussions like these help all of us explore our understanding of a topic and I always find my own learning process enhanced by them).

No, Norse is Not a Bellwether of the Threat Intel Industry but Does Hold Lessons Learned

January 30, 2016

Brian Krebs published an outstanding report today titled “Sources: Security Firm Norse Corp. Imploding” which has led to the emergence of a number of blogs and social media rumblings about what this means for the cyber threat intelligence community. Some have already begun positioning that this is the fall of threat intelligence. I would not only disagree and believe this to be a mostly isolated case but position that if anything this is a good sign of the community’s growing maturity. The purpose of this blog is to discuss why Norse’s potential and impending implosion does hold some lessons learned for the industry but holds no prediction of negative things to come for the threat intelligence community as a whole.

Before elaborating on these points though, I want to start off with the much needed statement about the people at Norse. To anyone in the community that holds strong negative feelings for Norse (and you are not alone) please be conscious that many of the individuals working at Norse were professionals and very talented. Many of the negative feelings towards the company were likely based on the marketing efforts and mislabeling of the content and value of their product; not negativity towards the people that work there. I hope the former employees land softly at their next jobs and I would encourage companies looking to hire to think of these individuals without prejudice.

With regards to Norse it was in many ways a good looking company. It garnered national media level attention through smart placement of their cyber attack map (yes the pew pew cyber map analysts have mostly grown to hate – but it looked good in media). There were some key employees recruited who were well respected in the industry. And it raised tens of millions of dollars in investments to appear as an exciting California security startup. So now that the company is apparently imploding it does seem natural to think that this may be an indication of things to come with regards to the threat intelligence industry and for a ripple effect in investments into this space. However, I would state this as wholly inaccurate although there are some lessons learned here for both investors and security startups.

First, Norse Corp. may have garnered national level attention but most of it was not actually good attention. Also, they billed themselves as a threat intelligence company when, in my opinion, they simply were not. Folks who are familiar with me, or read it in the Krebs report, will remember that I came out very publicly chastising their dangerous assessment that there were Iranian attacks on U.S. industrial control systems. The key reason that they had a bad assessment is actually why Norse was always doomed to fail. The company was interpreting Internet scanning data against their high level sensors as attack intelligence. Most threat intelligence companies rely upon enriched data complemented with access to incident response data of actual intrusions; not scanning activity. Norse also held no verifiable industrial control system expertise but were quick to make assessments about these systems. And further when they stated that there were attacks on control systems by Iran what the data seemed to show was they actually should have said scans against systems trying to mimic industrial control systems by Iranian IP addresses. The effort by them and the think tank AEI to state that there should be policy considerations in the Iranian nuclear negotiations based off of this data is a great representation of what not to do in the industry. Simply put, they were interpreting data as intelligence. There is a huge difference between data, information, and intelligence as I outlined here. While their product and Internet level scanning data was interesting and potentially very valuable for research it was not threat intelligence. So while they may have billed themselves as significant players in the threat intelligence community they were never really accepted by the community, or participating in it, by most leading analysts and companies. Therefore, they aren’t a bellwether of the threat intelligence industry or of other companies having trouble simply because they weren’t really ever in “the industry.” The threat intelligence community can be fairly small and making strategic mistakes can have significant lasting impact. Trust is a huge part of the equation in this community.

Second, this case-study of Norse holds great lessons learned. First, because trust is a significant part of doing intelligence work and in participating in this community there is a requirement for companies to realize they are dependent on the ecosystem and are not living in a bubble. Formal and informal relationships, company partnerships, and information sharing can help companies succeed quickly. It is not a competitive landscape in such that companies should think that success is a finite item where one company’s success means less is available for others. Quite the opposite. As threat intelligence is used more appropriately throughout the industry it will continually open up the market. For example, threat intelligence is meant to make good security programs better or to help give important context and information to strategic level organization decision makers – it is not meant to replace bad security programs or act as a magical solution for security. Second, threat intelligence companies should be very careful in lining up their marketing efforts with an honest assessment of what the company’s product or services actually produce. This should apply to any security startup but it is vital in the threat intelligence community. Whereas claims around general security can be difficult to interpret there are definitive ways to look at company claims in intelligence and dismiss them completely as hype. This dismissal is hard to recover from. Finally, an important lesson learned here is for investors and Venture Capital firms to dig deep not only into what is being shown by the company but also in how they are perceived in the community. There are many “experts” in this community who’ve never held the appropriate positions or roles to ever have been put in a situation to speak with expertise about threat intelligence. As an example, one of my critiques of Norse was that their “intelligence report” on industrial control system attacks was not written by anyone with industrial control system expertise. Just as we would expect a Russian intelligence analyst to have an understanding of Russia or even speak Russian the community and investors should demand that assessments are qualified by actual expertise not just general “cyber” expertise.

Venture Capital firms invest in companies with the expectation of not getting an immediate return on investment. In an overly simplified stereotype most Venture Capital funds expect not to see their returns for five to seven years with events such as an IPO or company merger/acquisition. Following that logic, it is reasonable to believe that investments made five to seven years ago are starting to be looked at for their return on investment to the Venture Capital firms. The landscape for investment will likely become much more competitive. There will be lessons learned from investing in good-sounding but under-performing companies. Investors and industry analysts will demand more proof of claims, understand what hype looks like a bit better, and invest even more intelligently. This is a good thing for the industry. I doubt Norse will be the last company to fail in the threat intelligence industry but the industry and investments into it will likely continue to grow. The focus will be on smarter money.

 

 

Context for the Claim of a Cyber Attack on the Israeli Electric Grid

January 26, 2016

This blog was first posted on the SANS ICS blog here.

 

Dr. Yuval Steinitz, the Minister of National Infrastructure, Energy, and Water resources, announced today at the CyberTech Conference in Tel Aviv that a “severe cyber attack” was ongoing on the Israel National Electric Authority. His statements were delivered as a closing session at the conference and noted that a number of computers at the Israeli electricity authorities had been taken offline to counter the incidentthe previous day.

There are few details that have been offered and thus it is far too early for any detailed analysis. However, this blog post attempts to add some clarity to the situation with context in how this type of behavior has been observed in the past.

First, Dr. Steinitz mentioned that computers had been taken offline. This discussion around the choice by the defenders to take systems offline indicates a normal procedure in terms of incident response and malware containment. The intention of the incident responders cannot be known at this time but this activity is consistent with standard procedures for cleaning malware off of infected systems and attempting to contain an infection so that it cannot spread to other systems. Taking systems offline is not preferable but the fact that systems were removed from the network does not necessarily make the incident more severe. On the contrary, this indicates that incident responders were able to respond early enough with planned procedures to counter the incidentprior to an impact.

Second, there have so far been no outages reported or any such impact of the “attack” quantified. It appears, only from what has been reported so far, that the use of the term “cyber attack” here is very liberal. Malware infections in industrial control system (ICS) networks are not uncommon. Many of these environments use traditional information technology systems such as Windows operating systems to host applications such as human machine interfaces (HMI) and data historians. These types of systems are as vulnerable, if not more so, than traditional information technology systems and malware infections are not novel. With regards to historical case studies it is far more common for incidental malware to lead to system failures than targeted attacks. For example, the Slammer malware reportedly caused slow downs in the Davis-Besse nuclear power plant’s networks and crashed a utility’s supervisory control and data acquisition (SCADA) networkin 2003. However, in terms of targeted/intentional intrusions leading to outages we only have three validated public case studies: Stuxnet, the German Steelworks facility, and the Ukrainian power grid. It is these targeted intrusions where an outage occurred that could be considered an attack. Often times people unintentionally abuse the phrase “cyber attack” when it is more appropriate to classify the activity as adversary intrusions, compromises, or espionage activity. To understand what constitutes an actual attack it is helpful to read theICS Cyber Kill Chain.

Third, there has been an increased focus on cyber security in Israel both as it relates to the cyber security of national infrastructure and in the technology companies that are making Israel an enticing locationforventure capital funding. In January, Israeli Prime Minister Benjamin Netanyahu gave a presentation to the World Economic Forum where the center of his discussion was cyber security. This was followed by a Februaryannouncement that the Cabinet in Israel approved a plan for a comprehensivenational cyber defense authority. With the increased focus on cyber security it is entirely possible that Israel had taken a proactive approach to looking through their infrastructure networks to identify threats. In the course of this action it may have found malware that may be targeted or incidental in nature. In either case, from what is being reported right now it appears unlikely that this is an actual attack and more likely it is the discovery of malware. However, it is important to watch for any developmentsin what is being reported.

Israel has threats that it must consider on a day-to-day basis. Critical infrastructure is constantly the focus of threats as well although there are a lack of validated case-studies to uncover the type of activity much of the community feels is going on in large quantities. However, reports of cyber attacks must be met with caution and demands for proof due to the technical and cultural challenges that face the ICS security community. Simply put, there is a lack of expertise in the quantity required alongside the type of data needed to validate and assess all of the true attacks on infrastructure while appropriately classifying lesser events. Given the current barriers present in the ICS community the claims of attacks should be watched diligently, taken seriously, but approached with caution and investigated fully.

Facts, Hype, and Takeaways from Reports on Iranian Activity Against the Power Grid and a Dam

December 21, 2015

This was first posted on the SANS ICS blog here.

 

Yesterday a report on Iranian activity focused on a small dam in New York was released by Danny Yadron at the Wall Street Journal. Today a report was released by Garance Burke and Jonathan Fahey at the Associated Press reporting on Iranian activity linked to the OpCleaver report by CYLANCE where documents related to Calpine were stolen. So what’s the hype, what are the facts, and what are the takeaways? Let’s explore:
The Facts:

I’ve worked with both Danny and Garance before and have a high amount of respect for the effort they put into their reporting. Reporting on technical content can be very difficult and sometimes leads to inaccurate reports especially when the topic of security is combined with control systems. Garance and Danny do their homework though. In that regards I instantly feel more positive about the articles. That’s also why I was willing to contribute a quote to Garance when she called and wanted a quote for the story. I didn’t get to see the story, didn’t know all that was going to be written, but understanding the type of data that was stolen that was related to Calpine — yes it absolutely is something an adversary would want and defenders should protect and she was correct to in emphasizing that.

In theWSJ story there were namedindividuals in the town who were present for, and recalled, the FBI response to the activity. Additionally, there are unclassified reports from the FBI and ICS-CERT that could likelycorrelated to the dam event. Both stories are credible in the fact that they occurred. Not all the details are properly fleshed out though for the ICS community and there’s a few areas to leave you wanting.

When looking at the ICS Cyber Kill Chain where did the dam and Calpine cases fall? Neither of them were attacks. I’d put the dam activity under Reconnaissance in Stage 1 and I’d put the Calpine case under Act under Stage 1 but not in Calpine networks. This is important to note; the “Act” was the exfiltration of sensitive documents related to Calpine but the intrusion was not in Calpine but instead in contractor networks. Or simply put, neither Calpine nor the dam were compromised. But both showed a focused effort by an adversary, possibly Iran but attribution is always tricky, against infrastructure.

Also, in the case of the dam the WSJ report notes that U.S. authorities confused the dam with other similarly named dams. The cell modem the infrastructure used would have been distributed out in a manner that likely made physical location difficult to determine. This may have confused the adversaries as well.

I’d highlight the following facts:

  • Both reports are credible news organizations and reporters
  • The WSJ report on the dam is additionally credible with regards to the event having taken place (the details could always be wrong though). This is due to correlated details with other unclassified reports, timing considerations, and a named source noting that the FBI did respond
  • The WSJ report identifies that the activity was “probing” but likely not scanning activity; the focused effort on queries and searches by the adversaries is more of a targeted Reconnaissance than random scans
  • The AP report is additionally credible given that named sources identified and provided samples of the stolen documents of internal information, passwords, and system diagrams in Calpine
  • The AP report identified that sensitive data about Calpine was stored on contractor networks and was not stolen from internal to the ICS
  • Neither the dam nor Calpine were compromised. There was no intrusion into ICS networks nor were there any attacks.

 

The Hype:

To anyone in the ICS community these reports likely have some cringe worthy statements to you. This has been the discussion in various social media circles already where ICS security professionals have taken offense to statements such as the AP report’s “cyberattackers had opened a pathway into the networks running the United States power grid.” The comments, which I agree with, are that there is no open pathway based off of these stolen documents. With the WSJ report the title states “Iranian Hackers Infiltrated New York Dam” which obviously did not actually occur since there was no intrusion. These issues are consistent with any news reports regardless of how good the journalists are on the subject matter. This is where I’m both empathetic and exhausted.

I’m empathetic because there are a lot of eyes on these reports and hands in the proverbial cookie jar. Very rarely do journalists get to choose their report’s title. Additionally, the reporters’ main audience is not the ICS community. It’s a more laymen non-technical audience. Any report that those of us would come up with in the community focused only on measured facts would likely be incredibly boring or entirely too technical for a laymen audience. I’m exhausted because this type of activity is understandable but not excusable. If we continue to hype threats and accidently miseducate the audience people will pay attention to that. Outside our community there are folks who impact our community. Policy makers and the general public have a lot of impact on ICS. Journalists and news organizations need to do better for sure, but we should also take into consideration they are trying to make something out of reports from a community who does not like sharing these types of events. Overall I felt positively about the articles but I’d like to see the news reporting community as a whole do better with regards to ICS and security.

I’d highlight the following hype:

  • The WSJ’s title is misleading as there was no intrusion
  • The AP’s statements around the impact of this data loss is (in some places) misleading. It is valuable data but does not make the grid any more vulnerable today than it was before
  • Both reports provide very little evidence and rely on unnamed sources for the attribution to Iran; given the number of reports and correlation of events the case is stronger than usual but still not enough to truly validate that the Iranian government was responsible

 

The Takeaways:

If I’m going to highlight the flaws of the journalist community I’m certainly going to highlight our own community’s flaws. News organizations need to do better in general but the ICS community needs to get better at identifying issues and being willing to share lessons learned. Some organizations are amazing at this but as an overall community there’s work to be done. The identification of the loss of data related to Calpine only came from a member at CYLANCE identifying the sensitive documents on one of the adversary’s FTP servers. The amount of documents stolen from multiple sites should have been detected by someone internal to those networks (such as Calpine’s contractor) and not waiting for a 3rd party notification. Additionally, anyone in the ICS community who’s been here long enough can think about a couple of close calls and actual incidents that are not public. If the community cannot figure out a way to responsibly share case studies and lessons learned then we will have to accept other people outside our community writing the narrative. It’s a hard task but we have to figure it out.

Defense is definitely getting better. ICS is not as vulnerable as people make it out to be. And defenders are taking a more proactive approach to security than ever before. But we as a community have some ground to cover. Taking an active defense approach to monitoring our networks, performing incident response, and sharing the non-sensitive details for the community to learn is required for us to raise the bar and have the ICS security story be written by the ICS community. Journalists are going to tell the stories regardless. It’s up to us to identify and guide a proper narrative or to not complain about it.

Additionally, the stories both highlight a focused effort by foreign adversaries targeting infrastructure. It also highlights sensitive ICS data being stored on non-ICS networks. This reinforces the need to bridge the IT/OT gap and have ICS and IT professionals work more closely together. The one thing I’ll push back on a bit from the ICS perspective is the comment from Calpine that the stolen data, diagrams, and passwords were old and thus pose no threat. Calpine may bean industry leader in this area but ICS diagrams, passwords, and data does not change that quickly at all and even when old can be useful. This type of information is definitely useful to an adversary for reconnaissance and learning purposes — but no it is not a threat to bringing down the grid or Calpine’s facilities.

I’d highlight the following takeaways:

  • The cultural and technical barriers to identifying incidents, responding to them, and sharing lessons learned need to be reduced in the community so the proper narrative can be written and security can be elevated
  • The IT/OT gap is a divide that must be bridged if for no other reason than the fact that all the sensitive information about an ICS does not just rely on the ICS networks; IT networks including contractor networks can reveal data about the ICS that we do not want adversaries to have
  • The data from the AP story would be useful to adversaries but should not be overvalued. The biggest takeaway is a focused effort by adversaries to learn about infrastructure and target it
  • The power grid or infrastructure such as dams are not as easy to impact as folks like to make it sound, but adversaries are getting smarter and focusing harder on this challenge — defenders too must get smarter and focus on the threat to keep the opportunity to damage infrastructure out of the hands of malicious actors