Monthly Archives: March 2015

Sydney Water Corporation audit: ICS security lessons for all

Posted on by

I read over the New South Wales (Australia) cyber security audit. I liked the fact that the audit is publicly available. I liked the fact that it included a close look at the industrial control systems of Sydney Water Corporation (SWC). This helps the average citizen understand where security improvements might need to be made.

NSW audit

I thought the auditors made some concise observations that could well be applied to a number of critical infrastructure operators:

  • SWC has an established Information Security Management System (ISMS), but it only covers the corporate data centre and not the engineering systems.

Comment: So the systems that control the service that the corporation exists to provide are not covered by the security management system?

  • SWC’s risk management process documents risks and controls at a strategic level but does not cover all operational level risks, such as the potential introduction of USB-based malicious software.

Comment: Ahh, no one has decided how to secure the SCADA. And the strategy they have is so high level that it does not reflect proven threat vectors.

  • A range of common specific risks and their mitigating controls have not been documented, including risks associated with non-expiring engineering passwords.

Comment: One password… forever…. for your SCADAs. Because you don’t want passwords getting in the way of the engineers doing their job. (but what about former employees?)

  • SWC indicated that an assessment is conducted for every SCADA related alert from national computer emergency response team (CERT Australia), with emails received on a regular basis by several managers whose job it is to assess impacts. However the assessment process was not defined and the analysis documentation that was provided to support this assertion was limited to a minority of the security advisories released by the US Government.

Comment: At least they say they are looking at vulnerabilities, right?

Those may sound easy enough, but the truth is that they require a change in mentality reaching from corporate management to operations engineers. Will they do it?

And what about your water provider?

Protecting what matters most

Posted on by

I heard some surprising and insightful conversation from a pair of young schoolchildren the other day.

Joedamadman: Thomas School Bus

They were chatting about riding the bus to school. One of them said, “I don’t understand why the bus driver is the only one who gets a seat belt.”

“Yeah”, came the response, “and he’s the oldest one!”

Although they couldn’t tell you so, these two students were already grasping some important concepts about safety, security and risk.

  1. They honed in on the purpose of the school bus — to get *the students* to school safely (rather than the driver).
  2. They did a comparison of useful remaining life — reasoning that it makes more sense to worry about the children, because they have longer to live than the bus driver.

Those same thoughts have a nice analogy to ICS security.

  1. Whether your business is generating electricity or making cookies, your most important computing assets are those controlling the industrial process — it’s the production network that is making you money! You should not ignore its safety and security while only investing in protection for the “enterprise side”.
  2. Withe a limited budget you’re going to have to choose where to dedicate the most resources. There may be significant challenges with securing older plants. If you are going to build a new facility it is your chance to invest in a lifetime of a more-secure, more-safe control system. Focus your security efforts and budget where they will serve you the longest.

Automated “pre-cyber terrorism” indicators, anyone?

Posted on by

I came across what I thought was an interesting concept: the Cyber Attack Automated Unconventional Sensor Environment (CAUSE) program from IARPA.

The briefing provided by IARPA to entities who may propose solutions is fascinating.

IARPA

In short, the idea is to get beyond the *reactive* nature of indicators of compromise (IOCs). While I am a proponent of information sharing, I am well aware that IOCs are a treadmill game much of the time. I don’t think IOCs are useless, but I generally view them the same way I view antivirus signatures.

IARPA wants to progress towards an *automated* and *predictive* approach that combines a wide variety of information (about industries, markets, geopolitics, etc.) with cyber security indicators.

IARPA2

According to the slide deck, IARPA has a whole plan set up to *measure* the effectiveness of each proposed solution. The measurements will even include a “ground truth” component theoretically allowing IARPA to compare warnings generated with actual events.

Lots of good thoughts in this one. Will it work? At least they have a plan to find out.

Owners and operators of critical infrastructure might benefit from re-examining their own use of cyber intelligence and how they plan to move beyond the reactive IOC treadmill.

Five reasons ICS security fragility hasn’t mattered — yet

Posted on by

Brian Contos on the Norse security blog offered “Five Reasons ICS-SCADA Security is Fragile“. I especially liked seeing a blog sponsored by a threat intelligence company include a brief discussion of “zones” — an OT security concept unfamiliar to many IT security practitioners.

