Copyright © 2005, Sandia Corporation. The submitte.docx

*
*
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
*
*
OutlinePart I: IntroductionPart II: Threat EnvironmentPart III:
Security AdministrationPart IV: Technical Best PracticesPart V:
Discussion
*
*
Part I: IntroductionDefinitionsCurrent Security
VulnerabilitiesComponents of Sustainable Security
Part I: Introduction
*
*
Automation Systems
Any subsystem that electronically measures state, alters process
control parameters, presents / stores / communicates data, or the

management thereof
Master Station
Sub-Master Station
RTU 1
RTU n
RTU 1
RTU m
Sensor
Relay
*
*
Automation SystemsCritical to the safe, reliable, and efficient
operation of many physical processes Used extensively in
infrastructure Electric powerWaterPetroleumNatural gasAlso
used in manufacturing operationsAutomation enables quicker
and more coordinated system control compared to human
operation (in many cases there is no effective alternative)

*
*
Automation Systems in
Electric PowerSCADASupervisory Control and Data
Acquisition(All-encompassing government term for
automation)EMSEnergy Management
SystemProtectionRelayingAGCAutomatic Generation
ControlWAPWide Area ProtectionEtc.
*
*
Categories For
Automation ComponentsSystem dataFundamental element of
any information systemSystem security is applied to preserve
data attributes (AAI&C)Security administrationEncompasses
non-automation functions as documentation and
procedureComponents include security plans, implementation
guidance, configuration management and security enforcement
& auditingArchitecture & designPlatformsNetworks and
communications

*
*
Vulnerabilities ExistSCADA equipment, IT equipment upon
which SCADA depends, software, processes, policies,
communications, etc…Common Vulnerabilities in Critical
Infrastructure Control Systems, SAND2003-1772CMore
vulnerabilities exist than have been
foundhttp://www.sandia.gov/scada
*
*
Vulnerabilities are ProliferatingDependence on Internet and
related technologyIncreasing adoption of new
technologiesReliance upon automation over human
controlConnectivity between SCADA & IT enterpriseUnique
issues related to real time controlSlow adoption of security
solutions

*
*
Relevant TrendsDesign is moving towards open standards Most
hardware vendors are foreign companiesNumerous integrators
and system providersPresent state of security is not
commensurate with the threat or potential consequencesSecurity
is 5-10 years behind typical IT systems because of isolated
stovepipe organizationArbitrary applications of technology,
informal security, and the fluid vulnerability environment lead
to unacceptable risk
*
*
Changing SCADA Systems
*
*
Vulnerabilities:

DataSensitivity levels for PCS data are usually not
establishedAbsence of data sensitivity distinctions makes it
impractical and fruitless to identify where security precautions
are appropriateLack of data classifications is a direct byproduct
of deficient administration in automation security
*
*
Vulnerabilities:
Security Administration
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 DesignMany 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
signalsIn some cases, security, fire, and other systems are
integrated into the automation system as points of measurement
and control

*
*
Vulnerabilities:
Platforms
*
*
Vulnerabilities:
Networks and Communications
*
*
Future Automation SecuritySecurity administrationBetter
security technologyThird-party assessments

*
*
Security AdministrationSecurity administration is paramount to
manage security risksExploited vulnerabilities are directly
related to implementation and operation of a particular SCADA
systemSCADA 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
*
*
Security AdministrationModern 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

developmentsSCADA security administrator must have clear
authority to alter running configurations to mitigate
vulnerabilitiesThat power must derive from clear and direct
policy
*
*
Improved TechnologyCritical 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
protocolsLow-cost encryption for serial SCADAApplication-
layer stateful inspection for SCADA firewallsAccounts and
logging for RTUs
*
*
Third Party AssessmentsInternal auditing and assessment of
security administration and system implementation are
essentialRegular external evaluations are also critical to catch
residual problems caused by organizations being too close to

issues or unaware of new tactics and toolsContemporary
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 II: Threat Environment
*
*
Threats are IncreasingIncreasing awareness by adversaries of
cyber as an attack mechanismAdoption of Internet technology
adds a practiced class of adversariesReducing sophistication
needed to be a cyber adversary is allowed by proliferating
attack toolsIncreasing threat of worms and viruses

*
*
Malevolent Threat AssessmentClass - Criminal, Terrorist,
Extremist, Political/militaryMotivationCapability - skills,
resources, technologyTactics - stealth, deceit, social
engineeringAction - sabotage (denial of service,
misinformation) or theftType - insider, outsider,
collusionConstraints - risk aversion, monetary, tactics
*
*
Outsider Cyber ThreatHackers – cause trouble (vandalism),
potential for extensive damageHacker coalition – promote a
cause or positionOrganized crime – profit motivatedForeign
intelligence – promote a cause or position at an international
level
*
*

Outsider Adversary Levels
*
*
Insider Cyber ThreatPhysical access onlyMaintenance /
custodial staff, contractorsPower user, no special privilegeUse
SCADA information / control systemsDomain knowledge with
privileges Manages and maintains SCADA information and
control systems
*
*
Insider Levels

