summary

i need 400 to 500 words

*
*
Copyr

ia Corporation

The submitted manuscrip

has been authored by a contr

tor of the U.S. Government

der contract No. DE

–

AC04-94AL85000. Acco

ing

y, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government purposes.
Unlimited release – approved for public release.
Sandia National Laboratories report SAND2005-1001C.
Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy’s National Nuclear Security

Admin

istration

under contract DE-AC04-94AL85000.

TUTORIAL C:
AUTOMATION SECURITY TUTORIAL

Jason Stamp

Network

System

s Surviva

bility

and Assurance Department
Sandia National Laboratories
March 11, 2005
Clemson University – 2004

Power

Systems Conference

Outline
Part I: Introduction
Part II: Threat Environment
Part III: Security Administration
Part IV: Technical Best Practices
Part V: Discussion

Part I: Introduction
Definitions
Current Security

Vulnera

bilities
Components of Sustainable Security
Part I: Introduction

Automation

Systems

Any subsystem that electronically measures state, alters pro

cess

control parameters, presents / stores / communicates data, or the

management

thereof
Part I: Introduction

Master

Station

Sub-Master Station

RTU

RTU n

RTU 1

RTU m

Sensor

Relay

Automation

Systems
Critical to the safe, reliable, and efficient operation of many physical

processes

Used extensively in infrastructure
Electric power
Water
Petroleum
Natural gas
Also used in manufacturing

operations

Automation enables quicker and more coordinated system control compared to human operation (in many cases there is no effective alternative)
Part I: Introduction

Automation Systems in
Electric Power

SCADA

Supervisory

Control

and

Data

Acquisition
(All-encompassing government term for automation)
EMS
Energy

Management

System

Protection

Relaying
AGC

Automatic

Generation Control

WAP

Wide Area

Protection
Etc.
Part I: Introduction

Categories For
Automation Components

System

data
Fundamental element of any information system
System

security

is applied to preserve data attributes (AAI&C)
Security administration
Encompasses non-automation functions as documentation and procedure
Components include

security

plans, implementation guidance, configuration management and security enforcement & auditing
Architecture & design
Platforms
Networks and communications
Part I: Introduction

Vulnerabilities Exist

SCADA

equipmen

IT equipment upon which SCADA depends, software, processes, policies, communications, etc…

Comm

on Vulnerabilities in Critical

Infrastructure

Control

Systems, SAND2003-1772C
More vulnerabilities exist than have been found
http://www.sandia.gov/scada
Part I: Introduction

Vulnerabilities are Proliferating
Dependence on

Internet

and related technology
Increasing adoption of new technologies
Reliance upon automation over human control
Connectivity between SCADA & IT enterprise
Unique issues related to real time control
Slow adoption of security solutions
Part I: Introduction

Relevant Trends
Design is moving towards open standards
Most hardware vendors are foreign companies
Numerous integrators and system providers
Present state of security is

not

commensurate with the threat or potential consequences
Security is 5-10 years behind typical IT systems because of isolated stovepipe organization
Arbitrary applications of technology, informal security, and the fluid vulnerability environment lead to unacceptable risk
Part I: Introduction

Changing SCADA Systems
Part I: Introduction

Vulnerabilities:
Data
Sensitivity levels for PCS data are usually not established
Absence of data sensitivity distinctions makes it impractical and fruitless to identify where security precautions are appropriate
Lack of data classifications is a direct byproduct of deficient administration in automation security
Part I: Introduction

Vulnerabilities:
Security Administration
Part I: Introduction

Category

Vulnerability

Po
l
icy

The PCS has no specific documented security

policy

or security
plan. This key vulnerability
generate
s the proliferation of
procedural and technical vulnerabilities.

The PCS often has no specific
or
documented security plan.

Implementation g
uides for equipment and systems are usually
absent
or deficient
.

There are no administrative mechanisms for security
enforcement in the system lifecycle.

Procedures

Security audits are rarely performed, if at all.

Training

There is neither formal security traini
ng nor official documented
security procedures.

Configuration

Management

Usually, t
here
is
no formal configuration management and no
official
ly
documented procedures. Hence, there are neither
formal requirements, nor a consistent approach
for

configurati
on management.

Vulnerabilities:
Architecture and Design
Many systems include centralized data storage and control (often single-points-of-failure)
Some lack effective control hierarchies which may result in physical damage to infrastructure assets
Many companies are leveraging their automation links and networks for emergency services and signals
In some cases, security, fire, and other systems are integrated into the automation system as points of measurement and control
Part I: Introduction

Vulnerabilities:
Platforms
Part I: Introduction

Vulnerabilities:
Networks and

Communica

tions
Part I: Introduction

Future Automation Security
Security administration
Better security technology
Third-

party

assessments
Part I: Introduction

Security Administration
Security administration is paramount to manage security risks
Exploited vulnerabilities are directly related to implementation and operation of a particular SCADA system
SCADA use and operations are managed by people whose actions are defined and

controlled by

the system’s security administration
Unrealistic to expect any SCADA operation to be free of vulnerability and immune to threat
In the fluid IT environment, changing conditions demand constant vigilance

Only

through constant evaluation and maintenance can security be sustained
Effective and sustainable security for SCADA depends on effective security management
Part I: Introduction