The post prompted me to ask, “If ICS security is so fragile, then why are known incidents so infrequent?” and “Why aren’t bad things happening to our infrastructure every day?”

I am not the first to ask these questions. And, while I don’t pretend to have all the answers, I’m offering an alternative to Mr. Contos’ perspective.

Five reasons ICS fragility hasn’t mattered — yet.

1. Product is still being produced. At the end of the day, some process outages are tolerated. Until we have a spike in these outages which we can positively trace to cyber attacks, from a business perspective there isn’t much reason to be concerned.

2. Ignorance is bliss. You can’t catch what you can’t observe. Just don’t install any security sensors on your ICS networks, and you are good to go!

3. The “air gaps” separating IT and OT networks at large ICS installations do provide some security. OK, I’m playing devil’s advocate to the customary “air gaps don’t exist”; but look, some gap, some segmentation, is better than none. Very few, if any, large ICS installations are connected directly to the Internet.

4. Process engineering can defeat cyber attacks. I’m not implying that ICS are built to stop intentional attacks, but where dangerous conditions can occur, physical-world engineering helps avoid those conditions.

5. Successful attacks against ICS for specific, premeditated, physical consequence requires cross-domain expertise. Your average script kiddie might brick your Modicon PLC using the Modbus function code for firmware upload, but he probably can’t predict what that will do to the process relying on that PLC.

DNI Clapper’s threat assessment: Something sensible, something exaggerated

Posted on by

I read DNI Clappert’s assessment of the cyber threat, as briefed to the Senate Armed Services Committee.

Clappert

I was pleased to see this statement (on page 1):

Overall, the unclassified informs istion and communication technology (ICT) networks that support US Government, military, commercial, and social activities remain vulnerable to espionage and/or disruption. However, the likelihood of a catastrophic attack from any particular actor is remote at this time. Rather than a “Cyber Armageddon” scenario that debilitates the entire US infrastructure, we envision something different. We foresee an ongoing series of low-to-moderate level cyber attacks from a variety of sources over time, which will impose cumulative costs on US economic competitiveness and national security.

 

Wow, I thought a U.S. military leader would never learn to temper the cyber alarmism.

But then I read this (on page 7):

Computer security studies assert that unspecified Russian cyber actors are developing means to access industrial control systems (ICS) remotely. These systems manage critical infrastructures such as electric power grids, urban mass-transit systems, air-traffic control, and oil and gas distribution networks. These unspecified Russian actors have successfully compromised the product supply chains of three ICS vendors so that customers download exploitative malware directly from the vendors’ websites along with routine software updates, according to private sector cyber security experts.

 

That sounds like a direct reference to the Havex/Crouching Yeti/ Dragonfly malware. Several phrases in there seem overblown:

  • “These systems manage critical infrastructure…”

Yes, ICS manages critical infrastructure, but the placement of the statement makes it seem like actual “electric power grids, urban mass-transit systems, air-traffic control and oil and gas distribution networks” were infiltrated in this case.

Now there is some open source evidence that an electric utility and an ONG firm in Norway had Havex on their networks. But it is not clear that it was on their ICS networks. There are probably HAVEX infections in the USA, but were those infections on ICS for all those sectors?

  • “have successfully compromised the product supply chains of three ICS vendors…”

Yes, ICS provider supply chains have been compromised in the past. But in the case of Havex/Crouching/Dragonfly, the “supply chain” happened to be “Web pages” — not nearly as exciting as it sounds, but clever move by the attackers none-the-less.

The attackers wrapped the original installers with their own installers. If you 1) are downloading files from the public Interwebs to use in “critical infrastructure”, 2) aren’t verifying file integrity, and 3) and aren’t forcing “run only signed code”, then who knows what could happen to your ICS networks, even from run-of-the-mill malware.

Moreover, the ICS vendors whose Web sites were compromised were relatively small players. Joel Langill said the attacks could be targeted at the pharmaceutical sector, I wondered about manufacturing that relied on robots, Reid Wightman thought maybe data centers. None of which are an obvious fit for “critical infrastructure”.

So, good job on the early self-restraint, but let’s use more precision on the examples!