Information Sharing and the ICS-ISAC

Sunday, April 15, 2012

Chris Blask

A966b1b38ca147f3e9a60890030926c9

The topic of information sharing has become one of the most interesting in the process of ferreting out “The Solution” to ICS cybersecurity.

Aspects of the effort to secure industrial control systems  – including timing, technology and workforce – lend themselves to suggest that answers lie less in technology and more in Robert’s Rules.

There is much wailing and gnashing of teeth among the Information Sharing crowd. Over the past decade valiant efforts have been met with what might not always look like success. The federal government has loomed over the conversation, the brave and the timid from the private sector either strode forth or crabbed hesitantly towards the shadow of the leviathan.

It is not uncommon to hear subject matter experts ask why more isn’t being done, these days. Particularly among the war-weary who have witnessed works like the “Fall of the House of Food ISAC”. Information sharing efforts to date have certainly not exceeded their highest expectations.

But rather than being a matter of a failure of any particular party, it is more that the initial expectations might not have fully encircled the scope of the issue. Both on the federal government side as well as the private sector worthy efforts have been undertaken that themselves were about as much as could be done up to this point.

Bob Radvanovsky partnered with Lofty Perch and started the SCADASEC forum. The Department of Homeland Security stood up ICS-CERT.  These and efforts like them have both provided a medium for communication when there was otherwise none, as well as demonstrated some strengths and weaknesses of common models. Most existing efforts are more likely to grow to more fully fill their niche in coming years than they are to be displaced.

All of this is of course not happening in a vacuum. In 1998, before infosec was even mainstream in IT, Presidential Decision Directive NSC-63 set the framework for a federally-supported ecosystem of Public/Private Information Sharing and Analysis Centers (ISACs). A number of efforts have been undertaken to create ISACs for vertical sectors such as Electricity (ES-ISAC) and Water (Water-ISAC), as well as several different types of horizontal functions like the Multi State ISAC (MS-ISAC) and IT-ISAC.

Some efforts – such as the Food & Agricultural ISAC – began with good intentions and then starved for lack of information to share, or parties to share it with. Such instances themselves provide lessons to inform future efforts, laying the first lines on the blank page for others to begin putting a frame on the true nature of the challenge.

Other efforts – such as SCADASEC, ICS-CERT and MS-ISAC – give examples of the reach and limitations of successful information sharing nodes of different types. Among them that the federal government can do a good job of information sharing among its many warrens but is limited in its ability to effectively use these same methods to penetrate much beyond its walls.

The recent NIAC report from January of this year contains lots of gems on the current state of information sharing. Among them we find a developed awareness of the reach and limitations of public, public/private and private information exchanges:

  • (p. ES-3) D. There is currently not an effective process to engage—in a systematic and sustained manner—senior executives in the private sector with their counterparts in government.
  • (p. ES-4) C. Intelligence information-sharing mechanisms between the private sector and the Federal Government are complicated, at times confusing to the private sector, and may be redundant and/or conflicting. As a result, engagement through trusted personal relationships remains a primary means of facilitating the flow of needed intelligence information.
  • (p. ES-5) C. The private sector reaches out to multiple sources to meet its intelligence needs, including trusted personal relationships, trade associations, various DHS components, other government agencies such as the FBI, Sector-Specific Agencies, sector Information Sharing and Analysis Centers, fusion centers, and State and local law enforcement. While it is important to note that the “value proposition” of various sources and mechanisms varies across sectors, there is a common concern over receiving redundant, late, or conflicting information.

While information sharing within the government and information sharing within the private sector has developed relatively effective mechanisms, the interface between the two domains remains problematic. As with most interfaces, the manner in which these two domains interact has a fundamental impact on the characteristics of both sides.

The ISACs stand as the formal forums for government and the private sector to perform some of the functions of this interface. What in 1998 began with a mandate to create an ISAC has developed into a matrix that shows signs of success. The vertical and horizontal blocks each perform a definable function and interconnect in relatively logical ways.

This figure is one way to view these interconnects:

Vertical ISACs like ES-ISAC provide focus on specific sectors or functions. The National Council of ISACS (NC-ISAC) acts as a horizontal ISAC to ensure “Sharing among Sharers”. MS-ISAC combines the value of all of the vertical ISACs for the purpose of state and municipal bodies. Horizontal ISACS like IT-ISAC and Supply Chain ISAC (SC-ISAC) capture and transport commonalities between sectors.

The ICS-ISAC is currently being created to perform a function similar to the IT-ISAC. Most vertical sectors employ industrial control systems of one form or another, with both shared commonalities as well as sector-specific technologies and processes. The ICS-ISAC will be chartered to put in place structures to capture these commonalities and ensure their value is effectively shared among the ISACs and their public and private constituencies.

