Friday News & Notes

SCADA Security News

Richard Bejtlich blogged “SEC Guidance Is A Really Big Deal” regarding the SEC telling companies they need to disclose cyber incidents and risks. If you read financial statements you are already beginning to see cyber security disclosures along side other material warnings. Are we going to see public companies with ICS write things such as “our ability to safely produce (power, product, ..) is at risk if an attacker can gain any access to our plant networks because these systems lack basic security features and we have chosen to do nothing about it”?

We are starting to see the results of the Intel/McAfee/WindRiver/NitroSecurity acquisition path. This week Intel/McAfee announced their blueprint for critical infrastructure protection. There is also a Protect Critical Infrastructure page on the McAfee site and a solution guide. I got excited when I read the term McAfee Embedded Control, but it wasn’t what I thought. We will review the solution in more detail in a future article.

Proponents of the “anti-virus is too dangerous to run on ICS” got another data point this week as an Avira anti-virus update caused a number of false positives. The false positives stopped regularly used applications from running and could be compared to causing an outage in an ICS. Rather than abandon or move to manual anti-virus updates, owner/operators should leverage the redundancy in the system and split hot/standby servers and workstations into different groups. Update one group and schedule the next group to update the next day. In the rare case where there is anti-virus update issue your ICS will still be operable. This is a good practice that many owner/operators have used for years now.

Rapid7 released a telnet_ruggedcom module for Metasploit. The module, developed by Borja Merino, “greps out the MAC address from the telnet banner, performs the password conversion magic, and stores it off into Metasploit’s credential database for later use (say, with the telnet_login module).” This module exploits the vulnerability found by Justin W. Clarke.

The Dutch have issued an ICS Security Checklist (ht: @m00st) with 5 administrative security control principles and 10 technical security control principles. Many of the checklist items have sub items, but it’s concise at four pages and accessible.

There is a serious argument on the FERC audit of NERC. It’s not related to security per se. It deals with NERC’s accounting and finances. NERC objected and heavily commented on most of the findings. This article provides a summary or you can read all of NERC’s comments. This doesn’t appear to be a case where the truth is in the middle. Either the auditor was way off or NERC has been playing by their own set of rules. Appreciate comments from anyone who knows the details.

Howard Schmidt, the US Cybersecurity Czar, announced he was leaving the post at the end of the month. His tenure has actually been a few months longer than planned. Wired  had a fascinating article/interview with Mr. Schmidt when he started more than two years ago with two great pull quotes.

  1. “it’s possible that hackers have gotten into administrative computer systems of utility companies, but says those aren’t linked to the equipment controlling the grid, at least not in developed countries. He’s never heard that the grid itself has been hacked.”
  2. “‘As for getting into the power grid, I can’t see that that’s realistic,’ Schmidt said.”
BTW … Stuxnet PLC vulnerabilities have not been fixed 613 days after Ralph Langner revealed them.

Tweet of the Week

You decide:

@ I can compile ClamAV to run on Wago's PLCs if it helps...
@ReverseICS
K. Reid Wightman

or

Not everybody was kung-fu fighting. I, for one, was not. Your research is flawed.

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Read More

S4 Video: EDF on HW Security to Protect USB Ports

Here is the final S4 2012 video, Pascal Sitbon of EDF presents “Preventing Attacks on Critical Infrastructure through Hardware Protection Against Malicious USB Devices”.

Pascal brought the prototype called SCOOP (Selective Control of Peripherals). It had two main use cases.

  1. Human Interface Protection
  2. Mass Data Storage Protection

Read More

EMET v3 Introduces Group Policy, More

Flyswatter (image by Ultra-lab)EMET v3 was released two days ago and it introduces a most-coveted feature: support for management via Group Policy.

EMET is Microsoft’s answer to legacy software problems.  It introduces address space layout randomization and other wizardry to legacy applications that were not compiled to support such features.  This in turn helps prevent your vendor’s programming mistakes from becoming your headache and forensics analysis post-mortem after a hacker attack by hopefully preventing an exploit from succeeding.  For maximum benefit, software should be installed on Windows Vista/7/2008, though there is some benefit to running EMET even on XP/2003 systems.

Suha Can gave a great presentation on the product at S4 2012.  I’m the guy at the end asking about Group Policy support…

Centralized management means that you can apply EMET policies to every system on your network centrally, requiring that pesky programs with foreverday vulnerabilities be run with EMET protection.  The download comes with a User Guide, which has decent instructions on setting up features for common and uncommon applications using the Group Policy snap-in.

EMET is awesome for a lot of reasons.  First, it is free.  Second, it gives applications a lot of security — public exploits don’t work off-the-shelf.  Detailed analysis of the ASLR used shows it to be pretty darned good when configured properly.  This means that a bad guy trying to exploit a buffer overflow on your system is probably going to crash the service over and over again instead of getting a nice, shiny shell on your process control network.
Read More