Security Administration
Modern SCADA must be addressed and managed in a style appropriate for a critical IT system
SCADA no longer enjoys freedom from concern for security
Information Age has introduced malevolent human threat
Need for dedicated security personnel
Ineffective for SCADA system administrators and managers to also bear the responsibility for security
Cutbacks in staff and increasing system complexity in most cases deny adequate attention to security from SCADA operations personnel
SCADA security staff has a heavy training burden to keep abreast of threat and vulnerability developments
SCADA security administrator must have clear authority to alter running configurations to mitigate vulnerabilities
That power must derive from clear and direct policy
Part I: Introduction

Improved Technology
Critical to embrace the role of technology to achieve overall security for future SCADA
Development of secure technology, protocols, and standards will equip SCADA security personnel with necessary tools for secure implementation
Some advancements may include:
Secure protocols
Low-cost

encrypt

ion for serial SCADA
Application-layer stateful inspection for SCADA firewalls
Accounts and logging for RTUs
Part I: Introduction

Third Party Assessments
Internal auditing and assessment of security administration and system implementation are essential
Regular external evaluations are also critical to catch residual problems caused by organizations being too close to issues or unaware of new tactics and tools
Contemporary security assessments may not be helpful to organizations with emerging security programs
For now, an assessment process that focuses primarily on security management and organizational culture while addressing only glaring vulnerabilities in implementation is the best balance for most
Part I: Introduction

Part II: Threat Environment
Part II: Threat Environment

Threats are Increasing
Increasing awareness by adversaries of cyber as an attack mechanism
Adoption of Internet technology adds a practiced class of adversaries
Reducing sophistication needed to be a cyber adversary is allowed by proliferating attack tools
Increasing threat of worms and viruses
Part II: Threat Environment

Malevolent Threat Assessment
Class – Criminal,

Terrorist

, Extremist, Political/military
Motivation
Capability – skills, resources, technology
Tactics – stealth, deceit, social engineering
Action – sabotage (denial of service, misinformation) or theft
Type – insider, outsider, collusion
Constraints – risk aversion, monetary, tactics
Part II: Threat Environment

Outsider Cyber Threat

Hacker

s – cause trouble (vandalism), potential for extensive damage

Hacker

coalition – promote a cause or position

Organized

crime – profit motivated

Foreign

intelligence – promote a cause or position at an international level
Part II: Threat Environment

Outsider

Adversary Levels

Part II: Threat Environment

Insider Cyber Threat

Physical

access

only
Maintenance / custodial staff, contractors
Power user, no special privilege
Use

SCADA information

/ control systems
Domain knowledge with privileges
Manages and maintains SCADA information and control systems
Part II: Threat Environment

Insider Levels
Part II: Threat Environment

Cyber Terrorism
Terrorist:
Someone using force or violence to intimidate or coerce a government or civilian population in furtherance of political or social objectives
Cyber Terrorist:
Someone who uses cyber mechanisms to intimidate or coerce a government or civilian population in furtherance of political or social objectives
Part II: Threat Environment

Cyber Terrorist
Goals and Methods
Remotely affect systems resulting in:
Injury / loss of life
Loss of availability
Loss of public confidence
Disruption of ability to meet mission goals:
Damage to equipment or facilities
Corrupt databases
Denial of service
Inject false information
Create false trust or mistrust
Part II: Threat Environment

Cyber Concerns
No “Cyber Pearl Harbor” event yet
Perhaps because:
The current generation of terrorists may not trust this medium
As technology savvy terrorists increase in rank and influence, these mechanisms may be considered as more valuable
As it is proven to be an effective means for terrorism, its use may increase
Assessments Introduction
Part II: Threat Environment

*
*
Copyright © 2005, Sandia Corporat

ion.

The submitted manuscript has been authored by a contractor of the U.S. Government under contract No. DE-AC04-94AL85000. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government purposes.
Unlimited release – approved for public release.
Sandia National Laboratories report SAND2005-1001C.
Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.

Part III:
Security Administration
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Administration For
Sustainable Security
Control framework
A starting point for the business administration of the enterprise employing SCADA
Security is addressed as part of the company’s comprehensive risk management program
Coupling the need for security to the organization’s business model is the most direct way of evaluating security investment
Enforcement
Security policy
Security plans
Implementation guidance
Configuration management
Auditing/assessment
Technical security

controls

Security policy

is key: it bridges the control framework to enforcement
Part III: Security Administration

Administration Hierarchy
Control framework
Security policy
Security plan
Implementation
guidance

Business

management
SCADA management
SCADA personnel
Translate business objectives into actionable policy
Instantiate policy objectives for specific SCADA systems
Apply plan requirements to specific technology and subsystems
SCADA Business
SCADA Organization
SCADA System
SCADA

Equipment

Increasing specificity
Increasing authority
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Security Policy
Security policy for SCADA administration translates the desired security and reliability control objectives for the overall business into enforceable direction and behavior for the staff to ensure secure SCADA design, implementation, and operation

An organization should have one security policy with authority over all SCADA systems, connected elements, and personnel
Unique characteristics of SCADA necessitate a complete policy separate from the normal company information policy
Formulated by the SCADA management staff, with input from the business leadership
Fosters a strong link between the control framework and the policy
Part III: Security Administration

What is Policy?
A formal statement of what will (and will not) be done
Mandatory rules that will be followed… not suggestions or guidelines
Product and vendor independent
It does not include system security settings, configuration rules, or computer setup rules
Part III: Security Administration

Justification for Separate
Automation Policy

Acceptable use

of automation system should be narrower than IT systems due to:
Different mission
Different sensitivity of data
Different criticality of function
Automation systems have more immediate physical consequences therefore:
Interconnections must be better controlled
Access and CM more strictly enforced and monitored
Administration and enforcement is simpler with a separate policy
Don’t embellish IT… this just gets messy when trying to include all of the caveats for automation
Tension between automation systems and IT security
Part III: Security Administration

