See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/289881199

Industrial Control System (ICS) Cyber Security for Water and Wastewater
Systems

Chapter · October 2014

DOI: 10.1007/978-3-319-01092-2_3

CITATIONS READS

24 489

1 author:

Joe Weiss
Applied Control Solutions, LLC
7 PUBLICATIONS   36 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Lack of authentication and security of process sensing View project

All content following this page was uploaded by Joe Weiss on 18 November 2016.

The user has requested enhancement of the downloaded file.

 Industrial Control System (ICS) Cyber Security for Water and WasteWater Systems

Joe Weiss, PE, CISM, CRISC, ISA Fellow, IEEE Senior Member

Industrial Control Systems (ICSs) operate industrial infrastructures worldwide including,

water/wastewater, electric power, oil/gas, pipelines, chemicals, mining, pharmaceuticals,
transportation, and manufacturing. ICSs measure, control, and provide a view of the process
(once only the domain of the operator). ICSs are susceptible to cyber threats and there have
been numerous cases where water and wastewater facilities have suffered either unintentional or
malicious cyber attacks. This chapter will explain what is ICS cyber security, how it applies to
the water/wastewater domain, and what can be done to better secure water/wastewater ICSs.

1. Water/Waster Control System Cyber security

1.1 Background

Industrial Control Systems (ICSs) operate the industrial infrastructures world-wide

including electric power, water, oil/gas, pipelines, chemicals, mining, pharmaceuticals,

transportation, and manufacturing. ICSs measure, control, and provide a view of the

process (once only the domain of the operator). These types of systems are commonly

utilized throughout the global industrial infrastructures. The commonality of ICSs and

their architecture enabled the International Society of Automation (ISA) to establish one

general process industry committee for cyber security - S99 [1].

Security is like a three-legged stool consisting of physical security, Information

Technology (IT) security and ICS security. The first leg is physical security. It is

generally well-understood and often addressed by experts coming from the military or

law enforcement. The second is IT security. It generally deals with traditional

commercial off-the-shelf (COTS) hardware and software and connections to the Internet

with experts coming from IT and the military. There is little doubt that IT security is

1
necessary and that systems are continuously being probed, tested, and hacked. The third

leg, ICS security, is much less understood, has little expertise, is often not considered

critical. Those working in this area are generally either from the IT security community

with little knowledge of ICSs or ICS experts knowledgeable in the operation of systems,

not security.

ICS cyber security was formally identified in the mid-late 1990’s with the publication of

Presidential Decision Directive (PDD) 63 [2]. It was at this time the US Department of

Energy’s (DOE) National Laboratories starting performing cyber security assessments of

utilities on a confidential (not classified) basis. As these assessments were not made

public, there was little knowledge of the results unless the utilities’ were willing to share

their results.

At the time, ICS cyber security awareness was very low and its perceived importance

even lower. Generally, it was viewed as a corporate IT issue with little direct impact on

power plant or grid operation. Moreover, it was viewed as a hindrance to ICS technology

advancements. From a security perspective, ICSs were generally isolated networks and

the concept of “security by obscurity” was alive and well. As security was not a

consideration, there was little reason to question the need for tighter system integration.

The fundamental reason for securing ICSs is to maintain the mission of the systems be it

produce or deliver electricity, make or distribute gasoline, provide clean water, etc. I do

not believe it is possible to fully electronically secure ICSs. However, we can make them

2
more secure and also minimize the possibilities of unintentional incidents that have

already cost hundreds of millions of dollars as well as a number of lives.

Cybersecurity is generally viewed in the context of traditional business Information

Technology (IT) systems and Defense computer systems. Industrial Control Systems

(ICSs) are frequently not viewed as “computers” nor are they often considered to be

susceptible to cybersecurity threats. Consequently, cyber security is taught within the

Computer Science Departments focusing on traditional IT concepts. Control system

theory and applications for ICSs are addressed in the various engineering disciplines but

do not address computer security.

1.2 What are ICSs [3]

Industrial Control Systems (ICSs) operate the industrial infrastructures world-wide

including electric power, water, oil/gas, pipelines, chemicals, mining, pharmaceuticals,

transportation, and manufacturing. ICSs measure, control, and provide a view of the

process (once only the domain of the operator). Typical types of ICSs include

Supervisory Control and Data Acquisition (SCADA), Distributed Control Systems

(DCS), Programmable Logic Controllers (PLC), Remote Terminal Units (RTU), and field

instrumentation. ICSs are commonly utilized throughout the global industrial

infrastructures. Almost all university engineering programs offer courses in control

system theory.

3
ICS networks and workstations including the human-machine interface (HMI) are

generally IT-like systems and may be susceptible to standard IT vulnerabilities and

threats. Consequently, they can utilize IT security technologies and traditional IT

education and training apply. The field instrumentation and controllers generally do not

utilize commercial-off-the-shelf operating systems and are computer resource

constrained. They often use proprietary real time operating systems (RTOS) or embedded

processors. These systems have different operating requirements and can be impacted by

cyber vulnerabilities typical of IT systems and also cyber vulnerabilities unique to ICSs.

Figure illustrates the different aspects of an ICS from the Windows-based workstation