Inside its own walls the US federal government has made significant improvements in information sharing. The private sector has developed for-profit and non-profit mechanisms which gather, process and disseminate information with often reasonable effectiveness.  The ISAC structure has evolved into a workable matrix that can be improved upon over time.

The indications are that we will continue on these paths and build on lessons learned. While the future will remain a mystery until it arrives the past is clearly laid out to see. The story it tells does not foreshadow endless doom and strife. Rather, it points the way to success.

———-

[Editors Note: Those interested can join the Linkedin ICS-ISAC Group. Chris is also doing a keynote speech on the topic of “Information Sharing in the Age of LIGHTS” at 4pmPT, April 17th as part of the “Smart Grid Educational Seminar Series”.

Possibly Related Articles:
7233
SCADA
Industrial Control Systems
SCADA Security Strategies Cyber Security Infrastructure ICS Industrial Control Systems LIGHTS ICS-ISAC Information Sharing
Post Rating I Like this!
5cbe1364caf51f95cac6484a832d66d0
Bob Radvanovsky Chris, the origins of "SCADASEC" never really "partnered" (per se) with Lofty Perch (although we indicate that we're strategic partners with them currently), Lofty Perch's involvement was during the formulation of the initial mailing list, and not much more.

Both Jake Brodsky and I had discussed the possibility of starting some kind of control systems security mailing list with Matt Franz several years ago, who was at that time working at Digital Bond. Jake got referred to me via Matt, and both jake and I hit things off right away; we spent the better part of one winter night (and morning) discussing ideas and options, and how we wanted this mailing list to proceed/evolve.

Jake and I took the best of the ideas and ran them past a few people. Jake discussed them with an attorney to see where we stood from a legal perspective, and I discussed similar aspects with Mark Fabro from Lofty Perch. Mark, though he liked the idea, made a bet with me that the list wouldn't survive a year. I won that bet (NOTE: it wasn't a big bet). Mark was initialy involved because of his visibility within the evolving SCADA security community, though he is not as involved in the day-to-day activities as both Jake and I are today.

In general, the problem with information circulation has to do with two primary problems:
First, people do not like to publish their mistakes for fear of potential lawsuits or regulatory fines. If there is no regulatory immunity or requirement for reporting, most/many organization aren't or won't to say much of anything. Second, government usage of CRADAs and classified information tends to limit what most individuals representing these organizations can say or do.

The SCADASEC mailing list doesn't have those limits. We exist *outside* of many of these charters because we're private, and respect the rules and laws of the countries that support and cooperate with us (esp. include the U.S. through DHS).

SCADASEC is chatter -- unfiltered chatter -- more specifically -- it is "raw intelligence".

Thus, people can say just about anything they want to, and they can filter the information how ever they see fit or can receive from another intelligence source. Neither Jake nor I have the cycles to filter or "weed out" the chatter for a summary report (despite the numerous requests that we have had from several key individuals); many people want SCADASEC reduced to a 1-3 page summary report; that's all well and good, but for something that is being provided free to the public, and considering that neither one of us receive any compensation whatsoever from this endeavor, this goes against the principle of providing a useful "sanctuary" for people from all walks of life, to openly discuss concepts, issues and techniques. Having SCADASEC as a free, public, open, raw intelligence source was always, originally, our intent.

The ISAC model needs tweaking (IMHO, it needs to be "re-written"). First, they are not looking at all of the raw information sources, and in many cases, usually don't verify the intelligence sources,, with most circumstances just performing "cut 'n pastes" from newspaper articles (no different in some cases to what we do on SCADASEC). Often times, most of the contributors on SCADASEC will often drill down to the source of the information to get as much of the real story as they can find. If a private researcher finds a control systems' vulnerability, members on SCADASEC can reference the actual discovery, and the membership community (often) contributes their experiences and perspectives to further illuminate the actual impact of that discovery to this community. Essentially, SCADASEC has become an integrated community.

From a differing perspective, an ISAC offers to interpret the information for you within a closed community (and there have been many ISACs that have posted information hours/days later following heated discussions on SCADASEC). Although some would like to think that SCADASEC is a primary source of intelligence, we would rather think of it as an aggregated form of raw intelligence from multiple open sources.
1334599457
A966b1b38ca147f3e9a60890030926c9
Chris Blask Hey Bob,

That is an interesting bit of history. I had hired someone at Lofty who told me the story I related, but as you know I was not involved with setting that up with you.

The "open valve" nature of SCADASEC is an important ingredient in the info sharing soup. It is not the kind of thing that the ISAC structure really lends itself to, and less-so the pure public centers - and even Private For-Profit don't really have the DNA to go there.

Perry said it well: you are a SCADA hero.

:~)
1334614624
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.