Justification for Separate
Automation Policy
Smaller, different audience
SCADA engineers
SCADA operators
Not business administrators, HR, regular employees
Legislative requirements on automation systems are different
Currently, security plans, policy, etc are not required, but…
With current concerns fueled by incidents like the blackout in the northeast, regulation is coming
It’s better to have the administrative controls in place before they are required by legislation
Part III: Security Administration

Policy Elements
Definitions for critical organizational elements
Positions in the automation systems security administration

Data

categorization and

ownership

Description of important elements of the automation

architecture

Creation and enforcement of the risk management program for automation security
Evaluating vulnerabilities and their security controls
Security investments
Residual risk
Review cycle (which

contributes to

ongoing security through risk reevaluation)
Part III: Security Administration

Policy Sections
Data security
Platforms
Networks and communications

Manual

operation (including exercises)
Personnel
Security training
Essential for understanding policy and requirements, and staff compliance is predicated upon adequate awareness
Enforcement
Security plans for specific systems or subsystems
Implementation guidance for specific technologies
Configuration management
Auditing/assessment
Part III: Security Administration

Policy Framework
Why a framework?
Allows for a systematic approach
Convenient
Hierarchical
Easy to sort
Created for automation systems
History of assessments
Multiple industries
Multiple iterations
Part III: Security Administration

Policy Framework
Part III: Security Administration

Policy Section Headings
Purpose
Scope
Policy
Responsibilities
References
Revision History
Enforcement
Exceptions
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Security Plans
The SCADA security plan enumerates specific security guidelines for systems or groups of systems based on fundamental concepts from the security policy

Relates policy to reality
The plan is the core security document for implementation, operation, and maintenance
Very similar in concept to the NIST definition
Details the collection of controls and control practices necessary to meet the control objectives of the security policy and control framework
Considerably more technical than policy
Elements of the security plan can be garnered from statements of industry practice or best practice
Part III: Security Administration

System Identification
System Name/Title
Unique identifying information
Responsible organization
Ex: federal organization responsible for the system
Contact information
Sufficient information so that a responsible party can be located.
System owner will be designated here
Part III: Security Administration

System Identification
Security Personnel
The contact information for the person ultimately responsible for the security of the system

Operational

Status

The system (or parts) may be in development or maintenance phases
Description
General description and purpose of the system
Software, hardware, and vendor information
Part III: Security Administration

System Identification
Environment
Any details about the operating environment that raise security concerns (i.e. connected to the Internet)
What hardware or software is used to secure these connections
Interconnections
Include up-to-date network diagrams
Laws, regulations, and policies
This ties back to the Organization and Relationships portion of the security policy
Sensitivity
For both information and system
Use the data categories defined within the policy
Part III: Security Administration

Management Controls
Assessment and auditing management
List known/identified threats and vulnerabilities
Include dates, results, planned dates, etc for auditing and assessment
Assessment and audit results
Both internal and external
Include dates if changes are necessary
Rules of Behavior
Employees should sign a copy of this and review often
Accreditation details
Part III: Security Administration

Management Controls
Planning for system lifecycle
Describe how security has been implemented for all phases of the system
Initiation
Development/Acquisition
Implementation
Operation/Maintenance
Disposal
Configuration management issues need to be considered for all phases
Part III: Security Administration

Operational Controls

Personnel

security
Background checks
Least privilege/need-to-know
Computer room access
Termination procedures
Physical & environmental controls
Physical access
Emergency preparedness
Data

protection

Audit

trails, marking, transportation, etc.
Part III: Security Administration

Operational Controls

Contingency

Plans
Backup & recovery
Disaster recovery
Manual Operations Plan
Maintenance Controls
Configuration management
Access controls
Parts of this will be covered in rules of behavior and technical controls sections
Part III: Security Administration

Operational Controls
Data integrity and validation controls
Documentation inventory
Vendor documents
Administrative documents (policy, procedures, etc)
Security training
Incident response capability and handling procedures
Part III: Security Administration

Technical Controls
Identification/authentication
Passwords, smartcards, etc.
Logical access controls
Who or what can have access to specific system resources

Remote

access

controls
Screen saver locks and banner requirements will also be included here
Audit trails / logs
What must be logged by what devices
Who has access to the logs
Review and retention cycle
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Implementation Guidance
Implementation guidance enforces the security plan and policy for the implementation of specific technologies

A compilation of directives for the configuration, installation, and maintenance of equipment or software
Almost entirely technical
Example: an implementation guide for the application of password checking software on some particular computing platform
The need for the software and its configuration are necessary to meet the requirements of the security plan, which in turn satisfy the demands of the SCADA security policy, derived from the control framework based on the business objectives of the company
Other implementation guides
Network cabling
Ethernet switches
SCADA applications
Operating systems
Computing platforms, etc.
Adherence to implementation guidance and the security plan is tabulated in the system’s configuration management
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Definition
“Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items.”
[IEEE Std 729-1983 updated as IEEE Std 610.12-1990]
Configuration Management
Configuration
Identification
Configuration
Control
Configuration
Status
Accounting
Configuration
Audit &
Review

Part III: Security Administration

Benefits of
Configuration Management
Configuration management trades a one-time upfront cost and a little operational overhead for…
Money saved by avoiding unnecessary improvements and upgrades
Time and money saved by avoiding complications during necessary improvements
Time and money saved in maintenance
Without configuration management:
A simple disk failure turns into a system-