with built-in security to the field elements with generally little to no security.

4
Figure 1 Control System Basics

ICSs continue to be upgraded with advanced communication capabilities and networked

to improve process efficiency, productivity, regulatory compliance, and safety. This

networking can be within a facility or even between facilities continents apart. When an

ICS does not operate properly, it can result in impacts ranging from minor to

catastrophic. Consequently, there is a critical need to ensure that electronic impacts do

not cause, or enable, misoperation of ICSs.

1.3 Securing ICS and IT Systems

Securing systems consists of physical security, IT security and ICS security. Physical

security is generally well-understood and often addressed by experts coming from the

military or law enforcement. IT security generally deals with traditional commercial off-

the-shelf (COTS) hardware and software and connections to the Internet with experts

coming from IT and the military. There is little doubt that IT security is necessary and

that systems are continuously being probed, tested, and hacked. The third aspect unique

to the industrial community, ICS security, is much less understood, has little expertise,

and is often not considered critical. Those working in this area are generally either from

the IT security community with little knowledge of ICSs or ICS experts knowledgeable

in the operation of systems, not security.

5
The Triad of Confidentiality, Integrity, and Availability (CIA) effectively defines the

technologies needed for securing systems. In the IT domain, cyber attacks often focus on

acquisition of proprietary information. Consequently, the CIA triad results in

Confidentiality being the most important attribute which dictates that encryption is

required. However, in the ICS domain, cyber attacks tend to focus on destabilization of

assets. Moreover, most ICS cyber incidents are unintentional and often occur because of

a lack of effective message integrity and/or appropriate ICS security policies.

Consequently, Integrity and Availability are much more important than Confidentiality

which lessens the importance of encryption and significantly raises the importance of

authentication and message integrity. ICS security research and education should focus

on technologies that address Integrity and Availability.

ICS security is an engineering problem requiring engineering solutions. Resilience and

robustness are the critical factors in the survivability of compromised ICSs. ICS security

requires a balanced approach to technology design, product development and testing,

development and application of appropriate ICS policies and procedures, analysis of

intentional and unintentional security threats, and proactive management of

communications across view, command and control, monitoring and safety. It is a

lifecycle process beginning with conceptual design through retirement of the systems.

1.4 Differences between IT and ICS Systems

6
Cybersecurity is generally viewed in the context of traditional business IT systems and

Defense systems. IT systems are “best effort” in that they get the task complete when

they get the task completed. Unlike IT systems, ICSs are not general-purpose systems

and components but designed for specific applications. The ICS design criteria was

performance and safety, not security. ICS systems are “deterministic” in that they must

do it NOW and cannot wait for later as that will be too late. ICSs often are not viewed as

“computers” or susceptible to cybersecurity threats.

Legacy ICSs were not designed to be secured, easily updated, or with efficient security

troubleshooting, self-diagnostics and network logging. The ICS community has the

knowledge-base to understand what physical parameters are required to perform a root-

cause analysis of an incident. Consequently, the ICS community has developed the

detailed forensics for physical parameters - temperature, pressure, level, flow, motor

speed, current, voltage, etc. However, the legacy/field device portions of an ICS have

minimal to no cyber forensics. This area is ripe for research and development to

determine what specific types of forensics are needed and how they would be performed

in the least non-invasive manner possible.

Reliable and timely communications are critical for maintaining the operations of ICSs.

ICSs are deterministic systems with hard real time requirements meaning

communications must occur within a prescribed period of time. There was some signal

validation, no authentication, no encryption, and adequate speed (that is, some latency

was acceptable). TCP/IP is not deterministic and consequently, TCP/IP is only used for

7
non-process or safety critical communications. Since there is a movement to utilize

TCP/IP protocols from RTUs or PLCs to SCADA or DCS, there is another common look

and feel between the IT community and the ICS community. The use of TCP/IP and

Windows was a natural progression to the Internet. There are now many instances where

ICS are connected directly to the Internet using TCP/IP through Windows or other

commercial-off-the-shelf operating systems. In the future, TCP/IP will be used for

control and even safety applications. This really needs to be done with great care.

In the IT community, software security and secure software are often discussed in the

context of software assurance. Software assurance is broader than software security as it

encompasses the additional disciplines of software safety and reliability. Software

assurance aims to provide justifiable confidence the software is free of vulnerabilities,

that it functions in the intended manner and that the intended manner does not

compromise the security and other required properties of the software, its environment, or

the information it handles. Software assurance also aims to provide justifiable confidence

that the software will remain dependable under all circumstances. These include the

presence of unintentional faults in the software and its environment; exposure of the

operational software to accidental events that threaten its dependability; and exposure of

the software to intentional threats to its dependability in development and operation.

Software assurance addresses trustworthiness, predictable execution, and conformance

where trustworthiness means no exploitable vulnerabilities exist whether intentional or

unintentional; predictable execution provides confidence will function as designed; and

conformance means the software and products conform to applicable standards and

8
requirements. To date, the ICS community has not actively and formally applied these

principles.

Certain mainstream IT security technologies can adversely affect the operation of ICSs or

result in operator confusion. Examples include using port scanning tools that result in

components freezing-up or worse. Block encryption can slow down control system

