Comment from Ron Southworth
Time: January 19, 2007, 4:05 pm

Hi Dale,

I think I Beat Jake to this one…

For the most part information to/ from from field devices do not as a general rule require security for confidentiality requirements and the integrity of the information is hopefully handled in the protocol and in the communications layer.

If it was a pre-requisite for field device operation these discussions would have taken place years ago.

The requirement is born out of firstly a need to be seen to protect safety systems and next to provide utilities with a degree of mitigation to be capable of having business continuity if some untrusted party is attempting to compromise the field device.

We have a very new bi directional power feeder system here in Australia that requires control actions for safety and protection and load dynamics to react to a change in condition parameters within 4 ms. How do you put security encryption on that sort of control system and meet the control action timing criteria. What is the key parameter in this instance above security - Availability. This is something that needs to be part of the philosophical understanding of any research focus. Integrity in a control systems sense is not necessarily in the same context as in an IT system. Integrity for control systems field devices is centered in alteration of the information by the propagation method of the information and not looking outside of that context considering deliberate tampering of a message.

The Guy’s from INL when they present their intro to SCADA security course and describe the top three of security put Availability first. They have got it right.

For Control systems, especially with Critical Infrastructure you have to put Availability First.

We need to take an all in approach to risk because with control systems some times if you don’t do something in exactly a certain way things go bang or boom and people DIE or get very very ill and it costs Lot’s of money to fix or money is lost. This is what causes the emotional response and the focus away from the first risk mitigation technique, Remove the risk wherever possible. otherwise go Physical first, isolate that key link or group of field devices from the rest of the system and protect the perimeter to the group. Jake made the point of comparison to safety systems equally valid.

To be effective with implementing security for field devices or for SCADA systems end to end requires a more applied approach to the research and wherever possible leverage of existing methodologies and practices from the IT world and or military.

Taking standard security to the field devices is just not going to work in a lot of cases because encryption methods soak up time crunching numbers. DNP3 works around this in the proposed security standard and does offer a way forward if adopted. What needs to happen is for applied researchers to work at implementing a good security proposal like DNP3’s and build a good stack to meet this standard.

Essentially I am re just re-enforcing what Jake stated previously because he is quite correct.

A lightweight encryption method is a possible applied research avenue to pursue but not for the reasons you outlined. A lightweight encryption key life only needs to be short enough to be secure enough for the time a “command sequence” is occurring between the field device and master/ peer. What needs to be the focus is developing a device or method for providing encryption that can be light weight and very fast.

It is still just not going to be practical in some situations to use encryption as a mitigation method - Until we have the ability to push information faster than the speed of light!

Thanks again for raising the topic. The more it is discussed the quicker we will reach a range of workable solutions.

Comment from Jake Brodsky
Time: January 22, 2007, 8:52 pm

Ron said it pretty well, and there isn’t much left to say.

I would only add that there are many of us still using 9600 BPS and we’ll probably keep using it for the forseable future. Licensed radio isn’t sexy, but it is commonly in use among water utilities.

In addition I have observed that point counts tend to double every five years (I have modestly named this Brodsky’s Corolary to Moore’s Law). With that in mind, we need to overdesign the telecommunications networks so that we have capacity for the future. Letting security take over the extra bandwidth means we have that much less bandwidth for point count growth. We’ve been using similar telecommunications technologies for telecommunications for about ten years or more. If we didn’t think this far ahead, we’d end up spending a lot more money retrofitting the field. In many cases, the technology simply may not be there. You can’t throw spread spectrum technology at everything…

Oh, one other thing: even if the point count issue wasn’t reason enough to keep a bandwidth reserve, there are still issues of latency. Inline encryption such as AGA-12 proposes does introduce a substantial degree of latency to the equation. We use bandwidth for reasons besides just capacity, Dale. Sometimes we are thinking of responsiveness.

Comment from Dale Peterson
Time: January 22, 2007, 11:01 pm

