SCADA Security Basics: Integrity Trumps Availability

Submitted by Eric Byres on Tue, 2012-11-06 11:12

In last week's blog, Heather wrote an excellent summary of Mark Cooksley's network security presentation regarding "Why Industrial Networks are Different than IT Networks". In it she noted that the number one goal of ICS security is based on the concern for safety. This is spot-on in my opinion. However, there is more to consider when it comes to industrial security priorities…

ICS Security Priorities: Availability, Integrity, Confidentiality?

Last week’s article included the following table:

Priority

IT

SCADA/ICS
#1

Confidentiality

Availability
#2 Integrity Integrity
#3

Availability

Confidentiality

The first thing to take from this table is that (in general) IT and SCADA/ICS have different risk management priorities. Confidentiality is paramount for IT, while Availability is paramount for SCADA and ICS, followed by Integrity and Confidentiality (A-I-C). So far so good.

Or is it? Is Availability really the top priority for all control systems?

This table is taken directly from the ISA/IEC 62443-2-1 standards (formerly ISA-99) so it comes with excellent credentials. However, within a few hours of the blog going live, two readers immediately commented:

"With the network management systems and control centers, the priority should be 1- Integrity, 2-availability 3-confidentiality"

"While AIC may be the priority for a production system, I'd suggest that, for a Safety PLC, the priority should be IAC"

The above examples make sense - Integrity is more important that Availability for a safety system or a network management system.

Does Availability Really Trump Integrity for SCADA Systems?

Now these two exceptions got me wondering about ICS in general - have we got it wrong when we show availability being above integrity for control systems in general? The more I think about it, the more I think ISA/IEC 62443 is wrong. Integrity is nearly ALWAYS more important than availability in control systems (Confidentiality is still last).