*
*
Cyber TerrorismTerrorist:Someone using force or violence to
intimidate or coerce a government or civilian population in
furtherance of political or social objectivesCyber
Terrorist:Someone who uses cyber mechanisms to intimidate or
coerce a government or civilian population in furtherance of
political or social objectives
*
*
Cyber Terrorist
Goals and MethodsRemotely affect systems resulting in:Injury /
loss of lifeLoss of availabilityLoss of public confidence
Disruption of ability to meet mission goals:Damage to
equipment or facilitiesCorrupt databasesDenial of serviceInject
false informationCreate false trust or mistrust
*
*

Cyber ConcernsNo “Cyber Pearl Harbor” event yetPerhaps
because:The current generation of terrorists may not trust this
mediumAs technology savvy terrorists increase in rank and
influence, these mechanisms may be considered as more
valuableAs it is proven to be an effective means for terrorism,
its use may increase
Assessments Introduction
*
*
Part III:
Security Administration

Part III: Security Administration
*
*
Part III: Security AdministrationSecurity PolicySecurity
PlansImplementation GuidanceConfiguration
ManagementAuditing and AssessmentSecurity Enforcement
*
*
Administration For
Sustainable SecurityControl frameworkA starting point for the
business administration of the enterprise employing
SCADASecurity 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 investmentEnforcementSecurity
policySecurity plansImplementation guidanceConfiguration
managementAuditing/assessment Technical security
controlsSecurity policy is key: it bridges the control framework
to enforcement

*
*
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
*

*
*
*
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
personnelUnique characteristics of SCADA necessitate a
complete policy separate from the normal company information
policyFormulated by the SCADA management staff, with input
from the business leadershipFosters a strong link between the
control framework and the policy
*
*

What is Policy?A formal statement of what will (and will not)
be doneMandatory rules that will be followed... not suggestions
or guidelinesProduct and vendor independent
It does not include system security settings, configuration rules,
or computer setup rules
*
*
Justification for Separate
Automation PolicyAcceptable use of automation system should
be narrower than IT systems due to:Different missionDifferent
sensitivity of dataDifferent criticality of functionAutomation
systems have more immediate physical consequences
therefore:Interconnections must be better controlledAccess and
CM more strictly enforced and monitoredAdministration and
enforcement is simpler with a separate policyDon’t embellish
IT... this just gets messy when trying to include all of the
caveats for automationTension between automation systems and
IT security
*

*
Justification for Separate
Automation PolicySmaller, different audienceSCADA
engineersSCADA operatorsNot business administrators, HR,
regular employeesLegislative requirements on automation
systems are differentCurrently, security plans, policy, etc are
not required, but...With current concerns fueled by incidents
like the blackout in the northeast, regulation is comingIt’s
better to have the administrative controls in place before they
are required by legislation
*
*
Policy Elements Definitions for critical organizational elements
Positions in the automation systems security administrationData
categorization and ownershipDescription of important elements
of the automation architectureCreation and enforcement of the
risk management program for automation securityEvaluating
vulnerabilities and their security controls Security investments
Residual riskReview cycle (which contributes to ongoing
security through risk reevaluation)

*
*
Policy SectionsData securityPlatformsNetworks and
communicationsManual operation (including
exercises)PersonnelSecurity training Essential for
understanding policy and requirements, and staff compliance is
predicated upon adequate awarenessEnforcementSecurity plans
for specific systems or subsystemsImplementation guidance for
specific technologiesConfiguration management
Auditing/assessment
*
*
Policy FrameworkWhy a framework?Allows for a systematic
approachConvenientHierarchicalEasy to sortCreated for
automation systemsHistory of assessmentsMultiple
industriesMultiple iterations
*
*

Policy Framework
*
*
Policy Section HeadingsPurpose
ScopePolicyResponsibilitiesReferencesRevision
HistoryEnforcementExceptions
*
*
*
*

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 realityThe plan is the core security document
for implementation, operation, and maintenanceVery 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 frameworkConsiderably more
technical than policyElements of the security plan can be
garnered from statements of industry practice or best practice
*
*
System IdentificationSystem Name/TitleUnique identifying
informationResponsible organizationEx: federal organization
responsible for the systemContact informationSufficient
information so that a responsible party can be located.System
owner will be designated here
*
*

System IdentificationSecurity PersonnelThe contact information
for the person ultimately responsible for the security of the
systemOperational StatusThe system (or parts) may be in
development or maintenance phasesDescriptionGeneral
description and purpose of the systemSoftware, hardware, and
vendor information
*
*
System IdentificationEnvironmentAny details about the
operating environment that raise security concerns (i.e.
connected to the Internet) What hardware or software is used to
secure these connectionsInterconnectionsInclude up-to-date
network diagramsLaws, regulations, and policiesThis ties back
to the Organization and Relationships portion of the security
policySensitivityFor both information and systemUse the data
categories defined within the policy
*
*
Management ControlsAssessment and auditing managementList

