SCADA System Network Security

1
SCADA System Network Security

• Sid Valentine
• CSCE-727

2
PUT BIBLIOGRAPHY HERE

• OK

3
Project Overview

• Investigate SCADA/PLC functionality as it
  pertains to the national infrastructure areas to
  include
• Power Systems
• Water Treatment Facilities
• Oil Gas Refineries

4
Project Overview

• This project has been utilized to lay the
  foundation of the development of a method of code
  standardization and validation in systems
  involving SCADA technology.

5
Project Overview

• Steps which have been included in this initial
  process
• Determine the current state of SCADA system
  security being utilized.
• Determine an initial set of the most common
  problems which could be created through the use
  (or misuse) of SCADA technology.

6
SCADA

• SCADA Supervisory Control And Data Acquisition
• Used for remote control and monitoring of highly
  automated systems.
• Can be tied directly to a database for storage of
  all critical process information.
• Can be accessed (and possibly altered) from
  anywhere there is a network connection.

7
PLCs

• PLC Programmable Logic Controller
• The driving force behind many automated
  processes currently running in the infrastructure
  sector.
• Replaced relay (hardware) logic with software
  representation and control.
• Can be programmed to control any device (analog
  or digital) and any automated process.
• These systems currently control the production
  and distribution of the nations infrastructure
  components.

8
PLCs

• Ladder logic code, utilized to program a PLC can
  be configured to override hardware input and
  output devices, to the point that the hardware
  input devices can be physically disconnected any
  the process can continue to function.
• This is a crucial point when you consider that
  individuals on a remote SCADA terminal do not
  have to concern themselves with whether or not
  input devices are connected to the system, they
  just create them virtually.

9
Standard SCADA Process Flow
10
Typical SCADA System
11
Waster Water Treatment Plant Overview(Used from
Princeton, Indiana Waster Water Treatment Plant
Brochure)
12
Current State of Security in this Area

• Non-existent to minimal at best.
• SCADA system developers are inconsistent levels
  of security built into their packaged systems and
  development tools.
• The most common statement in SCADA system
  literature from manufacturers is If the security
  features interfere with functionality of the
  program, here is how to disable them

13
Current State of Security in this Area
14
The Infrastructure Industry Perspective

• Currently there are no common standards within
  each infrastructure sector.
• Although, each of the major infrastructure groups
  seem to be focusing on the same items.

15
The Infrastructure Industry Perspective

• These consist of
• Protection of SCADA through enhancement of the
  operating system.
• Protection of the SCADA through enhancements made
  to the SCADA software packages.
• Developing a Coding Standard for the SCADA
  system front end.
• Development of a more stringent validation policy
  for access into the system.

16
Protection through the O.S.

• Currently, only Wonderware is working closely
  with Microsoft to try to develop a security
  policy that will allow the security features of
  their SCADA package to work in conjunction with
  those provided by the operating system.

17
Protection through the SCADA Software Package

• Of the major SCADA system manufactures studied
  (Citect, RSView, and Wonderware) each have their
  own security policies and most currently conflict
  with those of the Windows operating system.

18
Development of a Coding Standard for SCADA

• This component is being utilized as the basis
  behind this project. Currently, there is no
  coding standard for SCADA system technology,
  which leads to the next criteria being discussed
  by industry

19
Development of a stringent validation policy

• Without implementing a coding standard for these
  systems, the development of Validation and
  Verification procedures is virtually impossible.
  There is not currently a standard in place to
  compare against.

20
Homeland Security Perspective

• The US Department of Homeland Security includes
  SCADA technology in its list of four types of
  high consequence software.
• This makes a SCADA system a high value target
  for attackers since SCADA systems are quickly
  being implemented into every mission critical
  function of this country.

21
Training Received for SCADA Implementation
22
Length of Training Received
23
Knowledge of Proper Coding Methodologies Prior to
SCADA Implementation
24
Educational Background of Individuals
Implementing SCADA System at the Local Level
25
Coding Standard

• When developing a coding standard for a SCADA /
  PLC system, the following fundamental issues must
  be considered
• Determining the communications protocol to be
  used on a given system design.
• Currently, there are anywhere from one to five
  different means to communicate with the PLC
  through the SCADA.

26
Coding Standard

• To create a useful coding standard, you must have
  a fundamental knowledge of the PLC and all of the
  devices that could be connected during a typical
  control scheme.
• A common misconception with automated processes
  is that all processes are basically the same.
  Not true.

27
Coding Standard

• Have a fundamental understanding of the types of
  faults that can occur (or be implemented) by
  either an inexperienced programmer or an
  individual with malicious intent.
• This will allow the standard to be written so
  that a set of validation and verification rules
  can be generally written.

28
Other Issues

• Be aware of the basic CPU and memory limitations
  inherent in a PLC that limit security options.
• Depending on the PLC, there may not be sufficient
  space in the CPU or in memory for a high level
  security protocol.
• Most memory space on the processor is dedicated
  to performing computations, performing state
  checks on hardware devices and storing the ladder
  logic.

29
Other Issues

• Currently control devices dont require
  authentication from an attached device that could
  trigger a command function.
• Currently, a PLC by design, will accept any
  command signal from any device, assuming the
  signal types are equal (analog vs. digital).

30
Other Issues

• Most SCADA and PLC systems have no built in
  confidentiality features.
• SCADA protocols are transmitted utilizing a plain
  text format across the network.
• Since there is currently no encryption standard
  utilized in SCADA technology, the system is an
  easy mark.

31
Other Issues

• There are no built in integrity checks.
• SCADA systems rely on the PLC system to check for
  the integrity of the data.
• The PLC is not designed for this functionality.
  It only has the ability to verify that data has
  made it from point A to point B.

32
Possible Malicious Entry Points

• Over utilization of binary bits
• Are they appearing in uncommon places?
• Are they missing activation coils which must be
  associated with the contacts?
• Does more than one binary with the same
  definition appear in more than one location of a
  given rung of logic?

33
Possible Malicious Entry Points
Potential malicious access point.
34
Possible Malicious Entry Points

• Misrepresented timer function blocks
• In the following example, a process timing block
  was intended to be set up for a 10 second
  interval as follows
• Preset 10
• Base 1.0
• Accumulator 0 (initial)

35
Possible Malicious Entry Points
36
Possible Malicious Entry Points

• Other possible entry points directly from the
  SCADA interface
• Integer files
• Counter sequences
• Bit Shift Routines
• Anything that can be referenced through the
  database of the system

37
First Steps Toward Protection

• Development of a coding standard to include
• Common binary locations for certain common
  functions and routines.
• Common timer counter locations and numbering
  sequences
• Common integer files
• Standardized documentation of a given sequence
• Development of validation routines for analog,
  digital and timing sequences common to a given
  process.

38
First Steps Toward Protection

• Development of a coding standard to include
• Standardized naming conventions that may include
  covert naming conventions for a given process
• i.e. dont make it easy. Although it is
  convenient to name a process component
  Line_5_Process_4_Start, this is not the most
  logical naming convention to protect your
  processes.

39
Future Work

• Generate, using the initial problem set from this
  work, a foundation model of use and misuse cases
  as they pertain to SCADA technology.
• These Use and Misuse cases were broken down
  into the amount of damage caused based on
  malicious and non-malicious intent.
• This data was then formalized into tabular form
  utilizing the standards outlined by ISO 17799,
  which is a comprehensive set of controls
  comprising best practices in information
  security.

40
Future Work

• Develop a coding standard to include ladder
  logic, C, Flow Charts and pneumonic coding styles
  as they pertain to SCADA and PLC systems.

41
Questions

• ????????