Guys - - All I’m saying is let’s look at the numbers and see what the real impact is, in all the areas you mention. There are likely to be low bandwidth, high response time requirement systems where it is not feasible. There are likely to be a growing number of higher bandwidth systems where it will be feasible now and in the future.

I think the community should have a goal of at least having the option of verifying the source and data integrity of control system requests and responses.

Comment from Erik Hjelmvik
Time: January 23, 2007, 5:46 am

Providing a response time in the size of 4ms (as Ron and his countrymen is having) shouldn’t really be a problem for normal cryptosystems. Normal block- and stream ciphers are really efficeient and are also designed to run fast in both hardware and software. For Rijndael (AES) the introduced latency is in the size of nanoseconds rather than micro- or milliseconds! Encrypting/decrypting data also don’t require very much resources (especially concidering the small amounts of data that are sent/recieved in SCADA/DCS networks).

However, is there really a need for encrypting the whole messages? As Ron points out:
“information to/ from from field devices do not as a general rule require security for confidentiality”

I’d say that integrity and authentication is what we really are interrested in. And this can be solved simply by appending an encrypted hash of the transmitted message to each packet. In this situation bot shared key cryptosystems and public key cryptosystems (such as RSA or Diffie Hellman) can be used since the amount of data that needs to be encrypted is very small.

I believe that there is some confusion regarding WHY cryptosystems should be used in control systems.
In cyrptography the focus normally is on confidentiality since it traditionally has been military and privacy needs that have been pushing cryptography forward. However the needs for control systems are totally different, and we need to understand this difference before we start using crypto systems. The fact that people are thinking of encrypting their control system data is a sign that they maybe havn’t really understod IF and WHY they need a crypto system.

Comment from Ron Southworth
Time: January 23, 2007, 9:59 am

Hi Dale and Erik.
I am enjoying the discussion.

It would certainly be a worthwhile effort to look at some statistics as to the real risk to the community where we compare perhaps what field devices actually pose as a security problem VS the communication medium that connects the devices from the field to Server.

Dale, I think I indicated that the approach to encrypting field device communications in each instance needs to be looked at firstly from a Risk basis. I think one of Mat Frantz’s comments about software design techniques from a while ago is very valid and worth everyone remembering.

Field devices are usually secured in some form of physical protection. The I/O Servers/ HMI are in some form of physical protection. It is not until you connect or interconnect them to the “outside world” that the external threat exists.

The internal threats are there all the time. I know this very well from first hand experience and I can relate more detail off Blog if this is needed. The threat from within is far more real and ever present and attacks happen much more frequently that we want to know and is often covered up. I see this area as needing much more attention to security in the immediate sense. The field devices are a longer term issue to resolve but probably easier to see methods to solve from a technical perspective.

Where systems have merged into the plug and play or COTS world seems to be what has caused an increase in perceived risk from “external vectors”. That does not mean I want to ban plug and play or COTS or any equipment or software present or future.

The CI operational environment of software and hardware needs to be subjected to better testing and rigour that what has been done in recent times before it is released to the unsuspecting end user. Security may be an effective tool assist in the improvement of the quality of code and reliability of the future Field devices and systems.

Erik, the method you describe with hashing I have seen work in some control systems using token style applications and these systems are very old even by my standards so it is possable.

As you say the why is very important. Integrity requirements are not always the same for every system. I would say that when is important and I think you have indicated this as well in part Erik. I don’t think that individual field data requires confidentiality unless it is classified as enterprise INFORMATION. I hope this statement makes sense.

The speed of crypto is still a function of the processor it is running on. Ns times for crypto requires some slick processing and math even for small data blocks. Of as much improtance is effective and reliable key management. How much extra does this add to the system overhead given that we are talking about approximately 30% for AGA12 without distributed key management.

We still seem to be concentrating far too much on the easy 20% and not so much on the 80%.

Effective change management, improving traceability & Operator Training -all will reduce the 80% value significantly and would provide a far better return on investment if we concentrated in this area. The task is some what more difficult. Perhaps this is why we look outside because it is easier?