known/identified threats and vulnerabilitiesInclude dates,
results, planned dates, etc for auditing and
assessmentAssessment and audit resultsBoth internal and
externalInclude dates if changes are necessaryRules of
BehaviorEmployees should sign a copy of this and review
oftenAccreditation details
*
*
Management ControlsPlanning for system lifecycleDescribe
how security has been implemented for all phases of the system
InitiationDevelopment/AcquisitionImplementationOperation/Ma
intenanceDisposalConfiguration management issues need to be
considered for all phases
*
*
Operational ControlsPersonnel securityBackground checksLeast
privilege/need-to-knowComputer room accessTermination
proceduresPhysical & environmental controlsPhysical
accessEmergency preparednessData protectionAudit trails,
marking, transportation, etc.

*
*
Operational ControlsContingency PlansBackup &
recoveryDisaster recoveryManual Operations PlanMaintenance
ControlsConfiguration managementAccess controlsParts of this
will be covered in rules of behavior and technical controls
sections
*
*
Operational ControlsData integrity and validation
controlsDocumentation inventoryVendor
documentsAdministrative documents (policy, procedures,
etc)Security trainingIncident response capability and handling
procedures

*
*
Technical ControlsIdentification/authenticationPasswords,
smartcards, etc.Logical access controlsWho or what can have
access to specific system resourcesRemote access
controlsScreen saver locks and banner requirements will also be
included hereAudit trails / logsWhat must be logged by what
devicesWho has access to the logsReview and retention cycle
*
*
*
*
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 softwareAlmost entirely
technicalExample: an implementation guide for the application
of password checking software on some particular computing
platformThe 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 companyOther implementation guides Network
cablingEthernet switchesSCADA applicationsOperating
systemsComputing platforms, etc.Adherence to implementation
guidance and the security plan is tabulated in the system's
configuration management
*
*
*
*

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
*
*
Benefits of
Configuration ManagementConfiguration management trades a
one-time upfront cost and a little operational overhead
for…Money saved by avoiding unnecessary improvements and
upgradesTime and money saved by avoiding complications

during necessary improvementsTime and money saved in
maintenanceWithout configuration management:A simple disk
failure turns into a system-wide upgradeA one hour job turns
into a week-long effortA short control system downtime
becomes loss of serviceConfiguration management is a
toolEnables change and operational crisis management
*
*
Configuration IdentificationSelect configuration items for a
system and recording their functional and physical
characteristicsUniquely identify configuration itemsEstablish
standard, reproducible characteristics for configuration
itemsCollect into baseline systems
*
*
Asset InventoryAny configuration management program must
start with a complete inventory of the equipment, software,
hardware, etc in the systemAll relevant information must be
recorded: software versions/patch level, hardware model
number, OS level, firewall rules, router ACLs, etc.

*
*
Item IdentifiersAll configuration items must be recorded and
assigned a unique identifier to assist in trackingUnique
identifiers can beA unique inventory numberA combination of
identifying informationSerial 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.
*
*
Access ControlYou need to keep track of the access control
environment – both networks and platformsRouter ACLs,
firewall rules, and user password files are important
configuration itemsRemember to protect this information - it is
invaluable to an adversaryConfiguration management will help
you keep track of who made changes, when, and why

*
*
BaselinesBaselines will be a secure configuration that has been
rigorously tested by the SCADA engineersBaselines can be used
in disaster recovery or for new equipment added to the
systemDevelop the baseline configuration once configuration
identification is complete
*
*
Common Operating EnvironmentDeveloping a COE for all
equipment is a necessary evilThis will establish a stable starting
point for all new machines introduced into the systemSCADA
Security Administrators can remove any unnecessary services,
applications, etc at this timeThe COE is the software
environment built using the implementation guideIdeally, the
COE can be installed with a simple process on new or old
systemsDisk imaging programs such as GhostInstall scripts such
as Kickstart

*
*
System ChangesChanges to operational systems come in two
flavorsFunctional improvementMaintenanceFunctional
improvement is usually incremental and limited in
scopeExamples: adding new PLCs, changing network rules,
changing device safety settingsConfiguration management can
help understand the consequences and improve the process
*
*
MaintenanceMaintenance – The recurrent, periodic, or
scheduled work necessary to repair, prevent damage, or sustain
existing components of an information or automation
systemThis is the most likely use of configuration management
in an operational systemThe next few slides will go into more
detail about the maintenance process
*
*

Requesting ChangeWho can request change?Operators, SCADA
engineers, business managers, security managersTracking
requested changesRecord and assign identification to each
change requestAvoid losing track of changes which makes
configuration control impossiblePrevent losing important
changes that could drop through the cracks
*
*
Evaluating ChangeChanges aren’t always feasibleEven when
changes can be made, often they can’t all be made at the same
timePrioritizing, planning, and organizing work is easier if
changes are evaluatedOne method - the person responsible for
the affected component performs a change request
analysisEstimate feasibilityEstimate cost of making the
changeEstimate effects on other parts of the
systemConfiguration Control Board (CCB) approves and
prioritizes based on the analysisThe CCB doesn’t have to be
formal
*
*