The Hidden Dangers of DNS

Tyrolean Traverse (kind of) over a riverDNS is probably the second most misunderstood protocol (the first being the control protocol du network), and that needs to change.  I can’t claim to be anything close to a DNS expert, but am known to do neat tricks with it now and then.

A few years back I was lucky enough to catch Dan Kaminsky present at ToorCon on IP-over-DNS tunneling, which planted a seed with me about general protocol tunneling.  He had just tinkered with doing DNS queries over SSH, itself tunneled over DNS (and proceeded to chug a cup filled with Cinnamon Toast Crunch and Mickey’s to celebrate, IIRC).

The technique is actually much older, and dates back to the late 90s/early 2000s, when hacker-types would dial-in to Microsoft PPP servers (normally used for software registration), and would tunnel to the Internet using the technique.

DNS can be a bit complicated, but there are some basic principles that should be understood about DNS where security is concerned.

Let’s take digitalbond.com.  If you are reading this, you entered www.digitalbond.com into your web browser.  Your web browser, in turn, had to figure out what IP address www.digitalbond.com belonged to.

To do that, your web browser first contacted your local DNS server.  This DNS server probably had our www.digitalbond.com cached (we’re Digital Bond, after all).  In the unlikely event that it did not have us cached, it would first try to figure out what DNS server was responsible for resolving digitalbond.com domains.  You can do this yourself via a Unix command line with the command ‘host -t ns digitalbond.com’.  On Windows, you would do this with the command ‘nslookup -querytype=ns digitalbond.com’.
Read More

Another DHS Bungle or Risky Stratagem?

SCADA Security VulnerabilityDHS Control System Security Program (CSSP) actions in the natural gas pipeline alert get even stranger. They have either bungled helping natural gas pipeline companies to protect themselves or have some risky stratagem to take down an attacker and are willing to accept the collateral damage.

1) First, what it isn’t. There still is no evidence disclosed by DHS that the goal of spear-phishing attacks is any way ICS related except the natural gas pipeline companies have ICS. There has not been evidence that they are trying to collect ICS information or attack the ICS.

2) As reported by Mark Clayton of CS Monitor, Bob Huber and Jonathan Pollet confirmed that there were similarities between the “indicators of compromise” of the natural gas pipeline compromise and those of the attack on RSA and its token database. In simple terms, it is likely that the same person or group that attacked RSA and US defense contractors is attacking natural gas pipeline companies.

3) DHS has not told the public or the affected natural gas pipeline companies that the source of the attack is likely the same as the RSA attack. It appears that DHS did not know about the likely connection to the RSA attack until told by outside security professionals. At this time it’s impossible to say what they knew and when, but it is clear they chose not to share this information with the people being attacked.

4) If the natural gas pipeline companies had been told it was the same attacker and similar attack, they could have implemented more effective defenses and responses. The RSA attack has been studied and effective protective and detective measures developed. DHS could have even shared these security controls with all of the energy sector to limit or prevent additional attacks.

Even more troubling is the DHS advice “do not block or take mitigating action”. Was DHS planning to take immediate action and responsibility for purging the RSA attacker from the affected companies? Short of that, the advice puts the companies at risk. They could have said this is a skilled attacker, based on the RSA attack link, and your company is going to need a well planned approach to identify where the attacker is and how to expel him.

Read More

A Request for a Competitive Process

INL Is DHSGuest author Sean McBride is the Director of Analysis and Co-founder of Critical Intelligence, a company that provides Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.

One simplified explanation for the differing views of Dale Peterson and Bryan Owen, as seen in the comments here and here is based on simple economic analysis.

Bryan represents the security function of a highly successful software company. His position directly benefited from the subsidies the US government made available to the private sector through the INL. The INL-OSIsoft story, I know from several conversations with Bryan, is quite compelling. I wish the details were publicly available to serve as an example for how to work security into the product lifecycle – even when the process can be painful.

On the other hand, Dale represents a highly-specialized consulting firm whose thought leadership has publicly and credibly pushed for improvement over much of the past decade. His firm must compete under market forces to land every client. As such, government subsidies through the INL are irksome as his potential clientele turns there, obviously attracted by taxpayer help and good PR.

From a business perspective, if I were in OSIsoft shoes, NOT going to INL is a mistake. However, I have a hard time believing that a firm like OSIsoft, with a security leader as sharp as Bryan Owen leading the way, could not have found a similar (and in some cases superior) quality of assistance in the private market space.

