Building a Better Control Systems Security Community

One of our goals for the first Gathering is to foster better connections for building security features into industrial control systems.  We’re not unique this way; PCSF did it before us, as did (and continue to do) other numerous alphabet soup groups.  Key among these groups is the social aspect of who is doing what and where these days.  People are building connections and, yes, we will continue to foster this growth.

So, the connections are growing.  Now what? It would be nice if people thought ahead and worked toward a few common goals, wouldn’t it?  That’s one of things that will make this Gathering different.  The technical sides to the control systems security problem are being identified and dealt with. But for the most part, we’re still stumbling around in the dark.

Let’s shine some light on the issue…

First, we need better intelligence.  I’m not talking about the hush-hush secret decoder ring stuff.  I’m talking about the sorts of things we can learn by sharing public information.  Most intelligence agencies get a great deal of traction simply by reading newspapers from around the world, looking at what books are in the libraries, studying what the schools are teaching; and by studying the backgrounds of leaders, both current as well as up and coming. It’s not espionage, it’s simply a matter of understanding who the people are in the country, what motivates them, and what resources they have.

So when I say that we need intelligence, I’m not talking about espionage.  What I’m talking about is an open source data gathering methodology.  What are the jobs that each critical infrastructure sector has? What proportions of staff are used for what? What resources do they use to get those jobs done? What problems do they have, and who is busy working on them, and what are they bringing to the table?

I’m also talking about studying incidents (and learning from them).  Whether these incidents were control systems related or not, they still bear some level of study.  It shows us who is working on what equipment, what training they have, what mistakes were made (design, operation, installation, etc.) and what the consequences are. At the end of the day it will enable engineers to design better control systems with more useful human interfaces.

Second, we need to get the group to integrate this data into useful, actionable information. This requires many talents; more talents than one person is likely to have.  That is where the connections fit in. We want to encourage people to recognize each other’s experience, strengths, and training.  By that, I’m not talking about certificates, or graduation from some school, but real hard nosed experience from real-life situations.  So if you’re a senior plant operator with a 15 year history on the floor of a facility, we want to hear what you have to say.  If you’re a security researcher who has found numerous problems in embedded software, we want you too.  If you’re an embedded systems programmer who knows the ins and outs of using embedded ‘C’ on various micro-controller platforms, we want you too. If you’re an integrator or OEM who has installed numerous control systems, we need to hear from you too. And if you’re not on this list and still think you have something to contribute, by all means come along and introduce yourself.  If at all, perhaps, you may meet people who are in the same boat as you.

The point is to get people together and talking to each other so that we can make the most sense of what we’re going to find.  That’s the first goal.

The second goal is to start conducting our own research. I’m not interested in the specifics of each and every flaw that we find, I’m interested in categorizing them and finding common solutions to them. Most of you probably know that office IT models often do not fit well on a plant floor.  We may be able to learn a thing or two from the office IT experience, but we’re still going to have to start from scratch.

Some of this research will involve gathering anonymized traffic samples from various industrial network equipment. Some of this research will involve testing older products such as obsolete programmable logic controllers, newer products, such as an ultrasonic level gauge, as well as brand new prototypes, such as an industrialized firewall.

Some of the research may include the testing of tactics.  For example, if we install a deliberate bandwidth throttle and an intrusion detection system, is it reasonable to expect someone to act in time to prevent an attack against the control system?

There are many other ideas to be researched.  What we’re trying to do is to build a group of people who can help themselves build better more useful, and more secure control systems for our critical infrastructure.

And that’s the second goal of the Gathering.

Of course, the third goal is obvious: you never know what might come from the casual sharing of a war story or three at this Gathering, so I encourage you to bring a few good ones with you.  If our President can forge new understanding over a few beers, I think we ought to do the same.

Safe Creative #1007086770468

