410.5 - ICS Secutiy Governance
410.5 - ICS Secutiy Governance
410.5 - ICS Secutiy Governance
4ı 0.5
ICS Security Goverrlance
SNS
THE MOST TRUSTED SOURCE FOR INFORMATION SECURITY TRAINING, CERTIFICATION, AND RESEARCH I sans.org
)
)
Copyright @ 2019, Justin Searle. All rights reserved to Justin Searle anüor SANS Institute.
PLEASE READ THE TERMS AND CONDITIONS OF THIS COURSEWARE LICENSE AGREEMENT
("cLA") CAREFULLY BEFORE USING ANY OF THE COURSEWARE ASSOCTATED W|TH THE SANS
COURSE, THIS IS A LEGAL AND ENFORCEABLE CONTRACT BETWEEN YOU (THE
"USER") AND THE SANS INSTITUTE FOR THE COURSEWARE. YOU AGREE THAT THIS AGREEMENT
IS ENFORCEABLE LIKE ANY WRITTEN NEGOTIATED AGREEMENT SIGNED BY YOU.
With the CLA, the SANS lnstitute hereby grants User a personal, non-exclusive license to use the
Courseware subject to the terms of this agreement. Courseware includes all printed materials, including
course books and lab workbooks, as well as any digital or other media, virtual machines, and/or data sets
distributed by the SANS lnstitute to the User for use in the SANS class associated with the Courseware.
User agrees that the CLA is the complete and exclusive statement of agreement between The SANS
lnstitute and you and that this CLA supersedes any oral or written proposal, agreement or other
communication relating to the subject matter of this CLA.
BY ACCEPTING THIS COURSEWARE, YOU AGREE TO BE BOUND BY THE TERMS OF THIS CLA, BY
ACCEPTING THIS SOFTWARE, YOU AGREE THAT ANY BREACH OF THE TERMS OF THIS CLA MAY
CAUSE IRREPARABLE HARM AND SIGNIFICANT INJURY TO THE SANS INSTITUTE, AND THAT THE
SANS INSTITUTE MAY ENFORCE THESE PROVTSTONS By TNJUNCTTON (WTTHOUT THE NECESS|TY
oF POSTING BOND), SPECtFtC PERFORMANCE, OR OTHER EQUTTABLE RELtEF.
lf you do not agree, you may return the Courseware to the SANS lnstitute for a full refund, if applicable.
User may not copy, reproduce, re-publish, distribute, display, modify or create derivative works based upon
all or any portion of the Courseware, in any medium whether printed, electronic or otherwise, for any
purpose, without the express prior written consent of the SANS lnstitute. Additionally, User may not sell,
rent, lease, trade, or otherwise transfer the Courseware in any way, shape, or form without the express
written consent of the SANS lnstitute.
lf any provision of this CLA is declared unenforceable in any jurisdiction, then such provision shall be
deemed to be severable from this CLA and shall not affect the remainder thereof. An amendment or
addendum to this CLA may accompany this courseware.
SANS acknowledges that any and all software and/or tools, graphics, images, tables, charts or graphs
presented in this courseware are the sole property of their respective
trademark/registered/copyrig ht owners, including :
AirDrop, AirPort, AirPort Time Capsule, Apple, Apple Remote Desktop, Apple TV, App Nap, Back to My
Mac, Boot Camp, Cocoa, FaceTime, FileVault, Finder, FireWire, FireWire logo, iCal, iChat, ilife, iMac,
iMessage, iPad, iPad Air, iPad Mini, iPhone, iPhoto, iPod, iPod classic, iPod shuffle, iPod nano, iPod touch,
iTunes, iTunes logo, iWork, Keychain, Keynote, Mac, Mac Logo, MacBook, MacBook Air, MacBook Pro,
Macintosh, Mac OS, Mac Pro, Numbers, OS X, Pages, Passbook, Retina, Safari, Siri, Spaces, Spotlight,
There's an app for that, Time Capsule, Time Machine, Touch lD, Xcode, Xserve, App Store, and iCloud are
registered trademarks of Apple lnc.
SOF-ELK@ is a registered trademark of Lewes Technology Consulting, LLC. Used with permission
Governing Law: This Agreement shall be governed by the laws of tlıe State of Maryland, USA.
tcs410 5 E01 01
ıcs4I0.5 ıCSISCADA Security Essentials
The SANS ICS 410, ICS/SCADA Security Essentials course, was developed by a collection of experts whose diverse
work experiences, knowledge, and skills truly blend together to cover the very specific content areas for this course.
Justin Searle is the Director of ICS Security at InGuardians, specializing in ICS securify architecture design and
penetration testing. Justin led the Smart Grid Security Architecture group in the creation of NIST Interagency Report
7628 and has played key roles in the Advanced Security Acceleration Project for the Smart Grid (ASAP-SG), National
Electric Sector Cybersecurity Organization Resources (NESCOR), and Smart Grid Interoperability Panel (SGIP). Justin
has taught courses in hacking techniques, forensics, networking, and intrusion detection for multiple universities,
corporations, and security conferences. He is currently a Senior Instructor for the SANS Institute. In addition to electric
power industry conferences, Justin frequently presents at top international security conferences such as Black Hat,
DEFCON, OWASP, Nullcon, and AusCERT. Justin co-leads prominent open source projects including the The Control
Thing Platform, Samurai Web Testing Framework (SamuraiWTF), Samurai Security Testing Framework for Utilities
(SamuraiSTFU), Yokoso!, and Laudanum. Justin has an MBA in International Technology and is a CISSP and SANS
GIAC certified Incident Handler (GCIH), Intrusion Analyst (GCIA), Web Application Penetration Tester (GWAPT), and
GIAC Industrial Control Security Professional (GICSP).
Dr. Eric Cole is an industry-recognized security expert with over 20 years of hands-on experience. Dr. Cole has
) experience in information technology with a focus on helping customers focus on the right areas of security by building
)
out a dynamic defense. Dr. Cole has a master's degree in computer science from NYIT and a doctorate from Pace
University with a concentration in information security. He served as CTO of McAfee and Chief Scientist for Lockheed
Martin. Dr. Cole is the author of several books, including Advanced Persistent Threat, Hackers Beware, Hiding in Plain
Sight, Network Security Bible, Znd Edition, and, Insider Threat. Eric is the inventor of over 20 patents and is a researcher,
writer, and speaker. He is also a member of the Commission on Cyber Security for the 44th President and several
executive advisory boards. Dr. Cole is the founder and an executive leader at Secure Anchor Consulting, where he
provides leading-edge cybersecurity consulting services, expert witness work, and leads research and development
iııitiatives to advaııce tlıe state-of-tlıe-afi iıı iırforırıatioıı systeırıs secuıity. Dr. Cı:le is actively iııvıılved witlı the SANS
Technology Institute (STI). He is a SANS faculty Fellow who works with students, teaches, and develops and maintains
courseware.
Contributine Authors
Michael Assante is currently the SANS project lead for Industrial Control System (ICS) and Supervisory Control and
Data Acquisition (SCADA) security. He served as Vice President and Chief Security Officer of the North American
Electric Reliability Corporation (NERC), where he oversaw industry-wide implementation of cybersecurity standards
across the continent. Prior to joining NERC, Michael held a number of high-level positions at Idaho National Labs and
he served as Vice President and Chief Security officer for American Electric Power. His work in ICS securiğ has been
widely recognized and he was seleçted by his peers as the winner of Information Security Magazine's security leadership
award for his efforts as a strategic thinker. The RSA 2005 Conference awarded him its outstanding achievement award
in the practice of security within an organization. He has testified before the US Senate and House and was an initial
member of the Commission on Cyber Security for the 44th Presidency. Prior to his career in security, Michael served in
various naval intelligence and information warfare roles and he developed and gave presentations on the latest
technology and security threats to the Chairman of the Joint Chiefs of Staff, Director of the National Security Agency,
and other leading government officials. ln 1997, he was honored as a Naval Intelligence Officer of the Year.
Tim Conway is currently the Technical Director of ICS and SCADA programs at SANS. He is responsible for
developing, reviewing, and implementing technical components of the SANS ICS and SCADA product offerings. He
was formerly the Director of CIP Compliance and operations Techıology at Northem Indiana Public Seıvice Company
(NIPSCO) where he was responsible for Operations Technology, NERC CIP Compliance, and the NERC training
environments for the operations departments within NIPSCO Electric. Tim was previously an EMS Computer Systems
Engineer at NIPSCO for eight years, with responsibility over the control system servers and the supporting network
infrastructure. He previously served as the Chair of the RFC CIPC, is the current Chair of the NERC CIP Interpretation
Drafting Team, a current member of the NESCO advisory board, the current Chair of the NERC CIPC GridEx 2013
Working Group, and the current Chair of the NBISE Smart Grid Cyber Security panel.
Disaster Recovery 40
1
Measuring Cybersecurity Risk 52
I
Final Thoughts and Next Steps lıl
)
)
)
)
_)
_)
)
)
)
)
)
)
_)
)
)
@ 2019, Justin Searle 3
)
)
)
Course Roadmap l. lntroduction
2" ICS Cybersecurity Programs
l
There are many steps in initiating an ICS Cybersecurity Program in your company. The first will be getting support from
leadership for funding and authority to enforce. Next, you will want to staft building your ICS Cybersecurity Team. Once
the teaın is up and running, at least with a few members' you will need to start identifying what business regulatory
requirements you are required to fulfill and what cybersecurity risks your company faces. This is not an easy process and,
in truth, never really ends.
Start small and organically, address it as bite-sized chunks, and continue growing your understanding of the risks you
face. A good parallel is the differences in agile development compared to waterfall development. Choose small
milestones that can be accomplished in weeks, not months. As you begin to understand the risks you face, start to develop
and later modiflı your policies and procedures to address your current understandings ofrisk, and execute those policies
and procedures in your organizations.
Manifesto for Agile Software Development's 12 principles, which apply well to cybersecurity programs:
1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity-the art of maximizingİhe amount of work not done-is essential
I 1. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly
Reference:
https://en.wikipedia.org/wiki/Agile_software development
ıcs4l0ı|c9scADASecurityBsentials ı
ICS security requires a comprehensive, integrated approach in which multiple solutions are tiered together to accomplish
will make an organization and its control systems secure because any
a goal. There is no single security solution that
single measure could be bypassed (and miss an attack altogether) or compromised. When protecting any entity take the
-
President, for example - there are many people, measures, and systems put in place to keep him secure. The same robust
approach needs to be applied to your network or any critical asset in your organization.
When it comes to ICS security, there is no silver bullet. Multiple measures that complement each other must be put in
place across a variety of control options. For example, you would deploy a preventive measure such as a firewall, a
detective measure such as an IDS, and a deterrent measure such as a guard at your front gate, just to name a few. Even if
one of the measures failed, the other measures would be able to detect the attack before there was a problem; or, catch an
attack in action to minimize the amount of daınage caused.
Resources:
https ://www.nist. gov/cyberframework
.)
,!
)
8 @ 2019, Justin Searle
_)
I
NısT csF coRE FuNcTıoNs
İ!f,,filra]- rE.+il!?r.'lll-ı
ciİtcoıJİs st'ğCılı@İıİs
DETEÇT DE-
EEtrE- GElrçfifıli-
ffiat fir'r'rı:ıl,?re
Identify - Develop an organizaİional understanding to manage cybersecurity risk to systems, aSSetS, data, and
capabilities. The activities in the Identify Function are foundational for effeçtive use of the Framework. Understanding
the business context, the resources that support critical functions, and the related cybersecurity risks enables an
organization to focus and prioritize its efforts, consistent with its risk management strategy and business needs. Examples
of outcome Categories within this Function include: Asset Management, Business Environment, Governance, Risk
Assessment, and Risk Management Strategy.
Protect - Develop and implement appropriate safeguards to ensure delivery of critical infrastructure services. The
Protect Function supports the ability to limit or contain the impact of a potential cybersecurity event. Examples of
outcome Categories within this Function include: Identity Management and Access Control, Awareness and Training,
Data Security, Information Protection Processes and Procedures, Maintenance, and Protective Technology.
Detect - Develop and implement appropriate activities to identify the occurrence of a cybersecurify event. The Detect
Function enables timely discovery of cybersecurity events. Examples of outcome Categories within this Function include
Anomalies and Events, Security Continuous Monitoring, and Detection Processes.
Respond - Develop and implement appropriate activities to take action regarding a detected cybersecurity incident. The
Respond Function supports the ability to contain the impact of a potential cybersecurity incident. Examples of outcome
Categories within this Function include: Response Planning, Communications, Analysis, Mitigation, and Improvements.
Recover - Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or
services that were impaired due to a cybersecurity incident. The Recover Function supports timely recovery to normal
operations to reduce the impact from a cybersecurity incident. Examples of outcome Categories within this Function
includc: Rcctıı,cry Planning, Improvements, and Communicatioııs.
Reference:
https ://www. nist. gov/cyberframework
Asset Management (ID.AM): The data, personnel, devices, SySteınS, and facilities that enable the organization to achieve
business purposes are identified and managed consistent with their relative importance to business objectives and the
organization's risk strategy.
Business Environment (ID.BE): The organization's mission, objectives, stakeholders, and activities are understood and
prioritized; this information is used to infoım cybersecurity roles, responsibilities, and risk management decisions.
Governance (ID.GV): The policies, procedures, and processes to manage and monitor the organization's regulatory, legal,
risk, environmental, and operational requirements are understood and inform the management of cybersecurity risk.
Risk Assessment (ID.RA): The organization understands the cybersecurity risk to organizational operations (including
mission, functions, image, or reputation), organizational assets, and individuals.
Risk Management Strategy (ID.RM): The organization's priorities, constraints, risk tolerances, and assumptions are
established and used to support operational risk decisions.
Supply Chain Risk Management (ID.SC): The organization's priorities, constraints, risk tolerances, and assumptions are
established and used to support risk decisions associated with managing supply chain risk. The organization has
established and implemented the processes to identif,i, assess and manage supply chain risks.
Reference:
https ://www. ni st. gov/cyberframework
,V T)
. "Fl
şr
1.9 ( No
\w d{'
vu
s" ^ -}.r
kr. 1ı)
s ",P \.ü
hd
10 O 2019, Justin Searle
.)
i-,
Y nrf C/
J ('
(
Identity Management, Authentication and Access Control (PR.AC): Access to physical and logical assets and associated
facilities is limited to authorized users, processes, and devices, and is managed consistent with the assessed risk of
unauthorized access to authorized activities and transactions.
Awareness and Training (PR.AT): The organization's personnel and partners are provided cybersecurity awareness
education and are adequately trained to perfoım their infoımation security-related duties and responsibilities consistent
with related policies, procedures, and agreements.
Data Security (PR.DS): Information and records (data) are managed consistent with the organization's risk strategy to
protect the confidentiality, integriŞ, and availability of information.
Information Protection Processes and Procedures (PR.lP): Security policies (that address purpose, scope, roles,
responsibilities, management commitment, and coordination among organizational entities), processes, and procedures
are maintained and used to manage protection of information systems and assets.
Maintenance (PR.MA): Maintenance and repairs of industrial control and information system components is performed
consistent with policies and procedures.
Protective Technology (PR.PT): Techıical security solutions are managed to ensure the security and resilience of systems
and assets, consistent with related policies, procedures, and agreements.
Reference:
https ://www.ni st. gov/cyberframework
Anomalies and Events (DE.AE): Anomalous activity is detected in a timely manner and the potential impact of events is
understood.
Security Continuous Monitoring (DE.CM): The information system and assets are monitored at discrete intervals to
identiff cybersecurity events and veriflz the effectiveness ofprotective measures.
Detection Processes (DE.DP): Detection processes and procedures are maintained and tested to ensure timely and
adequate awareness of anomalous events.
Reference:
https ://www. nist. gov/cyberframework
Response Planning (RS.RP): Response processes and procedures are executed and maintained to ensure timely response
to detected cybersecurify events.
Communications (RS.CO): Response activities are coordinated with internal and external stakeholders, as appropriate, to
include extemal support from law enforcement agencies.
Analysis (RS.AN): Analysis is conducted to ensure adequate response and to suppoı1 recovery activities.
Mitigation (RS.MI): Activities are performed to prevent expansion of an event, mitigate its effects, and eradicate the
incident.
Improvements (RS.IM): organizational response activities are improved by incorporating lessons learned from cuırent
and previous detectioıı/response activities.
Reference:
https ://www.nist. gov/cyberframework
RC.CO - Communications
' Manage public relations, repair reputation, and communicate with stakeholders
)
Recovery Planning (RC.RP): Recovery processes and procedures are executed and maintained to ensure timely
restoration ofsystems or assets affected by cybersecurity events. )
Improvements (RC.IM): Recovery planning and processes are improved by incorporating lessons learned into future )
activities. )
Communications (RC.CO): Restoration activities are coordinated with internal and external parties, such as coordinating )
centers, Intemet Service Providers, owııers of attacking systems, victims, other CSIRTs, and vendors. )
Reference: )
https //www. ni
: st. gov/cyberfr amework _)
)
)
)
_)
.)
)
)
)
)
)
)
)
14 @ 2019, Justin Searle
)
)
)
NısT csF ıMPLEMENTATıoN TıERS
organizational cybefsecurity risk management practices a'e rpt formalized, and rlsk ıs managed in an ad İoc and
sometimes reactjve manner^ There is limited awareness of cybersecurity risk at ihe organizational level, and an
organjzation_wide approach to managing cybersğcufity risk haş nol been established,
- Tier 3: Repeatable
The ofganizatbn's risk man8gemenı practices ar€ foImaıly approved and €xpressed as pdiÇy. There is an
o.ganizalion-wide approach to manage cybersecurity risk-
Tier4: Adaptive
The o.g€nızation adapts its cybersecuriıy practicas based on bssons learned and pĞdicüve indic€tors d€rivgd from
previaıs ard cUrent cybersecurity acüüties. There b an organizaüon-wide approach lo managing cyöe'secUrity risk
that uses risk-informod po|icies, processes, and ProcedUres ıo address poıential cyb€rsecuriıy events.
These steps illustrate how you can use the NIST CSR Framework to create an ICS Cybersecurity Program in you
organization, or improve your current program.
Remember, start with bite-sized chunks, improving your program bit by bit. Most of us are working with teams that are
understaffed and underfunded, and the worst thing you can do is attempt to do everything at once, which often results in
lots of planning but little execution. The purpose of your program is to make your systems more secure, and while
planning is a very necessary part of this process, planning by itself results in no actual protection.
Reference:
https ://www. ni st. gov/cyberframework
$r.
V
ü o^.ı
**\ o
ö" \'
.l
)
l
)
)
Course Roadmap I. lntroductİon
2. ICS Cybersecurity Programs
. Saning the Process
. Frameryorks ısA/ıEc 62,143, lso/lEc 27@l, NlsT csF
Day r: ICS Overview . Using üe NısT csF
3. lCS Cybeısecurity Policies
. Policies,Sandards,Guidance,and Procedures
Day z: Field Devices and Controllers . Culture and Enforcement
. Examples and Sources
Day 3: Supervisory Systems 4. Disaster Recovery
. DR and BCP Programs
. Modificatİon for Cybersecurity lıcident
Day 4: Workstations and Servers 5. Measuring Cybersecurity Rısk
. Quantitative vs Qualitative
. Traditional Models
Day 5: ICS Security Governance . Minimilng Subjectıvıty
6. lncident Response
. Six Step Process
7. Exercise 5.!: lncİdent Response Tabletop Exercİse
8. Finaİ Ttıoughts and Next Steps
. oüer lCS Cources by SANS
. oüer SANS Curriculums and Coursg
. Netwars
)
)
)
)
)
@2019, Justin Searle 19
)
)
)
PoLıcY HıERARCHY
ffi;ffi
or sections
. Policies: HighJevel directives Standards
E
. Standards: Mid-low-level
directives
. Guidelines: Low-level
recommendations and
Guidelines
examples
. Procedures: Low-level steps ;*"ipracııioner iü-:}
İ"'j }V{ Rracııtıoner
i:* j
İ''jİ praçtıtianer
and checklists
Ü]i Pıactitioner lÜ,= o,".*uon", ü ,,r.u,.on",
Procedııres
ıcs4l0 Bsentials
In the example organization implementation picture, you aan see policies and their association to the highest levels of an
organization and the use ofstandards by management across various business units. The guidelines and procedures are
implemented by the practitioner levels in the organization.
we will now discuss the uniqueness of each document type and why they are utilized.
Policies are typically viewed as a governing document that refers to standards, guidelines, and procedures. Sometimes
multiple standards, guidelines, and procedures exist to support a goveııing policy. Policies help shape the culture of an
organization and foçus on the mission or goals of the organization and not on the joumey or Steps necessary to achieve
the desired goal.
Policies are all-encompassing in that they typically apply to all individual employees, contractors, and vendors. Basically,
anyone who is being paid by aı organization is subject to the policy, and nonperforTnance of a policy item will typically
result in disciplinary action up to and including termination.
a-\"
Aa
STANDARD
Standards provide the details regarding what must be done in support of the policy. Often, standards vary within an
organization based on specific business unit operating needs and may require documented exemptions to the policy. An
example of this may be an exemption to the coıporate policy, which explicitly allows the cybersecurity team to run
specific tools on the network to capture and analyze traffic. In addition, specific standards may exist for certain business
needs like company phones, laptops, desktops, and email application standards.
Guidelines exist as the most flexible document in this chain. Guidelines provide some best practice framework around
how to satisfy the standards and they change depending on changes in the environment.
,)
,)
@ 2019, Justin Searle 23
)
)
)
PROCEDURE
If you consider these documented approaches in the context of a family trip, policies indicate where the family is going;
standards indicate when the family will be at a location and what will be done; guidelines would be recommendations of
things to do in the area; and procedures would be the step-by-step directions for getting there.
A policy is a directive that indicates a conscious decision to follow a path toward a specified objective. Often a policy
can initiate the institution and empowerment of resources or direct action by providing procedures or actions to be carried
out. The policy itselfshould be effective and realistic and have achievable security goals.
It is critical to write down in a clear and concise manner what is expected of everyone in the organization when it comes
to security. It is also helpful to inform people about what is expected of them, what the organization does, and what
others in various roles within the organization do.
It is good to follow an approach where ifthe policy you need does not exist, or is badly out ofdate, you create, or update
it, and then have it approved. The final step in establishing a framework is to assess critical policies. Even though you
just wrote or updated them and you know they are correct, policies should be checked. It is better ifyou do not check
your own work. We can only spot our own errors a small percentage of the time. When you ask a person to help you by
verifying policy contents, ask that they include the most conımon elements in their analysis, including:
' Purpose: Security policy usually contains a statement, often at the beginning, describing the reason the policy is
being established and any associated goals.
' Related documents: This is often titled "References" and usually cites higher-level policy or implementation
guidance.
' Cancellation: New or updated policy may supersede existing (perhaps outdated) policy. This section identifies
those policies and clarifies what is actually in effect.
' Background: This optional section provides information amplifuing the need for the policy. It may also provide
historical information relevant to the subject.
' Scope: This section identifies the depth and breadth of coverage (to whom or what the policy applies). Is it for
one element of the organization or will it also apply to contractor agencies who work for your organization?
' Policy statement: Identifies the açfual guiding principles or what is to be done. The statement(s) are designed to
influence and determine decisions and actions within the scope of coverage. The statements should define actions
thnt nrc pnıdcnt, cxpcdicnt, or advantagcorıS to tl'ıe orgaııizatioır.
A great way to check your policy, is to use the SMART acronym above. Just like in setting SMART goals, creating
SMART policies can be highly effective.
Policy is not detail-oriented; it is a high-level focus about who has to do what. It should not include step-by-step
instructions. The rule of policy assessment is that the policy covers the "who" and "what needs to be done." Procedures
cover how to do it. For example, the policy would state that each user must change his or her password every 90 days.
The procedures would give you the details of how to change a password on a given operating system. In general,
procedures can be updated with far less review than policy.
)
)
)
Security policy must also be in accordance with local, state, and federal computer-crime laws. ISMS (Information
Security Management System) is a process by which an organization formulates security policy based on ISO 27001
Standards. Consider the information that needs to be secure and consider the level at which it must be secured, and then
exaınine the policy to see whether it is consistent with the mission Statement and with the following other policies:
Program polİcy: This high-level policy sets the overall tone of an organization's security approach. Typically,
guidance is provided with this policy to enaçt the other types of policies and who is responsible. This policy may
provide direction for compliance with industry standards such as ISO, QS, BS, AS, etc.
Issue-specific policy: These policies are intended to address specific needs within an orgaıization. This may include
password procedures, internet usage guidelines, and more. This is not as broad a policy category as the program
policy; however, it is broader than the system-specific policy.
System-specific policy: For a given organization, there may be several systems that perform various functions where
the use of one policy goveming all of them may not be appropriate. It may be necessary to develop a policy directed
toward each system individually. This is a system-specific policy.
If you discover any discrepancies, note them because you will need to resolve them for the policy to be meaningful.
Again, note any contradiçtions you discover so that you can get the document corrected.
Examine the policy for provisions to keep it current. Security policy should be reviewed regularly. Policy revisions
should reflect lessons learned from recent incidents and new threats to the organization's security.
Policies Procedures
. Scope of the Information Security . Risk treatment plan
Management System (ISMS) . Operating procedures for IT management
. Information security policy and objectives . Incident management procedure
. Risk assessment and risk treatment . Business continuiŞ procedures
methodology
. Statement of applicability Other
. Definition of security roles and . Inventoryofassets
responsibilities
. Risk assessment report
. Acceptable use of assets
. Access control policy
. Secure system engineering principles
. Supplier security policy
ISO 27001 is a good source to consult for which policies and procedures you need to have as part ofyour ICS
Cybersecurity Program. ISO 27001:2013 requires the following documents.
Policies
. Scope of the Information Security Management System (4.3)
. Information security policy and objectives (5.2 and 6.2)
. Risk assessment and risk treatment methodology (6.1 .2)
. Statement of applicability (6.1.3 d)
. Definition of security roles and responsibilities (A.7.1.2 and A.13.2.4)
. Acceptable use of assets (A.8.1.3)
. Access control policy (A.9.1.1)
. Secure system engineering principles (A.14.2.5)
. Supplier security policy (A. I 5. 1 . 1 )
Procedures
. Risk treatment plan (6.1.3 e and 6.2)
. Operating procedures for IT management (A.12.1.1)
. Incident management procedure (A. 16. I .5)
. Business continuity procedures (A.17 .1.2)
Other
Inventory of assets (A.8.1.1)
Risk assessment repoı't (8.2)
Policies Procedures
. Controls for managing records . Procedure for document control
. Bring your own device (BYOD) policy . Procedure for internal audit
. Mobile deüce and teleworking policy . Procedure for corrective action
. Information classification policy . Procedures for working in secure areas
. Password policy . Exercising and testing plan
. Disposal and destruction policy . Maintenance and review plan
. Clear desk and clear screen policy
. Change management policy Other
. Backup policy
. Business impact analysis
. Information transfer policy
. Business continuity strategy
ISO 27001 :201 3 also recommends the following documents, but does not require them. This is also sound guidance for
you and your program, suggesting that you should focus on the set on the previous slide first, then move on to these
doçuments.
Po licies
. Controls for managing records (7.5)
. Bring your own device (BYOD) policy (A.6.2.1)
. Mobile device and teleworking policy (A.6.2.1)
. Information classification policy (A.8.2.1, A.8.2.2, and A.8.2.3)
. Passwordpolicy (A.9.2.1, A.9.2.2, A.9.2.4,A.9.3.1, and 4.9.4.3)
. Disposal and destruction policy (A.8.3.2 and A.11.2.7)
. Clear desk and clear screen policy (A. 1 1.2.9)
. Change management policy (A.12. 1.2 and A.14.2.4)
. Backup policy (A.12.3.1)
. Information transfer policy (A.13.2.1, A13.2.2, and A.13.2.3)
. Business continuiry strategy (A.17.2.1)
Procedures
Procedure for document control (7.5)
Procedure for internal audit (9.2)
Procedure for coırective action (l0.1)
Procedures for working in secure areas (A.1 1.1.5)
Exercising and testing plan (A. 17. I .3)
Maintenance and review plan (A.17.1.3)
Othcr
Business impact analysis (A. I 7. l. I )
A well-written policy with clear, concise guidance is of relativelyno use if it is not enforced and adhered to. Ensuring
that a policy is actually implemented begins with an organization's culture and a widely known understanding throughout
the organization that compliance is of utmost importance, which requires Suppoı1 throughout İhe organizaİion, starting
with leadership. This is typically referenced as a culture of compliance within an organizaİion, and many organizations
develop a communications approach to providing awareness of the internal compliance culture.
Organizations typically implement compliance controls to ensure that policies are being implemented effectively and to
provide for routine validation that any deficiencies are being tracked and mitigated in a manner that prevents recuffence.
In addition to a strong culture of compliance and effective compliance controls, organizations must perform routine
reviews oftheir policies and update them as needed. This process ensures policies reflect the current state ofthe business
and ensures that current leadership has reviewed and understands the guidance that has been established for the
organization. Compliance gap assessments can also be used to validate current performance levels compared to expected
compliance-related requirements.
The US Federal Energy Regulatory Commission provided guidance through the issuance of a policy statement on
compliance. Docket No. PL09- 1-000 says to:
Provide suffiçient funding for the administration of compliance programs by the Compliance officer.
Promote compliance by identifuing measurable perfoımance targets.
Tie regulatory compliance to personnel assessments and compensation, including aompensation of management.
Provide for disciplinary consequences for infractions of Commission requirements.
Provide frequent mandatory training programs, including relevant "real world" examples and a list of prohibited
activities.
Iınplement an internal lıotline through which personnel may anonymously report Suspected compliançe issues.
Implement a comprehensive compliance audit program, including the tracking and review of any incidents of non-
compliance, with submission of the results to senior management and the board.
Reference:
htp://www.ferc. gov/whats-new/comm-meet/2008/l 0 1 608/M-3.pdf
Controls provide the governance tools to ensure that policies are being complied with throughout the organization. Strong
technical and procedural controls help to ensure that business processes routinely and consistently perform accurately and
reliably.
When controls are used consistently, they can help build a picture or scorecard of performance across the organization to
determine if there are specific areas of concern.
Controls may also be implemented to assess continued compliance to external regulation measures.
These objectives will be achieved in ICS environments through technical controls (automated processes) and through
procedural controls. An example of a technical control is a physical security badging system or an electronic
authentication system for cyber assets. Procedural control examples could be to require all visitors to sign in at a front
desk when in a facility.
The best place to start is with your IT department's current IT security policies. The last thing you want as an ICS
Security team is to be an exception to the formal company IT securiry polices. You aren't an exception-you just have
different constraints and requirements. Duplicate what the IT securiry teams have already created and modify them for
ICS. You will need to change the scope to what is appropriate for ICS, but while you do that, try to stay as close as you
can to what they have. This will allow for easier company-wide updates and minimize the pushback you receive. Work
with IT and management to modify scope between IT and ICS policies. This will mostly be nefwork specific, relating to
assets or data residing in ICS networks from Layers 3 and below. You should end up with your highestlevel policies in
the company having a Scope that encompass both IT and ICS, with your mid-level and lower polices staı1ing to diverge
into separate policies.
other resources are available for organizations to reference and utilize when developing policies from sçratch. These are
all non-ICS-specifiıc policies, but remember, the reasons our ICS SyStemS are vulnerable and most of what we do to
defend them are focused around IT technologies, so our ICS policies are mostly IT focused. The templates available
provides a great starting point and framework for policy development and can be a useful resource to compare against
existing policies to see whether there are any gaps or areas of weakness that should be further developed.
References:
The SANS Policy Website - http://www.sans.org/security-resources/policies/
CSo online - http://www.csoonline.corrı/articlel486324lsecurity-tools-templates-policies
Information Shield - http://www.informationshield.com/
We are quickly covering the North America bulk power system regulatory scheme adhered to (by agreement) by the
United States, Canada, and Mexico. The regulations are enforced by law and agreement in the meınber states and are
implemented by Electric Reliability Organizations (ERO). The North American Electric Reliability Corporation (NERC)
was selected as an industry body to serye as the ERO. The following slides are an example of NERC's regulation for
some of the topics we have discussed. The NERC Critical Infrastrucfure Protection Standards (NERC CIP) were selected
for a review because they are the first comprehensive cybersecurity regulation applied to the main segments of bulk
power systems in three countries and have a wealth of information that can be analyzed and openly discussed. We will
use this information to see where cybersecurity controls and practices have been successful and/or challenging for power
ICS.
The Noıth American Electric Reliability Corporation (NERC) is a not-for-profit entity whose mission is to ensure the
reliability of the bulk power System in Noıth America. NERC develops and enforces reliability standards; annually
assesses seasonal and long-term reliability; monitors the bulk power system through system awareness; and educates,
trains, and certifies industry personnel. NERC's area of responsibility spans the continental United States, Canada, and
the northeın portion of Baja California, Mexico.
While other sectors have developed standards and frameworks for cybersecurity requirements for critical infrastructure,
NERC has a unique enforcement capability and has matured over the last l0 years. We will look at how the enforceable
NERC Standards fit for a couple of the topics we discuss.
You should look to the NERC Standards as a possible model that many sectors will eventually heed for critical
infrastructure cybersecurity assets. Look to the electric sector as a possible compass for where your sector of interest may
go.
The NERC CIP Standards provide a non-academic, non-research-based approach to ICS cybersecurity requirements that
have been implemented by hundreds oforganizations effectively over the last 10 years. The standards have never been
perfect and as a result, have continued to evolve, demonstrating flexibility in providing the necessary requirement
language detailing what an organization must do while remaining non-prescriptive in regard to how an organization can
meet the requirement.
These improvements over time have moved the standards from the early days of the ı200 Standards, which were Control
Center-focused, to the 1300 Standards, which expanded into field assets and eventually into the CIP Standards
framework that has been in effect for many years. The CIP Standards should be viewed as one paradigm in the Versions
7, 2, and 3 implementations of the requirements. In this paradigm, the CIP Standards required organizations to identify
the assets they owned or operated that were critical to the Bulk Electric System, and these earlier standards took an
"everything gets everything" approach, where all identified Critical Cyber Assets were subject to all requirements. This
earlier paradigm resulted in many unintended consequences and had numerous organizations self-identifuing that they
did not own or operate any critical assets. The new paradigm, partially introduced in CIP Version 4, but going into effect
in CIP Versions 5 and 6, took a high, medium, and low criteria-based approach that identified assets that were critical
within the standards and implemented a systematic approach to allow organizations to group assets and apply the
requirements to the group ofassets, rather than each individual asset.
As organizations manage their CIP programs, they undergo audits and potential penalties for areas of non-compliance.
This violation information is publicly available and can be evaluated to determine the areas of greatest challenge within
the CIP Standards, as well as evaluating the areas of greatest risk for an adversary to target. The violation information for
ClP-related penalties does not provide the details of which organization received the penalty, but the details of the non-
compliance event are provided. Defenders in many industries can leam from these challenges.
Throughout North America, the NERC CIP Standards have been evaluated for applicability, adoption, or modification to
apply similar reqrıireıııeııts oıı otlrer critical iııfrastıuı:tuıe, suclı aS watel, oil, alıd gas. Ill additiolı, otlrel'couırtl'ies lıave
conducted studies and evaluated the NERC CIP Standards during the development of their country- or region-specific
guidance.
Controls framework
. Senior manager approval every 15 months
. Continuous monitoring
. Self-report
. Self-certification {ö
. Whistleblower _ çL('' "* .f,\
. Spot check ö A" '
. 3-/6-year audit cycle
Penalty structure
. Staggered penalty matrix based on risk and severity
. Federal penalty structure up to gr million per day/per violation
Entities are required to utilize continuous monitoring of their reliability obligations and compliance programs in a manner
that seeks out and identifies deficiencies. When identified, entities are required to immediately self-report any identified
violations of the requirements through the use of self-report forııs. The self-repoı1ed violation becomes a Possible
Violation that is investigated by the NERC Regional Entity, and if a violation is confiımed, then the entity begins
working with the enforcement depaı1ment from the Regional Entity, which detemines the penalty amount.
Entities subject to NERC regulation must also self-certiflu on a monthly, quarterly, or annual basis depending on the
standard and the requirement. The self-ceı1ification establishes an auditable point in time when the entity is self-
certiflıing a status on an individual requirement.
There is also a whistleblower capability, where anyone can contact NERC or a region and repoıt a Possible Violation that
will result in a Compliance Violation Investigation of the entity.
NERC also has a routinely scheduled 3-year or 6-year audit cycle that is utilized to assess an entity's compliance over the
entire 3-year or 6-year period since the last audit. In addition, NERC has the capability to exerçise a spot check on any
standard or requirement at any time of any entity.
Through the Energy Policy Act of 2005, FERC has federal sanction capability that extends to NERC and the regions.
Each standard has requirements that have been assigned risk and severity levels, and penalties will be determined using
these assigned risk and severity levels. The sanction guidelines allow for penalties up to $ I million per day per violation.
The NERC CIP-003 Standard addresses requirements around Security Management Controls with the requirements
around cybersecurity policies that address the requirements of the CIP Standards. CIP-003-6 Rl.l lists the required
cybersecurity policy topics that must be addressed for high- and medium-impact BES Cyber Systems. This can be
separate individual policies or an overarching umbrella policy. The training requirements in CIP-004-6 R2.l also require
training on these policies.
Reference:
http://www.nerc.com/pa./stanüPages/Reliabi1ityStandardsUnitedStates.aspx?jurisdiction:United%20StateS
0
PRc{05 0?006 ğP{07 oPoo{ VAR.00? fAc.008 oP403 TpL.00ı fnc-oog ToP-co2
NERC has more than 100 reliability standards, and it tracks the most violated standards of all time. The set of CIP
Standards represents 10 of the 1OO-plus NERC Standards, and based on acfual violations in Ql and Q2 of 20l6,the CIP
Standards represent 4 of the top l0 most violated standards. The l0 CIP Standards have traditionally held 6-8 spots in the
top 10 most violated standards of all time, which is an ongoing inventory of violations, a strong indication of the dynamic
nature ofthe cybersecurity-focused standards versus the traditional reliability-focused standards, as well as the
challenges of maintaining compliance with standards that represent repetitive reoccurring tasks that need to be performed
on a large number of assets.
Reference:
http://www.nerc.com/palc omplCE1Pages/Compliance-Violation-Statistics.aspx
Section takeaways
. Policies: High-level directives
. Standards: Mid-low-level directives
. Guidelines: Low-level recommendations and examples
. Procedures: Low-level steps and checklists
Recommendations to olyner/operators
. Use SMART and five W's to reüewyour policies annually
Recommendations to governments and industry regulators
. Correlate your guidance and regulations internationally
. Facilitate dissemination to needed parties
Writing a Policy
We also learned a great deal about the business drivers, roles, and various activities involved in creating a policy
)
ıcs4 ı 0.5 Fİeld Devices and Controllers
Disaster Recovery
Applicable Standards:
. NısT CSF v1.1: Rc.ıM-l, RC.ıM_2
. lsA/ıEc 62443-2-1:2009: 4.4.3.4
. ıso/ıEc 27oot:2o13: 4.15.1.5, Clause 10
. NısTsP800_53 Rev.4ı CP-2, ıR_4, ıR-8
. coBıT 5: APoL2.06, BAı05.o7, BAı07.08, Dss04.08
Determine
Plan improvements,
business and
modifications, and
updates
This slide shows the basic steps that are necessary when developing a business continuity (BC) or disaster recovery (DR)
plan. We start with Project Initiation, in which new or enhanced functionality is required. At this point, you must get
management approval to start the project. Management is instrumental in making sure that you have access to the
resources that are required to get thejob done. The next sequence ofsteps in the process concern the company's
vulnerabilities, their significance to the company, and what the company is going to do about them.
First, the company determines its vulnerabilities through a Risk Analysis. The company then assesses the impact that
each of these vulnerabilities represents for the company by completing a business impact analysis. Realistically, no
organization has the resources to deal with every vulnerability. Instead, in this step, the company prioritizes the
vulnerabilities based on their likelihood and impact. Those yulnerabilities that represent greater risk to the company are
identified so that steps to avoid their occurrence can be planned. In the event that those plans fail, the prioritized
vulnerabilities can also be given priority in terms of recovery of affeçted operations.
Remember, not all losses are directly associated with the loss of money, although it will most likely affect the company
financially in the long run. Do not forget to include the "intangible" losses, such as customer satisfaction or loss of
consumer confidence. For instance, if a major e-conımerce shopping site is down for a long time, consumers will become
frustrated and will perhaps begin shopping somewhere else. At that point, it does not matter what caused the problem:
Earthquake, flood in the data center, or a Denial-of-Service attack. The fact is that the site was down. The faster the
company is able to recover, the better. Conversely, professional handling of a disaster can actually improve an
organization's reputation with its customers and other stakeholders.
a
a
.l
Lack of Prioritization
There is a need to prioritize the key business processes. The risk is to prioritize less-than-çritical processes instead ofthe
ones crucial for business survival. This is a time for thoughtful evaluation and decisions.
Inadequate Insurance
Some organizations lack adequate insurance coverage and fail to support the filing of insurance claims, and these
inadequacies result in delayed or reduced sefflements. The plan may lack appropriate processes for capturing losses and
recOvery costs, without which the organization may realize a loss greater than otherwise necessary.
Summary
Use these examples of common mistakes as a checklist to review your organization's contingency planning - i.e.,
documentation, testing, integration with organizational processes and personıel, etc.
*l
,<J
1o5
sJ *-€
( ;) ş
A business continuity plan (BCP) is defined as a plan for emergency response, backup operations, and post-disaster
recovery maintained by an activity as a part of its securify program that will ensure the availability of critical resources
and facilitate the continuity of operations in an emergency situation. Business continuity planning enables the quick and
smooth restoration of business operations after a disaster or disruptive event.
The BCP is an overarching plan that details recovery from a disaster and business resumption planning, as well as a
compilation or collection of other plans, including:
. Disaster recovery plan
. End-user recovery plan
. Contingency plan
. Emergency response plan
. Crisis management plan
' Other plans as required (for example, a server recovery plan or a phone system recovery plan)
A BCP is a business's last line of defense against risks that cannot be controlled or avoided by other risk management
practices. In addition to an immediate action plan for recovering the business, the BCP should also consider a long-term
plan that keeps the business running. For example, after the company has relocated resources and established operations
in a new location, how should the business work to re-establish the disaster site? Long-term planning should also include
public relations and possibly marketing, with a plan to maintain the positive, reliable image for the company following a
disaster.
The BCP doesn't just define how a company should react to a disaster to keep the business operational; it must also define
how the business will restore 100% of the operation, including the ability to continue to meet defined business goals.
Example of a BCP
One organization, Morgan Stanley Dean Witter, was blessed with an individual who had the foresight to plan for the
attack on the World Trade Center. Rick Rescorla was a unique individual. In 1985 and again in 1993, he identified the
World Trade Center as a target for terrorist attacks. Rescorla is a prime example of what one person can do when
committed to doing the right thing. Hundreds of people who were in those buildings on September I I are alive today as a
result ofRescorla's planning and because they practiced for such an attack.
Summary
Like a business continuity plan, the BRP doesn't just involve IT; it involves all levels of the organizaİion' The best BRPs
that we've seen include how the organization will continue to meet and exceed the defined goals for a business following
a disaster.
_)
)
46 @ 2019, Justin Searle
)
)
l
BUsı NEss ıMPACT ANALYSıS (BıA) oVERVıEW
The business impact analysis (BIA) documents what impact a disruptive event might have on a corporation. The BIA
prioritizes business functions versus risks to identisı the criticality of functions and the time fraııe on which they must
recover. Some business functions, if down for only a few seconds, might dramatically and detrimentally impact the
business. other business functions might be intemıpted for days or weeks and have no negative effect on the corporation.
The primary goal of the BIA is to deteımine the maximum allowable downtime for any given system, or maximum
tolerable downtime (MTD). Understanding the MTD for business processes is mandatory before designing your disaster
recovery plan. Without the MTD calculation for systeıns, you won't know if the plan meets or exceeds the requirements
of the business. While exceeding business requirements is usually a good thing, the cost of doing so may not be.
The process of developing the BIA typically involves interviewing the various key users of the various computer systems
to get a better understanding of how a disaster could impact the ability to continue operations. Some of the key inteıview
questions might include:
' What would be the impact of an information technology failure on cash flow and revenue generation?
. Would the disaster impact the level of service?
. How long could the outage last before it began to affect your productivity?
. Would there be irretrievable loss of data?
. What are the key resources that are required to be kept operating?
. At what point would those resources need to be in place?
' How does this process/system interact with other processes and systems? What are the dependencies on this
process?
When putting together the BIA, the answers should come from, or be concurred by, executive management. At that level,
management understands çost trade-offs such as between mitigation and loss, and has individual accountability either
way. Lower management may err toward too much (that is, too expensive) risk avoidance, whereas upper management
might prefer to occcpt ccıtnin rigkş and rcdircct mitigation resollrces elsewlrere iıl tlıe busiıress. Tlıis is a collurrolı ırıistake
in BCP/DRP planning.
The NERC EOP standards are a set of reliability standards that address emergency operations, and EOP-008 specifically
addresses the requirements for entities to address the loss of control center functionality. NERC CIP-009 provides a set of
requirements addressing recovery plans for Critical Cyber Assets.
Reference: http://www.nerc.com/palstand/Pages/ReliabilityStandardsUnitedStates.aspx?jurisdiction:United%20States
NERC EOP-008-1 requires applicable entities to provide for a location and method for performing backup functionality
until the primary control center is restored. The backup control center must provide adequate power facilities for
operations and provide physical and cybersecurity protections. The backup control center must provide for necessary
operator tools, applications, and situational awareness, as well as all necessary voice and data communications.
These processes must operate in a manner that keeps both sites consistent and in many cases, requires real-time
replication of data from site to site while in normal operations, so the backup site would be current in the event of an
emergency condition. In addition, the transition period ofpersonnel and systems being transferred cannot exceed 2 hours.
During the 2-hour transition period, the entities must plan for actions to take during the transition period, including
communiçations and notification to necessary parties. These plans must be reviewed and exercised annually, and they
must be performed in a manner in which they do not rely on voice or data communications from the primary control
center.
Reference:
http://www.nerc.com/pa,/stanüPages/ReliabilityStandardsUnitedStates.aspx?jurisdiction:United%20StateS
While EOP-008-1 applies to certain entities depending on the functions they perform, CIP-009-6 applies to certain
identified BES Cyber Systems within an organization depending on the impact they have on BES. Depending on the
entity, they may be subject to EoP-008 and not cIP-009, or reverse, or neither, or both.
CIP-009-6 requires the recovery plans to address the following: Conditions for activation of the recovery plan(s), roles
and responsibilities ofresponders, processes for the backup/storage ofinformation required to recover BES Cyber
System functionality, and processes to verisı the successful completion of the backup processes. In addition, the plans
need to address retention ofpotential cybersecurity incident related information ifpossible.
Testing and updating the recovery plans is required every l5 ınonths, and the test can be performed through recovery
after an acfual event, or through a paper test as you evaluate procedures, contact info, and system restoration or failover
procedures contained in the recovery plan, or you can perform an operational exercise. For certain systems, an
operational exercise must be performed every 36 months.
After completion of these tests, lessons learned follow-ups must be documented and updated as well any updating the
plans based on organizational role or responsibility changes or technology changes.
Reference:
http://www.nerc.com/palstand/Pages/ReliabilityStandardsUnitedStates.aspx?jurisdiction:United%20States
Section takeaways
. ICS CybersecurityTeams often don't own BCP and DR
. Often already created for each critical ICS process
. But we can influence them
. Most plans fail to consider or properly respond to cyber events
Recommendations to owner/operators
. Modify plans to include proper cybersecurity incident responses
Recommendations to vendors
' Create or improve your cybersecurity emergency response services for customers
' Educate customers in appropriate cybersecurity responses for your products
)
I
)
)
)
@ 2019, Justin Searle 51
)
)
)
Course Roadmap Z
l. Introduction
lCS Cybersecurğ hograms
. Sarting the hocess
. Frameworks: lSA/lEC 62443, ıso/lEc 2700ı, NısT csF
Day r: ICS Overview . Using üe NısT csF
3. ICS Cybersecurity Policies
. Policies,Sandards, Guidance, and Procedures
Day z: Field Devices and. Controllers . Culture and Enforcement
. &les and Sources
Day 3: Supervisory Systems 4. Disaster Recovery
. DR and BCP Programs
. Modificaüon for Cybersecurİty lncidents
Day 4:Workstations and. Servers > 5. Measuring Cybersecurity Risk
.
Quantitatİve vs Qualiative
.
Traditional Models
Day 5: ICS Security Governance .
Hinimİzing Subjectİvıty
6, lncident Response
.
Six Step Process
7. Exercİse 5.l: lncident Response Tabletop Exercİse
8. Final Thoughs and Next Steps
. oüer ]CS Courses by SANS
. other SANS Curriculums aıd Courses
. Netwarc
)
_]
--)
-)
-l
-l
Applicable Standards:
)
CIS CSC: 4
' coBıT 5; APo12.01, APo12.02, AP0L2.03, APo12.04, APoLz.os, APo].3.02,
Dss04.02, Dss05.01, Dss05.02, BAı08.01
)
)
)
)
)
)
_)
)
)
)
)
)
_)
)
@ 2019, Justin Searle 53
)
)
__)
RısKAPPRoAcHEs
There are two risk assessment approaches: Qualitative and quantitative. In quantitative risk assessment, we try to assign
an objective numeric value; typically, this value represents a monetary loss value. Qualitative risk assessment, however,
deals with more intangible values and focuses on variables and not just the monetary losses.
Quantitative risk assessment is a far more valuable business tool because it works on metrics; usually in dollars. The
bottom-line cost in dollars is what management is looking for when trying to understand the implications of how a risk
can affect the organization.
Qualitative risk assessment is much easier to perform and can identify high-risk areas. For instance, you need to perfoım
a risk assessment to determine the impact of installing a wireless LAN access point in your organization. The first order
of business is to detenıine the ıulnerabilities, threats, and therefore the risks of using a wireless LAN. Then you
determine if those risks apply to your organization and determine the likelihood that you are at risk. One of the risks of
using a wireless LAN is the possibility of someone sniffing the wireless network traffic, and that a misconfigured access
point can allow rogue client connections. These are real risks that need to be addressed. Can you put a monetary value on
these risks? If someone does connect to your network via the open access point, how much is that going to cost your
company in lost revenue?
As you aan see from this example, quantitative risk analysis in this situation does not quite work. A qualitative approach
is much better because we can arrive at a less subjective result. In qualitative risk assessment, the results are typically
categorized as low-, medium-, or high-risk events. A person operating a wireless LAN access point in the house in the
country, where the nearest neighbor is 5 miles away, is at a low risk of having someone trying to connect to the network.
A company in the middle of a high-tech park, with an access point that allows rogue connections, has a high risk.
Easier-to-answer questions
. What can be compromised? (Asset/Process)
. What or who could compromise it? (Threat Actor)
. What could the threat actor do? (Threat)
. What weakness can the attacker exploit? (Vulnerability)
. What could this mean for the company? (Risk)
. If it happened, how bad could it be? (Impact of Risk)
Harder-to-answer questions
. How likely is it to occur? (Likelihood)
. How often could it happen? (Frequency)
How reliable are the answers? (Subjectiüty)
To decide between accepting, mitigating, or transferring the risk, we need to better understand the risk and how it affects
us
When evaluating risk, it is helpful to ask yourself some key questions listed in the slide above.
The answers to these questions help us focus on the actual threats and gain a better understanding of their impact if they
were to actually happen. The first question is to ask ourselves: What exactly are we afraid ofl What is the actual threat?
Is the threat something tangible? Can we accurately define the threat?
And if we can define the threat, what damage could it cause? What is the probable extent of the damage? For instance,
the damage could be anything from a few comrpted files to a complete destruction of our critical processes, causing loss
of life and damage to the environment. In other words, what is the impact of the risk? Another variable to consider is the
frequency of the threat. How often could this threat happen? Is it just once or can it occur more often?
The last question relates to the recognition of uncertainty. That is, how sure are you of the answers to the previous
questions? Can you validate and prove your answers? This might be a difficult question to answer because it might be
hard to accurately perform our risk calculations on operating systems or new programs when new lulnerabilities are
constantly being discovered.
When all is said and done, in the end, it all comes down to money. What management will be considering is, "How much
financial loss are we willing to accept in a single (threat) event?" If a company's database is compromised and that
database contains your proprietary (and valuable) secret formula for your next revolutionary drug, tlıen you could not
afford even one risk to your system that might lead to the theft of this formula. Remember, we stated that risk involves
uncertainty. The uncertainty here is that we cannot accurately determine the exact value of the formula (it might make
millions of dollars, or it might not make any money at all because the formula might not work).
What this leads to is the calculation of the Single Loss Expectancy or SLE. The SLE is the dollar value that is assigned to
a single event. That is, it is the organization's loss from a single event. The Exposure Factor (EF) is the percentage of loss
a threat event would have on the asset. The EF is expressed in teıms of 0 to 100% loss of an asset. What happens when
the event occurs more than once? We then calculate the Annualized Loss Expectancy or ALE. The ALE is the annual
expected financial loss from a threat.
6, n b 1\ uc nrli \\ ( n.-r^\
Use likelihood and frequency to help prioritize actions inside each level
ICS applications are best prioritized by the function a specific system provides as measured against the consequences
involved if the system did not funçtion properly or were misused.
Functions, for our purpose of prioritizing, can be described as the following (you ınight add levels or expand definitions
for local use):
Level 0 - Safety and Emergency Action aııd Shutdown
Level I - Control (closed loop regulation or protection systems in the power system)
Level2 - Supervisory Control
Level 3 - Monitoring and Alanıing
Level 4-Telemetryonly
Level 5 - Auxiliary services
These functions can be mapped to consequences that may occur if the function is disrupted, affected, or misused. To
identify specific consequences, an analysis effort including process engineers can be performed to identify how the
specific proçess or equipment/machinery could be affected if the function were lost or misused. These efforts can be
modeled off existing risk assessment methods used in engineering, such as PHAs, Hazops, LOPA, and FSAs. Having a
security analyst involved makes sure the team performing the analysis does not develop blind spots around what is
possible or attacks that could impact a specific system design. Some systems can be prioritized as "mission-critical" as
they are necessary to the proper function for the plant or process to run. Mission-critical systems may not always be
apparent as sorle ofthe requirements can be overlays such as regulation. In these cases, the plant could physically
operate safely, but the loss of the system might trigger a regulatory threshold that requires shutting down that plant (for
example, emission-monitoring sensor reporting on the stacks of a coal plant).
Trust is an important security concept and it can be defined in gradients from most trusted to least trusted. Changes in
trust gradient would require security enforcement and controls to interconnect and transverse trust boundaries. This is a
ırıaterial coırcept that fuı'ıış tlıç busis lul ISA-99/IEC-62,1,13 arghitectures. Keep in mind that SyStemS used to set or store
contigurations should be placed into the correct level if they can connect with those devices (for example, an engineering
workstation that can interface with a safety system would be considered Level 0).
Level I - Control
Process controllers, power system protection (relays), process shutdown (PSD), Programmable Logic Controllers
(PLCs), remote terminal unit (RTU), control servers, etc.
Level 4-Telemetryonly
Metering systems, historians, telemetry collection systems, etc.
Caution: You might identifu other "mission-critical" systems that could fall in Level 2 as their loss would require a
controlled shutdown of the plant or process. You may also charaçterize your security SyStemS or those controls that help
maintain the integrity of your Level 0 systems as being on par or in the same trust gradient. Many organizations use
security services, applications, and devices to protect high trust systems, but they don't apply the same level of security.
This is common when security services are provided from the general enterprise network. The best rule of thumb is to
have all your securify devices managed from a similar level or higher level of trust/protection than the system that you
are protecting.
Biggest benefits to the organization are countermeasures that protect the revenue
flow
An important question you will need to answer is, "Who in your organization is actually authorized to decide what level
of risk the organization will accept?" An issue that comes up from time to time is that lower-level managers make risk
decisions that can potentially adversely affect the entire organization. This is paı1ly a function of not understanding the
techıologies and risks involved. one method of mitigating this is with awareness training.
Another consideration façtor is the cost of the safeguard versus the acfual value of the asset. It makes sense that the cost
of the protection should not be more than what the asset is worth. Would you buy a $5,000 safe to protect a ring that is
worth only $100?
Cost-benefit analysis is the comparison of the cost of implementing countermeasures with the value of the reduced risk.
Can you accurately determine if the countermeasure is 100% effective? Antivirus software is known to fail against
unknown viruses, especially if the virus signatures are not up to date. Companies with firewalls are not 100% protected
because firewalls can be compromised (or bypassed) and because traffic containing attacks may legitimately pass
through the firewall.
Benefits are the reduction in the risks your company is exposed to. Keep in mind that the biggest benefits to the
organization may be the countermeasures that protect the revenue flow. This is especially true if your organization is
involved in ICS. The cost of a countermeasure is more than just the initial cost. There is the labor cost of monitoring the
devices and the life-cycle cost.
CIP-002 is sometimes refeıred to as the scoping standard in that the Attachment l criteria is used to identify the assets
and BES (Bulk Electric System) Cyber Systems in scope for applicability to the requirements. The requirements apply
based on the çriteria of high, ınedium, or low and the applicability of each requirement part.
Organizations subject to the NERC CIP Standards must consider the following asset types when evaluating the criteria of
Attachment l:
i. Control Centers and backup Control Centers
ii. Transmission stations and substations
iii. Generationresources
iv. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and
initial switching requirements
v. Special Protection Systems that support the reliable operation of the Bulk Electric System
vi. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above
Reference:
http://www.nerc.com/pa./stanüPages/ReliabilityStandardsUnitedStates.aspx?jurisdiction:United%20States
\r
Section takeaways \^ı\
\.-""J
. Calculating risk is hard and always subjective J
and Procedures
Day z: Field Devices and Controllers
)
ıcs4 ı 0.5 Fİeld Devİces and Controllers
Incident Response
Applicable Standards:
. NısT CSF v1.1: Rs
. ısA/ıEc 62443-2-1:2009: 4.3.4.5.L
. ıso/ıEc 27ooL:2o13: 4.L6.1.5
. NısT sP 800_53 Rev. 4: CP-2, cP_10, ıR_4, ıR-8
. cıs CSC: 19
. coBıT 5: APo12.06, BAı01.10
,)
.)
)
)
)
O 2019, Justin Searle 63
)
)
)
I
oİ7
\J L
''ı'-v 4(
I
o\ Lı//\'
onT
.,J"55
:::,' ga
\".}eJ\n
Preparation
Identification
Containment --)
Eradication )
)
Recovery )
Lessons Learned I
Based on the importance of incident response across the indusğ, it is important that a clear and standard process be )
followed. To create a starting point, the US Department of Energy (DOE) led an initiative to build a six-step process back
in the earŞ l990s. The six-step process used in this course and thıoughout the industry is based on the original process .)
The six steps listed here can help serve as a road map or a compass, if you will, to develop a phased approach to incident )
handling. Keep in mind that for this process to be successful, each step must be followed. )
)
)
)
_)
)
_i
)
J
)
)
)
)
)
)
_)
64 @ 2019, Justin Searle )
)
)
I
,
step
çe
Most critical and often overlooked v,,J ot\ {\, q'ü',
V
out-of-band communications important if you have VoIP -
,aaV'
,ı*^
ıf, ş a)
Policy '*(
. Organizational approach t'ı ^
N
..(
. Interorganization
Obtain management support
Identify contacts in other organizations (legal, law enforcement,
partners' tı
,' , '- ,\ ş / { a n-ı1 Lz ı^v\m; *\
Select team members Vu. V j,r, il i.ı^ V\ $pc.a\ ı^"}; ^ . - -
İc9l0 ı lcyscADA Securiç Bsentials 65
The preparation step is the first and most critical step of the incident handling process. The tasks associated with this step
must be perfoımed in advance, before the incident has occurred. This is the reason why it is often overlooked, or even
skipped. SANS recommends that you spend enough time preparing all the elements that are required during an incident,
with the goal of increasing the efficiency and success of your incident handling effoıts.
When it comes to incident handling' planning is everything, and preparation plays a vital role. It is impoıtant to have a
policy in place that covers an organization's approach to dealing with an incident. One item that a security policy needs to
cover is whether a company is going to notifo law enforçement officials or remain silent when an incident occurs. The
answer to that may depend on the severity of the incident; if so, what guidelines should the responder use to decide
whether to call? If you are going to contact law enforcement, have a list of phone numbers for each agency you may need
to involve.
Another important item to consider is whether to contain the incident and move into cleanup phases or to observe the
attack in an attempt to gather more evidence. The policy should also contain direction for interorganization incidents and
how the company works with other companies regarding an incident.
Incident handlers can be under extreme pressure. Consider a worrn that infects your entire infrastructure, effectively
making your network systems unusable. This is one reason incident handling teams must never rely on Voice over IP. If
you have a VoIP installation, consider the use of cell phones, walkie-talkies, or some other backup method of
communications. Incident handling can become a large-scale effort involving many people on many systems
simultaneously. This should be taken into account during the planning phase.
The time to make these types of decisions is before the incident, keeping senior management and legal staff apprised of
any changes to policy. Because ofthe sensitive nature ofincident handling, any decisions made could greatly affect your
career down the road if you did not get approval or reach consensus with management. The last thing you or your
coıııpaı]y waırts is foı' seılior ıılaııageıııcıı[ l.tı qucstiıın tır doubt the decisions that were made duriırg on iırcidcnt.
)
)
)
66 @ 2019, Justin Searle )
)
)
ıNcıDENT HANDLıNG - PREPARATıoN (2)
As the incident response team begins to mature and has responded to several large incidents, it is possible that members
of the team will get burned out and leave the team. Although this is certainly understandable, an approach you may want
to take is to provide compensation and other rewards for members of the team. This may run counter to your current
policies, but keep in mind that incident handlers are often called to perform their duties after normal business hours,
weekends, and holidays while under a lot of pressure to get things restored as quickly as possible.
During the preparation phase, an organization should make plans to update its disaster recovery plan to include incident
handling. After all, what is a disaster? It is an inçident and needs to be handled as such. Although disaster recovery plans
are often thought of as a checklist to get a business back up and running as quickly as possible, the skills possessed by the
incident handling team could be put to good use to reach this goal. In addition, the disaster recovery plan and the incident
handling procedures guide should contain information for emergency communications.
The issue of making privileged passwords available to others can be a delicate situation. However, in an emergency, a
handler may need access to critical systems.
One idea to consider is to incorporate a procedure where system passwords are kept in sealed envelopes in a locked
container or data center until they need to be used. This may seem cumbersome, but it does work and keeps the
passwords private until they are needed by the incident handling team. For this to work, the system administrators must
ensure to keep the passwords in the sealed envelopes up to date, and the incident handlers must make every effort to tread
lightly on the systems, inform the system administrators of any changes made, and above all, never use a privileged
password unless they are qualified on that operating system. One thing that will certainly make an incident worse is
having someone who has no idea what he is doing issuing commands as administrator or root.
Our computing environments are complex and will change over time. Training is critical for each member of the incident
handling team. Memory fades over time, especially if the members are not working on honing their skills on a regular
hasis. Having a chccklist on how to bring a Systeııı dowıı safely or oıı lrow to ıestoı'e a Systeııl fl'oıır tape caıl lıelp iır
preventing eırors and can reduce the stress on the handler. lf your team is tbllowing a checklist and the resulting
operation fails, it may be the fault ofusing an outdated checklist on a regular basis, so ensure they are updated to your
organization's current environment.
)
)
_)
)
.)
_)
,J
,)
)
)
)
)
)
68 @ 2019, Justin Searle
)
)
)
ıNCıDENT REsPoNsE PRACTıCE
ıcs4ı0| ıcyscADASecurityEssentials 61
If the first time you dust off your incident response plan (IRP) or communication and notification plan is when you have
an incident, then it is unlikely that you will handle the incident in an appropriate manner. Much like an athlete, practice is
critiçal if you expect to increase your performance and overall ability.
Performing exercises will help improve the abilities of your players to more quickly identiflu events of interest, provide
necessary training on what players should do, and almost equally important, what they should not do.
Many organizations have a mature risk assessment process that has been leveraged to examine the risk of impact to an
operating environment. Mature risk assessments involve internal business units responsible for an operational
environment, as well as across business units that interface or support the operational environment. As you build
advanced scenarios that simulate impacts to components of your operating environment, you will further examine the
pre-incident risk assessment determinations.
As players work through their response plans and attempt to contain, eradicate, and recover assets, it may become
apparent that additional layers of protection or capabilities would improve overall capabilities.
Players and planners will likely identifo important interdependencies across business units and internal or external
partners that may have not previously been identified as potential stakeholders in your incident response proress.
Cross-Business Unit collaboration, reporting, and incident assessment (including escalation procedures) include broad
business coordination (C-suite, public affairs, IT, operations, legal, corporate communications, customers, risk
committee, compliance, regulatory agencies, vendors, supply chain, facilities, physical security, law enforcement, and
more).
Many incident response plans fail to identiflı a true process of incident de-escalation or Cross-BU prioritization and
resoul'ce allocatioıl. Thelc ılıay ulsu bu ilııpırrtaııt rcpurting requirements post incident including:
. Regulatory reporting
. Financial impact reporting
Many organizations are required by regulation to perform routine communication tests and test reporting and
notification capabilities. For organizations that do not have external requirements, it should still be pursued in a test or
practice opportunity rather than discovering that you do not have a means of communication during an incident, either
due to poor documentation or due to primary communication system loss.
Many organizations' incident response plans do not provide adequate guidance and appropriate procedures; further,
many employees may not even be aware that an IRP exists or where it is. During an incident, it would be difficult to
ensure appropriate actions are taken ifa playbook is not well understood and practiced.
Exercises not only provide the ability to examine the resiliency and capability of your systems and your defenses, but
they also provide the ability to examine your personnel capabilities and maturity in responding to an attack. The
greatest systems and plans are unlikely to succeed without skilled, knowledgeable, and capable staff.
F-
"l
, ,....'b^ I 'ie- V-e'"^
!sı\ ) V
) ''
i-o^,f-
^\\ ş
When it comes to identi$ring an incident, members of the team should stay in their realm of expertise. You would not
want a Windows expert digging around a UNIX system, and vice versa.
Some possible signs of an incident that may warrant fuıther investigation essentially include anything suspicious, such as
intrusion detection alerts, unexplained entries in a log file, failed logon events, unexplained events (such as new
accounts), system reboots, and poor system performance.
Being able to correctly identify an incident çould be the difference between cleaning up the problem in a few minutes and
causing your organization's network to be down for several hours or even days. Obviously, any system outage could
potentially cost your company a lot of money, so it is important to identifu an incident correctly the first time and respond
accordingly. For example, after a fire alarm is pulled and a building evacuated, qualified firefighters respond to the scene
and investigate. Only then does the firefighter in charge at the scene authorize re-entry into the building. This should be
the paradigm we work under; be willing to alert early, have trained people look at the situation, and be able to stand down
quickly at a minimum of expense if nothing is wrong. No matter which course of action you decide to pursue, make
certain you have mechanisms in place to correctly identify an incident.
There is nothing wrong with alerting early if you maintain situational awareness, and everyone understands this might not
be an actual incident. All attempts should be made to avoid overreacting to the situation and escalating it too fast, only to
realize an hour later that you made a mistake. If that happens enough times, you could fall victim to the "boy who cried
wolf' syndrome; and then when a real incident occurs, no one will believe you because of the false alarms.
Chances are your organization has a2417 help desk operation that would be ideal for helping out with tracking the
incident and maintaining a paper trail. They could also be utilized to facilitate communication and contact other
personnel as the situation warrants.
According to Vcrizon's 20l3 Dııtıı llrccıch Repurl (DBIR)' lllc uvclagc tiıııt: bı;tıvuuıı a uurııpr'uıılisu aııd
detection of said compromise is 426 days.
It is impoı1ant to keep in mind that a primary handler should be assigned aS a team leader to keep the process flowing
while also making sure that no steps are overlooked or missed. For smaller incidents, often of the "Would you check this
out?" category, there isn't a need to send a core team of incident handlers. It is a reçommended practice to have a core
teaıı of well-trained handlers and also have incident handling skills and training aS paı1 of the job description for security
officers and system administrators. An organization that adopts this approach benefits by having multiple layers of
"firefighters."
However, in such a case, it is important to assign tasks in a way that encourages cooperation among the team and allows
them all to succeed. When assigning tasks to part-time members of the team, do so in a way that it is clear what is
expected of them: The quality of their investigation, their responsibility to preserve and collect evidence, what
documentation they should produce, and when it is due. It is also important that they know who they should contact if
they feel they need additional guidance or support.
After you deteımine that the event is actually an incident, the handler may decide to take the steps needed to build a
criminal or civil case. In this situation, witnesses should be identified, and a written statement of what they heard or saw
should be taken immediately while the information is still fresh in their minds. If a decision is ınade to involve law
enforcement, make sure senior management is notified, unless you have a detailed policy to follow.
okay, we have spent countless hours preparing for the eventualiŞ of an incident. We have a good idea of what it takes to
identify an incident, but where do we go from there? Being able to identify an incident solves only part of the problem.
We are still left with the task of isolating and eliminating the source of the incident. This section discusses some steps
that can be taken to contain an incident and, hopefully, limit its damage to the organization.
The primary responsibility of the incident handler is to make things better while adhering to the basic principles of
liability and negligence. Negligence for failure to meet a certain standard of care is generally determined by a court of
law. Specifically, negligence is defined as"'thefailure to exercise the degree of care expecled of a person of ordinaıy
prııdence in like circunıStqnces iıı protecting othersfi"om aforeseeable risk of harm in a particıılar situation."In other
words, a handler is responsible for meeting the expectations of the prudent person rule. Typically, a company that acts
reasonably or with due çare generally will not be found negligent. When an abnormal condition presents itself and there
is potential for an impact to operational equipment or facilities, the incident handler needs to communicate with
operations management to determine if conservative operations or other response actions are necessary.
There exists a potential for incident handlers to run into trouble while performing their duties. It is extremely important to
keep in mind that there is no aspect of incident handling that allows handlers to break the law. For example, if you
suspect someone within your organization of downloading child pornography, you can't download these files to your
tomputer to examine them. Also, a handler needs to exercise due care with regard to a person's privacy under the
Electronic Communications Privacy Act.
For instance, if you are an Internet Service Provider, you cannot just release the personal information of a subscriber
simply because someone claims they were attacked from the subscriber's IP address.
You should also be aware that corporate officers within your organization might be held liable for your actions if they are
considered unlawful.
One of the key aspects of the incident handling process is to be able to present, with a high level of detail, the different
pieces ofevidence found and all the actions performed during the whole process. For this purpose, you should take
detailed notes of all the events associated with the incident, from the Identification (step 2) to the Recovery (step 5)
phase, preferably using numbered paper notebooks.
)
ıNcıDENT HANDLıNG - ERADICATıoN
Before the system goes back online, an incident handler must make sure that he/she fixes the problem or the vulnerability
that the attacker used to compromise the system. At first glance, the tendency may be to wipe out the entire operating
system and rebuild it from scratch. Although this is certainly an effective way to remove any malevolent code, the
oppoıtunity for reinfection via the same channel still exists. There are a myriad of cases where systems were taken
offline, rebuilt, and put back on the network only to be compromised again within minutes or hours. This is because a
root cause analysis wasn't performed to determine why the incident happened in the first place.
It is not enough to simply recover the system and put it back online: The underlying security mechanisms of the affected
Systems must be altered, fixed, or upgraded to açcommodate any new vulnerabilities. If it is a production System, you
may hear voices of dissent from the organization about modiffing a seryer running on a production network. This is an
important, and to an extent, valid argument, but the counter is that if the system were compromised, then it must contain a
vulnerability that might exist on other servers and could be exploited on a continual basis until the problem is fixed.
Further, manually cleaning up the damage from an incident does nothing to prevent the problem from occurring again
unless the problem is accurately identified and removed, patched, or otherwise mitigated.
Attackers often try to establish additional ways of ensuring remote access to the compromised system, so they have
control of it even if the ıulnerability exploited originally is fixed. Such backup access methods are known as backdoors
and are implemented using several methods. Some of the most common ones include a process listening on a specific
port and offering shells access (without requiring authentication), creating a new user account with high privileges, and
scheduling jobs that periodically run programs that open new paths to access the system. As a wide incident handler, you
need to not only fix the vulnerability used during the initial system compromise but also identifu and remove every
additional backdoor left by the attacker.
After the system is recovered, it is a good idea to run a vulnerability scanner against the affected system to see ifthe
problem is, indeed, fixed and that no new holes were opened in the process. A number of commercial products, such as
TSS Intcrnct Scanncr, work wcll and prodtıce nice-lookiııg rePoı1s, but opeır source tools suclr as opeııVAS slıould ııot be
overlooked. If your organization is on a tight budget, and you need tools that pertbrm the task with great et'ticiency, then
you owe it to yourself to explore the open source options available.
f'
1ö
)
\
(
r\
ıcs4 l 0 ı lc9scADA Security Bsentials ,ı
The key point to consider in the recovery phase is to ensure you are not restoring vulnerable code that has already proven
itself to be exploitable by any number of attack methods. For example, if you restore a system from tape backup, then
you could be restoring a previous state that contained the vulnerability exploited by the attacker. In this rontext,
lulnerable code refers to operating system software that hasn't been patched to the latest levels, source code, and/or
application software being used on the affected system.
Before the system can be brought back into production, the incident handler needs to validate the system along with the
system administrator. Removing the r,ulnerability could have affected other functions of the system that are deemed
critical by the business. Anything that breaks after the recovery is likely to be blamed on the incident handler, so every
effort should be made to ensure the system is working as normal before turning it over to the system administrator.
In addition, the decision on when to put the system back into production has to be made by the system owner. The
handler can give advice and be as helpful as possible, but, ultimately, the final decision of bringing a system back online
rests in the hands of the system owner and/or administrator. It should go without saying that if the eradication were not
complete, or the infection vector were not closed off, there stands a chance of reinfection. Monitor the systems closely
for the first few hours of operation to see if anything crops up that could be attributed to the original incident. Monitoring
will also help demonstrate to İhe organization the importance of an incident handling team, and the dedication of the team
members to ensure the problem is taken care of correctly.
After the system has been restored and is back in operation, a report outlining the entire process should be drafted by the
primary incident handler. It is important to summarize the incident, identifying the most relevant conclusions obtained to
aid in avoiding similar incidents in the future. The report should contain areas for improvement, both in the security
infrastructure and in the incident handling process itself. In addition, the report must point out new security actions or
projects identified during the incident and that must be implemented to increase the overall security of the IT
environment.
The goal should be to get consensus with everyone involved. After the report has been drafted, all members of the
incident handling team should meet for a "lessons learned" overview. The goal of this meeting is to come up with a list of
items that need to be included in the executive summary of the report. The executive summary should contain a brief
synopsis of the entire incident, including the steps taken to recover and recommendations made.
Conducting a follow-up meeting with all involved parties is never a fun task, but it is vital to making sure the
organization understands what happened, why it happened, and what steps were taken to make sure it doesn't happen
again. During every incident, mistakes occur and there is a tendency to place blame. However, the goal of the follow-up
meeting should be to improve the process and learn from the mistakes.
.)
)
)
ıNCıDENT HANDLıNG _ LEGALAsPEcTs
Criminal Law
. Fines and/or imprisonment (global challenge)
Civil Law
. Compensation for damage (compensatory, punitive, or statutory) or loss
Don't forget about the non-ICS regulations you might need to meet
. Regulations: Financial (GLBA), accounting (SOX), healthcare (HIPAA),
merchants (PCI)
' Reporting security breaches, cyber-insurance, international standards (ISO
z7ooı), policies
As you can imagine, the security professional needs to take many factors into account when reacting to an incident; for
exaınple, whether law enforcement should be advised, whether charges should be filed, or if a criminal offense has been
committed.
Criminal law was designed to protect the public from conduct considered in conflict with certain societal norms (for
exaınple, assault, murder, rape' fraud, and more recently, computer crime). Criminal law generally imposes fines, orders
the confiscation of assets (for example, the proceeds of crime, or "drug money") and/or may impose a period of
iınprisonment. In some countries, the death penalty may be imposed.
Certain acts may have both criminal and civil consequences. A drunk driver may be prosecuted for the crime of drunk
driving and sued by the victim for damages for her injuries. Computer crime laws, such as the US Computer Fraud and
Abuse Act, may contain both civil and criminal law penalties.
Computer crime has proven to be challenging for global law enforcement agencies, as the crimes are often anonymous,
hard to trace, and borderless. The criminals may reside in a jurisdiction with inadequate, if any, computer crime laws. As
a result, it may be impossible to extradite them. Some computer crimes may even fall between the cracks. The law
attempts, with limited suacess, to keep pace with evolving threats. For example, intemational treaties, such as the
Cybercrime Convention, attempt to ensure that signatories have similar computer crime laws and that intemational
cooperation is rendered more effective.
Civil law deals with adjudicating private disputes between parties, such as neighbors fighting over noise pollution. The
Law of Torts is the area of civil law that deals with many such disputes. A "tort" is simply "a civil wrong." The Law of
Negligence forms an integral part of ''Tort Law." Generally speaking, to be held accountable for negligence, a paıty must
owe ''a duty of care'' to the injured pağ; there must be a breach of that duty, and damage must follow as a result of the
breach.
Sometimes, in certain egregious cases, or where the law allows it, the damages awarded may be punitive in nafure; more
than is necessary to restore the injured party to the position they were in before the breach.
In the event of an attack-malware, Denial of Service, loss of system availability, or stolen information-it is important
to get legal advice to ascertain whether court orders can be obtained to try to trace and./or recover assets or get
compensation from a defendant. Determined insiders may try to move stolen assets offshore. Involving legal counsel
and law enforcement agencies in a timely manner may be of the essence in trying to recover them.
After the Enron scandal and other such financial and accounting scandals, many governments have adopted tough new
laws and regulations to try to prevent similar incidents occurring in the future. For example, the US Sarbanes-Oxley Act
(SOX) is legislation intended to reform the accounting practices, financial disclosures, and corporate govemance of
public companies. Certain regulated sectors, such as pharmaceutical, healthcare, and financial services, have always
been heavily regulated around the world because there is a greater potential for harm to the public if something goes
wrong. For example, the Food and Drug Administration (FDA) in the United States regulates the drug companies to
ensure that they only develop, market, and sell "safe" products to the public; and the US banking regulators, such as the
FDIC and the OCC, are required to protect the public and the safety and soundness of the banking system as a whole.
International regulators, such as the Bank of International Settlements (BIS), issue rules and guidance to member banks
(for example, The Basel Accord) to protect consumers and global financial markets.
In certain regulated Sectors, such as fiınancial services and healthcare, stafutes Such as the Health Insurance Portability
and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act (GLBA) may compel industry participants to adopt
security policies and procedures that include incident handling and business continuity planning. HIPAA protects health
insurance coverage, establishes national standards for electronic healthcare transactions, and addresses the security and
privacy of health data. GLBA requires that financial institutions ensure the security and confidentiality of customer
personal information against "reasonably foreseeable" internal or external threats.
There are modern regulations affecting generic sectors, such as merchants dealing with credit card information. The
Payment Card Industry @CI) Data Security Standard is an industry regulation developed by VISA, MasterCard, and
other bank card networks. It requires organizations that handle bank cards to conform to security standards and follow
certain requirements for testing and reporting.
Traditionally, senior management has been reluctant to report security breaches for fear of negative publicity and other
adverse consequences. However, certain laws in the United States, such as SBl386 in the state of California, mandate
that security breaches be reported to consumers in defined circumstances, usually where the exposed or lost data was
unencrypted. Under US SEC rules, public companies are under an obligation to report to regulators if an event occurs
that may impact the stock price.
If competitors or foreign govemments are implicated in an attack, counter-espionage laws may be relevant. Certain
countries, such as Canada, Australia, and the EU member countries, have strong privacy laws that contain securify-
relevant provisions that must be respected, Such aS the ''Ley org6nica de Protecciön de Datos de Car6cter Personal''
(LOPD), Personal Data Privacy Protection Law, available in Spain.
Investigations may also reveal illicit employee activity, such as the downloading and storage of illegal software, music,
videos, or pornography on company propeğ. Such activity may expose the company to liability anüor severe penalties.
Hence, strong email and computer usage policies are essential. All employees must be fully aware of what constitutes
appropriate behavior and be aware ofthe consequences ofnon-compliance.
An ICS compromise is difficult to deal with. The scenario is further complicated by the fact that few owner/operators
detect the compromise themselves but are rather notified by the government, a researcher, or a firm. Few environments
have the logging capabilities in place to effectively deal with incidents that happened in the past. This is especially true
for incidents that occurred longer in the past than the default log rollover period on most network devices (approximately
30 days). Further complicating the confusion is the fact that many IT/OT organizations have different leadership chains
and effective decision-making is completely inhibited. The skills necessary to make decisions that impact both the IT and
the ICS environment are possessed by few people in an organization and in some cases, lie only in the hands of the
incident responder, who is usually not well enough versed in the specifics of that environment to make the decision.
Another layer that further complicates the ICS IR world is the involvement of the government. It is nearly certain that the
ICS-CERT, the FBI, and potentially a federal regulating entity will be involved in the incident. It is critical to remember
that the asset owner/operator is still in control, even though it may not feel that way. The government has a perspective
on threats and attacks that few others can provide and this should be taken advantage of. However, they lack the
resources to effectively see breaches through to the end. It is highly advised that owner/operators call an expert to help
manage all aspects of the incident and to be the trusted advisor when working with the govemment. It is essential that this
expert be chosen and vetted before an incident occurs. Each of these problems cause delays in a process where time is of
the essence. Pre-emptive planning and regularly scheduled exercises can greatly increase efficiencies and make
management of these incidents far easier.
Many asset owner/operators are caught up in the media-driven attack 2.0 frenzy. Almost without fail, successful attacks
are based on tried and true methodologies, many dating back to the early 2000s that a greaİ number of ICS assets are still
vulnerable to. A return to the fundamentals of security is necessary to combat sophisticated attaçkers.
Plan, plan, plan: Create an IR plan that holds authority for the entire organization. Use attack trees. kill chains. and any
other decision criteria that fit yolır organization. The purpose of an IR plan is to put the porver in the hands of those who
can acfually resolve the incideııt. Repoı1iııg stıuctures aııd escalatiolls are Ilecessary and they shı-ıuld be well documented.
TEST YOUR PLAN OFTEN.
-]
-]
_)
-)
Spend the money: The security team members in nearly every organization can provide a list of 5-10 items that
) concern them right off the top of their heads. Responding to an event is far more costly than preventing one. Investing in
-) your infrasffucture is the cost of doing business and spending less money sooner beats spending more money later.
-) Be involved: There are many information sharing mechanisms available for those in the ICS world. Awareness goes a
-] long way; aıorganization that is aware of the threats and risks facing it from the operator all the way to the CEo is an
organization that will work together to resolve an incident.
)
) Lastly, you will be attacked. Your security team needs to have the tools and the training to quickly identifu the level of
the attack and whether it was targeted. When it comes to leaming these skills, there is no substitute for experience.
lnvest in your people.
'l
,)
)
)
)
._)
.,)
)
,_)
_)
)
_)
_)
)
)
)
@ 2019, Justin Searle 83
)
)
)
REGULAToRY EXAMPLE oF ıNcıDENT HANDLıNG
- personnel
. Roles and responsibilities of response
. Incident handling procedures
Test incident response plan every 1s months one of three ways
. Respond to actual reportable event
. Perform a tabletop exercise
. Perform an operational exercise
Update based on lessons learned
ıcs4|0 ı ıCyscADA Security Rsentials
',t
NERC CIP-008 contains a number of requirements for organizations to develop and implement an incident response
plan.
These requirements result in the development and implementation of a required plan with repoı1ing notifications to the E-
ISAC, which operates as one of the few ISACs with mandatory reporting requirements.
Incident response plans need to guide the Cyber Security Incident Response Team (CSIRT) on how to appropriately
identifu a suspicious event, classiff the event as an incident based on analysis, and respond to the incident in a manıer
that ensures focus on safety and reliability. Organization plans will likely go far beyond these three items identified in the
requirements and will include additional guidance for your teams to include direction on incident chain of command,
individual roles and responsibilities, procedures aligned with the various phases of incident handling, and follow-up
actions where appropriate.
Reference:
http://www.nerc.com./palstanüPages/ReliabilityStandardsUnitedStates.aspx?jurisdiction:United%20States
An example Advanced TTX with distributed play exercise is the NERC GridEx exercise. This exercise has been run a
number of times and has defined objective sets for each exercise, which differs from the previous event. The exercise is
open for all NERC registered entities, select government, vendors, and other limited third-party participation. The
exercise is facilitated by a contained exercise control team that deploys the injects and overall drill communications;
however, entity planners and players conduct the exercise at their normal place of work or in a large conference room at
their distributed facilities.
Each year, GridEx has grown in paı1icipation and exceed ed 364 participating organizations and more than 4,400 players
The Electricity Sector - Information Sharing and Analysis Center (ES-ISAC) conducts Cyber Risk Preparedness
Assessments (CRPA) of NERC Registered Entities, assessing entity capability and response to cybersecurity challenges.
The CRPA is designed to aSSeSS the cuırent cyber resiliency capabilities of bulk power System entities and the adequacy
of existing reliability mechanisms related to the unique nature of cyber threats. By conducting such an assessment, NERC
can focus on key improvement areas and also identify best practices (successes) to be shared with the industry.
The CRPA exercise is run as a facilitated TTX and the exercise scenarios are designed to enable the organization to
assess its preparedness based on the capability to:
Detect cyber attacks
Prevent cyber attacks
Respond to cyber attacks
Manage their electronic systems and electric power assets to minimize potential damage
Communicate and coordinate effectively with interconnected neighbors and reliability coordinators to contain the
impact to the BPS
Comınunicate and coordinate effectively with appropriate local and federal authorities
NERC ES-ISAC has an entity staı1er kit that enables organizations to run their own drills. This can be
found on the student USB
Six-Step Process
' Preparation, Identification, containment, Eradication, Recovery, Lessons
Learned
Tabletop Exercises (TTX)
. Benefits of exercises
. Basic exercise concepts
. Guidance and resources for building an exercise
Provided resource references for advanced hands-on exercise capability
and further student development
In this module, we learned the fulI process involved in incident handling. Always remember that for this process to be
successful, each step must be followed. The six steps that we learned are:
1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery
6. Lessons Learned
Keep in mind that at some point, an incident will occur in every organization. Take a deep breath when it happens and
take a level-headed methodical approach to resolving the situation. You and your organization will emerge stronger and
more prepared for the next incident.
--)
TAKEAWAYS AN D REcoM ME N DATıo Ns -l
'-t
-l
Section takeaways
. Preparation, Identification, Containment, Eradication, Recovery, Lessons
Learned
Recommendations to owner/operators l
Recommendations to vendors
' Provide a means for customers to interface with you during an incident
I
.)
)
)
,)
)
)
)
)
)
)
)
)
_)
)
)
*)
88 @ 2019, Justin Searle
)
)
_)
Course Roadmap z lcs
62443, ıso/ıEc 2700ı' NlsT csF
Day ı: ICS overview
3. ıcs Policies
Models
Day 5: ICS SecuriŞ Governance .MinimizingSubJectİvity
6. lncident Response
.Six Step Pnocess
7. Exercİse 5.lı lncident Response Tab|etop Exercİse
8. Final Thoughs and Next Steps
. Other ICS Courses by SANS
. ottıer SANS Curriculums and Courses
. Netwars
)
ExERcısE 5.I : ıNCıDENT REsPoNsE TABLETOP ExERcısE
DURATıoNTıı.!E: ].5 - 2 HoURs
We are going to break into groups and perform a tabletop exercise
'
The instructor will present the first phase of the scenario and a list of questions
. Each group will discuss the questions within their group
. The instructor will discuss the possible answers each group came up with
'
The instructor will then present the next phase of the scenario with more questions
oBJEcTıvEs PREPARATıoN
Tie together learnings of all 5 days of the Break yourselves into groups of4-8 people
course in a tabletop exercise
Move so you can sit as a group
Provide students with an increased
understanding ofhow to play and conduct a
tabletop exercise
For this exercise, the students can pair up or work in groups with similar focus areas (lT security, Sys Admins, Network
Admins, OT, Control Sys Engineers) and provide consolidated feedback to the instructor on the various injects. Consider
the talent and focus areas of your team members. In an acfual response, it is essential to have developed roles and
responsibilities of various members to allow for a coordinated response.
Remote students can work together via the chat capability, and on-demand students can document their thoughts before
moving on to the discussion components. If the class or the instructor prefers, students can work independently and
provide feedback as they are able.
The CSO (Chief Security Officer) of the organization calls an emergency meeting
During a recent security assessment, suspicious traffic was found
. From company's IP 66.99.59.249
. To suspicious actor's lP: zo4'5ı.g4.23g
. Using TCP port 443
. Traffic is occurring Monday to Thursday
. Only occurring between 9 PM EST to 4 AM EST
ıcs4l0ı ıcsl/sCADAs€<urityBsenthıs 9l
During a recent security assessment, suspicious traffic was found leaving the company's IP address 66.35.59.249 and
communicating with a suspicious lP at204.51.94.239.
Multiple connections have been identified Monday through Thursday this week; however, they strangely only occur
between the hours of 9 PM EST and 4 AM EST.
In many ICS organizations around the world, the local law enforcement and intelligence agencies will monitor known
malicious sites and notify organizations if they see communications from their environment. For many ICS organizations,
this will be the first piece of evidence they receive that a compromise exists within their environment.
How can we find out which computer in the company's network is generating that traffic?
How can we discover what data is being communicated in that traffic?
What other questions should we be asking based on the information provided?
Should we notify law enforcement?
Should we block traffic to this IP?
Should we declare a cybersecurity incident or is this just a single event?
What other actions should we be taking or recommending?
It is important to consider the actions you would be taking in response to events: The policies and procedures you would
use, who you would notif,ı, and who in your organization escalates the event and has the ability to declare an incident. It
is also important to always consider the actions an attacker took or the ability they have demonstrated based on the
evidence you are receiving.
The IT team attempts to capture the traffic; however, they find it is encrypted in a TLS tunnel and
not going through the web proxy
The IT team checks the NAT (NetworkAddress Translation) logs on the firewalls
' The company's IP 66.35.59.z49 is the main dyııamic NAT address for the entire company
. Identify multiple hosts communicating to the ma]icious site (zo4.5ı.94.z39)
. Originating from numerous geographic locations in a variety of subnets
. They do not store a history of any of the accepted traffic on the firewall
. They do not have a NetFlow co]lector or any other traffic history seıver
Traffic going to the internet using HTTPS is often teıminated thıough a web proxy allowing organizations to inspect and
regulate the traffic; however, this must be configured for each machine in the organization or in some other way forced
into the web proxy. It is common to deny all HTTPS traffic that does not go through the web proxy; however, this is not
always possible with all traffic, and exceptions are often made. Web proxies are also often a point of conceıı regarding
privacy since employees may be sending personal traffic through the business web proxy such as social networks or
banking sites, which further frustrates their use.
aJ \ o ^1-) )I
What could be generating this traffic from these three machines?
fi\\1 }ı4 q L (5Y6^
If it is malware, how could it have gotten there? f ı,u.9 \ e-9&{\,
Are there any significant correlations in regard to department, country, or OS? c (bcc<-'n ,
PuUU
What should we do with these machines? - rı.ı\ı
}a
. G( Ş. *6 c,/, {rı*\ t'rn)o
What other information should we be asking for? (ı f "1
t9L 1'nl
.ıı2- U.nl i
IT pulls all three machines and replaces them for the employees
' They discover your endpoint protection software was disabled on all three assets
. They perform forensics on two of the machines
' They place one in a sandboxed network with access to the internet for monitoring
Sometimes when machines are reinfected, it is useful to ask the employee a few questions:
Has the asset been used in other networks?
Has the user connected any removable media recently?
Has the eııployee installed any software?
Has soıneone else used the asset?
Have any new assets been conneçted to the device?
Many modern email servers such as Microsoft Exchange have the ability to determine which users have read ceıtain
emails, and can pull unread eııails from email clients before they are read.
I
How do you think the attackers got the emails for üese specific users? )
.)
)
)
_)
-)
)
.)
)
_)
)
J
_)
)
)
96 @ 2019, Justin Searle
)
)
_)
ExERcısE 5.l: ıNC|DENT REsPoNsETABLETOP ExERcısE
PHASE 4: LATERAL ı,lovEı.'ENT
You provide your endpoint security vendor with a sample of the malicious PDF
. Your own team starts to analyze the PDF in a sandboxed environment
' You immediately verifu it shuts down endpoint software and communicates with 2o4.Sr.g4.2gg
IT security discovers even more compromised machines
. Confirms that employees of these machines DID NOT receive the emails
. All are communicating with other IP addresses in the 2o4.St.g4.o f 24, not 2o4.Sr.g4.2gg
' There is no trace of the PDF on these machines, but logs show logon types 3, 4, 5, and ıo
Ilostname Countıy Operating Sl,stem
rd*w7_ı38D R&D Uıited Kingdom Windows 7
nwk-lr'3z-ooız Networking India Windows XP
eng_w7_9684 Engiıeering Germany Windows 7
nwk_zoo8-emaı Networking United States zoo8 Server
eng_w3z-763ı Netherlands Windows 7
Windows event logs keep a record of login attempts. Windows logon fypes:
Once an adversary has a foothold in a corporate network, there is traditionally a well-interconnected environment that
allows an attacker to ınove laterally throughout the environment froın asset to asset.
After the initial infection, attackers can use the Microsoft NET.EXE command and the AT.EXE command to
compromise multiple internal machines. Attackers often employ AT.EXE because, by default, scheduled tasks are run as
the local SYSTEM account. In addition to built-in command-line tools, attackers may use tools like Windows Credential
Editor (WCE) or ııimikatz to harvest credentials on local machines. They can then use these accounts to move laterally
throughout the network.
Ana|yzing nfuser.dat timestamps can be çorrelated with this intrusion activity to create a better timeline.
Use of network and directory service segmentation can be an excellent defense in limiting lateral moveınent or at the
least identifuing when it occurs.
Miınikatz is ''recover'' cleaıtext passwords from LSASS. Why would LSASS store credentials?! Enter Digest
a tool to
\ JÇ
Authentication and wdigest. wdigest is the cleartext password required to support HTTP Digest Authentication and other
schemes that require the authenticating pağ to kıow the password and not just the hash.
While Black Energy 3 is one of the newer backdoors being used in the ICS, Poison Ivy offers a similar device often
considered a tool for novice "script kiddies." According to experts, it has become a common feafure of cyber-espionage
campaigns.
The following article exceıpt provides a good gliınpse into the tool; "Research by malware protection firm FireEye has
revealed that the tool seıved as lynchpin of many sophisticated cyber attacks, including the compromise of RSA SecurID
data in 20l1 and the 'Nitro' assault against chemical ııakers, government offices, defense firms, and human rights
groups last year. A Peeping Tom webcam sextortionist has been jailed for six years in the US after targeting several
young women in attacks that relied on a modified version of Poison Ivy, an incident that shows that the tool has malicious
uses beyond cyber espionage. Poison Ivy remains popular and effective eight years after its original release."
Reference:
http ://www.theregister.co .uW 20 13 I 08 /27lpoison_ivy_r at_4ptl
\ıı'
\
Using your new IOCs, you identify a few more Active Directory Use6 and Compüte6
Virus Total is a free website that scans uploaded files with alarge number of different antivirus software and other threat
intelligence tools attempting to indicate if the file is malicious. Some threat agents actively monitor Virus Total to
identify if their custom malware is recognized as an indiçator that their tustom malware has been discovered, So care
should be given in using Virus Total if you are attempting to prevent the attacker from knowing you are on to them. You
should also be careful not to upload any file that is sensitive in nature as it releases your file into the public domain.
Consider group memberships access and user credentials and the impact it may have on ınethods of access; Web servers,
Citrix environments, VPN user group, remote access groups, wireless, and even dial-up. With this level of access, there is
no longer a need for inteııet-based command and control; however, it may still be pursued as a distractor.
.^ü)
What do you think üe attacker is trying to do wıtrıiıııs MSAI domain ,r..rı qd},,rf, s
ğ
,)
)
)
)
)
)
_)
.)
)
)
)
)
_)
)
J
102 @ 2019, Justin Searle
)
)
)
ExERcısE 5. !: ıNCıDENT REsPoNsETABLETOP ExERcısE
PHASE 7: STRANGE BEHAVıORONTHE HMı
ry
İğenaı Suıpcct ıo*ıaıı ı.öİıa^a
#m
. Minutes later, the HMI reboots 'rıİ'üı&
1*- l" I 'ü
ı6İİffi#n ffikffi""1
,"'*i .S*ffih
i"
l
*ar'- !
What is the likelihood that the HMI event is related to the incident? çı-'\"V\'
'
If there are no IOCs on the master historian, is there any way that an attacker could
compromise from read-only historian to master historian?
,.19'
6,.ı'ı {\r- a \n*^
Since the control network has been islanded from enterprise, how could he get in? ı\ is \c^''^-pt\z)
,.,ı ,'
What could be causing the strange behaüor on the HMI? (!\.,"rn bır ır^ıfna
9 ) /
Who could help us discover what went wrong on the HMI?
ıfn n}".
What other actions would you be taking or recommending?
Who would you be notifying?
ıCs4l0ııcs/sCADASecurityEssenthls l06
Upon testing, other HMI/PLC pairs at this facility showed the same behavior
. Vendors confirm the HMIs and PLCs have not been modified
. Network captures at HMI show different packets than captures at PLC
. MAC Addresses and network switch MAC tables point to a nearby engineering workstation
Engineers report this workstation is used by a vendor for remote access, but it is not on your maps
ed
coNcLUsıoN: CoMPRoMlSEDwoRKsTArıoN HAD ETTERCAP ıNSTALLED
G:ı
Advğgry usıng rmote
EE
IE
ö
I
n((ğs credstiaıs
Etter(ap ınstalled
192.ı68,1'20o
AÇ
192.ı68.L100
ı9ıı6&ı.5o
HMı
-ffi,İ';
,"""i
ı
i#ı xü;;
After gaining escalated privileges and access to the directory service administration, the adversary obtained credentials
for remote vendor support. The adversary then çonnected to the engineering workstation via RDP and installed Ettercap.
d
:ı
Adversry Usın8 affiote
E
Eııı
E t
&
acçeas cİedentials
Ettarcap lnstıll?d
]!1i1oü Pöistil
192.168,1,200
t Miıil]Arı] P0isoD
ö
clainı içı he^.']
19?-16lt 1'.n) cleiıı-.to b 192'168.1'toc
ııı
HMı
=
::;ı:;
ıEFı
ıcs4l0 ı ıcsilscADA Security Bsenth|s l09
Selecting the MITM ARP poison attack froın Ettercap, and entering in target asset l of 192168.l .l00 and target 2 of
192. 168. I .50, Ettercap then sends an Address Resolution Protocol (ARP) update to 192. 168. I . I 00 and says if you want to
talk to 192.168.1.50, communicate to this MAC Address (entering the MAC Address of 192.168.1.200, the engineering
workstation) and then performs the same to 192.168.1.50 by sending an ARP update stating that if you want to talk to
192.168.1.100, communicate to this MAC Address (again entering the MAC Address for 192.168.1.200, which is the
engineering workstation). This approach places the engineering workstation in the coınmunication path between the two
targets when they talk to each other but does not impact their capability to talk to other assets.
The attaçker can simply capture traffic in this position' modiflz traffic, generate traffic, or Stop the communication
altogether. Based on the repoıted events, it appears the attaçker did not modifu any traffic from the PLC to the HMI;
however, when an operator sent a control signal, the attacker modified it and caused an operational event.
Section takeaways
. Entry point identified
. Attack contained
. Access eradicated
. Facilities restarted
' More cleanup remains on the corporate networks, for IT to handle...
Recommendations to owner/operators
. Perform a similar tabletop exercise in your own organization
. Start small with your ICS Security team
. Include more departments on the second run
)
SANS RESOURCES
0 ,ü
'JıJ
cıl' ,-'Y aö ıi'ı'{
'
dn
ıCs4 ı0 ı ıcs/scADA Security Bseıtials ı 2
'
SANS conveniently hosts quite a bit of information that will be useful to any security practitioner. Some excellent
resources
. SANS Reading Room - http://www.sans.orglreading_room/
. SANS NewsBites - http://www.sans.org/newsletters/newsbites/
' SANS Security Policy Project - http://www.sans.org/security-resources/policies/
' SANS ICS Cybersecurity Poster - https://www.sans.org/media/industrial-control-systems/ics-target.pdf
. SANS ICS Community Forum signup page - https://ics-community.sans.org/signup
Legal
.
)
1+ course, ı+ certification
)
)
)
)
)
J
,)
,)
_)
)
)
)
)
)
)
J
)
114 @ 2019, Justin Searle J
)
)
NETWARS
The chart at right shows the progress of the top 10 players, while the bottom shows the current score and momentum
(green shows those moving up the charts, red shows downward momentum, and yellow means that they haven't changed
slots recently) ofthe top l0 players.
SANS NetWars support finding people with information security aptitude, skills, and experience. They also provide
oppoıtunities for continual skill development in multiple disciplines in a fun and engaging fashion. NetWars' in
particular, provides in-depth scenarios so that participants can directly demonstrate their capabilities and includes a
scorecard showing areas for additional skill development.
"'We were very impressed with SANS NetWars. The material is relevant and educational, and the tournament style play is
remarkably engaging. I really like the scoring system and scoreboard."
Tice, Lockheed Center for Cyber Security
-Adam
Reference:
https ://www. sans. org/netwars
sANs ıNSTıTUTE
l 1200 Roclçille Pike, Suke 2@
N. Bethesda MD 20852
30t.6s4.sANS(7264
A
As/ı 3:24
Aardvark z:25-26
ABB t:8, 1;22, 2;9o' 3i43, 3:5z, 4:8, 4:ı5ı
Access Control Lists (ACLs) 1: 133, t:ıg6, 2ig3, 2ilo5, z:ı38, 4:4ı
ACK z''ıı6,3:76
Active Directory L:L34' ı:ı36, L:l4o' 3:53, 3:98, 3:L45,4i23'
4:Bo, 4:Bg, 4iBS36, 4:gg, 4:Lo7, S: 1o1
Advanced Encryption Standard (AES) g;Lg, g;22-29, B:25, 3;28, 3; 4o, 3:44,
3:48,3:5o,3:53
Advanced Security Acceleration Project l:2,2ilr 3:1, 4:1, 5:1
for the Smart crid (ASAP-SG)
Advantech 3:98
Aegis z:38-99
Agile Software Development 5i6
AirPort 1:23,2:54
alarm ı;4o, ı:65-66, ı;69, |:73-75, ı;77, ı:83,
1:1o9-11o, 1:119, |:|23' ı:ı36-ı37, Lil44'
z:94, z;96, 2:L28, 2iLgS,S 1o4-1o5, 4:r2r,
:
lndex-1
t:rrg, Lit2B, Litg6-tBT, Lir44, 2:8, 2:ro,
2i55' 2:94' z:96, z:ız8' 2:L35' 3:gg, 9:64,
3:1O4-1O5, 3:1O9, 4iL4, 4:24, 4:4O, 4:74,
4|L2o-L2L' 4:L24' 4;ız8, 5:44, 5:57 -58,
Si7t, S:78,5:8r, 5:99, b:1oB
ARP Spoofing 2:1Lo, z:ı45,3:6
Asset Management (ID.AM) 2:7O,5:g-7O
asymmetric algorithm 3:22,3:30
attack model 2i7
Attack surfaces zi7, 2:9, 212c, z:28, 4: 184-135
AUDITPOL.EXE 4:10O
Auüentication Bypass 3:1O9, 3:129-130, 4:L46
Authentication Header (AH) 2iLIT
Automatic Generation Control (AGC) ı:85
AVR rito7
Awareness and Training (PR.AT) 5:9,5:11
lndex-2
Bus Pirate z:zg-z6,z;38
Business Continuity (BC) ı:9, 5:z8-z9, 5:42-43, 5:45-46,5:48, 5:8ı.
Business Continuiğ Planning (BCP) S:48, Si4S-48, 5:5r, 5:8r
Business Enüronment (ID.BE) 5:9-10
Business Impact Analysis (BIA) 5:29,5:42,5:47
c
C-Band (+-8GHz) 3:39-40
Carrier Sense Multiple Access/Collision 2:103
Detection (CSMA/CD)
CDMA 3:37-38
Cellular backhaul 3:38
centralized logging 411,O7
CFATS 1:109
Chemical Facility Anti-Terrorism L:109
Standards (CFATS)
chkconfig 4:64
chown 4:6ı
chroot0 4:76
CIMPLICITY 3:98
CIP-ooz 5:37,5:60
CIP-oo9 5:37,5:48,5:5o
CIS CSC 2i5, 2:L9, 2i33, 2i49, 2:tO2, 2:14L, 3:5,
3:r8, 3:36, 3:96,3:79, g:1o2, B:12S, 3:r38,
4:5, 4i22, 4:52, 4;To, 4:96, 4:1L8, 4:L22,
5:ı-9,5:53,5:63
Cisco 2:6,2:|og,4:7ı,4:8o
Closed-Circuit TeleVision (CCTV) ı:74, t:ıı9,5;58
cmdlet 4:Bg, 4:44, 4i46-49, 4:79
COBIT 5 2:5, 2;Lg, 2:gB, z; 49, 2;82, 2:1C.2, 2:14r,
3:5, 3:ı8, 3:36, 3:56, 3:7g' 3iLo2' 3il25,
3:138, 4;5, 4:22, 4i52, 4:7o, 4:96, 4:Lt8,
4:L32'5:5, 5:19, 5:4ı, 5:53, 5:63
Command and Control (C&C) 5:101
Common Industrial Protocol (CIP) t:5, L:22, l:24, 2;2, z:63-64 r 2:r2L, 2:t82,
3:2, 3;t46, 4:2, 5;2, 5:34-35, 5i37-39,
5:48, 5:5O, 5:6O, 5:84
Common Vulnerability Scoring System z:ı5-ı6, 4:9, 5:54
(cvss)
Comnıoıı Wealrrıcss Eııuııreratioıı (CWE) 2i13, t:15,4:9
Communication Robustness Testing z:89
lndex-3
(CRT)
Communications of üeACM (CACM) 3:29
Comodo 4t7r
Compact Flash (CF) 2i20
CONFIG-RT_PREEMPT z:56
Containment 5:64,5:73-74,5:87-88
ContingencyAnalysis ı:75,ı:8ı,ı:ıg6
continuous ı:ı5, r:ı8-ı9, ı:8o,2:63,
1:31, 1:38, 1:5o,
2:132' 5:6, 5:9, 5:12, 5:35-36, 5:ır5
ControlNet 2:132
Counter-Mode/CBC-MAC Protocol 3:48,3:53
(ccMP)
Critical Infrastructure (CI) 1:3, 1:5, t"7, l:24, LiLaO, 1:].25, 2:2, 2:6,
2:l4' 2:|6,3|2,3i7o' 3:ıo6, 4i2' 4i|4'
4iL6-r7, S:2, S:g, S:34-35, S:113
Cross Site Request Forgery (CSRF) 3iL29,3:133-134
Cross Site Request Forgery (XSRF) 3:129,3:134
Cross Site Scripüng (XSS) 2:22' 3:L29, 3:133, 4:ı46
CrowdStrike 4:7r
Cryptographic Keys z:24, 2:26, 2:28, 2:gL, gt2o-2l
Cyber Risk Preparedness Assessments s:86
(cRPA)
ğber Security Incident Response Team 4:8, 4;ı4-ı5, 5:84
(CSIRT)
Cylance L:3, 2:2, 3:2, 4:2, 417L, 5:2
D
Data Breach Investigations Report 5t7r
(DBrR)
Data diode 1:1o9, 1:133, 2:138, 3:6, 3:ro-ı5, 3:1o3
Data Encryption Standard (DES) 3"22-23,3:25,3:4O
Data Link Connection Identifier (DLCI) 2|LO9
data link layer 2:6L, 2:65, z:67, z:ıo8-ıog
Data Security (PR.DS) 2i5o' 5:9' 5:ır, 5:8ı
DCOM/RPC z:r35,3:89
debugger 2:54
decision tree 4:LO
Decıytrıtion 2:143, 3:23-24, 3:28-Zg, 3:57
Defense-in-Depth 3i7,4:124,5:7
D eMilitariz ed Zane (D MZ) 1:130-131, 1:133, r:ı35-136, 1:14o, 2:8,
3:1o3, 3:ıo6, 3:1o8, 3:ıı6, 4:go, 4ilLg'
lndex-4
4:142,5t10l
Denial of Service (DoS) 2|2O, 2:3O, 2"59, 2:93, 2:144, 3:9, 3i57,
3:59, 3:62, 3:64-65, B;7o, 3i96, 4;9, 4;146,
4:749,5:4z,5:8ı
Department of Energ5ı (DoE) z:39, 4;ı8, 4:ı47, 5:64
Department of Homeland Security (DHS) li3, 7"22, lt24, t:7O, 1:113, t1725, 2:2, 2:t3,
z:39, z:84-85, 3:2, 4i2, 4:|o-|ı, 4:ı6, 4:ı8,
5"2
Derivative Term 1:35
Detection Processes (DE.DP) 5i9,5:r2
DeüceNet ı:74,z:64,2iL32
df 3:92,4:58-59
Diffie-Hellman 3:ZZ-23,3:28
Digital I/O l:4o,2:154
Digital Protective Relay (DPR) r:42
Digital Signatures z:ı38, g:Lg, 3:22-z3, 3:z8_3o
diode 1:1o9, 1:133, z:ı38, 3:6, 3:ıo-ı5, 3:1o3
Direct Sequence Spread Spectrum (DSSS) 3:46
Disaster Recovery (DR) r:1t4, 4:L9, 5:3, 5i4L-42, 5:45,5i47-48,
5:5ı,5:67,5:8z
Disaster Recovery Planning (DRP) 5i43,5:47
discrete ı:ı5-ı6, 1:19, 1:33, ı:4o, ı:8o, z:63, z"79,
2i132,3:22,5:12
disk free 4:58-59
Distributed Control System (DCS) 1:4, 1:31-33, |:76, r:8z, ı:85-8 6, |:|l.2,
1:131, 1: 138, t:r42-]..45, Z:93-94, 3:89,
3:ıo6,4;z6
Distributed Network Protocol (DNP) 2:27,2:g8, z:6z, z:ız8-729' 2;L33' 2iL37'
3:6,3:ı3,3:99
Distributed Network Protocol (DNP3) 2:L33
DNPs 2:2L,2:g8, z:6z, z:ız8-l29' 2;L33' 2iL37,
3:6,3:13,3:99
DNP3v5 2:2L
DNS Spoofing 2"tLO
Docker 4:76
Dragonfly 3:96
drivers 1:1, 1:13, r:47,1:9O, tito4, t:114, 2i5O,
2:73, 4:25-26, 4; 56, 4: 1O1, 5:39
DROP L:4r, L:82, r;g7, rir2r,2:1C,4,3:8-9, 3:rz,
3;ı4, 3:ı6, 3: 4o, 3; 59, 3: 6z-63, 3:66,
3:154, 4: 8z-83, 4:89, 4:9o-9r, 4i93-94,
4:LO3,5:rO6
lndex-S
E
lndex-6
EüerNet/IP z:62-63, 2:92, 2:t2L, 2;L28-t29, z:t1z
EtherNet/IP-CIP 2:l2l
European Programme for Criücal Li24
Infrastructure Protection (EPCIP)
European Union Agency for Network and 1"22,4:t5
Information Security (ENISA)
Event Log r:68, 3:ro5, gtro7, 4:3, 4:96-9T, 4:LoB,
4:ııı-ıı6,5|97' 5:Lo6
Event Viewer 4:97-98, 4:Lo3, ;LLI-LIB, ;Lrs
Exponentiation 3:28
Exposure Factor (EF) 4:75,5:56
Extensible Authentication Protocol (EAP) 3:53,3:64
F-Secure 4:7L
Facilities |:22-23' 1:LL2' ı: ıı8-120, z:L6, 2:156,
3:9O, 3t92, 3:99, 3: 1O5, 4:tO6, 5: 10-11,
5:49, 5:6o, 5:69, 5:73,5:85, 5:ro5, S:11o
Factorization 3:28
Factory Acceptance Test (FAT) r:Lr2-rr1, 1 : 11S, ril44, z:84, z:87
Federal Drug Administration (FDA) z:9ı,5:8ı
Federal Energy Regulatory Commission |i22, |:Log' 5:3ı, 5:36, 5:56
(FERC)
FieldComm Group 2"r29
File Replication Service (FRS) 4:4t,4:97
File Transfer Protocol (F-fP) z:zo,2;|o8, 3:88, 3:L|2, 4:76, 4:ı39
FIN z:ıı6
find 2|9,2:39' 3:8o, 3:rr4, 4:46, 4:54, 4:6ı,
4:63,4:8ı,4iL37
FIPS PUB 180-1 3:26
FIPS PUB 180-2 3:26
FireEye 2:6,2;99, 4:7r, Sigg
Firewall Builder 4:80
firmware L:22, Li37, LiL25, 2i2O, 2'.22, 2:24, 2:26,
z:28-29, 2:Bt, 2;Bg, 2i47, z;So-SL, 2i7o,
2:73,2;Loo, B:24,3:53, 3:65, g:99, g:1oS,
3:127,5:77
Fortinet 4t7r
Forward Error Correcüon 3:39
Fraıırework Iırıpleırreırtatioır Tiers 5:15
Front End Processor (FEP) ı:83, z:3o, z:68, z:ı3o 2;L33-L34
'
lndex-7
Front-End Processor (FEP) 1:83, z:3o, z:68, z:ı3o 2:L33-I34
'
FullyQualified Domain Name (FQDN) z:LO9
Function Block Diagram (FBD) r:37
Functional Safety 2i97
Fuzzing 2:22, 2:63, z:ı47-ı48, 3:3, 3:119, 3:rz8,
3:147,3:ı49-ı56
Fızzy Lo$c 1:36
G
Global Naügation Satellite System z:57-58
(GNSS)
Global Positioning System (GPS) z:57-58'3:4ı
GNU Radio z:38,3:6r
GoodFET z:25-26
Google hacking 4:133,4:36
Googlebot 4:L33
Governance (ID.GV) 1:106, S:1, 5:9-1o, 5:3o, 5:32, 5:8r
Government Communicaüons 3:29
Headquarters (GCHQ)
Gramm-Leach-Bliley Act (GLBA) 5:8o-8ı.
grep 4146,4:6L,4:65
Group Policy Object (cPO) 4133,4i35,4:4L,4ILOO
GSM g:24,3:87-38,3:63-64
H
HART Ii37' L:4t, z:64-65, z:ız8-ızg,3:37' g:42-
47,3:LO5,4:55, 5:115
HART Communication Foundation 2i129,3:45
HART Communication Foundation (HCF) 2:129,3:45
TIART-IP z:ız8-ız9
Hashed Message Authenticity Check 3:26-27,9:3o, 3:S3
(HMAC)
Havex 3i96-99
HAZar d and O Perability (IIAZOP) 1:1O5, 2:97r 2itOO
Hazar d Op erations (HAZOP) 1:105, 2:97,2:LOO
Health Insurance Portability and 5:8o-8ı
Accountability Act ( HI PAA)
Hear[Lıleetl 3:31
hidden-key-raw 2:42,2:44-45
I
lndex-8
l
High Voltage Protection (HVP) 3:37
Highway Addressable Remote Transducer ı: 4ı, z: 6 4_6 5, z:ız8-ız9, 3: 43, 3: 45- 46
(HARr)
historian 1:2o' L:49' ı:65-66, ı:68, ı;77, Liı-I
'
|:136-L37' |:|44' z:58, z:ız8, 2:135, 3:3,
3:6, 3:ı3, 3:19' 3:1o2-1o3, 3:105-106,
3:1o8-1o9, 3:t|6-Ll7,3:ı35-136, 4:1o8,
5:58, 5:99, 5:1O1-1O4
Hitachi li22
HMAC-MDs 3:26-27
HoneyNet 4:r22-r23
honey1ıot 3igg, 4:3, 4:ıı8-ızz, 4:|24-L3o, 4|t47-L48
Honeypot 3:9g, 4:g, 4:||8-122, 4:l24-|3o' 4:ı47-ı48
Honeywell Li22,2:93,3:47, 4zL5L
Honeywell Safeğ System Firewall 2i93
Host IDentifier (HOST_ID) ziLO9
Human Machine Interface (HMI) |:4' |;2o, |:22' 7;37' r:33, r: 65-67, ı:69,
7i73, |;77, r: 8z, ı: 89-r o\ tI37' L:|44' 2i9'
2"21, 2:3O, 2:73, 2:1-].}, 2:L28, 2:130,
2:1gB-l3S, 3:3, 3:6, Bitg, B:87,3:SL,3i7o,
3:8o-8r, 3:98, 3:105-ro6, 3:rr9, 3:12S-
r29, 3tr33-r34, 3:t36, 3: 139, 3:144, 3:149,
4:25, 4:27-28, 4;77, 4;L94, 4tr41-t48,
5:58, 5:99, S:1og-1o5, S:to7,S:1o9
hybrid 1:15, 1:19, 2:lO7
Hyper Text Transfer Protocol Secure 2:1o8, 2;142,9:L12, 4:3o, 4:83, 4:92,
(HrrPS) 4:139,5i93
Hyper-V 4124
HyperText Transfer Protocol (HT'IP) 2:38, 2:1O8, 3:72, 3;74, 3ttr2, g:126,
3:131, 3ir34, 3:149, 3:151-152, 4"24, 4:92,
4:|33, 4:|39, 4:ı48-ı49, 5:99
ICPMv6 4:85
ICS-CERT ı:7o, L:L26,2:t3-l6' z:84, z:88, z;99,
2:|35' 3:3ı, 4:7-8, 4iL3, 4:ı6, 4;ı8, 4il46'
5:82
Idaho National Laboratory (INL) z:85,4:ı8
Identification z:ı4, z:89,2i97' 2;L13, 3İ51, 3:92, 4:7'
4i29' 4; L4L, 5:60, 5:64, 5:7 ı-72, 5i74,
S:87-88, S:99
lndex-9
IEC 6o87o 2:133' z:ı36, z:ı.38
IEC 615o8 2tg6-97
IEC 6ı5rr z:96
IEC 6ı5ı3 z:96
IEC 6185o z:64, z:ıo7, 2:728, 2||34' 2: 138
IEC 61968 z:ı38
IEC 6ı97o z:ı38
IEC 6zo6r z:96
IEC 6235r z:r38
IEC6z4zg 2t96
IEC6z443 1:20, 1:13J, 2:5, 2:3J, z:89-9o, 2:1oo, 3:S,
3:ı2, 3:ı8, 3:36, 3:56, 3:1o2, 3:|25'3:r38,
4:5' 4:22' 4:52' 4:7o' 4:96,4:ıı8' 4il32'
5:5,5:8, SiL7, S:rg, S:84, Si4t,5:53, 5:63
IEC 6259r 3i43
IEC-62443 z:89,9:57
IEEE z:63, z:65, 2: Lo3, 2:1C,9, 2iLrB, 2:L28,
2:133, 3i29, 3:37, 3: 44, 3: 46-48, 3: 52- 53,
3t64
IEEE 8o2.r5.4 3:44,3:46-48
IEEE 8oz.ıX 3:64
Improvements (RC.IM) 7:rrL, S:L44, 4:26,5:9, S:t3-L4, S:35, S:42
Improvements (RS.IM) Liltr, B:L44,4:26, S:9, S:r3-r4, S:BS, Si42
Incident Handling 3:7, 5:64-65, 5:67-68, 5:7L-75, 5:77-8ı,
5:84,5:87
Independent System Operator (ISO) ı: 42, l:8ı, 2i 5, 2:|g' 2i33' 2: 49, 2:6l', 2:82,
z:96, z:ıoz,2:tg6,2:L4L' g:5, g:ı8, g:7g,
3:1o2, 3:12S, 3:138, 4tS, 4:22, 4t52, 4:7o,
4:96,4:ıı8' 4i|32' 5:5,5:8, 5:L7' si:ıg'
S:27 -zg, 5i41, SiSg, 5: 63, 5 : 8o
Indicators of Compromise (IOC) 4:38,5:1OO
Industrial Control Systems ğber 4iL6
Emergency Response Team (ICS-CERT)
Information Protection Processes and 5:9' 5:11
Procedures (PR.IP)
Input/Output (I/O) ı:39, ı:8z, z:87, z:ızg, 4:74
Insecure Storage 4:ı46
Instrucüon List (IL) 1|37,4:t4
Integral Term 1:35
Intelligent Electronic Devices (IED) L:42-43, ı:82, 2:68, 2igo, 2i|3o, 2: 133-
134
Iııter-Coırtrol Ceııter C<ımmunications r:8r, z:ız8, 2:136, 3:13
Protocol (ICCP)
lndex-10
Interface Identifi caüon 2:LLs
International Data Encryption Algorithm 3:L9,3:22-23
(rDEA)
International Electrotechnical t:2o r It37, 1: 133, 2:5, 2:tg, 2:33, 2249,
Commission (IEC) z:64-65, z:82, z:89-go, 2:96-97, 2: 1oo,
2i1o2' 2i|o7' 2:ı28, 2: L33-|36' z ı38, :
lndex-11
IPSec z:63, z:ııı, 3;7' 3i4o, 4i23-24, 4: 15o
IPSec NAT traversal 4:L50
iptables 4:8o-84, 4:88-94
IPv4 2: 1o8, 2;rLt-rLB, 2:r1S, 2ir21, 4:84-85
IPv6 z:63, z:ıo8 2:Lll^,2:113-115, 2|LL7' 3:45-
'
47,4:83-85
ISA Security Compliance Institute (ISCI) z:89
ISA SP-gq 3iL2
T3A-62443 1:13
ISAıoo 3:37,3i42,3t45-47
ISAıoo.ııa 3:37,3:42,3t45-47
ISAgg z:89-9o
ISO z6z6z z:96
ISo z7ooı 5:8, 5:ı7, 5:z7-z9, 5:8o
t
jail0 4:76
John the Ripper 3ir79,3i749,3i154
K
Ka-Band (26.5-4oGHz) 3139-40
Kali 2:34
Kaspersky Lab 3:95,3:99,4i7L
Kerberos 3iL45,4i23-24,4:39
Key Reinstallation Attack (KRACK) 3:53
Keyspace 3:20
kill 4:6ı,5:8z
killall 4:6ı
Ku-Band (rz-ı8GHz) 3:39-40
L
Ladder Diagram (LD) Li37
Layer z Tunneling Protocol (LzTP) 4:150
Layers of Protection Analysis (LOPA) 1:1O5,5:57
LDAP ı:ı36, 3;L45' 4:24
Lessons Learned a:85, 5:r3-t4, Siz7, g:5o, g:64, 5:7o, 5:78-
79, S:82,5:84, 5:87-88
Level o lizo, L:25' ı:76, ı;tz7,1:133, ı:ı38-ı39,
lndex-12
2:8, z:19-2o, zi49, 2;7o, 2:82, 2;gz, 2;LLg,
2:128, 4:64, 4:77, 4:86, g:57-58
Level ı L:rg-2o, L:29, L:76, 1:193, 1:1S8, 2iLLg,
2;ız8,3:127' 5:57-58
Level z Li2o, Li25' ı:66, ı:73, |:76' L:L33,1:136-
137, LIL O, 2:93, 2;t28, 2iLg5, 3i3, 3;79,
3:8ı, 3:ıo6, 3;t26, 4:3o, 5:57-58
Level 3 ||2o' |;25' ı:66, ı;74, ı:76, ı:8o, ı;87,
r:to7, 1:133, r:t35-r37, 1:139-140, 3:1OO,
3:106, 3:1o8, 3:116, 3:ız6, 4;2o, 4;3o'
4:64, 4:86, 4:142,S:S7-b8
Level 4 t:2o, r:25,1:tgg-135, 3:ro8, 4:64, S:ST-SB
Line of Sight (LOS) 3:39
Local File Inclusion (LFI) 3:129,3:135
Local Security Policy 4:33,4:rr4
locate 3:65,3:88,4:6ı
Logarithm 3:28
IonWorks r|74
low-level machine code r:37
LTE 33738
rxc/rxD 4:76
Lynis 4:66
lndex-13
,)
)
mbtget 2:38, 2:151,2i153-L57
McAfee L:2, 2|1, 3:1, 4:t, 4:7L, 4:107, sil
MDs gitg, B:22, gt26-27
Media Access Control (MAC) 2i92, 2it03-to4, 2it0g-111, 2:113, 2:142,
g:22, 9i27, 3:38, 3: 44, 3: 46-49, g:St, g:57,
3:59, 3;6ı, 3:64, 4:7 4, 4:85, 5:ıo7, 5:1o9
Merkle 3:29
Message Digest z (MDz) 3i26
messages log 4:LO4-705
Metasploit r:LL2, z:94,3:64, g:7o, g:tr1, 4:L4o
microkernel 2t52-54
Microsoft 2:S3, 2:SS, 2:195, g:88-84,3:99, 3:14S,
4tS, 4ir2-r3, 4:22-26, 4;283L, 4 3g-3S, :
lndex-14
Communications Integration Center
(NCCTC)
National ğbersecurity and z:ı3, z:99,4;ı6
Communications Integration Center
(NCCTC)
Naüonal Electric Sector Cybersecurity L"2, 2:1, 2"37, 2|39, 3:L, 4|L, 5:1
Organization Resources (NESCOR)
National Institute of Standards and L|2' |i|4, 7|22, l:33' ı:73, ı;76, ı:84, ı:ı31,
Technology (NIST) 2:1, 2:5, 2:L9, 2:33, 2:37, 2:39, 2:49, 2:59,
z:8z, z;ıoz,2:ı.4l^,3:1, 3:5, 3:18, 3:26,
886, gi16,3;79, B;to2, B;L25,3:138, 4:1,
4iS, 4:22, 4;94, 4i52, 4;7o, 4:96,4:118,
4:|32' 5:1, 5:5, 5:8-ı7, 5:19, 5i34' 5:4|,
5:53,5:63
National Security Agency (NSA) l|3, 2"2, 3|2, 3i29, 4i2, 5:2
National Technical Research Organisation l:24
(NrRO)
National Vulnerability Database (NVD) 2:L3
Neighbor Discovery Protocol (NDP) 4:85
NERC Critical Infrastructure Protection 5:34
Standards (NERC CIP)
NERC EOP-oo8 5:48-49
Netcat 2i153,2t157
netstat 4:6ı,4:89,5:|o7
Network Access Control (NAC) 2iLO6,4:23-24
Network IDentifi er (NET_ID) 2:lo9
Network Intrusion Detecfion System 1:133, Z:r3O,3:6
(NrDS)
network layer z:6ı, z:67, z:ro8-ıo9, 2:|L5, z:ı4z,3;46
Network Load Balancing (NLB) 4:24
Network Prefix 2:113
Network Time Protocol (NTP) 2i57-59,2:108
nftables 4:8o,4:84-85
NIST CSF 2:5, 2itg, 2:83, z:49, z;82, z:toz, 2:ı.4L,
3:5, 3:18, 3:36, 3:56, 3i79,3:tO2,3:t25,
3:138, 4:5, 4:22, 4i52, 4i7O, 4:96, 4:LL8,
4;L32, 5:5, 5:8-ı5, 5iL7, 5:t9' 5i4l, 5i53'
5:63
NIST SP 8oo-53 2:5, 2:Lg, 2ig1, 2:49, z;82, 2:Lo2, 2:r4L,
3:5, 3: 18,
336, 3:56, 3i79, 3"1C2, 3"125,
3:198, 4;5, 4:22, 4;52, 4;7o, 4:96, 4irr8,
4:132,5:5, 5:19, 5:4r, 5:53, 5:63
NIST SP 8oo-82 l:14
lndex-l5
NIST SPSoo-82 ı:73, ı:76, ı:84, ı:ıgı, z:g7
nmap z:38, 4:88-89, 4:9ı-gz, 4:|33, 4il37-]-3g'
4:t43,4:149
Nmap z:38, 4:88-89, 4:9ı-9z, 4:133, 4i137-l3g'
4:143,4:L49
Nmap Scripting Engine (NSE) 4:L37
non-routable IP 2:tL2
Norü American Electric Reliability L:3, l:22, 1:1O9, 2i2, 2i39, 3i2, 3;t46, 4i2,
Coıporaüon (NERC) St2, 5:54-99, 5:48-5o, 5:57, 5:6o, 5:84-86,
5:113
o
Object Linking and Embedding (OLE) z:ı35,3:96
Object Linking and Embedding for z:9z, z;ız8, 2:135, 2:L47, 3:6, 3:ı3, 3:96-
Process Control (OPC) 98,3:103, 3:Lo7' 3:115, g:ız6
Open DeviceNet Vendors Association 2:t32
(oDVA)
Open Systems Interconnect (OSI) r:68, z 6o- 6ı, z:66-67, 2|93, 2:Lo4'
: 2: 1o8,
2:|32, 2:142' 3:6, 3:44, 3:ıo7, 4:84
OpenVPN 4:r50
Out of Band (OOB) 3:23,3:50
Over-The-Air (OTA) 3:46
lndex-16
4ir34,5i95
physical layer z:6ı,z:65
PIC LiroT
pn_rt 2:125
Point-to-Point Tunneling Protocol (PPTP) 4:r50
POWERLINK z:62, z:64
PowerPC LitoT
PowerShell 4:3, 4:23-24, 4:37, 4:39-47, 4:44-50, 417 5,
4:79, 4:r0r-r02, 4"rr5
Precision Time Protocol (PTP) 2i57-58
Preparation 4:Lo2, 5:64-65, 5:67, 5:87-88
presentaüon layer z:6ı,z:ı4z
Presidential Policy Directive zr (PPD-zr) I:24
Preğ Good Privacy (PGP) 3:4o,3:88,4:8
Process Control System (PCS) 1:19, L"73, LilO
Process Hazard Analysis (PHA) ı.:1o5, 2:97,2|Loo
Process ID (PID) L:34-35,4:89, 5:ıo
process model 1:15, 1:19
Process Variable (PV) ı:34, ı:36
PROFIBUS Iı74,2:62, z:64-65, z:68, z;ı3ı, 4:7
PROFINET z:6z-65, 2;|o7' 2;|2|' z:ız8-ızg, 2;I3|'
4:7
ProfiNet z:62-69, 2iro7, 2;r2r, 2:L28-L29, 2ir1r,
4t7
Programmable Logic Controller (PLC) t:7, L"4, t:22, L:3L, L"33, Lt37, L"39, L:45-
63, ı:73, ı:76, ı:8z, l:85, ı:89-9:^, I:gg,
t:to7,1:198, 2;2o-2L, z:zg, z:66-67, z:72-
76, z:79, z:96, z:ııo,2:|3o' 2:|33-|34,
3:6,3:7o, 8:75-76, 4177, 4:t46, 4:L49,
5:58, 5:99, StLoS-ro7,S: 1o9
Project SHINE 4iL39
Proof-Of-Concept (PoC) 2i29
Proportional Term 1:35
Protective Technology (PR. PT) 5:9,5:11
ps 4:45,4:6ı
Purdue Enterprise Reference Architecture l:20
(PERA)
pwd z:39,4:6ı
a
QNX 2:51-53
lndex-I7
Quality of Service (QOS) 2:trt,3:39,3:46
Quality of Service (QoS) z:63,3:39,3:46
Quanütative Risk Analysis (QRA) 1:1O5,5:54
lndex-18
Rockwell Automation ı:8, ı;zz, 4;ı5ı
RS-z3z r:4r,r:82,2:2o
RS-4zz r:4r
RS-+8S ı:4ı,ı:8z
RSA 1:3, 1:11O, 2i2, 2"23, 2i38, 2:42, 2i62,
z:67, z:89, 2;gg, 2:t23, 2;144, 3;2, 3:7,
3:ı6,3;ı9,3:22' 3:27' 3:38-39, 3:4ı, 3:58,
3:6ı, 3:76, 3:88, 3:98-99' 3:107' 3|752'
4"2, 4:LO4, 4;134, 4;137, 4"r5O, 5"2, 5:6,
S:BS, S:7r, 5:98-99, 5:ro8
runlevel 4:64-65
s
57 Comm 21721
sTcomm 2|r25
Safety Instrumented Function (SIF) z:95,5:58
SafeŞ Instrumented System (SIS) ı:3z, ı:86, 2:93-97, 2:99-Loo, 3;6, 3:ız,
5:58,5:ıo5-ro6
Safety Integrity Levels (SILs) 2:97
Saleae Logic Analyzer 2:38
Samurai Security Testing Framework for I"2,2:lr 3il, 4:1, 5:l
Utilities (SamuraiSTFU)
Samurai Web Testing Framework L:2, 2:L, 2:34, 3:1, 4:1, 5:L
(SamuraiWTF)
Sandia National Laboratories (SNL) 4:18
SCADA HoneyNet 4iL22
SCALANCE 56oz 2:93
Schneider Electric L:22, L:7r, 2:99, 3:47, 4:151
Schneider Electric (Citect) L:22, l:71, 2i99, 3: 47, 4|t5l
secedit.exe 4:33
Secure File Transfer Protocol (SF tP) 3:112
Secure Hash Algorithm (SHA) Birg, B;22, 3:26-27, 3:53
Secure Hash Standard (SHS) 3:26
Secure SHell (SSH) z;63, z:ıo8' 2:L42' 3:4o, 3:112, 4;62,4|76-
72, 4i88, 4tto7, 4:t1g,4:1So
Secure Simple Pairing (SSP) 3:50
Security Conünuous Monitoring (DE.CM) 5:9,5:12
Security Templates 4:33-34,4:67
Security.evtx 4:rt'
ScntinelOne 4:7r
Sequenüal Function Chart (SFC) 1:37
lndex-19
session layer 2:6L, z;ıo8' 2:|32' 2:142
SetPoint (SP) |:14' |:34' 73637' ı:73, ı:76,1:84, 1:ı3ı,
2:5, 2:L9, 2:33, 2:37, 2:49-50, Z:65, Z;82,
2ito2' z:ı36,2:|4L,3:5, 3:12, 3:18, 3:36,
3:56,3:79,3i|o2' 3:1o5, 3:L25' 3:ı38, 4:5,
4:22, 4:39, 4i52, 4:7O, 4:96, 4:LL8, 4;132,
5:5, 5:19, 5:34, 5:41,5:53, 5:63
SHA-ı 3:26-27
SHA-256 3:26
SHA-384 3:26
SHA-sız 3:26-27
Shodan 4:133' 4|L39-74o' 4|743, 4:|45, 4:ı48-ı5ı
Siemens l:8, |:22, Li72' 2|g3' z:g8, z:ızı, 3l31,
3:43,3:47,3:gO, 3:93, 3198, 4;7, 4;27,
4:t4O,4:L45-t4g
SIMATIC 3:75,9:98, 4i27, 4:145, 4:147
Single Loss Expectancy (SLE) 5:56
Site Acceptance Test (SAT) 1:1r.2-113, L:7r5, r:L44, 2:84, 2;87, z:92,
4:42,4:86
Small Business Server (SBS) 4:24
SMART goals 5:26
Smart Grid Interoperability Panel (SGIP) 1t2, 2:1,3:1, 4:1, 5:1
SOAP r:74
Softing 3:43
Software Restriction Policies (SRP) 4:33,4173-74
Solaris 4tSB, 4:57-98, 4:66, 4:76, 4:8o
Sophos 4i7L
SQL Injection (SQLi) z:38, z:ı48' 3i3' 3|7o' 3:1o9, 3iLL6,3:119-
L23' 3:L29' 3:|32' 4:ı46
SQL Injection (SQLI) z:38, z:ı48' 3:g, 3:7o, 3: 1o9, 9:ıı6, 3: 119-
123, 3it2g, 3iL32, 4:L46
sqlmap z:38,3:ızz
Stratum z:58-59
strings 2t27, 2"42, 2i 44-45, 2:l-13, 2:125, 2it48,
4:46, 4:Lo7, 4:L86, 4tr47, 4:149
Structured Query Language (SQL) r:68, z:38, z:ı48,3i3,3:7o' 3:106, 3:1o9,
3:LL6, g:119-128, B:r29, B:192, 4:t46
Structured Text (ST) 1:37
Stuxnet ı:63, ı;7ı-72, 2:8, z:ı56, 3igo-g1' 3|g7'
3i99,3:134, 417, 4it2
Subnet II) 2:113
sudo z:76, 4:6ı, 4:64-65, 4:8z, 4:84, 4|8g-g3,
4:737
lndex-20
Supply Chain Risk Management (ID.SC) 5:10
Symantec gigo, S;92, g:94,4;62, 4t7r
symmetric algorithm 3:22,3:3O
SYN z:ıı6,3:76
SYN-ACK 2:L|6, 4:89, 4:9ı-9z
syslog 2:1o8, 3:ıı, 4:64-65, 4|Lo4-|o7, 4;Io9
System On a Chip (SOC) 1:L34, 2i47, 4;24, 4:1O8
System Robustness Testing (SRT) e:89
SystemV L;Lı , z;89, z:98,2:135,3:ro6, 4;6, 4i57,
4:63-64, 4:66, 4:ız3, 5:106
System.evtx 4:Lr5
T
Table Top eXercise (TTX) 5:85-87
tap point 3:11
TC 57 2:138
Telecommunications Industry Associaüon ı:4ı, z:65-66
(rrA)
telinit 4:64
Telnet 2:2O, 2ir}8, 3itt2, 3:139, 4;L39, 4: 15O
Telvent 1:71
Temporal Key Integrity Protocol (TKIP) 3:53
Termineter z:38
TIA-z3z ti4t
TIA-4zz L:4r
TIA-+8S ı:4ı,z:65-66
Time Division Multiple Access (TDMA) 3:39'3:46
Toshiba z:64
Total Phase z:25-26
Transmission Control Protocol (TCP) ı:8o, ı:87, 2:3,2i9' 2;2I^,2:38, z:5ı, z:6z-
64, z:66-67, 2:69, z:86-87, 2i92, 2:ro2,
2ilo7 -Lo9' z;lLL' z;tı5-tı6, 2:LL9' 2iL22-
128, ziLz1, 2;Lz8-t3L, 2it42, z:L4S-L46,
2:L5l-157' 3:8, 3: ı4, 3;4o, 3;49, 3i74, 3;76,
3:8ı, 3:83, 4:4o' 4i56' 4:6ı, 4;79,4:8z-83,
4;89,4:gt, E.gt, S:ro7
transport layer z:6ı-6z, z:67, z:ıo8, 2;115-116' z:ı36,
2:L42,3:53, 4:1O9
Trend Micro 4|7L,4:I,22-123
Triple DES 3:23
TrustcdBSD 4t74
lndex-21
TSA Pipeline 1:109
TTLS 3:53,3:64
U
Unidirectional Gateway 1:133, 3:6, 3:ız-ı3, 3:ı6
LJNIX commands 4:6o-6ı
User Datagram Protocol (UDP) z:64, z:87, 2: 1o8, 2:lLL' z:ıı5-ıL6, 2;728,
2:L32' 2:L42' 2|L53' 3:8, 3:ı4, 4:6ı, 4:7g,
4:83,4:ıo6' 4:Log
V
VAX 3:84
VBScript 4:41
Velocio L|L' 1:45-47, L;6o-6l, ı:63, r:89-91, |:gg,
2:72-75,2:77,2:79
Very Small Aperture Terminal (VSAT) 3i37,3:39-40
Virtual L.A,N (VI-\N) z:ıo5-ro6,3:38
Virtual Local Area Networks (VLANs) 2:2ı^, 2:63, 2:to5-1o6, 2:L44
VMware Li,-,I:45, L:47, r:go, r:93,2:73-74, 4t24,
4:39
Vulnerabilities t:144, 2:6, 2;Lo, 2:L2-t7, 2:20-22, 2:24,
2:z8,2z3o, z:g8, z:47, z:5ı, z:6g, z:85,
z:87-88, 2:gt, 2:gB, 2:135, 2:t47-t48, Bi7,
3:gg, g:4o, 3:57, 3:69, 3:83, 3:93, 3:97,
3:1o9, 3:ıı4-ıı6, 3:119-120, 3iL23' 3:L2g'
3:132-133, 3:135, 3:t41, 3:L49, 4;6-9, 4:tZ,
4iL6, 4:25-26, 4:zg, 4il3o, 4:L86, 4it4t,
4:t45-L46' 5i 42, 5;54-55, 5:6ı, 5:75
Vulnerability Identifi cation Testing (VIT) z:89
VxWorks 2i51,2:54
w
Weak Session Management 3:129,3:131
Whitelisüng 1:109,3:8z,4:7ı,4:73
Wi-Fi Protected Access (VYPA) 3:48,3:53' 3:6ı,4:zg
WiMax 3:39
WinCC 3:94' 3:98
Windows Embedded Compact 2:5L,2i55
lndex-22
Windows Firewall 4:78-79,4i8r
Windows Server Essenüals 4i24
Windows Server Update Services (WSUS) 4:30-31
Windows Storage Server 4i24
Wired Equivalent Privacy (WEP) 3:53
Wireless Industrial Technology 3:43
Konsortium (WiTECK)
WirelessHART z:64,3:37,9:42-47
Wireshark 2i38, 2:7 6-78, z:8o, 2i1-Lg-L2o' z;ızz-ız6,
2:t97, 2:r1g, 2iLSB, 3:66, 3:69-72, g:7 S-77
WirlessHART 3:43
wmic.exe 4i40
x
x86 LiLO7,2i55,4157
XML t:7 4, z:t28, 2:tg1, 4: 1o3
ıo<d 2:27,2t42-45
z
zbgoodfind z:42, z:46
ZedAttack Proxy (ZAP) 2:38, 3:119, 3iL49, 3:151-154
Zenmap 2:38,4:$8
ZigBee 2:42, 2: 46, 3:37, 31 42- 44, 3: 47 - 48, 3 :
58-
59,3i63
)
)
.)
)
)
,)
lndex-23
)
)
)
raaaaaa Iaa:a.a -tttt-t-t-t-ll.) -lll.]-l-)