Developing and
Testing ChangeOnce a change is approved, engineers can
develop the changeUsing configuration management, they can
start with the current status of the systemAs they develop the
change, they can determine what must be released to the
operational systemTesting, either by the developers or (better
yet) by a separate testing group ensures the proposed release
will work
*
*
Releasing the ChangeThe CCB looks at the results of
development and testing and decides whether or not to release
the changeSome type of reporting is necessary - at least verbal
reportsAll involved have to remember that changes have pros
and cons - make sure the pros beat the consDevelopers then
release the change into the operational system and notify the
requesterThis is important to close the cycle
*
*

Configuration Status
AccountingIf 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 timeBeing able to find out original
configurationsKnowing your system state as you analyze
changes
*
*
Patching CyclePatching software is a major cause of change
requestsSoftware patches are a frequent headache for SCADA
system engineersSCADA applications’ release cycle is often
much longer than platform patch cyclesSCADA applications
tend to be sensitive to underlying platform changesIn a perfect
world, patches would be unnecessary; in our world, it is an
important part of system maintenanceAnyone familiar with
modern operating systems knows that patches occur with regular
frequencyThese patches are released to solve a number of bugs,
security holes, or other software problemsSCADA applications
are becoming multipurpose and the code-base is larger. As a
result, patching will become even more critical in the future.

*
*
Patching CycleHow do you know when you need to patch your
software?Mailing lists are a great resource for keeping up to
dateVendor mailing lists have the highest valueSecurity mailing
lists are less effective, requiring more time to sift through the
irrelevanciesThese lists will often be the first to issue
information on patches or updates in software or
hardwareMaintenance contracts with vendors can also helpSome
vendors will give early warning to those with active
maintenance contractsAlso, some vendors will only release
patches to clients who have maintenance contracts
*
*
Applying PatchesWhat if this breaks my system?It is possible
that a patch will have a bugWill break your existing systemWill
turn on features or services you don’t wantPossibly, just not
workInstalling 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...

*
*
Test LabsSo 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
*
*
What Goes in the Test LabIdeally – an exact replica of your
entire system is bestBut in reality:Workstations and servers for
every OS that you useA sample of your network equipment (1
router, 1 switch, 1 firewall, ...)One of each type PLC, RTU,
sensor, etc.Some system dataAn old capture of sensor data
works wellData must be similar to what you collect/use/process
on a day to day basisAll of these should be configured to be an
accurate representation of your system

*
*
*
*
DefinitionsAuditThe function of measuring something against a
standard Auditing enforces configuration management, security
plans, and implementation guidanceAssessmentMore arbitrary
and subjective: how well do the policies/implementations secure
the systemOverall, assessment (internal and external) enforces
the entire chain of security administration
*
*
Auditing vs. Assessment AuditWorks with standards and best
practicesChecklists to determine if you do what you say you

doDone to youAssessmentWorks with experts in the field and
the implementation staff to find vulnerabilitiesTries to break the
security on the systemDone with you
In traditional IT, either of the two may include penetration
testing and vulnerability scans. This is strongly discouraged on
SCADA systems.
*
*
InternalLower costStaff time is the greatest cost hereNo privacy
concernsStaff has already been certified to see the data on the
systemIf there are different levels of data classification, ensure
that staff performing the audit are permitted to see all
levelsDay-to-day experience with the system can reveal
problems that should be addressedOther staff may be more
willing to talk with internal auditorsLess educational down time
since staff is already familiar with the system
*
*
ExternalCan be more comprehensive since the audit/assessment
team must learn the system from scratchThis can lead to a more

complete picture of the systemExternal parties may be aware of
new tools and techniquesNot hampered by internal
politicsFewer blind spotsThey have no special interest in any
part of the systemTrust**This may work for or against the
auditors/assessors
*
*
Types of AuditsConformanceHow well system conforms to
policies/procedures PolicyConfigurationBest practice (other
than security)SecurityMeasure policy/procedures against
security best practicesPhysicalCyberCodeGenerally only in
software development environments
*
*
Types of AssessmentsThreat Assessment Identify the threats
(internal and external)
Vulnerability AssessmentIdentify vulnerabilities for a specific
system in a normal operating environment
Risk AssessmentRisk = threat * vulnerability * consequence
Red Team AssessmentIdentify high consequence vulnerabilities

in a malicious threat environment
*
*
ProtectThe information in an audit/assessment report would be
highly valuable to any attackerIt identifies the weaknesses and
existing controls protecting your systemThese results should be
protected at a high levelBefore beginning an external
audit/assessment, determine what the external company will do
with the resultsIs this an acceptable risk for your system
*
*
ReadThere 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