wide

upgrade
A one hour job turns into a week-long effort
A short control system downtime becomes loss of service
Configuration management is a tool
Enables change and operational crisis management
Part III: Security Administration

Configuration Identification
Select configuration items for a system and recording their functional and physical characteristics
Uniquely identify configuration items
Establish standard, reproducible characteristics for configuration items
Collect into baseline systems
Part III: Security Administration

Asset Inventory
Any configuration management program must start with a complete inventory of the equipment, software, hardware, etc in the system
All relevant information must be recorded: software versions/patch level, hardware model number, OS level, firewall rules, router ACLs, etc.
Part III: Security Administration

Item Identifiers
All configuration items must be recorded and assigned a unique identifier to assist in tracking
Unique identifiers can be
A unique inventory number
A combination of identifying information
Serial number + date of purchase + ?
This will assist all member of the team when it comes time to patch. Unique identifiers will allow the team to track which machines have been patched/upgraded.
Part III: Security Administration

Access Control
You need to keep track of the access control environment – both networks and platforms

Router

ACLs, firewall rules, and user password files are important configuration items
Remember to protect this information – it is invaluable to an adversary
Configuration management will help you keep track of who made changes, when, and why
Part III: Security Administration

Baselines
Baselines will be a secure configuration that has been rigorously tested by the SCADA engineers
Baselines can be used in disaster recovery or for new equipment added to the system
Develop the baseline configuration once configuration identification is complete
Part III: Security Administration

Common Operating Environment
Developing a COE for all equipment is a necessary evil
This will establish a stable starting point for all new machines introduced into the system
SCADA Security Administrators can remove any unnecessary services, applications, etc at this time
The COE is the software environment built using the implementation guide
Ideally, the COE can be installed with a simple process on new or old systems
Disk imaging programs such as Ghost
Install scripts such as Kickstart
Part III: Security Administration

System Changes
Changes to operational systems come in two flavors
Functional improvement
Maintenance
Functional improvement is usually incremental and limited in scope
Examples: adding new PLCs, changing network rules, changing device safety settings
Configuration management can help understand the consequences and improve the process
Part III: Security Administration

Maintenance
Maintenance – The recurrent, periodic, or scheduled work necessary to repair, prevent damage, or sustain existing components of an information or automation system
This is the most likely use of configuration management in an operational system
The next few slides will go into more detail about the maintenance process
Part III: Security Administration

Requesting Change
Who can request change?

Operator

s, SCADA engineers, business managers, security managers
Tracking requested changes
Record and assign identification to each change request
Avoid losing track of changes which makes configuration control impossible
Prevent losing important changes that could drop through the cracks
Part III: Security Administration

Evaluating Change
Changes aren’t always feasible
Even when changes can be made, often they can’t all be made at the same time
Prioritizing, planning, and organizing work is easier if changes are evaluated
One method – the person responsible for the affected component performs a change request analysis
Estimate feasibility
Estimate cost of making the change
Estimate effects on other parts of the system
Configuration Control Board (CCB) approves and prioritizes based on the analysis
The CCB doesn’t have to be formal
Part III: Security Administration

Developing and
Testing Change
Once a change is approved, engineers can develop the change
Using configuration management, they can start with the current status of the system
As they develop the change, they can determine what must be released to the operational system
Testing, either by the developers or (better yet) by a separate testing group ensures the proposed release will work
Part III: Security Administration

Releasing the Change
The CCB looks at the results of development and testing and decides whether or not to release the change
Some type of reporting is necessary – at least verbal reports
All involved have to remember that changes have pros and cons – make sure the pros beat the cons
Developers then release the change into the operational system and notify the requester
This is important to close the cycle
Part III: Security Administration

Configuration Status
Accounting
If you have done configuration identification, recorded that information, and have a change control process then you have everything necessary for Configuration Status Accounting (CSA)
This part of configuration management is what saves money and time
Being able to find out original configurations
Knowing your system state as you analyze changes
Part III: Security Administration

Patching Cycle
Patching software is a major cause of change requests
Software patches are a frequent headache for SCADA system engineers
SCADA applications’ release cycle is often much longer than platform patch cycles
SCADA applications tend to be sensitive to underlying platform changes
In a perfect world, patches would be unnecessary; in our world, it is an important part of system maintenance
Anyone familiar with modern operating systems knows that patches occur with regular frequency
These patches are released to solve a number of bugs, security holes, or other software problems
SCADA applications are becoming multipurpose and the code-base is larger. As a result, patching will become even more critical in the future.
Part III: Security Administration

Patching Cycle
How do you know when you need to patch your software?
Mailing lists are a great resource for keeping up to date
Vendor mailing lists have the highest value
Security mailing lists are less effective, requiring more time to sift through the irrelevancies
These lists will often be the first to issue information on patches or

updates

in software or hardware
Maintenance contracts with vendors can also help
Some vendors will give early warning to those with active maintenance contracts
Also, some vendors will only release patches to clients who have maintenance contracts
Part III: Security Administration

Applying Patches
What if this breaks my system?
It is possible that a patch will have a bug
Will break your existing system
Will turn on features or services you don’t want
Possibly, just not work
Installing the latest greatest patch without testing is a recipe for disaster…
You need to make an informed decision – What is the impact of a bad patch on your system versus not patching?
If the patch brings down every computer you own, it is probably much more costly to install the patch!
Which all brings us to…
Part III: Security Administration