Hence, the deeper issue I see in Dale’s repeated and sometimes stinging analyses is a request for leadership at  some level (Ms. Menna, Mr. Weatherford, Mr. King, Mr. Lieberman, Ms. Collins, Mr. Schmidt) to address the questions:

  • If cyber security of critical infrastructure is as critical as we like to make it sound, isn’t it time to start a competitive process that encourages ICS-security innovation?
  • Doesn’t the near-decade-long “INL owns this space” mentality risk shutting the door on fresh approaches to ICS-security?
  • Are non-competitive contracts, vendor subsidies, and non-disclosure agreements providing the daylight necessary to gauge real progress?
  • Isn’t there some OMB guidance about National Labs competing with industry?

Read More

ICS-CERT ≠ DHS CSSP; INL = DHS CSSP

INL ICS SecurityLet’s take a closer look at DHS since this is the week of DHS’s ICSJWG Spring Conference. Like many, I’m guilty of treating ICS-CERT as if they are THE DHS sponsored organization responsible for ICS security in the US Government. ICS-CERT is part of the DHS Control System Security Program (CSSP) and should be treated and evaluated as a CERT.

ICS-CERT does a fine job coordinating activities between researchers and companies. They are balanced and try to reach a compromise that satisfies both parties. It is a huge benefit for a researcher to be able to turn over findings to ICS-CERT and let them deal with the coordination. Just ask McCorkle and Rios who turned over a huge amount of HMI vulns. There have also been many cases where ICS-CERT knocking on a vendor’s door has gotten a response after the researcher was ignored.

While ICS-CERT has done well on coordination when the researcher and company cooperate, their products, alerts and advisories, are based and biased towards whatever the vendor has admitted or released. It’s not surprising that the vendor panel at ICSJWG had high praise for ICS-CERT. It’s also not surprising they support the vendor’s point of view since many are customers paying INL top dollar for ICS security services.

ICS-CERT has failed to use their ICS expertise or wealth of lab equipment in the ICS-CERT Alerts and Advisories. They have been a clipping service, reporting whatever information others have chose to make public and no more. The best example of this is the Beresford vulnerabilities where ICS-CERT had the Siemens equipment, must have known Dillon was right, and still went with the Siemens party line until it was no longer tenable. That ICS-CERT did not suffer a massive black eye when they completely missed the PLC attack portion of Stuxnet is still baffling. It’s so easy to get me ranting on this topic … and the point is that a CERT is just a portion of what DHS is responsible for in ICS security.

While ICS-CERT ≠ DHS CSSP, it is credible to say that ICS resources at Idaho National Labs (INL) is DHS CSSP. Marty Edwards, the DHS Director of CSSP was formerly in a similar role at INL. Marty still lives in Idaho and has his office at INL. ICS-CERT resources are from INL. The DHS CSSP program office has been staffed by INL contractors. The DHS training courses were developed and are delivered by INL. The fly away teams come from INL. It goes on and on.

PNNL and Sandia play bit roles in DHS ICS security compared with INL, and actual DHS employees unconnected to INL are anomalies and tend to only last a year or two.

A fair characterization is DHS has outsourced ICS security to INL.

Read More

SCADACON (ICS Readiness Condition)

SCADA Security Readiness and FUDThere have been more than a few hysterical articles, also full of hysteria, in the press based on attack information provided by DHS. Wow, a number of large companies have been subject to a spear-phishing attack! ICS specific threat or attack information = 0.

This could be a precursor to a serious attack on pipeline or water ICS, but based on the information DHS has put out it is merely everyday life for a large corporation connected to the Internet with users who email and access web sites. It is odd that DHS plays up these issues and downplays the serious vulnerabilities that continue to go unfixed by vendors and unaddressed by owner/operators in the deployed ICS.

There is also a question as to what is the criteria for a DHS fly away team getting involved in a cyber incident. All it takes is any cyber attack on a company with some link to the critical infrastructure? The question I would have asked at during the ICSJWG case study on the Curran-Gardner water non-incident is “why did DHS get involved in a small outage in a small water utility?”. This is a topic for another article, but it ties together with the CSSP at DHS groping to prove its doing something in this space while still avoiding the contentious issues where their leadership is needed.

So after a bit of DHS bashing, and in the spirit of the DEFCON scale, here is our SCADACON Rating Scale:

SCADACON 5

A critical infrastructure company is receiving a wide variety of almost continuous attacks from the Internet. Attackers are banging against the corporate/Internet firewall. Attackers are sending email with malware attachments and links to compromised websites. SCADACON 5 is every day for any company or individual who connects to the Internet.

SCADACON 4

Your company is receiving some sort of targeted attack. This could be a spear-phishing or some other attack customized with company information to lure your employees into taking an action that will give an attacker a foothold. The attacker could have already succeeded and is enumerating the network or even gathering or corrupting any data besides specific information on the control system.