*
*
Using the Assessment ResultsAn assessment is a waste of time,
resources, and money if the findings are not usedA detailed
report of what the assessment team found will assist the
organizationProblems should be addressed in order of
criticalityFixes or mitigation strategies must be determined and
implementation teams and deadlines assignedAfter the fixes
have (presumably) been completed, a follow-up assessment
should be performed
*
*
LoggingIdeally, logs should be recorded for any
device/application that has the potential to be
misusedRealityNot all devices/applications have logging
capabilityLogging DOES impact system performanceLogging
must be tailored to ensure that operational jobs are still
performed adequatelyThis may require some tweaking and time
to get the right balance between logging and operations

*
*
Using LogsOnce you have all these log files sitting around,
what do you do?Logs can generate massive amounts of data to
sort throughLogs 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 processIf you don’t look at the logs,
you are wasting resources by collecting them
*
*
ConcernsWhere to store the logsHow long to store the dataWho
will review the dataHow often will this be doneWhat is the
classification for log dataThis affects storage, review, and
destruction procedures
*
*

IncidentsYou’ve collected the log data, reviewed it, and you see
evidence of a break-in. What now?WaitPreserve & backup
NotifyLock downInvestigate
*
*
WaitDo not immediately run to fix the problemYou might make
it worse (cut off users)You will destroy evidence
*
*
Preserve/BackupBoth the logs and an image of any affected
machines should be copied for analysisThis will give you time
to investigate later plus more stuff for prosecutionTry to get the
copies on write-once media so there is no doubt about their
integrityThis can assist in prosecutionThere are several tools
available to assist in this process*:Ghostdd
* Independent Review of Common Forensic Imaging Tools,
Mark Scott, August 2003.

*
*
NotifyDo not head out on your own vigilante styleHave
procedures of who to contact and whenSystem adminsSecurity
peopleLaw enforcementUsers (maybe)
*
*
Lock DownSecure the affected systemThis may require severing
network connectionsThis may require wiping the system and
reinstalling from the baseline (see configuration
management)Use the backup system in the interim
*
*
InvestigateNow, 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.
*
*
*
*
The Enforcement Cycle
For SCADA AdministrationThe IT control framework enforces
the business direction of the companyThe SCADA security
policy enforces the IT control frameworkSecurity plans and
implementation guidance enforce the security
policyConfiguration management enforces the security plan and
implementation guidanceAuditing enforces configuration

management, security plans, and implementation
guidanceOverall, assessment (internal and external) enforces the
entire chain of security administration
*
*
Part IV:
Technical Best Practices
Part IV: Technical Best Practices

*
*
Technical Best PracticesFour categories:Data
SecurityArchitecture and DesignPlatformsNetworks and
CommunicationEach section covers:IntroductionTrends and
ObservationsSuggestions
*
*
Automation Reference ModelDescribe data and functionsMap
these to locations and equipmentDevelop general best practices
for security
*
*
Technical Best PracticesData SecurityArchitecture and
DesignPlatformsNetworks and Communications

*
*
Data Security: IntroductionRationale for data classificationIs
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
missionEvaluation of CIA (Confidentiality, Integrity,
Availability) requirements for data
*
*
Trends and ObservationsSites with no data categorized All
information is available to anyoneSecurity controls are usually
commensurate to the levels determined Often there are
noneSCADA system are more “important” than other systems,
but the data is still not categorizedNon-SCADA has
categorization, while SCADA does not
*

*
Data Security Categories Live/Real-timeSafety/mission
criticalOther operational status and
controlAdministrativeACLsAuthentication informationOther
configuration settingsInput/output database (points)
ArchivedTrending dataWarranty and maintenance
dataAccounting information
*
*
Data Security SensitivityProposals refer to
confidentialityIntegrity is necessary for all classesIncludes
need-to-know/useHighest level of protection listed first
*
*
Data Security SensitivityShared with a small group within the
work areaSpecific to a function or taskExamplesSecurity
controls informationSafety critical commands or
measurementsOperator control directivesAdministrative
passwords on control systemsPoints database

Shared within a group (perhaps including customers or
suppliers)Specific to certain functions or
areasExamplesContaminate levelsEquipment statusPerformance
informationAccounting usage information
Shared with anyoneGeneral in natureExamplesReservoir
levelGross plant outputRegulatory compliance
Private
Restricted
Public
*
*
Exceptions and CaveatsRegulated industries may have specific
classificationsThere may also be legal requirements for data
protection
*
*

*
*
Architecture and Design: IntroductionArchitectures are specific
to missionSecure and reliable storage, processing, and
transmission of system dataDesigned to implement some
consistent security policyThe system security plan is related to
its architectureImplements enclaves consistent with data
sensitivityAn enclave is the “container” for data elements of
like security characteristicsEnclaves can be implemented as
perimetersAn enclave can be implemented as access controls on
storage media or platforms
*
*
Trends and ObservationsNot based on any security policyBolt-
on security doesn’t work well (if at all)Usually could be secured
to a reasonable level, with good governanceEvolution of
systems introduce vulnerabilitiesPoint solutions fix some
perceived problemInteractions not anticipatedData enclaves not
considered

