The diagram itself should show the dependencies of each system relative to the mission going
outward until the installation commander reaches a point where he/she no longer has
ownership. At that point, the system dependencies end as indicated by circles in the diagrams
above.
The numeric values are assigned to each process or system based on this one rule.
• A system inherits the values of all of those systems that depend on it.
o The mission value is set to 1.
o All other systems derive their values from the mission value.
o Circular connections are handled consistently (choose to either add them or do not
add them)
The easiest way of generating these values is to use a database or a table in Excel. An example
table is shown in Table Atch1-1. Do not generate these values while determining
dependencies. Attempting to do so will not benefit the facilitated meeting. The table should
contain these columns: Process/System Boundary, Zi (relative importance), Dependants, and
geographical information services (GIS) coordinates of the Process/System (optional).
The cells should be linked as indicated by the cell references depicted. The geographical
information services (GIS) data are the GIS coordinates of that component, they are optional. Zi
is the aggregated impact or importance value of the component based on dependencies.
Table Atch1-1. Example Relative Importance of Interdependent Systems
A B C D E F G H
1 Process / System GIS Zi D1 D2 D3 D4 D5
Boundary Data [=sum(D1…Dm)
]
2 Mission 1
3 Cyber System Mission =SUM(D3:H3) =C2
4 Backup Generator =SUM(D4:H4) =C2
5 Fuel Supply =SUM(D5:H5) =C2 =C4
6 Cyber System Fuel
=SUM(D6:H6) =C5
Supply
7 Cyber System Fuel
=SUM(D7:H7) =C6 =C9
Supply DMZ
8 IT System Fuel Supply
=SUM(D8:H8) =C7
Mgmt
9 Cyber System Fuel
=SUM(D9:H9) =C10
Supply Tank Farm
77
10 Fuel Supply Tank Farm =SUM(D10:H10) =C5
11 Substation A =SUM(D11:H11) =C17 =C12 =C9
12 Substation B =SUM(D12:J12) =C2 =C16 =C5 =C20 =C7
13 Cyber System
=SUM(D13:H13) =C11
Substation A
14 Cyber System
=SUM(D14:H14) =C12
Substation B
15 Leased Line =SUM(D15:H15) =C13
16 Water Supply =SUM(D16:H16) =C2
17 Water Supply Tanks =SUM(D17:H17) =C16
18 Electrical Supply
=SUM(D18:H18) =C11
External
19 Cyber System External
=SUM(D19:H19) =C18
Electrical Supply
If this were mapped to a GIS map using an alternative elevation of the relative importance, the
data would represent terrain that needs securing. The lower elevations are the items of
interest and the areas of higher relative importance would be key locations to control the
region. The scope of this project prevents the creation of a graphical tool kit so the variations
of the graphical depiction will be based on the people contributing to this activity. A white
board “exercise” would also work to create a physical image depicting the interdependencies.
Generating the diagram and table
The facilitator should use materials they have at hand. A large white board, poster-sized paper
hung on the wall, or poster-sized paper on a tabletop are examples of suitable mediums.
1. Starting with the mission, draw an object and label it “mission” or use the proper
mission name.
2. Describe the mission and its functions to the assembled experts and draw radial lines
outward from the mission object to show dependencies.
Example: The facilitator makes the statement, “The mission is to provide bombers; which
require maintenance, fuel, runways, ordinance, and crew.” The facilitator draws radial lines
outward connecting it to objects labeled “maintenance,” “fuel,.” “runways,” “ordinance,” and
“crew.”
3. The experts assembled should represent people knowledgeable about each function
with which the mission relies. Some experts will know about several functions. In an
78
orderly fashion, capture everyone’s input. Drawing objects and connecting lines to
show the systems/processes and dependencies. Use arrows if the dependency is one
way with the arrow pointing toward the downstream or consumer component. Resolve
conflicts in a professional manner. Resolution may take the form of a field trip, a field
test, or a discussion. If the resolution must be postponed until after the facilitated
session, document the object with a question mark to show uncertainty.
NOTE: Computer networks should be viewed in a frame of consumer/publisher. What
system produces the information and what system consumes the information. The
consumer is dependent on the producer. The producer is not dependent on the
consumer.
4. Document the diagram. This can be done by printing, photographing, or whatever
means is suitable for the medium.
5. Generate a table of Relative Importance of Interdependent Systems based on the
diagram.
6. The table will generate values for each system/process based on the documented
dependencies.
Assessing the risk and prioritizing risk management actions
Assessing the risk and prioritizing the risk management actions on a macro scale requires a
high-level determination of cyber risk. The purpose of the high-level determination is to
prioritize areas of focus to perform more time consuming assessments. Performing this
calculation will take into account how a system is used or monitored.
Calculation of Priority based on Use
Maintenance for mechanical devices is fairly well understood. There are differences in opinions
on how best to perform maintenance. Cyber systems require a different kind of maintenance.
The concern is the chance that, due to a lack of information technology maintenance, the
control system will be an easier target for hacking. A quick search using the NIST National
Vulnerability Database (http://nvd.nist.gov/view/vuln/search) is presented in Table Atch1-2.
These are the rates of reporting, not necessarily the rate of discovery. Each product has the
vulnerabilities it was created with; products do not create new vulnerabilities by existing. As
interest in a system increases, the number of reported vulnerabilities increases. This is
different from a mechanical device that wears out over time. Programs do not wear out,
though the vendor may discontinue the product.
79
Table Atch1-2. Number of Reported Vulnerabilities
Reported over Reported over
Company 3 months 3 years Avg / Month
Oracle 185 984 27.3
Microsoft 83 876 24.3
Linux 121 855 23.8
Adobe 29 535 14.9
McAfee 1 25 0.7
Symantec 20 98 2.7
Invensys 7 14 0.4
ABB 6 47 1.3
Siemens 9 34 0.9
Cisco 56 473 13.1
Juniper 0 16 0.4
Dlink 1 10 0.3
Intel 11 138 3.8
AMD 2 9 0.3
NVIDIA 3 7 0.2
ATI 7 68 1.9
Dell 1 13 0.4
Access to a control system allows users to perform actions. Stuxnet showed how important this
is. The vulnerabilities used by Stuxnet were not vulnerabilities in the Siemens software; they
were vulnerabilities in the operating system. Once on the consoles, Stuxnet made use of the
Siemens software to perform tasks it was designed to do. Any vulnerability that allows
arbitrary execution of code can allow malicious software access to control system functions
that are available to the user account the vulnerable program is using.
80
A control system uses three methods of user access control:
1. The first is no security. The software will run as the operating system account currently
logged in. These types of systems often run as an administrative level user. If one can
log into the console, one can perform any action on the system such as opening
breakers or valves, adjusting set points, or downloading new configuration to the field
controllers.
2. The second method is a custom user account manager on top of the operating system
accounts. This method can result in security being turned on/off for the control system
and circumstances where no user accounts exist for the control system thereby locking
the console until it is rebuilt with an image or reinstalled. This method will typically use
an auto-login account for the operating system and then have the operations personnel
use their own custom user account to gain access to the control system interfaces. The
auto-login account is often an administrative level user.
3. The third method is to use accounts integrated into the operating system user accounts.
This is more common of systems designed after 2001. This will be a mix of user
accounts with role-based privileges. A look at the processes running on the console will
show a number of user accounts that are control-system specific that likely have
administrative rights, which are used to keep key system functions operational.
This is why software management and system monitoring is important for control systems.
Assume that the system can be compromised then watch the system for aberrant behavior
indicating unstable code. Achieving this level of monitoring takes resources in the form of
people, procedures, and technology. All of which cost money to deploy and maintain. In the
previous section, the interdependencies of the infrastructure were determined and a table was
built. The relative importance to the mission was determined for each system. That value does
not take into consideration operational conditions or mitigation measures in place. The
following columns should be added to the table of relative importance:
• Maintenance (patching, evaluating/testing patches, etc.) performed regularly for
o Operating system
o Hardware
o Third-party software
o Control system software
o Customized software
• System monitoring frequency (how often is the system used/observed)
• System log (all logs) monitoring frequency
• Physical connections
The resulting table with values is shown in Table Atch1-3.
81
Table Atch1-3. Operational Considerations for Relative Importance
A I J K L M N O P
Log
Operating Third-Party Control Customized Monitoring
1 Process / System Boundary System
Hardware
Software System Software Frequency
Monitoring Connections
Frequency
2 Mission
3 Cyber System Mission 1 0 0 1 1 0.2 1 1
4 Backup Generator
5 Fuel Supply
6 Cyber System Fuel Supply 1 1 1 1 1 0.1 1 2
Cyber System Fuel Supply
7 0 1 1 0 1 0.4 1 2
DMZ
Operating System Value of 1 if this needs attention. Value of 0 if this is maintained and fully patched.
Hardware Value of 1 if this needs attention. Value of 0 if this is maintained and fully patched.
Third-Party Software Value of 1 if this needs attention. Value of 0 if this is maintained and fully patched.
Control System Value of 1 if this needs attention. Value of 0 if this is maintained and fully patched.
Customized Software Value of 1 if this needs attention. Value of 0 if this is maintained and fully patched.
Monitoring Value based on the frequency of operations monitoring - Continuous: 0.1, Hourly: 0.2, Daily: 0.4, Weekly:
Frequency 0.8, Monthly: 1.0, Yearly: 2.0, More: 4.0
Log Monitoring Value based on the frequency of monitoring any logs - Continuous: 0.1, Hourly: 0.2, Daily: 0.4, Weekly: 0.8,
Frequency Monthly: 1.0, Yearly: 2.0, More: 4.0
Number of interfaces. Console +1, Network (wired / wireless) +1, USB/Serial/Firewire/CDROM/DVD etc. +1
Connections
(max 3)
82
The calculation for the relative importance of interdependent systems (Zi) was the sum of the value
of the dependencies shown as the yellow highlighted cell, C3 of Table Atch1-4.
Table Atch1-4. Subset of the Example Relative Importance of Interdependent Systems
A B C D E F G H
1 Process / System GIS Zi D1 D2 D3 D4 D5
Boundary Data [=sum(D1…Dm)
]
2 Mission 1
3 Cyber System Mission =SUM(D3:H3) =C2
The table additions of columns I through P will be used in the calculation of the relative importance to
mission modified by operational considerations. This value will be called the Cyber Readiness.
Attention should be given to the entries with higher values.
An additional column should be added to the table so the calculations can be automated. For the
purposes of this calculation, row 3 in the table will be used. All cells will be using this reference. C3
represents Zi.
Cyber Readiness
= Log10(C3) * sum(I3:M3) * N3 * O3 * P3
These values are then the risk prioritizations of the ICS/cyber components that support the functions
with which missions rely. The higher values represent more at risk to the system. Some systems will
have mitigations already in place, having the conversation with the system owner can determine if
this is the case. The judgment of what resources to place should never be solely on the numeric
value, however the numeric value can assist in making that determination.
83
ATTACHMENT 2 CHECKLIST OF RECOMMENDED ACTIONS
The following tabular format checklist presents recommendations made earlier in the handbook
using a modified DOTMLPF-F37 construct. The checklist does not cover every last action that may be
taken to secure installation ICS. Additional actions may be identified during assessment or even in
the midst of implementation. Also, this is generic, meaning that applicability is broad rather than
specific. Each installation will have differences, in some cases significant, in control systems
architectures, security measures already in place, organizational and personnel management, and
missions. The “one-size-fits-all” approach offered here will indeed yield a more secure ICS, but a
closer fit will require tailoring (such as using other tools, requesting assistance of SMEs, etc.).
Actions are not listed in a particular order, except that policy should first be well-established so as to
facilitate implementing actions in other areas. Nor do actions need to be implemented sequentially;
many actions may be undertaken in parallel.
NOTE: A separate table may be used for each type of ICS or by mission supported.
The columns in the table are:
• FOCUS: COTMLPF-P area
• ACTION: ICS security action to implement
• COMMENTS: Notes/comments about that action
• PRI #: Priority assigned to the action (self-defined priority scheme and criteria)
• POC: Person or office with primary responsibility for managing that action
• ASSGND: Date assigned by installation commander or ICS security team
• DONE: Date completed
Blank rows are included at the end of each “Focus” section for installation-specific additions.
37
Modified by replacing the “D” with a “C” for cybersecurity.
84
TITLE <name of control system, infrastructure, or mission>
MISSION(S) SUPPORTED:
OTHER INFORMATION:
FOCUS ACTION COMMENTS PRI POC DATE DATE
DONE
# ASSGND
POLICY
Review ICS policy requirements with
ICS Security Team
Review existing policy(ies) and
amend/adopt as appropriate
Develop policy for the following:
• Roles & responsibilities
(including vendors & third
parties)
• Vulnerability & risk
assessments
• Access control
• Security of assets
P • Configuration control
• Acquisition of hardware &
85
O software
• Patch management
L
• Inventory accounting
I
• Education, training & exercises
C
Review ICS service level agreements Changes to ICS systems often require vendor
Y with vendors and integrators and/or integrator approval or support, which
may not be covered in existing service level
agreements
Set software and SDLC requirement See the DHS Cyber Security Procurement
standards for ICS procurements Language for Control Systems document,
http://www.us-
cert.gov/control_systems/pdf/FINAL-
Procurement_Language_Rev4_100809.pdf
Create incident response management Incident management across business
plan with vendor, integrator, or third boundaries, i.e. incident coordination with
party ICS provider commercial energy providers, requires
significant planning and cooperation; better
to have the plan worked out before an
incident occurs
86
LEADERSHIP
Promulgate policies
Schedule awareness briefings for ICS
managers, operators, & users
Attend stakeholder events Gain and enhance situational awareness
Collaborate with ICS vendors and Focus should be on security and training
service providers
L Develop new or adapt existing plans to
address ICS. Plans include at least:
E
• Disaster Recovery
A • System Security
• Contingency (include response
87
D to INFOCON, FPCON)
• Continuity of Operations
E
Add key ICS information to the Think of most if not all ICS-related
R Commander’s Critical Information List information as at least FOUO
PERSONNEL
Train all ICS managers, operators & Include policies, roles, security, incident
users response handling, etc.
Develop a refresher training program
Perform background checks on
everyone with ICS responsibility
Require confidentiality or non-
disclosure agreements
88
P Create an ICS incident response team Can model on existing IT CERT or on DHS’s
ICS-CERT
E
Enforce system access controls Includes network (logons) and physical
(cipher-locked doors)
R
Maintain rosters for access to physical
S facilities
O Immediately delete all access (physical This must include third-party vendors,
and system) of those who resign, contractors, etc. as well as direct employees
N retire, move, are fired, etc. and military
N Provide checklists/SOPs to each Can be used also for training
operator position as appropriate
E
TRAINING
Ensure ICS-specific training prior to
granting individuals access
Require IA training (initial & refresher) In some cases, users of IT components of ICS
89
for all ICS managers, operators & users are overlooked in IA training
Provide threat & vulnerability
awareness via appropriate venues
T
Document all training; maintain
R currency
Exercise ICS-related plans
A
Include ICS in base-level exercises For example, when INFOCONs are
I implemented or when FPCON is elevated
ORGANIZATION
Appoint an ICS IAM Most installations with DOD networks already
have an assigned IT network IAM; an ICS IAM
is distinctly separate and trained specifically
to ICS issues (but will coordinate with IT IAM)
O
Assign responsibility for ICS
R configuration control
Specify ICS roles & responsibilities of
90
G at least:
• Commander
A
• CEs/PWs
N
• Communications/IT
I
• Operations
Z
Identify leads for developing ICS- Or for incorporating ICS considerations into
specific plans existing plans
A
Publish chain-of-command for incident
T response
I Identify roles & responsibilities of
vendors, third parties
O
FACILITIES
Create a map/chart/topology of all Include buildings, rooms, panels, cabling, etc.
physical facilities
91
Identify & inspect all physical facilities
F Develop a plan of action & milestones
for correcting facility security
A deficiencies or weaknesses
Identify and secure portable assets For example, fly-away kits, laptops, spares.
C
Depict their locations on the facility map
I Secure all cable terminations (their Wiring termination boxes often are located in
housings) isolated areas and with only minimum
L security controls (e.g., easily cut padlock,
wire with lead breakage seal)
I
MATERIEL
Document the entire ICS infrastructure Include logic diagrams, data flows,
dependencies, and particularly connection to
mission/mission support assets
M Assign responsibility for accountability Include acquisition, configuration, inventory,
for physical assets etc.
92
A Establish acquisition policy and
process
T
Require testing of any new component Always test before adding to the live
or program off-line infrastructure
E
Identify and control all ICS
R documentation and software media
I Ensure all replaced components are
“cleaned” prior to disposition
E
Provide failover or redundant servers
L and other components serving critical
mission functions
CYBER SECURITY
Define & defend perimeters; Part of a comprehensive defense-in-depth
approaches may include: strategy
• Segmentation
• DMZs
93
• Enclaves
• VPNs to cross defended
boundaries when necessary
C
Control individual access:
Y • Assign individual/unique logon Follow standard DOD practices
IDs and passwords
B
• Design user access control
E architecture based on Least-
User Access (LUA) model
R
• Require role-based access For existing as well as new accounts
control (RBAC)
S • Disable all “guest” or
anonymous accounts
E
• Set UAC policy for event log ICS systems and applications are relatively
C auditing static; any change to UAC configuration at
the operating system, application, and data
U levels need to be identified immediately and
reviewed for security implications
R
• Set timeline and threshold Event logs (functional and security) need to
monitoring requirements for be reviewed in a timely manner; it will not do
I
UAC events the teams any good if an IT IDS team reviews
T the alerts because the IDS team will not
understand ICS traffic initially
Y • Ensure functional UAC auditing Security-impacting changes to an ICS are
and monitoring thresholds are more likely to be detected through functional
94
put in place incident evaluation rather than through
security event monitoring; make sure ICS
admins are reviewing their systems for
security-impacting events
• Ensure audit configuration and As with previous comments, egress traffic
log monitoring on ICS systems from the ICS networks to the
can detect unusual egress corporate/military or Internet need to be
traffic from privileged user evaluated so a baseline of normal egress
accounts traffic can be established; unusual or
anomalous egress traffic from privileged
accounts needs to be identified and
evaluated as quickly as possible
Protect operating system:
• Disable all unnecessary
network services
• Use (and keep current) virus- Virus detection programs may be difficult to
checking software update on live systems, and therefore will
C require diligence in maintaining currency
Y • Establish software lifecycle Out-of-date software of any sort (firmware,
management policy operating system, third party/COTS, custom
B code, development frameworks, etc.) should
all be maintained and within n or n-1 releases
E of a vendor’s supported software
R • Enable audit logging & monitor
• Remove all unnecessary
programs
95
S • Implement security policies per Security configurations should be done on
vendor best security practices each OS in addition to the external access
E list controls like port configuration; this means
disabling autorun, limiting remote registry
C access, etc.
U • Consider using IDS If consider, do so judiciously and in close
consultation with cybersecurity specialists
R who probably already had implemented an
IDS on the IT network. Many IDS marketed
I specifically for ICS may not actually add more
value to defense than already provided by
T the IT side IDS.
Y Protect data:
• Encrypt data in motion (at least Probably not able to encrypt data on the
on the IT side) purely ICS component side, such as between
a PLC and a master server; definitely unable
to encrypt between a PLC and a sensor
• Enforce controlled access to
stationary data (files,
databases, etc.)
• Back up system routinely and A backup held exclusively by a vendor will not
keep backups secure & be “accessible” in certain circumstances, such
accessible as a FPCON Charlie or Delta
• Implement separate data Data segregation provides another security
management procedures for layer and helps prevent random failures of
business/ICS/operational data the OS/application from impacting data; since
and data configuration files config files are often transferred from failing
96