Let's take a more general case than a safety system, one where production has limited impact on safety. For example, take an automation line making 10” frozen pizzas and putting them into cardboard packages for shipping to food stores. Now imagine that the control system sent the wrong message and the line started making 15" pizzas, ones too big for the boxes? As the production manager, which would you prefer to do:

  • continue making pizzas (even if they don't fit in the packaging) or
  • shut down and fix the issue?

If you picked the latter, then you choose integrity of your process over the availability of your process.

I think most engineers and most companies, even if safety isn't an issue, would pick integrity over availability. Certainly there is tolerance for some error (15.1" pizzas are fine), but ultimately there is a threshold where integrity trumps all.

In the case of food processing, production problems have limited impact on safety. If something goes wrong, it is likely more important to fix the production problem rather than keep the system running. This is a case where Integrity trumps Availability.

In fact, I think this preference has been built into our communications since the early days of control systems. What do we find in the last 2 or 4 bytes of every message set over a wire in a factory? Depending on the technology, you find a Frame Check Sequence (FCS), Cyclical Redundancy Check (CRC) or Block Character Check (BCC). And what do these bytes do? Allow the receiving device to validate the Integrity of a message. And what do they do if the integrity check fails? Discard the message. And if too many checks fail, the system goes down. So much for Availability.

If availability was more important than integrity, control systems vendors would let users turn off the integrity checks. But vendors don't give us that option - they quickly realized that bad information is worse than no information at all. Customers will be far more upset if a PLC opens the wrong valve rather than opening no valve at all.

Integrity of SCADA and ICS Systems is What Really Matters

I think that for nearly all modern production systems, integrity is what really matters the most, even when safety isn't involved. And if this is true, then we need to remember that in our security designs for ICS.

It doesn't mean that we say availability isn't important, because it is. Nothing ends a security project faster than a self-induced "Denial of Service".

But we need to demand that the ICS vendors supply products with integrity that can't be easily circumvented. This is a requirement that will not be answered by throwing encryption at the problem.

At the same time the user community needs to figure out how it can add integrity checks to the control systems that are installed and running today in our factories, refineries and utilities.

Without both users and vendors working on this, our SCADA and ICS systems will stay vulnerable for the next 20 years. That is something our world cannot afford.

Let me know your thoughts on Integrity and Availability and what needs to be done to secure systems for both types of risk.

Related Content to Download

Presentation - "Introduction to Network Security"

 

Download this 71 slide presentation and learn:

The differences between IT and ICS systems and high level solutions for securing industrial networks

  • What firewalls do and what they do not do
  • The OSI Model and how different technologies secure different layers of it
  • What VPNs are and the different types of encryption they use

 

Related Links

 

 RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres

Comments

14
Submitted by Shawn Gold (not verified) on Tue, 2012-11-06 13:11

Eric,

I'll challenge the premise that integrity is more important than availability in one key aspect; the likelihood of an integrity issue over an availability issue. The CRC, BCC or FCS codes were not designed to prevent cyber attacks but to prevent damaged data due to the flaky nature of the technology at the time. Now, the medium is ubiquitous and the likelihood of an integrity issue within a SCADA/ICS is arguably much less of a concern than the availability. Of course both are bad and while lack of integrity could be devastating, lack of availability is very much where we want to focus our concerns today.

Submitted by Ray Parks (not verified) on Tue, 2012-11-06 13:37

Feedback from electric utility customers and others has varied - but they are usually more worried about integrity of the control signals from the control center to the field device than with the integrity of the data from the field device to the control center. The theory in this case relies on the fact that attacks on control systems either act upon the communication stream from the operator to the field device or on the data from the field device to the operator. In some cases, e.g. Stuxnet, the attack acts on both - but this is usually because the attacker is trying to deny information to the operator.

MITMing or spoofing commands to the field device can cause changes in the process under control. This happens immediately and may not be reversible by the operator. For this reason, integrity of the control communication stream has the highest priority.

MITMing or spoofing the data presented back to the operator is done to cause the operator to take an action. Except in systems that have safety concerns dictating a rapid response, the operator should consider the data they're seeing and decide on an appropriate action. If the data does not present a consistent picture across the system and over time, the operator will probably decide the field device is broken - this is not uncommon. In a refinery, the inside operator will ask an outside operator to step around to the sensor and look at it manually. In an electric utility, a lineman will be dispatched to check the bus or substation. Except in those cases where "loss of view" can result in disastrous consequences, many processes can survive an integrity attack on the data stream, thus integrity of that data stream is not as important as for the command stream.

The problems arise with human or operational safety systems (i.e. protection relays, nuclear safety systems, liquid heater shutdowns). These should be using data available locally and thus be relatively immune to integrity attacks, with the major exception of distributed safety systems. An example is protection relay schemes that rely on data from relays at the other end of the electric bus. Wide Area Management (WAM) using phasor measurement units (PMUs) also acts like the distributed protection relay schemes but with much shorter response times. In these few specific cases, integrity of the data stream between devices (not device-operator) is vitally important.

Submitted by David Metcalf (not verified) on Tue, 2012-11-06 15:38

I think that this debate over the arrangement of these 3 system properties is a good starting point (inherited from IT security) but the categorisation is too coarse. I think this is supported in ICS security by ISA/IEC standards (which define more system attributes than CIA) and more generally in IT security by Professor Ross Anderson.

Each part of the system may require different properties to be prioritised. For example in a batch plant is the recipe management/storage system integrity or confidentiality more important. If each property was lost which would do most damage to the company?

I believe we need to tune our approach a little more.

Submitted by djohnd58 on Fri, 2012-11-16 00:55

Following on from my earlier comment, I fully support the recognition that for some categories of control systems Integrity is the most important attribute, typical examples being Safety systems, or those which guarantee a products quality.

Submitted by Hubert Kirrmann (not verified) on Wed, 2012-11-07 04:08

In SCADA systems, process control and manufacturing, integrity has priority over availability, since safety clearly depends on integrity, and availability depends on integrity.
However, there exist applications where safety depends on availability, and integrity breaches can be tolerated for a short time. This is for example the case in fly-by-wire aircrafts, where occasional outages are tolerated, as long as the normal data flow is restored. Control loops treat the integrity breaches as noise. But this particular case is a very small fraction, so the rule is: integrity primes over availability.

Submitted by Ruslan Stefanov (not verified) on Wed, 2012-11-07 06:27

The main difference between Availability and Integrity is in decision making process based on available information. In case of Availability violation Dispatcher in Control Center (or PLC) can't make any decision concerning industrial process (except the only decision to restore availability). In case of Integrity violation he will make incorrect decision based on incorrect information (providing he don't know that integrity is broken). Consequences of absent or wrong decision in both cases for industrial process are the same (providing strict time constraints during industrial control process when there is no time for restoring of availability). Only the correct decision is acceptable. So there is no difference between availability and integrity for industrial process and ICS.
Rather than discussing priority of CIA triad elements let's think about more adequate security terms (based on CIA and real world threats) for ICS and industrial process. For example:
1. Visibility of industrial process (availability & integrity)
2. Manageability of industrial process (availability & integrity)
3. Integrity of parameters of industrial process (integrity)
4. Continuity of industrial process (availability)
5. Lack of possibilities for concealing of malicious or criminal actions (integrity)

Submitted by djohnd58 on Sun, 2012-11-11 06:14