*
*
Legacy ArchitectureRadial serial linksLittle or no distinction
between users and administratorsFunctions/privileges associated
with accounts, not individualsNo security maintenance (or
ongoing risk management)Do not integrate well in the security
environment of newer componentsNo data protection (and no
categorization of data)Usually designed for a standalone
environment, but are often used otherwise
Plant
Remote Station
Control Center
Remote Station
Remote Station
Plant
Comm interface
RTU

*
*
Modern ArchitectureCommodity hardware and software has
vulnerabilities built-inThey are not addressed by SCADA
vendorsHave a larger set of attackersModern networking allows
“better” access to all nodesVulnerabilities are unaddressed by
the user’s organizationNo security policyNo understanding of
underlying IT systemsOut-of-the-box configurations are seldom
safe or secureUnreliability of patches necessitates development
systems
Plant
Remote site
Control Center
Remote site
Remote site
Plant
SCADA
Network
RTU
*
*
Hybrid ArchitecturesAll types of vulnerabilitiesMost common

*
*
Architecture and Design:
SuggestionsMature policy and governance essentialControl and
data hierarchyEliminate global access/privilege
requirementsUse principle of least privilegeAccess level
commensurate to level of data
sensitivityInterconnectionsControl direct connections behind
the perimeterNever violate security enclavesEvolutionRisk
assessment when adding new functions
*
*
Architecture and Design:
SuggestionsHeterogeneityDiverse implementations improve
survivabilitySituational and operational security
awarenessOperators/personnel aware of security issues
TrainingRedundancyContinuity of operationsBackups for
critical dataBackups for critical communicationsBackup

platforms for critical nodes
*
*
*
*
Platforms: IntroductionWhat is a platform? A platform is a
collection of hardware and software that can run a
programPlatform software includes its OS and
applicationsExamples of platforms:RoutersIEDs / PLCs /
RTUsServers and clients
*

*
RTUs / PLCs / IEDsCollect data from sensors and forwards
commands to devices such as relays and valvesCan also
aggregate data from other RTUs at remote sites and plantsMore
intelligent RTUs are becoming more prevalentPressures for
RTU advancement:Reduce duplication of functionality (points
may be sampled many times over in a substation)Network and
processing power ample for distributed controlSimplified
operation and managementTrends for RTUsSimilarity to other
IT devicesIncreasingly Ethernet or wirelessSCADA peer
connections used for data transfer to/from other devices and for
distributed control
*
*
SCADA ServersFunctionalitySend signals to acquire
dataReceive data from the systemCalculate and disseminate
signals for system-wide controlCurrent system values stored in
a memory databaseDrive operator displaysPopulate data
archivesImplementationMay be custom hardware for legacy
systems, or an older OS (VMS, etc.)Often, modern systems run
on Windows or UnixPlatform for SCADA servers may be the
same as those for display or archives

*
*
Types of SCADA
Servers and ClientsHuman-Machine Interface (HMI)Automated
controlEMSWAPAGCAlarm and events reportingFront-end
processor (FEP)Data archives
*
*
How Exploits WorkAttack opportunitiesBuffer overflowsInput
validation errorsSocial engineeringLeverage existing bugsTypes
of malwareTrojansVirusesSpywareWormsResults:Additional
accessCorruption or compromisePrivilege escalationSystem
failure / denial of serviceCommand injection
*
*

Trends and ObservationsNo configuration
guidanceAdministrator accountsShared accountsLogging not
enabledUnnecessary servicesInadequate patchingDefault OS
installationsEtc.
*
*
Platforms: Suggestions AuthorizationRestrict execution
privileges for programsAccess controlsAcceptable
passwordsCryptographically secure password storageSecure
remote authorization (radius server)Necessary/unnecessary
servicesDHCP, SSH, Telnet, FTP, TFTP, BOOTP, SMTP,
SNMP, HTTP, etc.Disallow remote managementCarefully
consider file sharingSecurity of networked operating systems
(NOS) is complexLoggingRemote or localReview logs for
anomalies or attacksAppropriate retention periodsMeets
standards and requirements
*
*
Platforms: Suggestions Physical security USB ports, pen drives,
guns/guards/gatesPhysical access by an adversary means a

compromise was possibly (if not likely)Patch
managementBackupsIncident responseDisaster recoveryAttack
recovery/law enforcement imagingResourcesSANS guidesNSA
guidesNIST guidesGOVCERTEtc.
*
*
Platforms: SuggestionsLimitations of security for
RTU/PLC/IED/legacy equipment:Not developed with security in
mindNo user accountsNo loggingTypically, no encryption
servicesUsually a single privilege level (maybe two)Passwords
from small set of charactersWorkaroundsWrappers for
applicationsTerminal servers for accessChange passwords
oftenIncrease physical security (cameras, doors, locks, guards,
guns, etc…)
*
*

