How do you prevent unauthorized changes to smart instrument settings without limiting usability?

MikeBoudreaux's picture
Submitted by MikeBoudreaux on Mon, 09/14/2009 - 18:03.

Following up on a recent LinkedIn discussion that spread across several control and safety groups about whether operators should be free to make their own changes to instrumentation settings... The majority of people responded that these kinds of changes should be subject to management of change. How do you prevent unauthorized changes in your facilities? Do you take a lock-down approach, implementing write-protection on smart devices? Or do you take a procedural approach, relying on management of change controls such as training, procedures, and policies? What are the trade-offs associate with each of these approaches?

For safety instrumented systems, IEC 61511-1 clause 11.6.4 (and ANSI/ISA 84) requires that smart sensors are write-protected to prevent inadvertent modification from a remote location, unless appropriate safety review allows the use of read/write. The standard requires that the review should take into account human factors such as failure to follow procedures. Many people interpret this to mean that the write-protection feature should be enabled on HART devices when they are in service. Is this how your company interprets this requirement?

‹ Performance Impact from Implementing Security Process Control Network Security Weak Links ›

Conversation on Twitter

MikeBoudreaux's picture
Submitted by MikeBoudreaux on Tue, 09/15/2009 - 15:10.

Here is a related conversation on Twitter between SCADAPer and me, from this morning.

  • MikeBoudreaux: I asked "How do you prevent unauthorized changes to smart instrument settings without limiting usability?" at #PAutoUP http://bit.ly/OIEca
  • SCADAPer: That is only part of effective change management not just for safety but for security and integrity of the process
  • SCADAPer: why are the two "seen" as being mutually exclusive how often do you change a process once is is operating?
  • MikeBoudreaux: I agree, it is a question of safety and security. It can also about culture and management, and not just technology.
  • MikeBoudreaux: In many cases, increased flexibility is considered more difficult because it is harder to make decisions.
  • MikeBoudreaux: Which is easier: "Do you want red, yellow, green, or blue?" vs. "What color do yo want?" - Depends on the situation?
  • SCADAPer: So true it is all of these things and more., Well, how about is it more a question on resilience! http://bit.ly/ff3BC
  • MikeBoudreaux: Similarly, flexibility and security are trade-offs for each other. More security = less flexibility, and vice versa.
  • SCADAPer: Situational awareness / Abnormal situation mgmt it is all about Grey scale mixing with color isnt it ? :)
  • MikeBoudreaux: Locking devices w/ write-protection increases security, but decreases flexibility & usability. Not always good tradeoff.
  • SCADAPer: DUNNO I think good security still permits flexibility it is more about authorized authenticated activities :)
  • SCADAPer: how about what you said is really more about product knowledge and change management procedures training
  • SCADAPer: as you say a lot of it all comes back to culture safety and security both benefit from an evolution of culture
  • MikeBoudreaux: I agree, but culture and mangement ensures people follow procedures and best practices, and don't cut corners.
  • SCADAPer: have you ever seen a HART device randomly go into program mode because of noise from a VFD drive locking the instrument stopped the problem
  • MikeBoudreaux: I am hard pressed to come up w/example where increasing security doesn't negatively affect usability. Please help. :-)
  • SCADAPer: Well I think that Hart instrument problem is a good example .
  • SCADAPer: Yes it is an additional step and something to remember but the benefit is a more reliable process
  • SCADAPer: using RFID security cards to automate logging into the HMI after a biometric of the operator has been verified.
  • SCADAPer: or maybe you have not seen effective security being implemented before Good security is like good safety - Layered
  • MikeBoudreaux: I agree. If decrease in usability is outweighed by the value of increased reliablity, then you're better off w/security.
  • SCADAPer: Good security increases availability and safety if you think about it
  • MikeBoudreaux: I agree. Well implemented security is easier than poorly implemented, but there is always a tradeoff vs. no security.
  • MikeBoudreaux: Not saying security is bad - I'm pointing out usability as a tradeoff. Some security technologies are easier than others.

Twitter Discussions

RonSouthworth's picture
Submitted by RonSouthworth on Tue, 09/15/2009 - 18:18.

Hi Mike,

Thanks for the speed debate more, really a mutual agreement fest on twitter, certainly a bit of fun. I am enjoying tweet deck immensely a great data mining tool for an insomniac like me.

To your most recent tweet on the selection of technologies, well that is quite true that some technologies fit a given enterprise far better that others. Re usability being a trade off. What you have said is a common complaint and the underlying causes to that complaint can be quite embroiled so there is some room for putting out some ideas and see where this takes us.