Test Labs
So how can you be sure that the patch issued 5 minutes ago will work for YOUR stuff…
You need to test… and test with your environment, not an ideal network that does not adequately represent your system
Part III: Security Administration

What Goes in the Test Lab
Ideally – an exact replica of your entire system is best
But in reality:
Workstations and servers for every OS that you use
A sample of your network equipment (1 router, 1 switch, 1 firewall, …)
One of each type PLC, RTU, sensor, etc.
Some system data
An old capture of sensor data works well
Data must be similar to what you collect/use/process on a day to day basis
All of these should be configured to be an accurate representation of your system
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

Definitions
Audit
The function of measuring something against a standard
Auditing enforces configuration management, security plans, and implementation guidance
Assessment
More arbitrary and subjective: how well do the policies/implementations secure the system
Overall, assessment (internal and external) enforces the entire chain of security administration
Part III: Security Administration

Auditing vs. Assessment
Audit
Works with standards and best practices
Checklists to determine if you do what you say you do
Done to you
Assessment
Works with experts in the field and the implementation staff to find vulnerabilities
Tries to break the security on the system
Done with you
In traditional IT, either of the two may include penetration testing and vulnerability scans. This is strongly discouraged on SCADA systems.
Part III: Security Administration

Internal
Lower cost
Staff time is the greatest cost here
No privacy concerns
Staff has already been certified to see the data on the system
If there are different levels of data classification, ensure that staff performing the audit are permitted to see all levels
Day-to-day experience with the system can reveal problems that should be addressed
Other staff may be more willing to talk with internal auditors
Less educational down time since staff is already familiar with the system
Part III: Security Administration

External
Can be more comprehensive since the audit/assessment team must learn the system from scratch
This can lead to a more complete picture of the system
External parties may be aware of new tools and techniques
Not hampered by internal politics
Fewer blind spots
They have no special interest in any part of the system
Trust**
This may work for or against the auditors/assessors
Part III: Security Administration

Types of Audits
Conformance
How well system conforms to policies/procedures
Policy
Configuration
Best practice (other than security)
Security
Measure policy/procedures against security best practices
Physical
Cyber
Code
Generally only in software development environments
Part III: Security Administration

Types of Assessments
Threat Assessment
Identify the threats (internal and external)
Vulnerability Assessment
Identify vulnerabilities for a specific system in a normal operating environment
Risk Assessment
Risk = threat * vulnerability * consequence
Red Team Assessment
Identify high consequence vulnerabilities in a malicious threat environment
Part III: Security Administration

Protect
The information in an audit/assessment report would be highly valuable to any attacker
It identifies the weaknesses and existing controls protecting your system
These results should be protected at a high level
Before beginning an external audit/assessment, determine what the external company will do with the results
Is this an acceptable risk for your system
Part III: Security Administration

Read
There have been instances where an assessment/audit is performed and the interested parties do not have the time or inclination to read the results… Why bother?
There are other cases where a 200 page penetration/vulnerability test has been delivered… again why bother?
A good assessment/audit will produce a concise report that must be read and acted upon
Part III: Security Administration

Using the Assessment Results
An assessment is a waste of time, resources, and money if the findings are not used
A detailed report of what the assessment team found will assist the organization
Problems should be addressed in order of criticality
Fixes or mitigation strategies must be determined and implementation teams and deadlines assigned
After the fixes have (presumably) been completed, a follow-up assessment should be performed
Part III: Security Administration

Logging

Ideally, logs should be recorded for any device/application that has the potential to be misused
Reality
Not all devices/applications have logging capability
Logging DOES impact system performance
Logging must be tailored to ensure that operational jobs are still performed adequately
This may require some tweaking and time to get the right balance between logging and operations
Part III: Security Administration

Using Logs
Once you have all these log files sitting around, what do you do?
Logs can generate massive amounts of data to sort through
Logs need to be reviewed for evidence of malicious or incorrect behavior – this can be a full time job!
There are tools that can assist in this process
If you don’t look at the logs, you are wasting resources by collecting them
Part III: Security Administration

Concerns
Where to store the logs
How long to store the data
Who will review the data
How often will this be done
What is the classification for log data
This affects storage, review, and destruction procedures
Part III: Security Administration

Incidents
You’ve collected the log data, reviewed it, and you see evidence of a break-in. What now?
Wait
Preserve & backup
Notify
Lock down
Investigate
Part III: Security Administration

Wait
Do not immediately run to fix the problem
You might make it worse (cut off users)
You will destroy evidence
Part III: Security Administration

Preserve/Backup
Both the logs and an image of any affected machines should be copied for analysis
This will give you time to investigate later plus more stuff for prosecution
Try to get the copies on write-once media so there is no doubt about their integrity
This can assist in prosecution
There are several tools available to assist in this process*:
Ghost
dd

* Independent Review of Common Forensic Imaging Tools, Mark Scott, August 2003.
Part III: Security Administration

Notify
Do not head out on your own vigilante style
Have procedures of who to contact and when
System admins
Security people
Law enforcement
Users (maybe)
Part III: Security Administration

Lock Down
Secure the affected system
This may require severing network connections
This may require wiping the system and reinstalling from the baseline (see configuration management)
Use the backup system in the interim
Part III: Security Administration

Investigate
Now, take the time to fully investigate the logs and images of the systems

This process will ensure that users suffer a minimal downtime and evidence is retained for possible prosecution. It will also give investigators sufficient time to properly investigate the incident.
Part III: Security Administration

