summary

*

*

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.

TUTORIAL C:
AUTOMATION SECURITY TUTORIAL

Jason Stamp

Networked Systems Survivability and Assurance Department

Sandia National Laboratories

March 11, 2005

Clemson University – 2004 Power Systems Conference

Copyright © 2005 Sandia Corporation

*

*

Outline

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

Copyright © 2005 Sandia Corporation

*

*

Part I: Introduction

• Definitions
• Current Security Vulnerabilities
• Components of Sustainable Security

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

Automation Systems

Any subsystem that electronically measures state, alters process control parameters, presents / stores / communicates data, or the management thereof

Part I: Introduction

Master Station

Sub-Master Station

RTU 1

RTU n

RTU 1

RTU m

Sensor

Relay

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Vulnerabilities Exist

• SCADA equipment, IT equipment upon which SCADA depends, software, processes, policies, communications, etc…
• Common Vulnerabilities in Critical Infrastructure Control Systems, SAND2003-1772C
• More vulnerabilities exist than have been found
• http://www.sandia.gov/scada

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Changing SCADA Systems

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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.

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Vulnerabilities:
Platforms

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

Vulnerabilities:
Networks and Communications

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

Future Automation Security

• Security administration
• Better security technology
• Third-party assessments

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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 encryption for serial SCADA
• Application-layer stateful inspection for SCADA firewalls
• Accounts and logging for RTUs

Part I: Introduction

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part II: Threat Environment

Part II: Threat Environment

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Outsider Cyber Threat

• Hackers – 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

Copyright © 2005 Sandia Corporation

*

*

Outsider Adversary Levels

Part II: Threat Environment

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Insider Levels

Part II: Threat Environment

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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 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 III:
Security Administration

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Policy Framework

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

Policy Section Headings

• Purpose
• Scope
• Policy
• Responsibilities
• References
• Revision History
• Enforcement
• Exceptions

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Requesting Change

• Who can request change?
• Operators, 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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Part III: Security Administration

• Security Policy
• Security Plans
• Implementation Guidance
• Configuration Management
• Auditing and Assessment
• Security Enforcement

Part III: Security Administration

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Automation Reference Model

• Describe data and functions
• Map these to locations and equipment
• Develop general best practices for security

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

Technical Best Practices

• Data Security
• Architecture and Design
• Platforms
• Networks and Communications

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Exceptions and Caveats

• Regulated industries may have specific classifications
• There may also be legal requirements for data protection

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

Technical Best Practices

• Data Security
• Architecture and Design
• Platforms
• Networks and Communications

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Hybrid Architectures

• All types of vulnerabilities
• Most common

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Technical Best Practices

• Data Security
• Architecture and Design
• Platforms
• Networks and Communications

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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
• Servers and clients

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Types of SCADA
Servers and Clients

• Human-Machine Interface (HMI)
• Automated control
• EMS
• WAP
• AGC
• Alarm and events reporting
• Front-end processor (FEP)
• Data archives

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Technical Best Practices

• Data Security
• Architecture and Design
• Platforms
• Networks and Communications

Part IV: Technical Best Practices

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

Perimeters

• 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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

Copyright © 2005 Sandia Corporation

*

*

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

*

*

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.

DISCUSSION

Clemson University – 2004 Power Systems Conference

Part V: Discussion