operation resulting in a Denial of Service. Locking up a system after a specified number

of password failures can have devastating consequences if it occurs during off-normal

conditions when operators are under great stress.

The current state of the IT world insures a high degree of intelligence and processing

capability on the part of the various devices within an IT system. The standard

implementation provides centralized control points for authentication and authorization

of IT activities. The lifetime of the equipment in an IT network, typically, ranges from 3

to 7 years before anticipated replacement and often does not need to be in constant

operation. By the very nature of the devices and their intended function, ICS devices

may be 15 to 20 years old, perhaps older, before anticipated replacement. Since security

was not an initial design consideration, ICS devices do not have excess computing

capacity for what would have been considered unwanted or unneeded applications.

Of considerable importance is intra- and inter- systems communication in both the IT and

ICS realms. ICS systems are intended to operate at all times, whether connected to other

systems or not. This independence makes the ICS very flexible, indeed. The age of the

9
equipment makes it difficult to authenticate communications properly. Not just between

servers, but between servers and devices, devices and devices, workstations and devices,

and devices and people. The older technologies do not have the ability, by want of

adequate operating systems, to access centralized authentication processes. By want of

the ability of the ICS network to be broken into very small chunks, the use of centralized

authentication is impractical, using the technologies of today. In an IT network, the

authentication rules take place in the background and are hidden, for the most part, from

the end user. In an ICS network, the authentication rules take place in the foreground and

require interaction with the end user, causing delay and frustration.

Patching or upgrading an ICS has many pitfalls. Patches need to be verified to determine

the patch is really the same as the one that was sent and to determine that the patch really

fixes a bug and won't adversely affect the system performance. This is not as easy as it

seems. The field device must be taken out of service which may require stopping the

process being controlled. This in turn may cost many thousands of dollars and impact

thousands of people. An important issue is how to protect unpatchable, unsecurable

workstations such as those still running NT Service Pack 4, Windows 95, and Windows

97. Many of these older workstations were designed as part of plant equipment and

control system packages and cannot be replaced without replacing the large mechanical

or electrical systems that accompany the workstations. Additionally, many Windows

patches in the ICS world are not standard Microsoft patches but have been modified by

the ICS supplier. Implementing a generic Microsoft patch can potentially do more harm

than the virus or worm against which it was meant to defend. As an example, in 2003

10
when the Slammer worm was in the wild, one DCS supplier sent a letter to their

customers stating that the generic Microsoft patch should not be installed as it WOULD

shut down the DCS. Another example was a water utility that patched a system at a water

treatment plant with a patch from the operating system vendor. Following the patch, they

were able to start pumps, but were unable to stop them!

The perceived distinctions between IT systems and ICS are starting to blur with grave

consequences. The Smart Grid Initiative is already providing real case histories of what

happens when those without an understanding of the operational domain try to set the

rules for systems they do not understand. Table 1 provides a comparison between key

characteristics of business IT and ICSs. These differences can have very dramatic

impacts on ICS operation and education.

Table 1 Comparison of Typical IT and ICS Characteristics [4]

Attribute IT ICS

Confidentiality (Privacy) High Low

Message Integrity Low-Medium Very High

Availability Medium Very High

Authentication Medium-High High

Time Criticality Delays Tolerated Critical

Security Skills/Awarenss Usually Good Usually Poor

Security Education Good Usually Poor

11
Engineering Education Usually none Yes

Certification CISSP (Certified Professional Engineer (PE)

Information Systems

Security Professional)

Life Cycle 3-5 Years 15-25 Years

Forensics Available Minimal

Impacts Business Impacts Business Impacts, Safety,

Environmental

1.5 Current Status

Figure 1 characterizes the relationship of the different types of special technical skills and

certifications needed for ICS cyber security expertise, and the relative quantities of each

at work in the industry today. Most people now becoming involved with ICS cyber

security typically come from a mainstream IT security background and not an ICS

background. This trend is certainly being accelerated by the Smart Grid initiatives, where

the apparent lines between IT and ICS are blurring. Many of the entities responsible for

control system cyber security, industry, equipment suppliers, and government personnel

do not fully appreciate the difficulties created by this trend.

12
 Why there are so few ICS security experts

ICS Security
Experts

CISSP certification No certification

IT Security PE
certification
ICS
Engineering

Figure 2 Relative Availability of ICS Cyber Security Expertise [4]

As can be seen in Figure 2, IT encompasses a large realm, but does not include control

system processes. The arrows indicate that most people coming into the ICS security

domain (from academia and the work force) are coming from the IT domain. This needs

to change. It does not take “rocket science” to compromise an ICS; however, it does take

“rocket science” to be able to protect an ICS and still have it be able to perform its

13
functions. Being able to do that is what constitutes an ICS security expert. Arguably,

there are less than several hundred people world-wide that fit into the tiny dot called ICS

cyber security.

There are many explanations for this imbalance. Firstly, there are simply more trained IT

security personnel than ICS security personnel. There is now significant money in

securing critical infrastructure. There is an old adage: “to a carpenter, everything looks

like a nail”. As ICS systems get more of an IT-look, IT views them as IT systems and

wants to apply their expertise to them. Secondly, there is often little funding for training