Would this suggest that every ICS needs assessed to identify the relative priority/weighting of Integrity/Availability/Confidentiality (which I'd still include for some product sectors, e.g. military), with, perhaps, controls being applied on the basis of which attribute has the highest priority. Perhaps this should also be applied to some other system types not usually included within the scope of ICS (but sometimes managed by the engineering, rather than IT, teams) such as security systems? What's more important in a security CCTV system, that there's a picture on the monitor, or that the picture actually shows what's there?

Typical priorities could include:

IAC - Safety PLC
ICA - System holding key Intellectual Property
AIC - Services (e.g. H&V) system

Once we've identified the relative IAC priorities what are the next steps? I'd suggest that, in most cases, there will be a common set of controls that need to be applied irrespective of which attribute has highest priority. This would include basics such as:

1. Access Control (including hardware access, software access, network segregation) - Influences IAC
2. Malware protection (Host Intrusion Prevention, Anti-Virus, Patching, Network Intrusion Detection etc.) - IAC
3. Change Control - I
4. Maintenance (including log auditing) - I
5. Encryption - C
6. Recovery arrangements (including redundancy)- A

In all scenarios, I'd still suggest a graded approach with increasing levels of control being applied as the IAC requirements increase, e.g. based on the impact of the system, as applied in IEC61508 where different levels of change control are required as the Safety integrity level increases.

An understanding of the importance of IAC on each ICS will also assist in understanding the impact of a vulnerability on a system, where the ICS-CERT alerts often identify the impact of a vulnerability in terms of Denial of Service' (i.e. Availability), 'Remote Code Execution' (i.e. Integrity), or Information Disclosure (i.e. Confidentiality), and hence the risk presented to the asset of a vulnerability

Submitted by Michael A. Anderson (not verified) on Wed, 2012-11-07 07:08

Good points made, but I look at it as if an operator is exposed to a dangerous situation where a control/safety system command needs to get out. In that case everyone wants the chance of the command working even if it is partially corrupted. Easy choice of availability over integrity. When you push a button in the field you expect it to work; same for a communicated command. Naturally we're striving for all 3 factors to be met, but I don't want integrity or confidentiality concerns interfering in safety or high value production whether its from CRC, Kerboros, or simple forgotten passwords.

Submitted by Dale Peterson (not verified) on Wed, 2012-11-07 08:37

Not a comment on you or Tofino - but the title of a presentation I gave at the IPA forum on Oct 25th. It was the PG version. The R rated version is scheduled for the SANS Summit and plays off the security term use and honesty/forthright definition. We are lacking both in the ICS security community.

I don't think it matters whether Availability is 1a and Integrity is 1b or vice versa. The main point is we need to get past the view that Availability is #1 and Integrity is an afterthought or much lower (like Confidentiality). It is yet another lesson demonstrated by Stuxnet where Availability was maintained, but Integrity was lost. Both are essential for most SCADA and DCS. The difference is most owner/operators have done a great job on availability, there quite frankly is no integrity in most ICS.

Dale Peterson

Submitted by Ralph (not verified) on Wed, 2012-11-07 08:53

The trouble we are always going to have is going to be generalizing CIA v.s. AIC for ICS when ICS is used to make pizza and ICS is also used to control power systems. As Ray pointed out, in power systems the importance of integrity for data being used for control is different than the importance of integrity for data that conveys measurements from the system to the operators who are controlling the system where availability is considered more important. Yet it is all ICS. I agree with David that this space is way too complex to assume that any single set of requirements for a given application applies to any other application even if they both use what we call "ICS".

Submitted by evan.hand on Thu, 2012-11-08 08:01

This is a chicken versus the egg type of question; If you do not have a processor or communication stream running, then it does not matter what code or data that you have in the system, it will not work. By the same token if you have bad data or the wrong instruction, it will not work.

The original intent of the AIC model was to highlight that IACS is different from IT systems. It was to highlight that control systems cannot go down without possible dire consequences to people and equipment. Taking it beyond
that would just be more confusing.

I would agree that there is equal weighting between the two requirements for most systems. Not as easy to display the difference in a simple chart, and does not drive home the difference to primarily data centric (as opposed to
physics centric) people and processes. Though a potentially interesting intellectual exercise, I do not see the benefit to change the model.

Submitted by cctv cameras Miami (not verified) on Mon, 2012-12-10 21:36

Mark Cooksley's network security presentation is very informative and I've enjoyed researching through this post. Knowing about security basics is very helpful to manage any security systems nicely. Thanks.

Submitted by Dexter Bosque (not verified) on Sun, 2013-05-05 00:44

Mark Cooksley's network security presentation is very informative and I've enjoyed researching through this post. Knowing about security basics is very helpful to manage any security systems nicely. Thanks.

Submitted by Gadgets (not verified) on Fri, 2013-10-25 22:02

Mark Cooksley's network security presentation is very informative and I've enjoyed researching through this post. Knowing about security basics is very helpful to manage any security systems nicely. Thanks.

Add new comment