Most companies are living in SCADACON 4, and it is naive to believe you are not if you are a company of any size — critical infrastructure or not. The information in the dire warnings from DHS to date have been SCADACON 4. This is why they are hysteria from an ICS perspective. Based on the information DHS provided, the fact that they are pipeline or water system related is incidental.

SCADACON 3

Now we have reached an ICS specific attack level.

At SCADACON 3 an attacker from the Internet or partner/customer network is trying to gain access to a system on the corporate network that is allowed to communicate to the ICS, such as a database server, SCADA admin PC, or IT staff system responsible for ICS switches.

A good example would be an email, including a file or a link with an important bulletin on the DCS application in use, purporting to come from a known DCS vendor source and sent to a DCS admin.

SCADACON 3 is very similar to SCADACON 4 except the monitoring has detected that capturing ICS information or attacking the ICS a goal of the attack.

SCADACON 2

An attacker on the corporate network is trying to gather information on the ICS or compromise the ICS.

The attacker has achieved the first, not too difficult, step of gaining a presence on the corporate network. The attacker could be trying to access file servers or databases with configuration files, drawings or other helpful information in crafting an attack. The attacker could be trying to find the corporate/ICS firewall and then find a way through it to a server on the ICS DMZ or actual ICS. ICS protocols may be seen, ICS default credentials, known ICS vulns will be exploited or perhaps web server, database or other 3rd party software on the ICS server or workstation will be compromised.

At SCADACON 2 you should be disconnecting the ICS network from the corporate network. Yes, I said and meant air gap. You should also assume you are about to lose control and view and at least have your emergency response plans ready.

Admittedly, the SCADACON rating could jump directly from SCADACON 4 to 2 if the attacker chose to find the easiest, non ICS-specific way to gain a presence on the corporate network. However if we treat every corporate network attack on a critical infrastructure company as an attack on the critical infrastructure we will waste a lot of energy. It’s better to focus on identifying events that would lead to SCADACON 3 or 2. Monitoring and detection of ICS specific attacks is key, and fortunately it is an area that is getting increasing attention in the ICS security community.

SCADACON 1

The SCADA or DCS system has been compromised and an attacker is implementing a real time or future loss of control or loss of view attack. The owner/operator no longer has reliable control of the process. Safety, economic, environmental and other worst case impacts could be looming

The frightening thing is it is very easy to go from SCADACON 3 to SCADACON 1 given the complete lack of user or data authentication in the most of the devices that control and monitor a system.

I’m not suggesting anyone actually use this SCADACON scale, but hopefully it is useful in understanding what we are looking for in monitoring actual ICS attacks and useful data.

Read More

Friday News & Notes

ICS Security NewsISA99 had a busy, well attended 3-day set of Working Group Meetings this week in Gaithersburg, MD. A lot of work gets done in these sessions, and it’s a testament to ISA99 they continue to get this level of participation and effort through many years of work. We hope to have some updates on the key decisions made in Gaithersburg this week.

Next week is the DHS ICSJWG Spring Meeting in Savannah, GA. It’s not a boycott, but unfortunately we won’t be in attendance at this edition. I decided early on to pass, since I attended the last two. Michael and Reid submitted papers, but were rejected. Later on they were asked to present, but by that time they were committed for work at a plant. We will be following the news and tweets from the event.

Tweet of the Week

Every company I know hates revealing attack data yet @ claims "targeted attacks" are up 81%. http://t.co/uANyOvlG Come on guys.
@jeffreycarr
Jeffrey Carr

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

A lot of RuggedCom / Justin W. Clarke articles, but nothing new.


Critical Intelligence’s ICS Security Event Calendar Updates

Read More

The Curious Incident of the Original Switch Manufacturer

Upside-Down Dog (Image by denverjeffrey)Dan Goodin at Ars Technica pointed out something very curious to me yesterday.  RuggedCom recently took down their ‘Customers’ page, which includes a list of companies for which RuggedCom is the OEM.  Fortunately various search engines keep caches of these things, including the Internet Wayback Machine™.

I have been fascinated with the OEM scene since listening to Sean McBride’s excellent presentation at S4 this past year .  Like automotive manufacturers, ICS equipment vendors have some very interesting and sometimes very odd relationships with other vendors.  Sometimes these are relationships with embedded OS and library (software), sometimes vendors make hardware for other vendors, and sometimes the relationships extend to both, with the OEM purchaser simply slapping a badge on the front…

In particular, RuggedCom had the following list of companies as OEM purchasers from their historical pages:

- ABB
- Areva
- Cooper Power
- General Electric
- Schweitzer Engineering
- Siemens
Read More