ICS personnel in cyber security as Operations often does not view this area as under their

purview. Is there any question as to why there are so many more IT-trained security

personnel than ICS-trained? The timing is ripe for the academic community to address

the need to educate more ICS technologists, researchers, and experts.

There is a convergence of highly integrated industrial automation combined with ICSs

sharing more and more constructs with IT. ICS cyber security is an emerging and

interdisciplinary field encompassing computer science, networking, public policy, and

engineering control system theory and applications. The lack of ICS cyber security

understanding in the industrial community is also often reflected in the academic

community. Having given lectures at National Defense University, the Naval

Postgraduate School, the University of Washington, the University of Illinois, and

Mississippi State University, the need for interdisciplinary focus and coordination was

evident. Unfortunately, today’s computer science curriculum often does not address the

unique aspects of ICSs. Correspondingly, the electrical engineering power systems focus,

14
chemical engineering, mechanical engineering, nuclear engineering, and industrial

engineering curricula do not address computer security. Consequently, there is a need to

form joint interdisciplinary programs for ICS security.

1.6 Why care, and more specifically, why should water and wastewater care?

To date, I have been able to document more than 200 control system cyber incidents

globally in many industries. These cases include electric power, water/wastewater,

chemicals, pipelines, manufacturing, transportation, etc. Even though most of these

incidents are not malicious, they have still caused considerable concerns. Moreover, most

of the unintentional cases could have been done maliciously. Impacts range from trivial

to significant environmental discharges to significant equipment damage to major electric

outages to deaths. In the water/wastewater industry, I have been able to document more

than 20 cases to date. Impacts range from trivial to significant environmental discharges

to loss of drinking water to pumping contaminated water into the drinking water system

to broken water mains.

Based on my experience as well as the 2011 McAfee report [5], the water and wastewater

industries are generally believed to lag most other industries in securing their control

systems. To date, the water and wastewater industries have experienced more than 20

control system cyber incidents. At least three have been malicious attacks. Consequently,

there is a need to educate the water and wastewater industries on how to secure their

control systems.

15
1.7 Examples of water and wastewater control system cyber incidents [4]

I will provide two examples – a malicious attack and an unintentional incident – both

caused physical problems.

1.7.1 Maroochy Wastewater Wireless SCADA Attack

Vitek Boden, a man in his late 40s, worked for Hunter Watertech, an Australian firm that

installed SCADA radio-controlled sewage equipment. Hunter Watertech installed radio-

controlled sewage equipment for the Maroochy Shire Council in Queensland, Australia.

Boden applied for a job with the Maroochy Shire Council, apparently after he walked

away from a "strained relationship" with Hunter Watertech. The council decided not to

hire him. Consequently, Boden decided to get even with both the council and his former

employer. He packed his car with stolen radio equipment attached to a (possibly stolen)

computer. He drove around the area on at least 46 occasions from February 28 to April

23, 2000, issuing radio commands to the sewage equipment he (probably) helped install.

Boden caused millions of liters of raw sewage to spill out into local parks, rivers and

even the grounds of a Hyatt Regency hotel. "Marine life died, the creek water turned

black and the stench was unbearable for residents," said a representative of the Australian

Environmental Protection Agency. Boden only got caught when a policeman pulled him

over for a traffic violation after one of his attacks. A judge sentenced him to two years in

jail and ordered him to reimburse the one major cleanup mentioned above. Boden's

attack became the first widely known example of someone maliciously breaking into a

control system (Figure 3)

16
 Figure 3 Maroochy SCADA System

Maroochy Shire Site Description

Maroochy Shire, a rural area of great natural beauty and a tourist destination, is located

about 100 kilometers north of the Queensland State Capital of Brisbane. It has an area of

approximately 1,157 square kilometers with a population of approximately 120,000.

Maroochy Shire has 880 kilometers of gravity sewers treating an average of 35 million

liters/day. Maroochy Water Services Sewerage SCADA System consists of 142 Sewage

Pumping Stations with two Monitoring Computers utilizing three Radio Frequencies.

17
Hunter Watertech Pty Ltd installed the “PDS Compact 500” computer device at each

pumping station capable of receiving instructions from a central control center,

transmitting alarm signals and other data to the central computer and providing messages

to stop and start the pumps at the pumping station. Communications between pumping

stations and between a pumping station and the central computer were by means of a

dedicated analog two-way radio system operating through repeater stations. Each repeater

station transmitted on a different frequency.

The Attack

The offences occurred between February 9, 2000 and April 23, 2000. Vitek Boden

accessed computers controlling the Maroochy Shire Council’s sewerage system, altering

electronic data in particular sewerage pumping stations causing malfunctions in their

operations. Vitek Boden had been employed by Hunter Watertech as its site supervisor on

the Maroochy SCADA project for about two years until resigning in December 1999. At

about the time of his resignation he approached the Council seeking employment. He was

told to enquire again at a later date. He made another approach to the Council for

employment in January 2000 and was told that he would not be employed. The sewerage

system then experienced a series of faults:

- Pumps were not running when they should have been

- Alarms were not reporting to the central computer

- A loss of communication between the central computer and various pumping

stations.