Have you seen the DNP3 draft security standards Dale? I would be interested in your thoughts of the draft as a methodology to securing field devices. I see that this is an effective method and that the challenge before me is finding implimentations that are compliant with the standard or do you consider there are weaknesses in the proposed standard? I think AGA12 is a valid alternate where bandwidth is not so much of an issue.

The key distribution and management challenges are what is in need of addressing or would you disagree?

Comment from Julian L. Rrushi
Time: January 23, 2007, 6:38 pm

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Hi Eric,

Thank you for the interesting comment.

Yes, SCADA communications basically need integrity and authentication. Confidentiality may not be needed since it is not a problem if an adversary reads the contents of SCADA protocol traffic. But let me, please, describe a brand new old scenario. Suppose a legitimate MTU sends a message which closes valves. Eve is there listening, so she records the aforementioned message along with the corresponding encrypted hash. Eve waits till the controlled facility is in a state in which closing valves is dangerous. At that point Eve sends to a SCADA field device the intercepted message and its encrypted hash. The receiving SCADA field device verifies the authenticity and integrity of the message. Since both of these factors will be valid the receiving SCADA field device will close valves. If Eve couldn’t read SCADA protocol messages she wouldn’t be able to select a message which she is sure that will close valves. The replay attack may not be so simple due to fields such as the transaction identifier or else, or the use of sequence numbers (which however are not present actually), but with a little patience Eve could exploit the lack of confidentiality.

Yes, SCADA/DCS protocols generally generate little traffic. In MODBUS TCP for example we may have an ADU frame as small as 8 bytes. But the effective amount of control data to be passed through an encryption engine may not be that small as it may seem. SCADA protocol messages tend to be highly repetitive. In addition, it may be relatively easy to get sensor data from a fieldbus network and construct the packet which has been encrypted. Padding in this case could alleviate the issue, otherwise Eve could be able to understand each encrypted message without possessing any valid cryptographic key.

Allow me please to write that I don’t agree when you write that a field device running a normal cryptosystem could provide a response time in the size of 4ms. It is true that normal block and stream ciphers are really efficient and are designed to run fast in both hardware and software. In fact the barrier is not represented by the fast block and stream ciphers, but by the limited computational power and memory of the devices where they run on, i.e. SCADA field devices. But of course I may be wrong. We may resolve the issue quite easily. Tomorrow at S4 Rob lampert will provide
some measurements of the cost of running cryptographic algorithms on microcontrollers.

Best regards,
Julian L. Rrushi

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFtj1crq0d5u53c2QRAsDVAKCEZK8qVYSOOdxSd/21i+T6ZJYQugCeNm0n
axYSCw4hOtlErIVgf2K+ImQ=
=8ZpB
—–END PGP SIGNATURE—–

Comment from Ron Southworth
Time: January 23, 2007, 9:40 pm

Hi Julian,

I can see the probability of man in the middle attacks being more likely to occurr in higher bandwidth “externally” connected field devices.

One of the challenges with field devices that I am certain you can apreciate is the life cycles. 15 to 25 years of expected reliable service. I dont think it is reasonable to expect a field device to be future proof for security requirements for their whole life cycle. I can see external appliances being used to secure the perimiter with life cycles of say 5 years possibly filling the need?

I look forward to hearing about some of the measurements in the coming weeks.

Comment from Julian L. Rrushi
Time: January 23, 2007, 11:57 pm

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

With regard to the issue whether confidentiality is needed in SCADA/PCS systems I would add to my previous post that timestamps which seem an obvious solution to replay attacks may not be that feasible in control networks. Timestamps would require synchronization among SCADA field devices, which in turn emplies the need for a protocol such as NTP (network time protocol). Running NTP within a process control network is in conflict with the principal that control traffic should not be mixed with non-control traffic. Furthermore, field devices would be required to run an implementation of NTP, which is quite out of question for now. But the matter is not over. NTP itself would need cryptography since NTP messages may be spoofed. Thus in that quite extreme case NTP messages woudl require authentication and integrity checking. So, here we fall into an endless loop. Thus, I believe that confidentiality is as important as integrity and authenticity in process control network. Thanks.