4 Responses to “Building a Better Control Systems Security Community”

  1. Bill Neet says:

    Warning – rant to follow – read at own risk…

    Why not add world hunger to the list and maybe universal health care too.

    There are already so much of this being done at other gatherings – like ICSJWG (old PCFS) ISA, SANS, LOGIIC,etc. that we all don’t have time for another group dealing with this – at least I don’t. Come join us at one of these vs starting something new.

    Also consider that people not about to sit a table with their competitors and discuss this openly – especially a control system vendor. Like it or not there ar competitive issues to deal with – not to mention the legal aspects of working together with competitors.
    While you are at it get out your checkbooks – if you want this “fixed” be willing to pay for it – if vendors are going to add security features or support security applicaitons be ready to compensate them for the work.
    If you are going to demand “secure systems” be ready to pay those who do it and reject those who don’t. Bet you purchasing folks will be all over that one. They won’t be the low cost vendors.
    Do I seem jaded – you bet. Been here – trying to do that – not getting very far.
    Customers are not demanding security –unless of course it is free.
    How about writing operations security policies that make sense and then asking the vendors to review and help implement them?
    How about doing a realistic risk asessment and then choosing the appropriate solutions insead of asking for everything “just in case”.
    End of rant….
    Answering rants welcome and appreciated.
    Bill

  2. I think that in Jake’s defense, you need to consider some of the objectives of these organizations before commenting…

    For starters, anything and everything that you discuss at ICSJWG is classified as “Sensitive, But Unclassified” (new classification is “Controlled Unclassified Information” (or “CUI”). ICSJWG expects everything to be given to them for free, and gives very little outside of the ICSJWG group (not discounting being a current member myself, but you have to *be* a member to fully appreciate the end-net result of whatever was discussed *within* ICSJWG; anyone *outside* of the ICSJWG won’t profit from the discussion).

    Two, DHS does *not* provide copies of their slides, presentations, or anything that is/was produced by or at DHS. Nothing. This is the current policy of DHS.

    Everything discussed is under scrutiny of “CIPAC” (or the “Critical Infrastructure Protection Advisory Council”). I know this because I work with 2 other CIPAC groups (other than ICSJWG) that require that we comply to CIPAC guidelines (as in signed documents). The same goes with the ICSJWG. If you think that you can walk away from an ICSJWG conference and openly discuss and share materials from that conference without ramifications, think again. What is discussed at ICSJWG *stays* at ICSJWG.

    Third, SANS, ISA, et. al. were established with a business profit model in mind. They exist to make money – nothing more. They *compete* with one another, and usually do *not* share and/or “play nicely” with one another. Case in point – any time you write a whitepaper for SANS, and submit it to them, it becomes their property (or at least, allowed unlimited access to your IP). Same goes with ISA.

    “The Gathering” is a small ‘grassroots’ group of like-minded people who are getting together to discuss this. Here’s where the differences begin…

    (1) Neither Jake nor I am doing this for a profit; the $50 is to cover for the room charge. Anything left over will be shared with the group.

    (2) After “The Gathering” has concluded, ALL materials will be posted on both the Infracritical web site, and discussed on the SCADASEC mailing list. Anyone is free to take what they wish, and use it however they see fit.

    (3) Individuals who contribute to “The Gathering” retain ALL rights to their IP, and are allowing us to share their IP for this function. Neither Jake nor myself retain any of the external IP, unless permission is given by the authors, and if permission is given, proper attribution is also given (name, telephone number, email addresses, etc.).

    (4) What is discussed at “The Gathering” may be openly discussed at other functions, etc.

    Hopefully, this has answered any questions that you may have about the event…

  3. Jake Brodsky says:

    First and foremost, the Gathering started off as a sort of SCADASEC meetup. It was my idea. However, I started wondering if there might be other reasons to socialize.

    I thought long and hard about it and discovered that we could make something more of this if we tried. I see many of the people who do good work and mean well at conferences. We’re all singing similar songs, but the lyrics don’t line up and many of us are in different keys.

    The problem with an effort by ISA is that it is all about control systems. The problem with SANS is that it’s all about IT. The problem with embedded systems conferences is that we’re not there so it’s about getting to market faster.

    There has to be a way to broaden these laser focused efforts and get people to look at a bigger picture. I sympathize with your remarks. I have been employed at a large water and sewer utility for 24 years and counting. During that career I’ve worked my way through the ranks starting as an instrumentation technician to my present position as a senior controls engineer. I attend standards committees. I am as close to the front lines of this problem as anyone can get. I also know that if we get hit with some cyber attack of any sort, that it could easily be me getting grilled in front of the Congress critters trying to explain how it happened. Trust me, that’s the very last place in the world that I want to be.

    I realize that we’ll be dragging many people kicking and screaming to this conference. We’re starting small and we’re figuring out how to scale up. The problem with most such conferences is where we’re going to attract the people from. ISA can draw from the control systems community. SANS can draw from the security research community. ICSJWG can draw from those in government. But the reality is that nobody is sitting in the middle of this, trying to make something happen. Every one of the aforementioned groups is doing this against the backdrop of their own context.

    What we need is a group to address the whole problem, not just the pieces. That’s what we’re trying to do here. We’re trying to find ways to set standards that the embedded systems developers can work from; we’re trying to find ways to set responsibilities that users can understand and work with; and we’re trying to set integration services so that they have a consistent set of deliverables that end users are expecting.

    As you yourself noted, the present system of having one group or another in disparate fashion release their own guidelines isn’t working all that well.

    We hope that by holding a friendly mixed conference and hack-athon that we can attract a group of like minded people who are experienced, yet willing to learn from each other.

    We could sure use your input. Are you interested?

  4. bill.neet says:

    I would love to attend but since my company won’t pay expenses I can’t afford it. Plus I have been stuck in Europe for some extra time due to the ash I can’t afford the time away either. Family concerns.

    I somewhat apologize for the rant but I have been doing security since 2002 (I am an engineer not a network or IT guy) and things are not getting better in my opinion. IMHO people are not really paying attention to the unique needs of the process control industry in all this. All they want to do is implement IT security solutions in a SCADA system. Let me be fairly specific.

    I deal in the process control system business. I sell a system – not a collection of COTS stuff you can assemble anyway you want. To quote one of my collegues from a competitive company “we are not in any way to be considered and information system or just some extension of the plant or enterprise LAN. Just because we use Ethernet, switches and PC does not mean we should be managed by IT or use the same policies. We are really proprietary systems built on COTS equipment”. Quite frankly we do not want the plant people unilaterially desiging and implementing their own security – will cause nothing but trouble for our types of systems.

    There are about 5 major control SYSTEM players in this industry and my guess is we do about 5000 systems per year from all the vendors.

    From an industry standpoint we -the industry – mostly do private industry. No grid, little power, little water/wastewater, no pipelines, and very little government business with our systems.

    Most of our systems are very small compared to an IT system and maybe compared to other systems like the grid or pipelines.

    Our systems are mostly self-contained and probably have 10 operator workstations (PC) and a few servers (<5). Some are bigger but the bulk – 80% are small.

    Our systems are installed in nasty places, on ships, platforms, jungles and other fun places where good help is hard to find. Especially maintenence help.

    So based on this all current IT based security solutions which we keep trying to implement in some for or other are not appropriate. Too expensive and/or too hard to maintain.

    So my problem with the above security groups is that they don't understand this – nor do most of the people (consultants) and they keep selling complex -hard to use solutions.

    Here is one thing I do know… if you install a security solution in a plant and it impacts production it will be a hard sell with management to keep it operational.

    So if the gathering will focus or address this situation it will be welcome but I really do not get that impression from you agenda.

    Focus on something the industry can implement using no IT resources or experience and you will really have something. Keep implementing big complex solutions and all you will do is prevent adoption and keep stuff insecure.

    You say that ISA is about control systems – not sure that is true as they deal with PLC based systems too – and they are not "control systems". If your model is not about process control then your gathering is not for me – and likely will be little for me to gain by attending.

Leave a Reply

You must be logged in to post a comment.