18
An employee of Hunter Watertech was appointed to look into the problem. He began

monitoring and recording all signals, messages and traffic on the radio network. As a

result of his investigations he concluded that many of the problems being experienced

with the system resulted from human intervention rather than equipment failure. Other

technical experts shared his opinion. Further, the evidence revealed that the problems

associated with the attack ceased when Vitek Boden was arrested. On an occasion during

the investigation, the investigator determined that pumping station 14 appeared to be the

source of the messages corrupting the system. He physically checked the pumping station

and ascertained that it was working properly and bore no signs of having been physically

tampered with. He concluded that the source of the false messages was a PDS Compact

500 computer with an address of 14 and he changed the identification number of

pumping station 14 to 3 so that any legitimate messages from that station could be

identified as coming from station 3. Conversely, any messages coming from a station

identifying itself as 14 would be known to be bogus.

On March 16, 2000, when malfunctions occurred in the system, the investigator

communicated over the network with a bogus pump station 14 that was sending messages

to corrupt the system. He was temporarily successful in altering his program to exclude

the bogus messages but then had his computer shut out of the network for a short period.

The intruder was now using PDS identification number 1 to send messages. Further

problems then occurred as a result of a person gaining remote computer access to the

system and altering data so that whatever function should have occurred at affected

19
pumping stations did not occur or occurred in a different way. The central computer was

unable to exercise proper control and, at great inconvenience and expense, technicians

had to be mobilized throughout the system to correct faults at affected pumping stations.

On one occasion, a pumping station overflowed causing raw sewerage to escape.

On April 23, 2000, an intruder, by means of electronic messages, disabled alarms at four

pumping stations using the identification of pumping station 4. The intrusions began just

after 7:30 pm and concluded just after 9:00 pm. By this time Vitek Boden had fallen

under suspicion and was under surveillance. Police officers located a vehicle driven by

him. When Boden’s vehicle was pulled over and searched at around 10:00 pm, a PDS

Compact 500 computer, later identified in evidence as the property of Hunter Watertech,

was found, as was a laptop computer. On examination it was found that the software to

enable the laptop to communicate with the PDS system through the PDS computer had

been re-installed in the laptop on February 29, 2000. The PDS Compact computer had

been programmed to identify itself as pump station 4 – the identification used by the

intruder in accessing the Council sewerage system earlier that night. The software

program installed in the laptop was one developed by Hunter Watertech for its use in

changing configurations in the PDS computers. There was evidence that this program

was required to enable a computer to access the Council’s sewerage system and had no

other practical use. The unchallenged evidence of a police computer expert was the

program had been used at least 31 times between April 7 and April 19 and that it was last

used at 9:31 pm on April 23, 2000. Also found in the car was a two-way radio set to the

frequencies of the repeater stations and the leads necessary to connect the PDS computer,

20
the laptop and the radio. The investigator and others gave evidence that the conduct of the

person responsible for the unauthorized interventions in the computer system displayed a

detailed familiarity with the system, beyond that which was likely to be held even by

Council technical staff. Technical experts other than the investigator also gave evidence

that the computer malfunctions, the subject of the charges, were the result of human

intervention. When apprehended by police Boden asserted in a taped conversation that all

the items in the vehicle were his own. He said he had been up to Rainbow Beach and that

he used the computer for study, personal correspondence and work in his family business.

He later sent a letter to the police requesting the immediate return of his property.

Examination of the laptop found in the car revealed start up and shut down times (on and

after February 28, 2000) consistent with the time of the attacks which the investigator had

uncovered and logged. The existence of other problems in the system showed that the

malfunctions were the result of human intervention. Once it was demonstrated that the

malfunctions resulted from human intervention, the existence of other problems became

of limited significance, the investigator was adamant that the malfunctions in the system

could only have been caused by unauthorized human intervention. Boden sought to

establish that some of the electronic messages that gave rise to the charges could have

been caused by system malfunction or by error on the part of Council employees. One of

his arguments in this regard showed three sets of identical messages on the same day

from addresses 000, 099 and 004. The Crown contended that only the message emanating

from address 004 was initiated by Boden. Boden pointed to the other messages as

evidence that defective messages of the nature of those relied on by the Crown may have

been caused other than by human intervention. Another witness, an engineer specializing

21
in computer engineering who, for a time, was Hunter Watertech’s project engineer on the

installation of the computerized sewerage system– said that all three messages were

generated by the PDS configuration program used on the PDS Compact computers. His

opinion was that the messages, other than the ones from address 004, were generated by

persons attempting to rectify the result of the alleged unauthorized intervention. He also

gave evidence that that 000 and 099 messages were not causing damage to the computer

system. The investigator gave evidence some days later than the computer engineer and

thus had more opportunity to consider the possible explanations for the 000 and 099

messages. His evidence was that these messages occurred over several days and resulted

from the actions of maintenance staff who were either employees of Hunter Watertech or

Council employees under direction of the former. He ruled out the possibility of

mechanical error. He said that the 004 messages were definitely generated by a person

different from the one who generated the other messages.

Timeline

1997-December 1999 - Vitek Boden employed by Hunter Watertech as site supervisor

December 3, 1999 - Boden resigns from Hunter Watertech