Best regards,
Julian L. Rrushi
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFtok0rq0d5u53c2QRAm/KAJ9rBoYrdw+CuSv0u8ezHe9eL05zNgCgkiXK
Pzss/437MSx6StxXQhBUnsY=
=rSm/
—–END PGP SIGNATURE—–

Comment from Ron Southworth
Time: January 24, 2007, 7:27 am

Julian
Time syncronisation is handled in a couple of ways presently with field devices. A number of utilities use GPS as a means to provide time syncronisation. I think from memory some regulatory compliance requirements specify a standard source of accuracy to be available for the field devices (eg A reference to a Cesium clock for NERC requirements) Some industrial grade Switch appliances such as RUGGEDCOM have this feature.No Need for NTP to be transmitted over the comms link it can be generated locally from the Switch.

The other method is within the protocol often used by CI- DNP3. DNP3 also has time stamping of all events.

There are some concerns with GPS systems being Jammed but how far do we have to mitigate obscure tisks ???

Comment from Erik Hjelmvik
Time: January 24, 2007, 8:16 am

Good discussion…

Julian,
As you mentioned timestamps are normally used to disable the use of replay attacks, this method can be used for both Message Authentication Codes (MAC) and public key signatures. However the simplest solution is to add a “nonce” (a number that is only allowed to exist once) to the data before creating the hash. This technique is very simple and requires no additional services such as NTP. If Eve would do a replay attack, on data sent from Alice to Bob, Bob will se that the recieved nonce value has already been recieved so he simply drops the packet.

Ron,
You are right, GPS is often used in control and SCADA systems (at least in electricity production and distribution systems anyway) to provide tome synchronisation. Regarding jammed GPS systems I would say that this is a topic thas hasn’t been investigated enough, not that I know of anyway. However I’d say Jamming can be handled, but GPS spoofing is a bit more scary in my opinion. And loosing the time synchronisation, due to spoofed GPS data, can have a much grater impact than just disabling any encrypted communication.

Comment from Ron Southworth
Time: January 24, 2007, 4:21 pm

Hi Erik,
Thankyou to everyone for the continuing this.

TISN Australia has done a paper on Jamming of GPS signals.
http://www.tisn.gov.au/agd/WWW/rwpattach.nsf/VAP/(930C12A9101F61D43493D44C70E84EAA)~GNSS+Advice+to+CEOs+with+CIO+ref+2.doc.pdf/$file/GNSS+Advice+to+CEOs+with+CIO+ref+2.doc.pdf

The next generation of GPS is going to be more robust with respect to jamming but as anyone with RF experiece we know RF has some properties that lend itself to Jamming at the very least in a localised area being effective. Spofing of GPS signals is also possable but would require some very clever folk. At what point would an expert determine that the return for effort regardless of motivation would not be more effective with more traditional “precussive” means of denial of service or distributed denial of service. I think that as the need for the accurate reconstrution of sequence of events that effect interconnected systems like the energy sector accuracy to absolute time becomes more of an issue.

I suspect that if contaminant issues arise and become frequent in the water industry the more accurate the time of exposure is known the more effective is the management of the situation . In an industry where things happen slowly this is one thing that happens quite fast. This harkens back to my point previously made. There are some risks that we just have to live with and that we need to change cultural issues to effectively mitigate.

As you say Erik there are a number of techniques that can be employed to stop replay attacks. I can still see the long term need to harden our field control devices but also to have a perimiter device in front of the field controller that can be changed over. Dare I say a plug and play and throw away every 5 years or less should the technques to work around the security features be necessary.

My reasonig is that the primary function for the field devce is to control and monitor a process. At what point should it be acceptable to forgo processor availability to its process control and monitoring functions to handle encryption and decryption. Maybe special chisets can be utilised to perform the crypt functions

I wonder if Eric Byres has share options??

I think he may be on a very good idea with the Tofino product. I wonder if he has considered this aspect as well.