Part III: Security Administration
Security Policy
Security Plans
Implementation Guidance
Configuration Management
Auditing and Assessment
Security Enforcement
Part III: Security Administration

The Enforcement Cycle
For SCADA Administration
The IT control framework enforces the business direction of the company
The SCADA security policy enforces the IT control framework
Security plans and implementation guidance enforce the security policy
Configuration management enforces the security plan and implementation guidance
Auditing enforces configuration management, security plans, and implementation guidance
Overall, assessment (internal and external) enforces the entire chain of security administration
Part III: Security Administration

*
*
Copyright © 2005, Sandia Corporation.
The submitted manuscript has been authored by a contractor of the U.S. Government under contract No. DE-AC04-94AL85000. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government purposes.
Unlimited release – approved for public release.
Sandia National Laboratories report SAND2005-1001C.
Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.

Part IV:
Technical Best Practices
Part IV: Technical Best Practices

Technical Best Practices
Four categories:
Data Security
Architecture and Design
Platforms
Networks and Communication
Each section covers:
Introduction
Trends and Observations
Suggestions
Part IV: Technical Best Practices

Automation Reference Model
Describe data and functions
Map these to locations and equipment
Develop general best practices for security
Part IV: Technical Best Practices

Technical Best Practices
Data Security
Architecture and Design
Platforms
Networks and Communications
Part IV: Technical Best Practices

Data Security: Introduction
Rationale for data classification
Is payroll information more important than a FYI memo?
Is an archived gate signal more important than a valve control signal?
Determination of data sensitivity is based upon mission
Evaluation of CIA (Confidentiality, Integrity, Availability) requirements for data
Part IV: Technical Best Practices

Trends and Observations
Sites with no data categorized
All information is available to anyone
Security controls are usually commensurate to the levels determined
Often there are none
SCADA system are more “important” than other systems, but the data is still not categorized

Non

-SCADA has categorization, while SCADA does not
Part IV: Technical Best Practices

Data Security Categories
Live/Real-time
Safety/mission critical
Other operational status and control
Administrative
ACLs
Authentication information
Other configuration settings
Input/output database (points)
Archived
Trending data
Warranty and maintenance data
Accounting information
Part IV: Technical Best Practices

Data Security Sensitivity
Proposals refer to confidentiality
Integrity is necessary for all classes
Includes need-to-know/use
Highest level of protection listed first
Part IV: Technical Best Practices

Data Security Sensitivity
Shared with a small group within the work area
Specific to a function or task
Examples
Security controls information
Safety critical

commands

or measurements
Operator control directives
Administrative passwords on control systems
Points database
Shared within a group (perhaps including customers or suppliers)
Specific to certain functions or areas
Examples
Contaminate levels
Equipment status
Performance information
Accounting usage information
Shared with anyone
General in nature
Examples
Reservoir level
Gross plant output
Regulatory compliance
Part IV: Technical Best Practices
Private
Restricted
Public

Exceptions and Caveats
Regulated industries may have specific classifications
There may also be legal requirements for data protection
Part IV: Technical Best Practices

Technical Best Practices
Data Security
Architecture and Design
Platforms
Networks and Communications
Part IV: Technical Best Practices

Architecture and Design: Introduction
Architectures are specific to mission
Secure and reliable storage, processing, and transmission of system data
Designed to implement some consistent security policy
The system security plan is related to its architecture
Implements enclaves consistent with data sensitivity
An enclave is the “container” for data elements of like security characteristics
Enclaves can be implemented as perimeters
An enclave can be implemented as access controls on storage media or platforms
Part IV: Technical Best Practices

Trends and Observations
Not based on any security policy
Bolt-on security doesn’t work well (if at all)
Usually could be secured to a reasonable level, with good governance
Evolution of systems introduce vulnerabilities
Point solutions fix some perceived problem
Interactions not anticipated
Data enclaves not considered
Part IV: Technical Best Practices

Legacy Architecture
Radial serial links
Little or no distinction between users and administrators

Functions

/privileges associated with accounts, not individuals
No security maintenance (or ongoing risk management)
Do not integrate well in the security environment of newer components
No data protection (and no categorization of data)
Usually designed for a standalone environment, but are often used otherwise
Part IV: Technical Best Practices

Plant

Remote Station
Control

Center

Remote Station
Remote Station
Plant

Comm

interface

RTU

Modern Architecture
Commodity hardware and software has vulnerabilities built-in
They are not addressed by SCADA vendors
Have a larger set of attackers
Modern networking allows “better” access to all nodes
Vulnerabilities are unaddressed by the user’s organization
No security policy
No understanding of underlying IT systems
Out-of-the-box configurations are seldom safe or secure
Unreliability of patches necessitates development systems
Part IV: Technical Best Practices

Plant
Remote

site

Control Center

Remote site
Remote site
Plant

SCADA
Network
RTU

Hybrid Architectures
All types of vulnerabilities
Most common
Part IV: Technical Best Practices

Architecture and Design:
Suggestions
Mature policy and governance essential
Control and data hierarchy
Eliminate global access/privilege requirements
Use principle of least privilege
Access level commensurate to level of data sensitivity
Interconnections
Control direct connections behind the perimeter
Never violate security enclaves
Evolution
Risk assessment when adding new functions
Part IV: Technical Best Practices

Architecture and Design:
Suggestions
Heterogeneity
Diverse implementations improve survivability
Situational and operational security awareness
Operators/personnel aware of security issues
Training
Redundancy
Continuity of operations
Backups for critical data
Backups for critical communications
Backup platforms for critical nodes
Part IV: Technical Best Practices