Early December 1999 - Boden approached City Council seeking employment

Early January 2000 - Boden reapproached City Council and was turned down

February 9-April 23, 2000 – SCADA system experiences series of faults

March 16, 2000, Hunter Watertech investigator tried to troubleshoot system

April 19, 2000 Log indicates system program had been run at least 31 times

22
April 23, 2000 Boden disabled alarms at four pumping stations using the identification of

pumping station 4. The intrusions began just after 7:30 pm and concluded just after 9 pm

April 23, 2000 Boden pulled over by police with computer equipment in car

October 31, 2001 –Boden convicted in trial – sentenced to 2 years

March 21, 2002 – Appeal rejected

Evidence

The counts on which Boden was found guilty related to acts of cyber penetration which

commenced on or about February 28, 2000.

• The laptop taken by the police from Boden’s vehicle had been reloaded with most of its

software operating programs on February 28, 2000

• PDS software file had been installed or re-installed on the laptop on February 29 at 3:46

pm. This is the software used to run or access the computers in the sewerage system.

o Run at least 31 times prior to April 19

o Last run on April 23

• Two-way radio was of the type used in the Council’s communication system.

o Tuned into the frequencies of the repeater stations

o Serial numbers on the radio matched delivery docket provided by the supplier of the

radios to Hunter Watertech.

• PDS Compact 500

o Address set to 004

o Serial number identified it as a device which should have been in the possession of

Hunter Watertech.

23
Attack Summary

• Vitek Boden was an insider who was never an employee of the organization he

attacked. He was an employee of a contractor that supplied IT/control system technology

to the Maroochy Shire Council. With his knowledge he was the “ultimate insider”.

• The service contract was deficient or inadequate concerning Watertech’s

responsibilities. Management, technical and operational cyber security controls were

inadequate. Personnel security controls that applied to its employees such as background

investigations and protection from disgruntled employees were inadequate.

• A number of anomalous events occurred before recognition that the incidents were

intentional. As a skillful adversary, Boden was able to disguise his actions. Extensive

digital forensics over a period of time were required to determine that a deliberate attack

was underway

• There were no existing cyber security policies or procedures.

• There were no cyber security defenses.

Observations

As reported by Slay & Miller, Robert Stringfellow was the civil engineer in charge of the

water supply and sewage systems at Maroochy Water Services during the time of the

breach and has presented his analysis in closed forums. Stringfellow observed:

• At first it was easier to blame installation errors for the problems.

• Upon reinstalling all the software and checking the system, pump station settings kept

changing beyond the ability of the system to do this automatically

24
• Conclusion: an external malicious entity was using wireless equipment to access the

SCADA system.

Stringfellow's analysis of the incident made several important points:

• It is very difficult to protect against insider attacks.

• Radio communications commonly used in SCADA systems are generally insecure or

are improperly configured.

• SCADA devices and software should be secured to the extent possible using physical

and logical controls

• It is often that case that security controls are not implemented or are not used properly

• SCADA systems must record all device accesses and commands, especially those

involving connections to or from remote sites; this requires fairly sophisticated logging

mechanisms.

Stringfellow also recommended the use of anti-virus and firewall protection along with

appropriate use of encryption. He emphasized a need for upgrade-able SCADA systems

(from a security perspective), proper staff training, and security auditing and control.

Possible Solutions

This case revolves around a disgruntled insider who was never an employee of the

organization he attacked. Some of the issues raised by analysis of this case are just being

addressed by cyber security practitioners 8 years later. Some are unresolved with no

solution in sight.

25
Policy and Procedures

Every organization should have cyber security policy and procedures. There are many

discretionary and judgmental activates that require guidance. Common sense isn’t

sufficient; dos and don’ts need to be written down. Neither organization had cyber

security policies or procedures in place. For example: NIST SP800-53 Policy AC-18

Wireless Access Restrictions (i) establishes usage restrictions and implementation

guidance for wireless technologies; and (ii) authorizes, monitors, controls wireless access

to the information system. Such policy would have addressed the two-way radio that was

used by Boden. The first control in every control family addresses policy and procedure.

With minor variations, the control begins: “The organization develops, disseminates, and

periodically reviews/updates: (i) a formal, documented, incident response policy that

addresses purpose, scope, roles, responsibilities, management commitment, coordination

among organizational entities, and compliance; and (ii) formal, documented procedures

to facilitate ….” Although enumerated for each control family, the family policy can be

included as part of the general information security policy for the organization. Family

control procedures can be developed for the security program in general, and for a

particular information system, when required.

Personnel Security

Since Boden was never a Maroochy Council employee, direct hiring controls by the

Maroochy Council were technically not applicable. However, is it prudent to have a key

personnel clause to protect the client from unilateral changes in key personnel by the

26
contractor. In general, the contract should extend applicable Personnel Security controls

to contractor employees. Determining which controls to apply to on-site contractor

personnel may not be easy since it depends on the role played by the individual.

System and Services Acquisition

Hunter Watertech supplied hardware, software, and services to the Maroochy Shire

Council. The cyber security responsibilities of the contractor organization (e.g., Hunter

Watertech) and the contractor’s employees (e.g., Boden) should be included in the

