Monthly Archives: November 2014

Critical Intelligence Quarterly Report

Posted on by

Yesterday Critical Intelligence released its ICS Security Trends and Analysis Report for Quarter 3, 2014.

Q3 graphic

Critical Intelligence really covers a lot of ground. For example, during Q3 the firm reported on total of 136 items pertinent to the electric sector. These range from indications and warnings updates, to ICS specific vulnerabilities, to attack tools, and defensive developments.

This is the 23rd quarterly report that I have been directly involved with creating at CI. While previous reports provided a fantastic overview of the emerging trends, and some dove deeply into interesting topics, we decided to try something different this time.

At the CounterIntel conference in September, several intelligence consumers asked for something that they could pass to their senior management to give them them a quick, but grounded understanding of what was really going on the ICS threat world that the execs should know about.

So, this time the report is just three pages plus the cover sheet. The first two pages describe the three most important ICS security developments that occurred during the quarter. The report then answers the questions “Why is this important?” and “What should I do about it?”

The last page is a brief statistical overview of all the items covered during the quarter. This provides a good feel for the value that CI is providing, and the items that the intelligence team at each ICS asset owner deals with on a regular basis.

If you are a Critical Intelligence customer, then please send in your feedback. If you are not, then schedule a sales call and see what you are missing!

Article on “spy” photographer

Posted on by

On October 30, 2014, the New York Times ran an interesting article on a student/photographer in Hong Kong, Dan Garrett. Mr. Garrett has been accused by the Chinese government of being “without any exaggeration a top-level spy”.

Dan Garret photo

From Dan Garrett’s Twitter https://twitter.com/DanGarrett97/status/516247801273913344/photo/1

The article goes on to tell Garrett’s story, but it never really answers the question of whether he is a spy. In the article, Garrett, whose LinkedIn profile shows him as a former GS-15 with the State Department, is quoted as saying “I’m no James Bond”.

So, what is a spy?

I attended a public conference with former CIA director Michael Hayden. He told the story of an assignment he had in Europe (maybe Germany?) many years ago to ride the train and count the number of military vehicles he saw out the window. Was this spying?

I’ve heard government security analysts mention incidents of “photography” at industrial facilities. Is taking a photos the same as spying? Does it depend on the photographer’s intent? Does it depend on who pays the photographer? Does it depend on whether the photographer knew how the information “collected” could/would  be used? Does the nationality of the photographer make a difference?

I guess I’m really getting at two points: Under what conditions is your organization concerned about photography? How does your organization mitigate photographic and video graphic reconnaissance?

I would also simply note that there are lots of nice stills and even flyover videos of infrastructure facilities on the Interwebs… and more being added daily.

 

But we’ve got two ISACs!

Posted on by

With all the talk about information sharing, including the possibility of the automotive ISAC, the launch of retail ISAC, the NIST draft information sharing guidance, and the launch of not one, but two ISACs to serve the Oil & Gas industry (DNG ISAC and ONG-ISAC) I couldn’t help but draw a cartoon:

Car

Automotive

PoS

Retailer

Defense

Finance

Oil

ONG

So before you misinterpret the cartoon, I want to make clear that I like ISACs. I think they are a good idea, and can be useful.

What I want to decry, however, is the fact that they are too often a political response for a failure to really care about security. They have turned into a way for participant firms to tell the government and themselves “See, we are doing something… we are getting information from DHS and making it available to our members… we don’t need regulation.”

If you are going to buy into the importance of “information sharing” and “threat intelligence”, then you should do it right. Hire a team, get the the technologies you need, generate thoughtful requirements. Without these things, what are you going to do with all that *awesome* intelligence/shared threat information anyway?

NIST Info Sharing Guidance and “Intelligence Requirements”

Posted on by

In case you missed it, NIST released draft cyber security Information Sharing Guidance. I’m sharing some of my thoughts on the document with the general public.

NIST title page