Technical Best Practices
Data Security
Architecture and Design
Platforms
Networks and Communications
Part IV: Technical Best Practices

Platforms: Introduction
What is a platform?
A platform is a collection of hardware and software that can run a program

Platform

software includes its OS and applications
Examples of platforms:
Routers
IEDs / PLCs / RTUs

Server

s and clients
Part IV: Technical Best Practices

RTUs / PLCs / IEDs
Collect data from sensors and forwards commands to devices such as relays and valves
Can also aggregate data from other RTUs at remote sites and plants
More intelligent RTUs are becoming more prevalent
Pressures for RTU advancement:
Reduce duplication of functionality (points may be sampled many times over in a substation)
Network and processing power ample for distributed control
Simplified operation and management
Trends for RTUs
Similarity to other IT devices
Increasingly Ethernet or wireless
SCADA peer connections used for data transfer to/from other devices and for distributed control
Part IV: Technical Best Practices

SCADA Servers
Functionality
Send signals to acquire data
Receive data from the system
Calculate and disseminate signals for system-wide control
Current system values stored in a memory database
Drive operator displays
Populate data archives
Implementation
May be custom hardware for legacy systems, or an older OS (VMS, etc.)
Often, modern systems run on Windows or Unix
Platform for SCADA servers may be the same as those for display or archives
Part IV: Technical Best Practices

Types of SCADA
Servers and

Client

s
Human-Machine

Interface

(

HMI

)

Automated

control
EMS
WAP
AGC
Alarm and events reporting
Front-end processor (FEP)
Data archives

Part IV: Technical Best Practices

How Exploits Work
Attack opportunities
Buffer overflows
Input validation errors
Social engineering
Leverage existing bugs
Types of malware
Trojans
Viruses
Spyware
Worms
Results:
Additional access
Corruption or compromise
Privilege escalation
System failure / denial of service
Command injection
Part IV: Technical Best Practices

Trends and Observations
No configuration guidance
Administrator accounts
Shared accounts
Logging not enabled
Unnecessary services
Inadequate patching
Default OS installations
Etc.
Part IV: Technical Best Practices

Platforms: Suggestions
Authorization
Restrict execution privileges for programs
Access controls
Acceptable passwords
Cryptographically secure password storage
Secure remote authorization (radius server)
Necessary/unnecessary services
DHCP, SSH, Telnet, FTP, TFTP, BOOTP, SMTP, SNMP, HTTP, etc.
Disallow remote management
Carefully consider file sharing
Security of networked operating systems (NOS) is complex
Logging
Remote or local
Review logs for anomalies or attacks
Appropriate retention periods
Meets standards and requirements
Part IV: Technical Best Practices

Platforms: Suggestions
Physical security
USB ports, pen drives, guns/guards/gates
Physical access by an adversary means a compromise was possibly (if not likely)
Patch management
Backups
Incident response
Disaster recovery
Attack recovery/law enforcement imaging
Resources
SANS guides
NSA guides
NIST guides
GOVCERT
Etc.
Part IV: Technical Best Practices

Platforms: Suggestions
Limitations of security for

RTU/PLC/IED

/legacy equipment:
Not developed with security in mind
No user accounts
No logging
Typically, no encryption services
Usually a single privilege level (maybe two)
Passwords from small set of characters
Workarounds
Wrappers for applications

Terminal

servers for access
Change passwords often
Increase physical security (cameras, doors, locks, guards, guns, etc…)
Part IV: Technical Best Practices

Technical Best Practices
Data Security
Architecture and Design
Platforms
Networks and Communications
Part IV: Technical Best Practices

SCADA Reliance on Networks
System operations
Logical interconnection of SCADA elements for status/control telemetry
Transmission of performance data
Remote operations
Limited offsite operations and maintenance
Extend monitoring and control to corporate offices
System administration and maintenance
Configuration management
Patches, updates, and upgrades
Remote contractor maintenance access
Business integration
Provide network applications (e.g., email) to operational environment
Integrate business activities with operations (e.g., forecasting and automated billing)
Networks must maintain data attributes (confidentiality, integrity, availability, authentication, non-repudiation)
Part IV: Technical Best Practices

Protocols
Legacy SCADA Protocols
ASCII or even bit based
Runs over serial links
Oldest “protocols” are tones or current loops
No security services (hashes, encryption, etc.)
Hundreds of varieties because of legacy, manufacturer-specific stovepipe SCADA installations
Modern SCADA Protocols
May run over serial, but increasingly support IP stacks
Often are object-oriented
Based on open or de facto standards
Still largely absent of intrinsic data security services
Greater functionality than legacy protocols
Part IV: Technical Best Practices

Trends and Observations
(You’ve seen this before…)
SCADA networks are increasing in scope and function
Increasing automation (remote locations)
Adoption of TCP/IP networking
Transition to public and virtual-private networks
Use of SCADA networks for other purposes (alarm)
Near real-time control
Outsourcing network (and system) administration
Shrinking boundary between business and operational networks
Part IV: Technical Best Practices

SCADA Dependence
On the Internet
Significant and growing
System operations
Connectivity among SCADA elements
Connectivity between SCADA systems
Remote operation through VPN access
System administration and maintenance
Example: contract network management
Business integration
Example: publishing data directly from SCADA to the Internet
Part IV: Technical Best Practices

Wireless

Connectivity
Licensed band wireless

Microwave