contract between the organizations. Almost all of the controls applicable to direct

employees are also applicable to contractor employees, but the exact details may vary.

Many of these controls also obligate the contractor organization concerning record

keeping and other support services. There is no indication that any of these controls were

included in the contract between Hunter Watertech and Maroochy Shire Council. All the

controls are important.

Awareness and Training

Personnel were not trained in preventing, recognizing, or responding to cyber-related

incidents. Security awareness and training inform personnel of the information security

risks associated with their activities and their responsibilities in complying with

organizational policies and procedures designed to reduce these risks.

Audit

27
The Maroochy communications and control components lacked sufficient audit capability

to support fault determination or forensic analysis. Audit is concerned with collecting

information that is significant and relevant to the security of the information system.

Audit supports other control families such as incident response, access control, and flaw

remediation.

Contingency Planning

The analysis indicates that there were no plans to deal with an emergency or system

disruption. Effective contingency planning, execution, and testing are essential to

mitigate the risk of system and service unavailability.

Incident Response

Response to the sewerage discharge was ad hoc. Considerable time elapsed during

troubleshooting before malicious intent was considered. An incident response capability

is necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating

the weaknesses that were exploited, restoring computing services, and apprehending

malefactors. Because performing incident response effectively is a complex undertaking,

establishing a successful incident response capability requires substantial planning and

resources. Establishing clear procedures for assessing the current and potential business

impact of incidents is critical, as is implementing effective methods of collecting,

analyzing, and reporting data. Building relationships and establishing suitable means of

communication with other internal groups (e.g., human resources, legal) and with

external groups (e.g., other incident response teams, law enforcement) are also vital.

28
Information Protection

Cryptography is employed as a protective mechanism for many objectives. A second line

of defense that was widely deployed only in 2006 was encryption protection of

information in stolen and lost devices. The US Office of Management and Budget

(OMB) issued a policy memorandum in June 2006, recommending safeguards for all

federal government agencies. While this OMB policy was issued in response to loss or

theft of devices containing Personal Identification Information (PII), its phrasing

encompasses protection of all sensitive data and information. The specific intent of this

policy is to compensate for the protections offered by the physical security controls when

information is removed from, or accessed from outside of the agency location and when

information is physically transported outside of the agency’s secured, physical perimeter

(this includes information transported on removable media on portable/mobile devices

such as laptop computers and/or personal digital assistants). The OMB policy is more

explicit. This policy would have addressed the laptop and two-way radio that were in

Boden's possession when he was arrested. However, since Boden had reloaded the

software and no data disclosure was involved, the practical impact is little to none.

Malicious Activities

Boden’s malicious activities included:

- Stealing equipment

- Issuing radio commands

- Falsifying network address

29
- Sending false data and instructions

- Disabling alarms

Access Control

Access Control is the process of granting or denying specific requests for obtaining and

using information and related information processing services. This is one of the

fundamental controls on any IT system. Most access controls are based on the identity of

the person, process, or device involved. Therefore, Identification and Authentication are

intimately tied with access control. Access controls need to be applied appropriate to the

communications environment. Access controls are the first line of defense against error

and omissions and malicious attacks from insiders and outsiders. Multiple access controls

would have alleviated or prevented the attack.

Identification and Authentication

Identification is the process of determining the identity of a user, process, or device, and

authentication is the process of verifying the putative or claimed identity, often as a

prerequisite to allowing access to resources in an information system.

Portable Device Protection

Part of defense-in-depth is recognizing that when some protections fail, there should be

more controls to help protect the organization. Theft of portable electronic equipment

occurs, often for the value of the equipment rather than the information stored. Boden’s

attack was an exception to this generality. An organizational assessment of risk guides

30
the selection of media and associated information contained on that media requiring

restricted access. Organizations document in policy and procedures, the media requiring

restricted access, individuals authorized to access the media, and the specific measures

taken to restrict access.”

System Monitoring

Another part of defense-in-depth is determining that something is going wrong. The

cause may be an intruder, often masquerading as an authorized user, or a malfunction. If

applied regularly and systematically, the type of forensics performed by Hunter

Watertech and the police might have detected the attack earlier.

Conclusions

The 2000 Maroochy Shire cyber event is important because it provides a public record of

an intentional, targeted attack by a knowledgeable person on an ICS. The attack by an

insider who is not an employee demonstrates several critical physical, administrative, and

supply chain vulnerabilities of industrial control systems. The key issue is the treatment

of vulnerabilities coming from suppliers or others outside the organization. Contractor

and sub-contractor personnel are often overlooked as potential attack sources. The

technical issues demonstrate the difficulty in identifying a control system cyber attack

and retaking control of a “hijacked” system. Once alerted to this type of attack, ICS

owners and operators may have adequate controls to protect their assets. However, a

determined, knowledgeable adversary such as Vitek Boden could potentially defeat these

controls.

31
Observations: This was arguably the first public case of a malicious attack on an ICS. It

was done by someone with insider knowledge who was not a traditional insider. It also

demonstrated that ICS cyber attacks are not always immediately obvious as a cyber

attack.

1.7.2 Non-Malicious ICS Cyber Incident

A water utility was upgrading the operator workstation from Windows NT4 Service Pack