My first post dealt with recommendation 2. Now let’s look at recommendation 1. It reads:

Organizations should perform an inventory that catalogues the information an organization currently possesses, the information that it is capable of producing, and document the circumstances under which this information may be shared.

The underlying concept behind this recommendation is absolutely solid. It’s a necessity.

However, it seems wordy to me — too much good stuff smashed in there. How about splitting it into two pieces: one for information collection/receiving (which the NIST draft calls “an inventory”), and one for sharing (which NIST calls “document the circumstances”).

I am going to focus on the collection/receiving piece. Here’s what I suggest:

Organizations should conduct a security intelligence gap analysis, that describes intelligence requirements the organization is and is not meeting.

 

I believe that information sharing is inherently an intelligence discipline rather than a cyber discipline. I think we should use language and concepts that have been used for years by intelligence professionals.

So, to do cyber information sharing, you have to start with “requirements” — as in “intelligence requirements”. These are what you want to know — but don’t know yet. There is real value in taking the time to identify those “known unknowns”.

Generating intelligence requirements requires a coordinated effort among many stakeholders across an organization.

For example, let’s take an electric utility: does your intelligence team know the vendor, product, and version of the PLC controlling the coal conveyor at Plant 16? Because without knowing 1) that requirement, and 2) the person who has that requirement, the intelligence team cannot effectively collect and report. And if your intelligence team isn’t collecting and reporting, then your plant security lead isn’t taking appropriate action based on the dynamic threat environment.

A few rough example requirements might include:

  • When were coal conveyors last attacked? Who did those attacks? Why? Where? How?
  • What exploit tools are known to enable attacks against PLCs controlling coal conveyors?
  • What IDS signatures exist for detecting those attacks?

I have to tell you: when it comes to threat intelligence/situational awareness, if you take short cuts up front — if you skip, or neglect, or rush the requirements — you are only impairing your ability to take appropriate action. Don’t do that!

Critical Intelligence is on the cusp of releasing a unique tool that helps operators of critical infrastructure generate intelligence requirements — and then collect against those requirements. If you are an intelligence analyst or a security manager working in critical infrastructure, shoot an email to info@critical-intelligence.com to request a demo.

Zetter and Stuxnet: Why ICS integrators and asset owners should care

Posted on by

It is exciting to see Kim Zetter tell a compelling story of Stuxnet for the masses: Countdown to Zero Day.

I had the opportunity to speak with her at the RSA conference this past Spring. I had just presented some interesting (free and open source!) research on Stuxnet. You can read about my RSA presentation here. While I have yet to read Zetter’s book, she has definitely gone beyond my work in many ways.

Sanctions announcement from U.S. Embassy in Iran

To correspond with her book’s release, I’m posting some interesting, but lesser known points on Stuxnet:

  • A 2004 strategy paper from a senior fellow at The Washington Institute proposed the following U.S. strategy for countering Iran’s nuclear ambitions (his other suggestions are also shockingly accurate):

introduction of destructive viruses into Iranian computer systems controlling the production of components or the operation of facilities;

 

  • Symantec said there were five target companies. Zetter names four (NEDA, Behpajooh, Foolad Technic, Control Gostar Jahed). Symantec must have known their names, but has never divulged them publicly.
  • The U.S. government had been tracking one particular Iranian ICS integrator, NEDA, for literally years as NEDA allegedly obtained embargoed goods through a global procurement network
  • NEDA was public about its Stuxnet infection problem
  • The State Department sanctioned NEDA for its involvement at Natanz after Stuxnet was “over” (sanctions announced in Dec. 2012) — which to me essentially confirmed that NEDA could have been the vector for perhaps both understanding Natanz ICS, and delivering Stuxnet — and its cousin code — to their objectives.

Conclusion: Based on these revelations of how Stuxnet “got in”, if I were a control systems integrator (especially one that supported military installations or capabilities) operating in the West, I would be very concerned about my own internal systems, and the control systems I was building for my customers.