Satellite
ISM unlicensed band wireless
802.11(a, b, g, etc…)
WEP, WPA, 802.1x (EAP, LEAP)
Packet radios
Other wireless techniques
Frequency hopping
Spread spectrum
None of these are secure by themselves
Use the best security available to you
Part IV: Technical Best Practices

Perimeter

s
Security enclaves
Based upon trust and data sensitivity
Defines perimeters and boundary points of systems/subsystems
Enforcement by router, firewall, application proxies, other filters
Address, service, content
Stateful, stateless
Need-to-know data flows may cross boundaries
Serial communications
Bulk encryptor plus physical security at endpoint
Wrap communication into a packet
Application proxy testing
Part IV: Technical Best Practices

Internet/

Intranet

Connection
Evaluate the business case first
Strict access controls determined by required data flows
Example router/firewall

DMZ

configuration:
Need to archive data for administrative usage
SCADA pushes data to archive machine
Users pull data from archive machine

Connections

allowed from SCADA to DMZ
Connections allowed from admin to DMZ
All other connections denied
Only necessary and valid services, messages, content, and addresses allowed to the DMZ
Part IV: Technical Best Practices

Remote Access

Evaluate the business case first
Options
VPN

Dial

-up
Activities
Remote data
Platform management
Application usage
Protection mechanisms
Positive ID for authorization
Authenticate user/device
Token cards/one-time passwords
Encrypt traffic
Log all usage
Use access timeouts & lockouts, activity timeouts, time periods
Minimum privilege
Deactivate when unnecessary
Part IV: Technical Best Practices

External/3rd Party Access
Evaluate the business case first
External vendors
Through protected mechanisms only
Authentication
Access controls
Application proxies
Etc…
Minimum privilege
Deactivate when unnecessary
External sources of data
Application proxies and validity checking
Procedures for operation when receiving invalid data
Receive as analog
Providing data to external systems
Use archived data
Send as analog
View-only terminals
Part IV: Technical Best Practices

Other Security Suggestions
Implementation guidance should mandate secure default configurations on all network devices
Force “good” passwords and eliminate default passwords
Disable in-band management (SNMP, Telnet, FTP/TFTP, web, etc.)
Disable finger
Disable routing of private network addresses
Control switch and hub connections
Use PPN/VPN
Adequate physical security
PPN can’t be shared
VPN can be shared
IDS
Technologies
Signatures
Anomaly detection
Advantages
Can catch known attacks
Good research tool
Disadvantages
False positives and negatives
Can compromise the architecture
Manpower intensive

Part IV: Technical Best Practices

DISCUSSION
Clemson University – 2004 Power Systems Conference
Part V: Discussion

SCADA System Security Program

SCADA Security Policy Framework

SCADA organization

and relationships

SCADA information
architecture

SCADA data

categorization and
ownership
Data
security

Data backup policy

Malicious software

protection policy

Data storage and

destruction policy

Platform
security
Communica
–

tion security

Manual
operations

Perimeter policy

Wired

connectivity

Wireless
connectivity
Remote access

External / 3

rd
party
access
Personnel
security
Acceptable use
policy

Account and

password policy

Configuration
management

Security plan and

guidance policy

Security policy

maintenance policy

Configuration

accounting policy

Audit

Accreditation policy

Internal/External

Audit policy

Incident reporting

policy

Log policy

Intrusion detection

policy

Applications

Support application

policy

SCADA application

policy
Physical
security

Asset Disposal

Training policy

Security risk

management
Client
RTU/PLC/IED
Server

SCADA Asset

Protection

Assessment Policy

l
a
t
i
g
i
d
l
a
t
i
g
i
d
RTU

Substation

Automation
Terminal

Power Metering Device

Power Protection Device

Power Control Device

Data

Aquisition

–
SCADA

Data Base Server

Comm
Interface
Comm
Interface

Meter Reader

(RF)

Internet

SCADA Control Center

SCADA Remote Site

•

SCADA Topology Model

•

Telemetry Database

•

History Logging

•

Alarm System

•

Load Shedding List

Data Acquisition User

Terminal
–

MMI/HMI

GIS

Management System

Billing System

Meter Reader

Other Admin Functions

l
a
t
i
g
i
d

RTU 2

RTU 3

RTU 4

RTU n
RTU 1
RTU 2
RTU 1
Category

Vulnerability

Minimal data flow control is employed (e.g. minimal use of

ac
cess

control lists

virtual private networks, or virtual

LAN

Configurations are not stored or backed up for network devices.

Passwords are

not encrypted in transit.

Passwords exist indefinitely on network devices.

Passwords on devices are shared

Administration

Minimal administrative access controls are applied.

There is inadequate physical protection of network equipment.

Hardware

Non
–

critical personn

el have physical access to equipment.

No security perimeter has been defined for the system tha

defines access points which must be secured.

Firewall

s are nonexistent or poorly configured at interfaces to

external (non

–

PCS) networks.

Perimeter

PCS networks are used for non

–

PCS traffic.

Firewall and router logs are neither collected

nor examined.

Monitoring &

Logging

There is no security monitoring on the PCS network.

Critical monitoring and control paths are unidentified,

complicating redundancy or contingency plans.

Link Security

PCS connections over vulnerable links are not protected with

encrypt
ion.

Authentication for remote access is substandard or nonexistent.

Remote Access

Remote access into the PCS network utilizes shared passwords

and shared accounts.

Wireless
Connections

Wireless LAN technology used in the PCS network without

strong a

uthentication and/or data protection between clients and

access points.