*
*
SCADA Reliance on NetworksSystem operationsLogical
interconnection of SCADA elements for status/control
telemetryTransmission of performance dataRemote
operationsLimited offsite operations and maintenanceExtend
monitoring and control to corporate officesSystem
administration and maintenanceConfiguration
managementPatches, updates, and upgradesRemote contractor
maintenance accessBusiness integrationProvide network
applications (e.g., email) to operational environmentIntegrate
business activities with operations (e.g., forecasting and
automated billing)Networks must maintain data attributes
(confidentiality, integrity, availability, authentication, non-
repudiation)
*
*
ProtocolsLegacy SCADA ProtocolsASCII or even bit basedRuns
over serial linksOldest “protocols” are tones or current loopsNo
security services (hashes, encryption, etc.)Hundreds of varieties
because of legacy, manufacturer-specific stovepipe SCADA
installationsModern SCADA ProtocolsMay run over serial, but

increasingly support IP stacksOften are object-orientedBased on
open or de facto standardsStill largely absent of intrinsic data
security servicesGreater functionality than legacy protocols
*
*
Trends and Observations
(You’ve seen this before…)SCADA networks are increasing in
scope and functionIncreasing automation (remote
locations)Adoption of TCP/IP networkingTransition to public
and virtual-private networksUse of SCADA networks for other
purposes (alarm)Near real-time controlOutsourcing network
(and system) administrationShrinking boundary between
business and operational networks
*
*
SCADA Dependence
On the InternetSignificant and growingSystem
operationsConnectivity among SCADA elementsConnectivity

between SCADA systemsRemote operation through VPN
accessSystem administration and maintenanceExample: contract
network managementBusiness integrationExample: publishing
data directly from SCADA to the Internet
*
*
Wireless ConnectivityLicensed band
wirelessMicrowaveSatelliteISM unlicensed band
wireless802.11(a, b, g, etc…)WEP, WPA, 802.1x (EAP,
LEAP)Packet radiosOther wireless techniquesFrequency
hoppingSpread spectrumNone of these are secure by
themselvesUse the best security available to you
*
*
PerimetersSecurity enclavesBased upon trust and data
sensitivityDefines perimeters and boundary points of
systems/subsystemsEnforcement by router, firewall, application
proxies, other filtersAddress, service, contentStateful,
statelessNeed-to-know data flows may cross boundariesSerial
communicationsBulk encryptor plus physical security at

endpointWrap communication into a packetApplication proxy
testing
*
*
Internet/Intranet ConnectionEvaluate the business case
firstStrict access controls determined by required data
flowsExample router/firewall DMZ configuration:Need to
archive data for administrative usageSCADA pushes data to
archive machineUsers pull data from archive
machineConnections allowed from SCADA to DMZConnections
allowed from admin to DMZAll other connections deniedOnly
necessary and valid services, messages, content, and addresses
allowed to the DMZ
*
*
Remote AccessEvaluate the business case firstOptionsVPNDial-
upActivitiesRemote dataPlatform managementApplication
usageProtection mechanismsPositive ID for
authorizationAuthenticate user/deviceToken cards/one-time
passwordsEncrypt trafficLog all usageUse access timeouts &

lockouts, activity timeouts, time periodsMinimum
privilegeDeactivate when unnecessary
*
*
External/3rd Party AccessEvaluate the business case
firstExternal vendorsThrough protected mechanisms
onlyAuthenticationAccess controlsApplication
proxiesEtc…Minimum privilegeDeactivate when
unnecessaryExternal sources of dataApplication proxies and
validity checkingProcedures for operation when receiving
invalid dataReceive as analogProviding data to external
systemsUse archived dataSend as analogView-only terminals
*
*
Other Security SuggestionsImplementation guidance should
mandate secure default configurations on all network
devicesForce “good” passwords and eliminate default
passwordsDisable in-band management (SNMP, Telnet,
FTP/TFTP, web, etc.)Disable fingerDisable routing of private
network addressesControl switch and hub connectionsUse

PPN/VPNAdequate physical security PPN can’t be sharedVPN
can be sharedIDSTechnologiesSignaturesAnomaly
detectionAdvantagesCan catch known attacksGood research
toolDisadvantagesFalse positives and negativesCan compromise
the architectureManpower intensive
*
*
DISCUSSION
Clemson University – 2004 Power Systems Conference
Part V: Discussion

SCADA System Security Program
SCADA Security Policy Framework
TM
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 LANs
).
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 personnel have physical access to equipment.
No security perimeter has been defined for the system tha
t
defines access points which must be secured.
Firewalls 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.
Category
Vulnera
bility
OS security patches are not maintained.
Configurations are not stored or backed up for important
platforms, including IEDs.
Default OS configurations are utilized, which enables insecure
and unnecessary services.
Passwords are
often stored in plain sight near critical systems.
Power
-
on and screen saver passwords are not utilized.
Passwords are not encrypted in transit.
Passwords exist indefinitely on platforms.
Passwords on devices are shared.
There are no time limi
t,
character length, or character type

requirements for the passwords
.
Minimal administrative access controls are applied.
Administration
Users have administrator privileges.
There is inadequate physical protection of critical platforms.
Non
-
critical personn
el have physical access to equipment.
Hardware
Dial
-
up access exists on individual workstations within the
SCADA network.
Monitoring &
Logging
System logs are neither collected nor examined.
Malware
protection
Virus checking software is
un
installed,
un
used, or