The sorts of challenges facing ICS e.g. compliance to legislation for one thing can cause this complaint mantra. I know you are a proponent of safety, and both topics have a lot of synergy. This to me applies to how we perceive them and assimilate them into the enterprise culture.

You may have heard Security people talking about resilience and I think this is a big part of a more unified approach to enterprise thinking. If you look at implementing security and safety for that matter with this in mind then this may help to understand the extra steps and processes we are doing in the name of security that really are about keeping things going regardless of the initial cause for upset to nominal operation of our ICS.

I don't think that security products are very unified, some single brand solutions are certainly further down the road than others to providing the sort of expectations traditionally on the hearts and minds of the controls engineering kin, there is however progress from as little as two years ago. The secret to a large amount of effective improvements for ICS security are largely about People policies and processes and tweaking what tech we have installed can yield significant improvements something in the order of 60% without capital outlay - a lot of outlay in documentation and in configuration management let's not under estimate the effort but I would argue that this is what is needed, some concerted effort.

Talk with you more soon

Ron

Security vs. usability examples

MikeBoudreaux's picture
Submitted by MikeBoudreaux on Wed, 09/16/2009 - 04:11.

You listed some very good examples where security can be provided without significantly sacrificing usability. I was thinking about biometrics, smartcards, and RFID too.

Here's one example that I encountered today where security got in the way of usability. I wanted to copy our conversation from Twitter into this discussion. Turns out, security got in the way because your tweets are protected. Even though you used the #PAutoUP tag, your tweets don't appear in the search. It took me a while to figure out how to easily extract our conversation. Not an easy task. Not a control or safety system example, but somewhat related to our conversation at least. :-)

To be balanced on the security is our friend side of things, the DeltaV smart switches that were released last year are an example where technology makes implementing security easier. Sure, if the switches are locked down you can't add additional devices to the network, but this provides added security which is valuable. Also, the switches can be easily unlocked and so it isn't such a burden. Besides, once a plant is running, how often are you installing new devices on the control network? It's not something you do every day.

Related to locking-down smart instrumentation, the HART v6 specification does make it easier to prevent unauthorized remote access, by providing software locks instead of hardware jumpers to implement write-protection. Neither option is as flexible as no write-protection, but one is many times easier than the other if you decide that you need to lock down devices for security.

Porting data in/out of a SCADA domain

RonSouthworth's picture
Submitted by RonSouthworth on Wed, 09/16/2009 - 20:56.

Hi Mike,

Well the issue around twitter (porting data between domains or network segments) is a real challenge in the ICS world This is actually a very a good scenario to discuss. How do you balance availability to security and get production data to/from the enterprise. That plant floor to boardroom marketing stuff that makes me cringe every time I see or hear a presentation (it means so much configuration and design work in practice to keep the wheels turning safely and securly)

You cannot easily use a USB thumb drive as you guys like calling them in your part of the world. The recent conflicker virus is a classic reminder of how easy it is to infect a system & infection of a system may lead to a loss of availability. To not implement the lock-down protocol for these portable devices for use in your control system is asking for real trouble and to not have a policy for authorised use equally is not very wise. You may note I did not suggest banning them. This is virtually impossible to administer in many enterprises and to sack someone over "forgetting" and using a thumb drive is just as impractical, you are better to issue devices used for specific purposes to staff and have limited approved activities and locations (consoles) for which these drives can be used to port data to from.

Behind the scenes you have implemented a range of controls including the likes of A/V and networking segmentation, good practices on firewall rule sets and switch settings all of these settings should be and are usually very easy and un-complicated compared to business systems configurations BTW.

These measure will actually facilitate the activity for certain risk appetites in a number of enterprises. Other situations where the risks and impact consequences are just too high you have to look at similar mitigation technologies and procedures including limiting data flow to only be "pushed" from the control domain to the business domain, TCP "data diode" appliances databases in demilitarized segments and the like forms of controls.

The data to be ported does have a value to the business and so has a justification for each expenditure necessary to facilitate the given control measure to allow the sort of transparency to the end users to be implemented. Good effective security when an end user Operator Shift supervisor etc is performing an authorised activity should be actually as transparent as is practicable, the inconvenience of authenticating the person being the only time the end user is actually being reminded that the need for the password entry is actually there in order to protect availability of the production environment.

I hope you can see what I am trying to convey Mike. The symptom of usability things getting in the way is actually more issues of education, knowledge gaps, experience and training and culture.

Ron Southworth
(- list admin @SCADAPer spective or the "SCADA GOSPEL" mail list)