4 to Service Pack P6a. The Ethernet driver from the operator workstation to the PLC was

via an Ethernet Card. Everything appeared to be working well. All validation tests were

signed off. Following the patch, the utility was able to start pumps at the water treatment

plant, but unable to stop them! The problem was caused by interactions between

products. There were no noticeable warnings from the operator workstation.

Observations:

System interactions are critical with ICSs and are very difficult to test in a non-

production environment. This is another case of meeting IT security requirements and yet

the system failed with lack of control system cyber forensics.

1.8 What Should Be Done [4]

1.8.1 General Recommendations

32
- Develop a clear understanding of ICS cyber security. This includes developing a clear

understanding of the associated impacts on system reliability and safety on the part of

industry, government, and private citizens.

- Define “cyber” threats in the broadest possible terms including intentional,

unintentional, natural and other electronic threats such as Electro Magnetic Pulse (EMP)

and electronic warfare against wireless devices. ICS cyber security threats are more than

botnets and malware.

- Change the culture in critical industrial infrastructure such that security is considered in

the same context as performance and safety (not as critical, but important to consider).

- Get IT and operations to work together.

- Establish a means for vetting ICS experts rather than using traditional security

clearances or IT certifications.

1.8.2 Administrative and Procedural

- Get senior management support as the process fails without it. Identify division of

responsibilities and reporting structure all the way to the Board of Directors as cyber

security is a corporate risk. IT staff have the ears of senior management and the Board of

Directors. I believe the IT audit staff can be an asset in securing ICSs if approached in a

teaming manner. However, this is not an IT task and should not be housed within the IT

33
organization.) Establish a credible budget to accomplish what will be identified.

Recognize cyber security is critical to safe and reliable ICS operation which translates

directly to the bottom line. Incorporate security into executive and employee

performance measures. Ensure appropriate awareness and training is regularly provided

to all personnel.

- Identify all affected stakeholders and their interactions. This is not an easy process as

there are many subtle relationships. These relations extend beyond Facility Operations

and even beyond the overall organization to encompass vendors, contractors, regulators,

first responders, and even the public.

- Mandate effective cyber security requirements so this is not a compliance exercise. An

effective, living program is critical. Take ICS cyber security as seriously as you take

enterprise cyber security. Secure based on electronic connectivity, not just the size of the

facilities or equipment.

- Determine what you really have. The hardware, software, and firmware that affect cyber

security are often not identified in any formal system diagrams or vendor documentation.

Identify all control system hardware and communication infrastructure. Document what

you have and what you have done. Establish a living Configuration

Management/Configuration Control Program that includes the ICS as well as cyber

security-specific software (e.g., patch versions), hardware (e.g, network interface cards),

and firmware.

34
- Determine what you really need from the ICSs in terms of functions, features, and

communication. This requires obtaining input from throughout the organization because

cyber security will affect any new systems.

- Determine what you want to do and do it. Again, this is not as easy as it seems. This

requires understanding of what features need to have security enabled.

- What risks are present? Traditional risk approaches of addressing probability and

consequence need to be modified. Probability should be 1 (it will happen) and

consequences should be based on “design basis threat” (worst case). Risk assessments

require a cost-benefit trade-off between performance/safety and security. This would

involve assessing the risk of both security and performance features. It also addresses

externalities including external personnel (e.g., vendors and contractors), economic

conditions, and social concerns. Questions to be answered include how risks can be

mitigated structurally, technically, and administratively.

- Develop ICS-specific policies and procedures. This is what I consider to be one of the

most important tasks in the entire process. Recognize that complexity significantly adds

security overhead and potential performance/safety impacts. Work with IT to make sure

that the ICS policies and procedures are not inconsistent. But first and foremost, they

must be developed for the specific equipment to be secured and in the way they are

expected to be operated.

35
- Make your equipment suppliers and contractors partners in securing your systems.

Require detailed documentation of what has been provided and how it has been tested

and secured. Do appropriate background checks to assure key vendor and contractor

personnel are competent and vetted - notice the use of the word vetted not “cleared”.

(Don’t forget about your own critical employees.) Work closely with your vendors and

contractors to make sure they are doing what YOU want.

- Consider lifecycle issues. ICSs can be cyber vulnerable from initial design until they are

retired or destroyed.

- Consider system recovery issues following an incident or attack. (see later

recommendations).

1.9 References

1. ISA S99, Industrial Automation and Control System Security,

http://www.isa.org/MSTemplate.cfm?MicrositeID=988&CommitteeID=6821

2. Presidential Decision Directive (PDD)-63, May 22, 1998,

http://www.fas.org/irp/offdocs/pdd/pdd-63.htm

3. Weiss, Joseph, The Need for Interdisciplinary Programs for Cyber Security of

Industrial Control Systems, WorldComp 2010, Las Vegas, NV

4. Weiss, Joseph, Protecting Industrial Control Systems from Electronic Threats, 2010,

Momentum Press

36
 5. In the Crossfire: Critical Infrastructure in the Age of Cyber War, P.1,

http://www.mcafee.com/us/resources/reports/rp-in-crossfire-critical-infrastructure-cyber-

war.pdf

37

View publication stats