not
updated.
Plant
Remote
site
Control
Center
Remote
site
Remote
site
Plant
Comm
collector
Plant
Remote
site
Remote
site
Remote
site
Plant
SCADA
Network
SCADA
Network
Admin
Network
Data
Server
Router
/
Firewall
DMZ

Intranet
Extranet
Adversary Levels
Organized
Crime / Cyber
Terrorist
Foreign
Intelligence
Hacker
Coalition
Hacker
Novice
Sophistication
Adversary Levels
Organized
Crime / Cyber
Organized
Crime / Cyber
Terrorist
Foreign
Intelligence
Foreign
Intelligence
Hacker
Coalition
Hacker
Novice
Sophistication
Adversary Levels
Sophistication
Physical Access
Only
Some Knowledge No
Authorized Access
Basic User
Power User, No Special

Privileges
Operator Knowledge
with Privileges
Domain Knowledge
with Privileges
Full Design
Knowledge, Full
Privileges
Sensor
Infrastructure
System
monitored by
monitors
monitored by
monitors
monitored by
monitors
monitored by
monitors
controls
controlled by
controls
controlled by
Actuator
Field I/O
produced by
produces
produced by
produces
triggered by
triggers
triggered by
triggers
Operator
Visual & Auditory
Representation of

Status
sampled by
samples
sampled by
samples
generated by
generates
generated by
generates
Status Data
Field Points
Local Automated
Control
Command Data
Field Points
produces
produced by
produces
produced by
sent to
processes
sent to
processes
analyzes
analyzed by
analyzes
analyzed by
generated by
generates
generated by
generates
System
Management
Functions
aggregates
aggregated

aggregates
aggregated
generated by
generates
generated by
generates
monitors
monitored by
monitors
monitored by
commands
commanded by
commands
commanded by
generates
generated by
generates
generated by
Operational
System Model
Oversight Entity or
Other SCADA System
monitors
monitored by
monitors
monitored by
initiates
initiated by
initiates
initiated by
Field
Technician
calls
calls
calls
calls

analyzes
analyzed by
analyzes
analyzed by
System Status
Data
Historical
Status Data
updates
updated by
updates
updated by
HMI
Contingency
Planer
Business
Objectives
influenced by
influences
influenced by
influences
I/O Controller
Historian
State
Estimator
analyzes
analyzed by
analyzes
analyzed by
System
-
wide
Automated
Control
generated by
generates

generated by
generates
Protective Relaying
(safety)
analyzes
analyzed by
analyzes
analyzed by
monitors
monitored by
monitors
monitored by
Exported
Data
Imported
Data
contributes to
contains subset of
contributes to
contains subset of
contributes to
contains subset of
contributes to
contains subset of
received from
provides
received from
provides
analyzes
analyzed by
analyzes
analyzed by
Stability Systems
(reliability)
Wide Area
Protection

Automatic
Generation Control
Regional Control
Signal
acts upon
influences
acts upon
influences
generates
generated by
generates
generated by
calls
calls
calls
calls
SCADA Field Equipment
System and Plant Control Centers
Automation
Oversight
Infrastructure
Equipment
Alarm System
Local Process
Control
Plant Process
Control
Sensors/Relays
RTU 2
RTU 3
RTU 4
RTU n
Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays

Sensors/Relays
RTU 1
Internet
Sensors/Relays
RTU 2
RTU 3
RTU 4
RTU n
Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays
RTU 1
Internet
Sensors/Relays
Master
Station
(Mainframe)
LAN
Microwave
Fiber
Radio
PSTN
l
a
t
i
g
i
d
RTU 2
RTU 3
RTU 4
RTU n
Sensors/Relays

Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays
User Terminal
User Terminal
User Terminal
Control Center
Remote Sites
Modem
RTU 1
Sensors/Relays
Master
Station
(Mainframe)
LAN
Microwave
Fiber
Radio
PSTN
l
a
t
i
g
i
d
RTU 2
RTU 3
RTU 4
RTU n
Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays
Sensors/Relays

User Terminal
User Terminal
User Terminal
Control Center
Remote Sites
Modem
RTU 1
Assignment Definition:
Use the data model designed in Week 2. This data model will be
reviewed and taken from the conceptual model to logical and
physical model status.
Make sure you define the following:
1. Select database management system (Oracle, SQL Server,
MYSQL, etc) and identify the data types and sizes for all
attributes.
2. Make sure all relationships have been addressed and
corrected.
3. Review data model to make sure data model is in at least 3rd
normal form (as defined by the normalization process).

Copyright © 2005, Sandia Corporation. The submitte.docx

Recommended

Recommended

More Related Content

Similar to Copyright © 2005, Sandia Corporation. The submitte.docx

Similar to Copyright © 2005, Sandia Corporation. The submitte.docx (20)

More from vanesaburnand

More from vanesaburnand (20)

Recently uploaded

Recently uploaded (20)

Copyright © 2005, Sandia Corporation. The submitte.docx