Guide To Industrial Control System (ICS) Security Systems Security【NIST SP.800 82R2】【JPCERT和èš

Guide%20to%20Industrial%20Control%20Systems%20(ICS)%20Security%E3%80%90NIST%20SP.800-82R2%E3%80%91%E3%80%90JPCERT%E5%92%8C%E8%A8

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 490

Download
Open PDF In BrowserView PDF
Japan Computer Emergency
Response Team Coordination
Center

電子眲名者 : Japan Computer Emergency Response
Team Coordination Center
DN : c=JP, st=Tokyo, l=Chiyoda-ku,
email=office@jpcert.or.jp, o=Japan Computer
Emergency Response Team Coordination Center,
cn=Japan Computer Emergency Response Team
Coordination Center
日付 : 2016.04.12 09:20:04 +09'00'

NIST Special Publication 800-82
Revision 2

Guide to Industrial Control
Systems (ICS) Security
Supervisory Control and Data Acquisition (SCADA) Systems, Distributed Control Systems (DCS),
and Other Control System Configurations such as Programmable Logic Controllers (PLC)
Keith Stouffer
Victoria Pillitteri
Suzanne Lightman
Marshall Abrams
Adam Hahn

This publication is available free of charge from:
http://dx.doi.org/10.6028/NIST.SP.800-82r2

邊蚳
䞀般瀟団法人 JPCERT コヌディネヌションセンタヌ

NIST SP800-82
第2版

産業甚制埡システムICS
セキュリティガむド
SCADA、DCS、PLC その他の制埡システム蚭定
Keith Stouffer
Victoria Pillitteri
Suzanne Lightman
Marshall Abrams
Adam Hahn

本出版物は次のサむトから無料で入手可胜
http://dx.doi.org/10.6028/NIST.SP.800-82r2

NIST Special Publication 800-82
Revision 2

Guide to Industrial Control Systems
(ICS) Security
Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and
other control system configurations such as Programmable Logic Controllers (PLC)

Keith Stouffer
Intelligent Systems Division
Engineering Laboratory
Victoria Pillitteri
Suzanne Lightman
Computer Security Division
Information Technology Laboratory
Marshall Abrams
The MITRE Corporation
Adam Hahn
Washington State University
This publication is available free of charge from:
http://dx.doi.org/10.6028/NIST.SP.800-82r2
May 2015

U.S. Department of Commerce
Penny Pritzker, Secretary
National Institute of Standards and Technology
Willie May, Under Secretary of Commerce for Standards and Technology and Director

NISTSP800-82
第2版

産業甚制埡システム(ICS)
セキュリティガむド
SCADA、DCS、PLC、その他の制埡システムの蚭定

Keith Stouffer
゚ンゞニアリング研究所(EL)
むンテリゞェントシステム ディビゞョン
Victoria Pillitteri
Suzanne Lightman
情報技術研究所(ITL)
コンピュヌタセキュリティディビゞョン
Marshall Abrams
MITRE 瀟
Adam Hahn
ワシントン州立倧孊
本出版物は次のサむトから無料で入手可胜
http://dx.doi.org/10.6028/NIST.SP.800-82r2
2015 幎 5 月

米囜商務省
長官 Penny Pritzker
商務省暙準技術担圓次官
米囜囜立暙準技術研究所 所長
Willie May

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Authority
This publication has been developed by NIST to further its statutory responsibilities under the Federal
Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.)
113-283. NIST is responsible for developing information security standards and guidelines, including
minimum requirements for federal information systems, but such standards and guidelines shall not apply
to national security systems without the express approval of appropriate federal officials exercising policy
authority over such systems. This guideline is consistent with the requirements of the Office of
Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as
analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided
in Circular A-130, Appendix III, Security of Federal Automated Information Resources.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and
binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these
guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official. This publication may be used by nongovernmental
organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-82, Revision 2 Natl. Inst.
Stand. Technol. Spec. Publ. 800-82, Rev. 2, 247 pages (May 2015)
This publication is available free of charge from
:http://dx.doi.org/10.6028/NIST.SP.800-82r2
CODEN: NSPUE2
Certain commercial entities, equipment, or materials may be identified in this document in order to describe
an experimental procedure or concept adequately. Such identification is not intended to imply
recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or
equipment are necessarily the best available for the purpose.
There may be references in this publication to other publications currently under development by NIST in
accordance with its assigned statutory responsibilities. The information in this publication, including
concepts and methodologies, may be used by federal agencies even before the completion of such
companion publications. Thus, until each publication is completed, current requirements, guidelines, and
procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may
wish to closely follow the development of these new publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide
feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are
available at http://csrc.nist.gov/publications.
Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Electronic Mail: nist800-82rev2comments@nist.gov

v

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

本文曞に぀いお
本出版物は、2014 幎連邊情報セキュリティ近代化法FISMA44 U.S.C. § 3541 及び䞀般法
P.L.113-283 に基づき、米囜囜立暙準技術研究所NISTがその法的責務を遂行するために
䜜成した。
NIST は、連邊情報システムの最䜎限の芁件事項を含んだ情報セキュリティ暙準及びガむドラむ
ンを䜜成する責務があるが、このような暙準及びガむドラむンは、囜家安党保障に係わるシステ
ムにおいおは、連邊圓局による圓該システムに察するポリシヌ暩限を行䜿する明瀺的承認がなけ
れば適甚されない。本ガむドラむンは、行政管理予算局OMB通達 A-130、8b(3)条、「政府
機関情報システムの保党」通達 A-130 付録 IV「䞻芁条文の分析」に蚘茉の芁件に䞀臎する。
補足情報は、通達 A-130 付録 III「連邊自動化情報リ゜ヌスのセキュリティ」に蚘茉されおいる。
本出版物のいかなる蚘述も、商務長官の法的暩限により連邊政府機関に適甚される暙準及びガむ
ドラむンを吊定するものではない。たたガむドラむンは、商務長官、行政管理予算局長官、たた
はその他連邊圓局の既存の暩限に倉曎を加えたり、代替するものず解釈しおはならない。
本出版物は、政府以倖の組織が任意に䜿甚するこずができ、米囜における著䜜暩の察象ずならな
いが、NIST は著䜜暩の垰属を明蚘するこずに感謝する。
米囜囜立暙準技術研究所NISTSP800-82 第 2 版、
Natl. Inst. Stand. Technol. Spec. Publ. 800-82, Rev. 2, 247 ペヌゞ2015 幎 5 月
本出版物は次のサむトから入手可胜(無料)
http://dx.doi.org/10.6028/NIST.SP.800-82r2
CODEN:NSPUE2
本文曞では、特定される営利団䜓名、装眮又は資料は、実隓的な手順又は抂念を適切に説明するた
めのものである。したがっお、NIST による掚奚や保蚌するものではなく、圓該営利団䜓、装眮又
は資料が、その目的に関しお埗られる最良のものであるこずを意味するものでもない。
本出版物では、NIST がその負蚗された法的責務に埓っお珟圚䜜成䞭の他の出版物を参照する堎合
がある。本出版物の抂念や方法論を含む情報は、前述の関連出版物の完成前であっおも、連邊政府
機関が䜿甚する堎合がある。よっお、各出版物が完成するたでは、珟圚の必須芁件、ガむドラむン
及び手順が存圚する堎合、それらは匕き続き有効である。連邊政府機関は蚈画䜜成ず移行の目的ず
しお、NIST によるこれら新芏出版物の䜜成状況を確認されたい。
各組織は、パブリックコメントの公募期間䞭に、党おの公開ドラフト文曞を閲芧し、コメントを NIST
に提瀺されたい。党おの NIST コンピュヌタセキュリティディビゞョンの出版物は、䞊蚘のもの

を陀き、http://csrc.nist.gov/publications から入手できる。
本出版物に関する意芋は、以䞋の宛先に提出されたい。
AttnComputer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
電子メヌルnist800-82rev2comments@nist.gov

vi

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of
concept implementations, and technical analyses to advance the development and productive use of
information technology. ITL’s responsibilities include the development of management, administrative,
technical, and physical standards and guidelines for the cost-effective security and privacy of other than
national security-related information in federal information systems. The Special Publication 800-series
reports on ITL’s research, guidelines, and outreach efforts in information system security, and its
collaborative activities with industry, government, and academic organizations.
Abstract
This document provides guidance on how to secure Industrial Control Systems (ICS), including
Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and
other control system configurations such as Programmable Logic Controllers (PLC), while addressing their
unique performance, reliability, and safety requirements. The document provides an overview of ICS and
typical system topologies, identifies typical threats and vulnerabilities to these systems, and provides
recommended security countermeasures to mitigate the associated risks.
Keywords
Computer security; distributed control systems (DCS); industrial control systems (ICS); information
security; network security; programmable logic controllers (PLC); risk management; security controls;
supervisory control and data acquisition (SCADA) systems

vii

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

コンピュヌタシステム技術に関するレポヌト
米囜囜立暙準技術研究所NISTの情報技術研究所ITLは、囜の蚈枬及び基準むンフラに関
する技術的統率を図るこずにより、米囜の経枈・公共犏祉を促進しおいる。ITL は詊隓、詊隓法、
基準デヌタ、抂念の実蚌及び技術解析の開発を進め、情報技術の開発ず生産的利甚を促進しおい
る。ITL の責務には、連邊情報システムにおける囜のセキュリティ関連情報以倖の、費甚効果の
高いセキュリティ及びプラむバシヌに関する運営、管理、技術及び物理的基準・ガむドラむンの
䜜成が含たれる。SP800 シリヌズは、ITL の研究、ガむドラむン及び情報システムセキュリティ
における公共犏祉に向けた取組䞊びに産官孊ずの連携に関する報告曞である。

抄録
本文曞は、SCADA、DCS、PLC その他の制埡システム蚭定を含む産業甚制埡システムICSの
保党方法に関するガむダンスであり、その独特な性胜・信頌性・安党性芁件に぀いお取り䞊げる。
ICS の抂芁ず兞型的なシステムトポロゞヌを述べ、これらシステムぞの䞀般的な脅嚁ず脆匱性を
明らかにし、関係するリスクを枛らすためのセキュリティ察策に぀いお提蚀する。

キヌワヌド
コンピュヌタセキュリティ、DCS、ICS、情報セキュリティ、ネットワヌクセキュリティ、
PLC、リスク管理、セキュリティ察策、SCADA

viii

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Acknowledgments for Revision 2
The authors gratefully acknowledge and appreciate the significant contributions from individuals and
organizations in the public and private sectors, whose thoughtful and constructive comments improved the
overall quality, thoroughness, and usefulness of this publication. A special acknowledgement to Lisa Kaiser,
Department of Homeland Security, the Department of Homeland Security Industrial Control System Joint
Working Group (ICSJWG), and Office of the Deputy Undersecretary of Defense for Installations and
Environment, Business Enterprise Integration Directorate staff, Daryl Haegley and Michael Chipley, for
their exceptional contributions to this publication.
Acknowledgments for Previous Versions
The original authors, Keith Stouffer, Joe Falco, and Karen Scarfone of NIST, wish to thank their colleagues
who reviewed drafts of the original version of the document and contributed to its technical content. The
authors would particularly like to acknowledge Tim Grance, Ron Ross, Stu Katzke, and Freemon Johnson
of NIST for their keen and insightful assistance throughout the development of the document. The authors
also gratefully acknowledge and appreciate the many contributions from the public and private sectors
whose thoughtful and constructive comments improved the quality and usefulness of the publication. The
authors would particularly like to thank the members of ISA99. The authors would also like to thank the
UK National Centre for the Protection of National Infrastructure (CPNI)) for allowing portions of the Good
Practice Guide on Firewall Deployment for SCADA and Process Control Network to be used in the
document as well as ISA for allowing portions of the ISA-62443 Standards to be used in the document.

Note to Readers
This document is the second revision to NIST SP 800-82, Guide to Industrial Control Systems (ICS)
Security. Updates in this revision include:
Updates to ICS threats and vulnerabilities.
Updates to ICS risk management, recommended practices, and architectures.
Updates to current activities in ICS security.
Updates to security capabilities and tools for ICS.
Additional alignment with other ICS security standards and guidelines.
New tailoring guidance for NIST SP 800-53, Revision 4 security controls including the
introduction of overlays.
An ICS overlay for NIST SP 800-53, Revision 4 security controls that provides tailored security
control baselines for Low, Moderate, and High impact ICS.

ix

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

第 2 版に関する謝蟞
本文曞の著者らは、官民の個人及び組織から倚倧の貢献があったこずを認め、ここに謝意を衚す
る。その瀺唆に富み建蚭的な意芋により、本出版物の党䜓的な質、包括性及び有甚性が向䞊した。
特に Lisa Kaiser囜土安党保障省、囜土安党保障省の Industrial Control System Joint Working
Group (ICSJWG)及び Office of the Deputy Undersecretary of Defense for Installations and Environment、
Business Enterprise Integration Directorate の職員、Daryl Haegley 及び Michael Chipley に察しお、そ
れぞれの特別な貢献に謝蟞を衚するものである。
旧版に関する謝蟞
旧版の著者である NIST の Keith Stouffer、Joe Falco 及び Karen Scarfone は、本文曞の原案を粟査
し、その技術的内容に寄䞎した同僚諞氏に謝意を衚する。著者は特に、NIST の Tim Grance、Ron
Ross、Stu Katzke 及び Freemon Johnson に察し、文曞の䜜成党般にわたり鋭い掞察を䞎えおくれた
こずに謝意を衚する。たた、官民から倚倧の貢献があり、瀺唆に富み建蚭的な意芋により出版物
の質ず有甚性が向䞊したこずにも謝意を衚する。ずりわけ ISA99 のメンバヌには感謝しおいる。
たた「SCADA 及びプロセス制埡ネットワヌクのファむアりォヌルに係る適正芏範ガむド」の䞀
郚を本文曞で利甚させおくれた英囜むンフラストラクチャ防護センタヌCPNI及び ISA62443 芏栌を同様に利甚させおくれた ISA に察しおも、謝意を衚する。
読者ぞの泚蚘
本文曞は NIST SP 800-82「Guide to Industrial Control Systems (ICS) Security産業甚制埡システム
セキュリティガむド」の第 2 版である。曎新内容は以䞋のずおり。
ICS の脅嚁ず脆匱性に関する改蚂
ICS リスク管理、掚奚芏範およびアヌキテクチャに関する改蚂
ICS セキュリティにおける珟圚の掻動に関する改蚂
ICS のセキュリティ性胜ずツヌルに関する改蚂
他の ICS セキュリティ基準およびガむドラむンずの補足調敎
オヌバヌレむの玹介を含む NIST SP 800-53 の新ガむダンス第 4 版セキュリティ察策
䜎・䞭・高むンパクト ICS に合ったセキュリティ管理策のベヌスラむンを䞎えおい
る NIST SP 800-53 第 4 版のセキュリティ管理策に察応した ICS オヌバヌレむ

本文曞は、英語版の原兞に沿っお察蚳するよう努めおいたすが、完党性、正確性を
保蚌するものではありたせん。本文曞に蚘茉されおいる情報より生じる損倱たたは
損害に察しお、JPCERT/CC は責任を負うものではありたせん。

x

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Table of Contents
Executive Summary .............................................................................................................................. 1
゚グれクティブサマリヌ ......................................................................................................................... 2
1.

Introduction ..................................................................................................................................... 9
1.1 Purpose and Scope................................................................................................................................... 9
1.2 Audience ................................................................................................................................................... 9

1.

はじめに.......................................................................................................................................... 10
1.1 目的及び適甚範囲 ................................................................................................................................. 10
1.2 察象者 ................................................................................................................................................... 10
1.3 Document Structure ................................................................................................................................ 11
1.3 文曞の構成............................................................................................................................................ 12

2.

Overview of Industrial Control Systems .................................................................................... 13
2.1 Evolution of Industrial Control Systems................................................................................................... 13

2.

産業甚制埡システムの抂芁............................................................................................................. 14
2.1 産業甚制埡システムの進化................................................................................................................... 14
2.2 ICS Industrial Sectors and Their Interdependencies ............................................................................... 15
2.2.1 Manufacturing Industries ............................................................................................................. 15
2.2.2 Distribution Industries .................................................................................................................. 15
2.2.3 Differences between Manufacturing and Distribution ICS............................................................ 15
2.2.4 ICS and Critical Infrastructure Interdependencies ....................................................................... 15
2.2 ICS の産業郚門ずその盞互䟝存性 ......................................................................................................... 16
2.2.1 補造業界 .................................................................................................................................... 16
2.2.2 配送業界 .................................................................................................................................... 16
2.2.3 補造 ICS ず配送 ICS の盞違 ...................................................................................................... 16
2.2.4 ICS ず重芁むンフラの盞互䟝存性 ............................................................................................. 16
2.3 ICS Operation and Components ............................................................................................................. 17
2.3 ICS の操䜜及びコンポヌネント ............................................................................................................ 18
2.3.1 ICS System Design Considerations ............................................................................................. 19
2.3.1 ICS のシステム蚭蚈䞊の考慮事項 ............................................................................................. 20
2.3.2 SCADA Systems.......................................................................................................................... 21
2.3.2 SCADA...................................................................................................................................... 22
2.3.3 Distributed Control Systems ........................................................................................................ 31
2.3.3 分散制埡システム ..................................................................................................................... 32
2.3.4 Programmable Logic Controller Based Topologies...................................................................... 35
2.3.4 プログラム可胜論理コントロヌラベヌスのトポロゞヌ ............................................................ 36
2.4 Comparing ICS and IT Systems Security ................................................................................................ 39
2.4 ICS システムず IT システムのセキュリティ比范.................................................................................. 40
2.5 Other Types of Control Systems ............................................................................................................. 45
2.5 別皮の制埡システム ............................................................................................................................. 46

3.

ICS Risk Management and Assessment..................................................................................... 49
3.1 Risk Management ................................................................................................................................... 49

3.

ICS のリスク管理ずリスク評䟡...................................................................................................... 50
3.1 リスク管理............................................................................................................................................ 50
3.2 Introduction to the Risk Management Process ........................................................................................ 51
3.2 リスク管理プロセスの玹介................................................................................................................... 52
3.3 Special Considerations for Doing an ICS Risk Assessment .................................................................... 55
3.3.1 Safety within an ICS Information Security Risk Assessment ....................................................... 55
3.3 ICS リスク評䟡の実斜に際しおの特別な考慮事項 ............................................................................... 56

xi

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

3.3.1

ICS 情報セキュリティリスク評䟡における安党性 .................................................................... 56

3.3.2 Potential Physical Impacts of an ICS Incident ............................................................................. 57
3.3.3 Impact of Physical Disruption of an ICS Process ......................................................................... 57
3.3.2 ICS むンシデントによる物理的圱響の可胜性 ........................................................................... 58
3.3.3 ICS プロセスの物理的䞭断による圱響 ...................................................................................... 58
3.3.4 Incorporating Non-digital Aspects of ICS into Impact Evaluations ............................................... 59
3.3.4 ICS の非デゞタル面を圱響評䟡に含める .................................................................................. 60
3.3.5 Incorporating the Impact of Safety Systems ................................................................................ 61
3.3.6 Considering the Propagation of Impact to Connected Systems ................................................... 61
3.3.5 安党システムの圱響を含める.................................................................................................... 62
3.3.6 接続システムぞの圱響波及に察する考慮 .................................................................................. 62

4.

ICS Security Program Development and Deployment .............................................................. 63

4.

ICS セキュリティプログラムの開発及び展開 ................................................................................ 64
4.1 Business Case for Security ..................................................................................................................... 65
4.1.1 Benefits ................................................................................................................................................ 65
4.1 セキュリティの事業事䟋 ...................................................................................................................... 66
4.1.1 䟿益 ................................................................................................................................................... 66
4.1.2 Potential Consequences .............................................................................................................. 67
4.1.2 生じ埗る結果............................................................................................................................. 68
4.1.3 Resources for Building Business Case ........................................................................................ 69
4.1.4 Presenting the Business Case to Leadership .............................................................................. 69
4.1.3 事業事䟋䜜成のためのリ゜ヌス ................................................................................................ 70
4.1.4 事業事䟋を組織の長に提瀺する ................................................................................................ 70
4.2 Build and Train a Cross-Functional Team ............................................................................................... 71
4.3 Define Charter and Scope ....................................................................................................................... 71
4.2 機胜暪断チヌムの組成・教育蚓緎 ........................................................................................................ 72
4.3 憲章及び適甚範囲の明確化................................................................................................................... 72
4.4 Define ICS-specific Security Policies and Procedures ............................................................................ 73
4.5 Implement an ICS Security Risk Management Framework ..................................................................... 73
4.4 ICS 固有のセキュリティポリシヌ及び手順の明確化 ............................................................................ 74
4.5 ICS セキュリティリスク管理䜓制の実行.............................................................................................. 74
4.5.1 Categorize ICS Systems and Networks Assets ........................................................................... 75
4.5.2 Select ICS Security Controls ....................................................................................................... 75
4.5.1 ICS システムずネットワヌク資産の分類 .................................................................................. 76
4.5.2 ICS セキュリティ管理の遞択 .................................................................................................... 76
4.5.3 Perform Risk Assessment ........................................................................................................... 77
4.5.4 Implement the Security Controls .................................................................................................. 77
4.5.3 リスク評䟡実斜 ......................................................................................................................... 78
4.5.4 セキュリティ管理の実装 ........................................................................................................... 78

5.

ICS Security Architecture ............................................................................................................ 79
5.1 Network Segmentation and Segregation ................................................................................................. 79

5.

ICS セキュリティアヌキテクチャ .................................................................................................. 80
5.1 ネットワヌクの分割ず分離................................................................................................................... 80
5.2 Boundary Protection................................................................................................................................ 83
5.2 境界の保護 .............................................................................................................................................. 84
5.3 Firewalls .................................................................................................................................................. 85
5.3 ファむアりォヌル ................................................................................................................................. 86
5.4 Logically Separated Control Network ...................................................................................................... 89
5.4 論理的に分離された制埡ネットワヌク ................................................................................................. 90
5.5 Network Segregation............................................................................................................................... 91
5.5.1 Dual-Homed Computer/Dual Network Interface Cards (NIC) ...................................................... 91
5.5.2 Firewall between Corporate Network and Control Network ......................................................... 91

xii

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.5 ネットワヌクの分離 ............................................................................................................................. 92
5.5.1 デュアルホヌムコンピュヌタ/デュアルネットワヌクむンタフェヌスカヌドNIC .......... 92
5.5.2 䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌル.................................................. 92
5.5.3 Firewall and Router between Corporate Network and Control Network....................................... 95
5.5.3 䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌルずルヌタ ...................................... 96
5.5.4 Firewall with DMZ between Corporate Network and Control Network ......................................... 97
5.5.4 䌁業ネットワヌクず制埡ネットワヌク間の DMZ 付きファむアりォヌル ................................. 98
5.5.5 Paired Firewalls between Corporate Network and Control Network .......................................... 101
5.5.5 䌁業ネットワヌクず制埡ネットワヌク間のペアヌドファむアりォヌル ................................. 102
5.5.6 Network Segregation Summary ................................................................................................. 103
5.6 Recommended Defense-in-Depth Architecture ..................................................................................... 103
5.5.6 ネットワヌク分離のたずめ ..................................................................................................... 104
5.6 掚奚倚局防埡アヌキテクチャ ............................................................................................................. 104
5.7 General Firewall Policies for ICS........................................................................................................... 105
5.7 ICS の党般的ファむアりォヌルポリシヌ............................................................................................ 106
5.8 Recommended Firewall Rules for Specific Services ............................................................................. 109
5.8 特定サヌビスの掚奚ファむアりォヌルルヌル .................................................................................... 110
5.8.1 Domain Name System (DNS) .................................................................................................... 111
5.8.2 Hypertext Transfer Protocol (HTTP) .......................................................................................... 111
5.8.3 FTP and Trivial File Transfer Protocol (TFTP) ........................................................................... 111
5.8.4 Telnet......................................................................................................................................... 111
5.8.1 領域名システムDNS ........................................................................................................ 112
5.8.2 ハむパヌテキスト転送プロトコルHTTP .......................................................................... 112
5.8.3 FTP 及びトリビアルファむル転送プロトコルTFTP ........................................................ 112
5.8.4 テルネットTelnet ............................................................................................................. 112
5.8.5 Dynamic Host Configuration Protocol (DHCP)........................................................................... 113
5.8.6 Secure Shell (SSH).................................................................................................................... 113
5.8.7 Simple Object Access Protocol (SOAP) .................................................................................... 113
5.8.8 Simple Mail Transfer Protocol (SMTP) ...................................................................................... 113
5.8.9 Simple Network Management Protocol (SNMP) ........................................................................ 113
5.8.5 動的ホスト構成プロトコルDHCP .................................................................................... 114
5.8.6 セキュアシェルSSH) ........................................................................................................... 114
5.8.7 シンプルオブゞェクトアクセスプロトコルSOAP ........................................................... 114
5.8.8 シンプルメヌル転送プロトコルSMTP ............................................................................. 114
5.8.9 シンプルネットワヌク管理プロトコルSNMP .................................................................. 114
5.8.10 Distributed Component Object Model (DCOM) ........................................................................ 115
5.8.11 SCADA and Industrial Protocols .............................................................................................. 115
5.9 Network Address Translation (NAT)...................................................................................................... 115
5.8.10 分散コンポヌネントオブゞェクトモデルDCOM............................................................ 116
5.8.11 SCADA 及び産業甚プロトコル ............................................................................................. 116
5.9 ネットワヌクアドレス倉換NAT .................................................................................................. 116
5.10 Specific ICS Firewall Issues ................................................................................................................ 117
5.10.1 Data Historians ........................................................................................................................ 117
5.10.2 Remote Support Access .......................................................................................................... 117
5.10.3 Multicast Traffic........................................................................................................................ 117
5.10 ICS ファむアりォヌル固有の問題 .................................................................................................... 118
5.10.1 デヌタヒストリアン .............................................................................................................. 118
5.10.2 遠隔サポヌトシステム .......................................................................................................... 118
5.10.3 マルチキャストトラフィック................................................................................................ 118
5.11 Unidirectional Gateways ..................................................................................................................... 119
5.12 Single Points of Failure ....................................................................................................................... 119
5.13 Redundancy and Fault Tolerance ...................................................................................................... 119
5.11 単方向性ゲヌトりェむ ...................................................................................................................... 120

xiii

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.12 単䞀障害点........................................................................................................................................ 120
5.13 冗長性ずフォヌルトトレランス ....................................................................................................... 120
5.14 Preventing Man-in-the-Middle Attacks ................................................................................................ 121
5.14 人が介圚する攻撃の防止 .................................................................................................................. 122
5.15 Authentication and Authorization......................................................................................................... 125
5.15 認蚌ず暩限付䞎 ................................................................................................................................ 126
5.15.1 ICS Implementation Considerations ................................................................................................. 127
5.16 Monitoring, Logging, and Auditing ....................................................................................................... 127
5.17 Incident Detection, Response, and System Recovery ........................................................................ 127
5.15.1 ICS 実装䞊の考慮事項 ........................................................................................................... 128
5.16 監芖、ロギング及び監査 .................................................................................................................. 128
5.17 むンシデント怜知、察応及びシステム埩旧...................................................................................... 128

6.

Applying Security Controls to ICS ........................................................................................... 129
6.1 Executing the Risk Management Framework Tasks for Industrial Control Systems ............................. 129

6.

ICS ぞのセキュリティ察策の適甚 ...................................................................................... 130
6.1 産業甚制埡システム甚リスク管理䜓制の実斜 .................................................................................... 130
6.1.1 Step 1: Categorize Information System ..................................................................................... 131
6.1.1 手順 1情報システムの分類 .................................................................................................. 132
6.1.2 Step 2: Select Security Controls ................................................................................................ 135
6.1.2 手順 2セキュリティ察策の遞択 ........................................................................................... 136
6.1.3 Step 3: Implement Security Controls ......................................................................................... 137
6.1.4 Step 4: Assess Security Controls............................................................................................... 137
6.1.5 Step 5: Authorize Information System ....................................................................................... 137
6.1.3 手順 3セキュリティ察策の実装 ........................................................................................... 138
6.1.4 手順 4セキュリティ察策の評䟡 ........................................................................................... 138
6.1.5 手順 5情報システムの蚱可 .................................................................................................. 138
6.1.6 Step 6: Monitor Security Controls .............................................................................................. 139
6.2 Guidance on the Application of Security Controls to ICS ...................................................................... 139
6.1.6 手順 6セキュリティ察策の監芖 ........................................................................................... 140
6.2 ICS ぞのセキュリティ察策の適甚に係るガむダンス .......................................................................... 140
6.2.1 Access Control........................................................................................................................... 143
6.2.1 アクセス制埡........................................................................................................................... 144
6.2.2 Awareness and Training ............................................................................................................ 153
6.2.3 Audit and Accountability ............................................................................................................ 153
6.2.2 意識及び蚓緎........................................................................................................................... 154
6.2.3 監査及び説明責任 ................................................................................................................... 154
6.2.4 Security Assessment and Authorization .................................................................................... 157
6.2.5 Configuration Management ....................................................................................................... 157
6.2.4 セキュリティ評䟡及び暩限付䞎 .............................................................................................. 158
6.2.5 構成管理 .................................................................................................................................. 158
6.2.6 Contingency Planning ................................................................................................................ 159
6.2.6 䞍枬事態蚈画........................................................................................................................... 160
6.2.7 Identification and Authentication ................................................................................................ 165
6.2.7 識別及び認蚌........................................................................................................................... 166
6.2.8 Incident Response ..................................................................................................................... 177
6.2.8 むンシデント察応 ................................................................................................................... 178
6.2.9 Maintenance .............................................................................................................................. 181
6.2.10 Media Protection ...................................................................................................................... 181
6.2.9 保守 ......................................................................................................................................... 182
6.2.10 メデむア保護......................................................................................................................... 182
6.2.11 Physical and Environmental Protection ................................................................................... 183
6.2.11 物理環境䞊の保護PE ..................................................................................................... 184

xiv

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.12 Planning ................................................................................................................................... 189
6.2.12 プランニング......................................................................................................................... 190
6.2.13 Personnel Security................................................................................................................... 191
6.2.13 人員のセキュリティ .............................................................................................................. 192
6.2.14 Risk Assessment ..................................................................................................................... 193
6.2.15 System and Services Acquisition ............................................................................................. 193
6.2.14 リスク評䟡 ............................................................................................................................ 194
6.2.15 システム及びサヌビスの取埗................................................................................................ 194
6.2.16 System and Communications Protection ................................................................................. 195
6.2.16 システム及び通信保護 .......................................................................................................... 196
6.2.16.1 Encryption ............................................................................................................................. 197
6.2.16.1 暗号化 ................................................................................................................................ 198
6.2.17 System and Information Integrity ............................................................................................. 203
6.2.17 システム及び情報の保党 ....................................................................................................... 204
6.2.18 Program Management ............................................................................................................. 209
6.2.19 Privacy Controls....................................................................................................................... 209
6.2.18 プログラム管理 ..................................................................................................................... 210
6.2.19 プラむバシヌ管理 ................................................................................................................. 210

List of Apendix
Appendix A—Acronyms and Abbreviations ......................................................................................................... 213
付録 A 頭字語及び略語 ..................................................................................................................................... 214
Appendix B—Glossary of Terms ......................................................................................................................... 219
付録 B 甚語集 .................................................................................................................................................... 220
Appendix C—Threat Sources, Vulnerabilities, and Incidents .............................................................................. 255
付録 C 脅嚁源、脆匱性及びむンシデント........................................................................................................ 256
Appendix D—Current Activities in Industrial Control System Security ................................................................. 283
付録 D 産業甚制埡システムセキュリティにおける珟圚の掻動 ....................................................................... 284
Appendix E—ICS Security Capabilities and Tools............................................................................................... 315
付録 E ICS セキュリティ機胜及びツヌル ......................................................................................................... 316
Appendix F—References .................................................................................................................................... 323
Appendix G—ICS Overlay ................................................................................................................................... 341
付録 G ICS オヌバヌレむ ................................................................................................................................. 342

List of Figure
Figure 2-1. ICS Operation ..................................................................................................................................... 19
図 2-1.ICS の動䜜 .................................................................................................................................................. 20
Figure 2-2. SCADA System General Layout ......................................................................................................... 23
図 2-2.SCADA の党般レむアりト .......................................................................................................................... 24
Figure 2-3. Basic SCADA Communication Topologies .......................................................................................... 25
図 2-3. 基本的 SCADA 通信トポロゞヌ .............................................................................................................. 26
Figure 2-4. Large SCADA Communication Topology ............................................................................................ 27
図 2-4. 倧芏暡 SCADA 通信トポロゞヌ .............................................................................................................. 28
Figure 2-5. SCADA System Implementation Example (Distribution Monitoring and Control) ................................ 29
図 2-5. SCADA の実装䟋分散監芖・制埡 ..................................................................................................... 30
Figure 2-6. SCADA System Implementation Example (Rail Monitoring and Control) ............................................ 31
図 2-6. SCADA の実装䟋列車監芖・制埡 ....................................................................................................... 32
Figure 2-7. DCS Implementation Example ............................................................................................................ 35
図 2-7.DCS の実装䟋 ............................................................................................................................................. 36
Figure 2-8. PLC Control System Implementation Example ................................................................................... 37
図 2-8. PLC 制埡システムの実装䟋 ....................................................................................................................... 38

xv

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Figure 3-1. Risk Management Process Applied Across the Tiers .......................................................................... 51
図 3-1.党段階にたたがるリスク管理プロセス ....................................................................................................... 52
Figure 5-1. Firewall between Corporate Network and Control Network ................................................................. 93
図 5-1.䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌル ................................................................... 94
Figure 5-2. Firewall and Router between Corporate Network and Control Network .............................................. 95
図 5-2.䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌルずルヌタ ..................................................... 96
Figure 5-3. Firewall with DMZ between Corporate Network and Control Network ................................................. 97
図 5-3.䌁業ネットワヌクず制埡ネットワヌク間の DMZ 付きファむアりォヌル ................................................... 98
Figure 5-4. Paired Firewalls between Corporate Network and Control Network .................................................. 101
図 5-4.䌁業ネットワヌクず制埡ネットワヌク間のペアヌドファむアりォヌル ................................................... 102
Figure 5-5. CSSP Recommended Defense-In-Depth Architecture ...................................................................... 105
図 5-5.CSSP の掚奚倚局防埡アヌキテクチャ ..................................................................................................... 106
Figure 6-1. Risk Management Framework Tasls ................................................................................................. 131
図 6-1.リスク管理䜓制業務.................................................................................................................................. 132
Figure C-1. ICS-CERT Reported Incidents by Year ............................................................................................ 275
図 C-1. ICS-CERT に届出のあった幎床別むンシデント件数 .............................................................................. 276
Figure G-1 Detailed Overlay Control Specifications Illustrated ............................................................................ 365
図 G-1 詳现オヌバヌレむ管理仕様の説明 ........................................................................................................... 366

List of Tables
Table 2-1. Summary of IT System and ICS Differences ........................................................................................ 43
è¡š 2-1.IT システムず ICS の盞違点 ........................................................................................................................ 44
Table 3-1. Categories of Non-Digital ICS Control Components ............................................................................. 59
è¡š 3-1. 非デゞタル ICS 制埡コンポヌネントのカテゎリヌ .................................................................................... 60
Table 6-1. Possible Definitions for ICS Impact Levels Based on ISA99 .............................................................. 133
è¡š 6-1. ISA99 に基づく ICS 圱響レベルの定矩 .................................................................................................... 134
Table 6-2. Possible Definitions for ICS Impact Levels Based on Product Produced, Industry and Security
Concerns ............................................................................................................................................................. 135
è¡š 6-2. 生産物、産業及びセキュリティ関心事に基づく ICS ぞの圱響レベルの定矩 .......................................... 136
Table C-1. Threats to ICS .................................................................................................................................... 255
è¡š C-1. ICS の脅嚁 ............................................................................................................................................... 256
Table C-2. Policy and Procedure Vulnerabilities and Predisposing Conditions ................................................... 261
è¡š C-2. ポリシヌ及び手順の脆匱性及び匱点ずなる状態 ..................................................................................... 262
Table C-3. Architecture and Design Vulnerabilities and Predisposing Conditions ............................................... 265
Table C-4. Configuration and Maintenance Vulnerabilities and Predisposing Conditions ................................... 265
è¡š C-3.アヌキテクチャ及び蚭蚈䞊の脆匱性及び匱点ずなる状態 ........................................................................ 266
è¡š C-4.構成及び保守䞊の脆匱性及び匱点ずなる状態 .......................................................................................... 266
Table C-5. Physical Vulnerabilities and Predisposing Conditions ........................................................................ 269
è¡š C-5.物理的脆匱性及び匱点ずなる状態............................................................................................................ 270
Table C-6. Software Development Vulnerabilities and Predisposing Conditions ................................................. 271
Table C-7. Communication and Network Configuration Vulnerabilities and Predisposing Conditions ................. 271
è¡š C-6.゜フトり゚ア開発䞊の脆匱性及び匱点ずなる状態................................................................................... 272
è¡š C-7.通信及びネットワヌク構成䞊の脆匱性及び匱点ずなる状態 .................................................................... 272
Table C-8. Example Adversarial Incidents ........................................................................................................... 273
è¡š C-8. 攻撃むンシデントの䟋 ............................................................................................................................ 274
Table G-1 Security Control Baselines .................................................................................................................. 345
è¡š G-1 セキュリティ管理ベヌスラむン ............................................................................................................ 346

xvi

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Executive Summary
This document provides guidance for establishing secure industrial control systems (ICS). These ICS,
which include supervisory control and data acquisition (SCADA) systems, distributed control systems
(DCS), and other control system configurations such as Programmable Logic Controllers (PLC) are often
found in the industrial control sectors. ICS are typically used in industries such as electric, water and
wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and
beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods.) SCADA systems
are generally used to control dispersed assets using centralized data acquisition and supervisory control.
DCS are generally used to control production systems within a local area such as a factory using
supervisory and regulatory control. PLCs are generally used for discrete control for specific applications
and generally provide regulatory control. These control systems are vital to the operation of the U.S. critical
infrastructures that are often highly interconnected and mutually dependent systems. It is important to note
that approximately 90 percent of the nation's critical infrastructures are privately owned and operated.
Federal agencies also operate many of the ICS mentioned above; other examples include air traffic control
and materials handling (e.g., Postal Service mail handling.) This document provides an overview of these
ICS and typical system topologies, identifies typical threats and vulnerabilities to these systems, and
provides recommended security countermeasures to mitigate the associated risks.
Initially, ICS had little resemblance to traditional information technology (IT) systems in that ICS were
isolated systems running proprietary control protocols using specialized hardware and software. Many ICS
components were in physically secured areas and the components were not connected to IT networks or
systems. Widely available, low-cost Internet Protocol (IP) devices are now replacing proprietary solutions,
which increases the possibility of cybersecurity vulnerabilities and incidents. As ICS are adopting IT
solutions to promote corporate business systems connectivity and remote access capabilities, and are being
designed and implemented using industry standard computers, operating systems (OS) and network
protocols, they are starting to resemble IT systems. This integration supports new IT capabilities, but it
provides significantly less isolation for ICS from the outside world than predecessor systems, creating a
greater need to secure these systems. The increasing use of wireless networking places ICS
implementations at greater risk from adversaries who are in relatively close physical proximity but do not
have direct physical access to the equipment. While security solutions have been designed to deal with
these security issues in typical IT systems, special precautions must be taken when introducing these same
solutions to ICS environments. In some cases, new security solutions are needed that are tailored to the ICS
environment.
Although some characteristics are similar, ICS also have characteristics that differ from traditional
information processing systems. Many of these differences stem from the fact that logic executing in ICS
has a direct effect on the physical world. Some of these characteristics include significant risk to the health
and safety of human lives and serious damage to the environment, as well as serious financial issues such
as production losses, negative impact to a nation’s economy, and compromise of proprietary information.
ICS have unique performance and reliability requirements and often use operating systems and applications
that may be considered unconventional to typical IT personnel. Furthermore, the goals of safety and
efficiency sometimes conflict with security in the design and operation of control systems.
ICS cybersecurity programs should always be part of broader ICS safety and reliability programs at both
industrial sites and enterprise cybersecurity programs, because cybersecurity is essential to the safe and
reliable operation of modern industrial processes. Threats to control systems can come from numerous
sources, including hostile governments, terrorist groups, disgruntled employees, malicious intruders,
complexities, accidents, and natural disasters as well as malicious or accidental actions by insiders. ICS
security objectives typically follow the priority of availability and integrity, followed by confidentiality.

1

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

゚グれクティブサマリヌ
本文曞は、セキュアな産業甚制埡システムICSを構築するためのガむダンスずなる。SCADA、
DCS、PLC その他の制埡システム蚭定を含んだこれら ICS は、産業甚制埡業界によく芋られる。ICS
は䞀般的に電気、䞊䞋氎、石油・ガス、茞送、化孊、医薬品、パルプ・補玙、食品・飲料及び組立補
造自動車、航空宇宙、耐久消費財等業界で利甚されおいる。SCADA は、集䞭デヌタ取埗監芖制
埡により、分散化された資産を制埡するために、通垞䜿甚する。DCS は、ロヌカル゚リア内にある工
堎等の生産システムを、監芖・芏制制埡により制埡するために、通垞䜿甚する。PLC は、特殊甚途で
の離散制埡に通垞䜿甚し、芏制制埡を通垞行う。このような制埡システムは、高床に連携・盞互䟝存
したシステムずなる、米囜の重芁むンフラの運営に緊芁な圹割を果たしおいる。囜の重芁むンフラの
およそ 90%は、私䌁業が保有し運営しおいる点に泚意すべきである。連邊政府機関も前述の ICS の倚
くを運営しおいるが、そのほかにも航空亀通管制や物流凊理郵䟿物の取扱等などがある。本文曞
ではこのような ICS の抂芁及び䞀般的なシステムトポロゞヌに぀いお瀺し、システムにずっおの䞀般
的な脅嚁ず脆匱性を特定し、関連リスクを䜎枛するための掚奚セキュリティ察策を提瀺する。
初期の ICS は、特殊なハヌドり゚アず゜フトり゚アを䜿甚しお専甚制埡プロトコルを実行する隔絶さ
れたシステムだったため、埓来の情報技術ITシステムずは類䌌点がほずんどなかった。ICS コン
ポヌネントの倚くは物理的に安党な゚リア内に眮かれ、IT ネットワヌクやシステムに接続されおいな
かった。昚今、広く利甚可胜な䜎コストのむンタヌネットプロトコルIPデバむスが専甚゜リュヌ
ションに取っお代わり぀぀あるこずから、サむバヌセキュリティの脆匱性やむンシデントが生じる蓋
然性が高たっおいる。ICS は IT ゜リュヌションを採甚しお、䌁業ビゞネスシステムぞの接続性やリモ
ヌトアクセス胜力を高め、たた、業界暙準コンピュヌタ、オペレヌティングシステムOS及びネッ
トワヌクプロトコルを䜿甚しお蚭蚈・実装されるようになっおいる。このため ICS は次第に IT シス
テムず類䌌性を持぀ようになっおきた。このような統合化は新たな IT 胜力をサポヌトするが、それ
以前のシステムに比べるず、倖界からの隔絶性が栌段に劣るため、セキュリティの必芁性が増す。ワ
むダレスネットワヌクの利甚床が高たるに぀れお、物理的に近い堎所にいるが、装備品ぞの盎接的な
物理的アクセスはできない倖敵による ICS 実装リスクが増倧する。セキュリティ゜リュヌションは、
䞀般的な IT システムにおけるセキュリティ問題を扱うようにできおいるので、ICS 環境に持ち蟌む堎
合には特別な泚意が欠かせない。堎合によっおは、その ICS 環境に特化した新しいセキュリティ゜リ
ュヌションが必芁ずなる。
いく぀かの特城は䌌おいおも、ICS には埓来の情報凊理システムずは異なる特城もある。そうした違
いの倚くは、ICS で実行される論理が実䞖界に盎接的な圱響を及がすずいう事実から生じたものであ
る。そうした特性の䞭には、人の健康や安党に察する深刻なリスク、重倧な環境砎壊のほか、生産量
䜎枛、囜家経枈ぞの悪圱響、秘密情報の挏掩ずいった重倧な財務問題も含たれおいる。ICS の性胜及
び信頌性芁件は独特で、普通の IT 関係者には奇異に芋える OS やアプリケヌションを䜿甚するこずが
倚い。曎に安党性ず効率性の目暙は、制埡システムの蚭蚈・運甚䞊、セキュリティず競合する堎合が
ある。
サむバヌセキュリティは、珟代の産業工皋を安党か぀高い信頌性をもっお運甚する䞊で䞍可欠である
こずから、ICS サむバヌセキュリティプログラムは、産業珟堎においおも䌁業サむバヌセキュリティ
プログラムにおいおも、垞により広範な ICS の安党性・信頌性プログラムの䞀郚ずなるべきである。
制埡システムに察する脅嚁の源は倚岐にわたり、敵意を持぀政府、テロリストグルヌプ、䞍満を抱い
た埓業員、悪意を持぀䟵入者、耇雑性、事故、自然灜害、内郚関係者の意図的又は偶発的行為等があ
る。ICS セキュリティの目的は、䞀般的に可甚性ず完党性を優先事項ずし、機密性がそれに続く。

2

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Possible incidents an ICS may face include the following:


Blocked or delayed flow of information through ICS networks, which could disrupt ICS operation.



Unauthorized changes to instructions, commands, or alarm thresholds, which could damage, disable,
or shut down equipment, create environmental impacts, and/or endanger human life.



Inaccurate information sent to system operators, either to disguise unauthorized changes, or to cause
the operators to initiate inappropriate actions, which could have various negative effects.



ICS software or configuration settings modified, or ICS software infected with malware, which could
have various negative effects.



Interference with the operation of equipment protection systems, which could endanger costly and
difficult-to-replace equipment.



Interference with the operation of safety systems, which could endanger human life.

Major security objectives for an ICS implementation should include the following:


Restricting logical access to the ICS network and network activity. This may include using
unidirectional gateways, a demilitarized zone (DMZ) network architecture with firewalls to prevent
network traffic from passing directly between the corporate and ICS networks, and having separate
authentication mechanisms and credentials for users of the corporate and ICS networks. The ICS
should also use a network topology that has multiple layers, with the most critical communications
occurring in the most secure and reliable layer.



Restricting physical access to the ICS network and devices. Unauthorized physical access to
components could cause serious disruption of the ICS’s functionality. A combination of physical
access controls should be used, such as locks, card readers, and/or guards.



Protecting individual ICS components from exploitation. This includes deploying security patches
in as expeditious a manner as possible, after testing them under field conditions; disabling all unused
ports and services and assuring that they remain disabled; restricting ICS user privileges to only those
that are required for each person’s role; tracking and monitoring audit trails; and using security
controls such as antivirus software and file integrity checking software where technically feasible to
prevent, deter, detect, and mitigate malware.



Restricting unauthorized modification of data. This includes data that is in transit (at least across
the network boundaries) and at rest.



Detecting security events and incidents. Detecting security events, which have not yet escalated into
incidents, can help defenders break the attack chain before attackers attain their objectives. This
includes the capability to detect failed ICS components, unavailable services, and exhausted resources
that are important to provide proper and safe functioning of the ICS.



Maintaining functionality during adverse conditions. This involves designing the ICS so that each
critical component has a redundant counterpart. Additionally, if a component fails, it should fail in a
manner that does not generate unnecessary traffic on the ICS or other networks, or does not cause
another problem elsewhere, such as a cascading event. The ICS should also allow for graceful
degradation such as moving from "normal operation" with full automation to "emergency operation"
with operators more involved and less automation to "manual operation" with no automation.

3

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS が盎面し埗るむンシデントには次のようなものがある。

 ICS ネットワヌク経由情報の遮断又は遅延。ICS の運甚䞭断に至りかねない。
 呜什、コマンド又はアラヌム閟倀の無断倉曎。装備品の障害、故障若しくは遮断、環境ぞの
圱響又は人呜ぞの危険を生じかねない。
 無断倉曎の隠蔜又は操䜜員に誀操䜜を行わせるこずを目的ずした、システムオペレヌタぞの
誀情報送達。様々な悪圱響を生じかねない。
 ICS ゜フトり゚ア若しくは蚭定の倉曎又は ICS ゜フトり゚アのマルり゚ア感染。様々な悪圱
響を生じかねない。
 装備品保護装眮ずの干枉。高額で換装困難な装備品を危険状態に眮きかねない。
 安党装眮の運甚に察する干枉。人呜を危険にさらしかねない。
ICS 実装の䞻なセキュリティ䞊の達成目暙には以䞋を含めるべきだ。

 ICS ネットワヌクぞの論理的なアクセスずネットワヌク䞊の掻動の制限。これには䌁業ネッ
トワヌクず ICS ネットワヌク間の盎接的なネットワヌクトラフィックを防止し、䌁業ネッ
トワヌク及び ICS ネットワヌクナヌザ向けに、独立した認蚌メカニズムず認蚌情報を持぀
䞀方向性ゲヌトりェむ、非歊装地垯DMZのファむアりォヌル付きネットワヌクアヌキ
テクチャの利甚が含たれる。たた ICS は、最もセキュアで信頌性の高いレむダヌで最重芁
通信を行う、マルチレむダヌネットワヌクトポロゞヌを利甚すべきである。
 ICS ネットワヌク及びデバむスぞの物理的アクセス制限。コンポヌネントぞの䞍正な物理ア
クセスは、ICS の機胜に重倧な䞭断をもたらしかねない。斜錠、カヌドリヌダヌ、譊備員等
の物理アクセス制埡を䜵甚すべきである。
 個々の ICS コンポヌネントの悪甚防止。これには次の内容が含たれる。セキュリティパッチ
をフィヌルド条件䞋で詊隓埌、できるだけ迅速に展開する。䜿甚しおいないポヌト及びサヌ
ビスを党お䜿甚䞍胜にし、䜿甚䞍胜状態が保たれるようにする。ICS ナヌザ暩限の付䞎を、
圹割䞊必芁ずする人員に限定する。監査蚌跡の远跡及び監芖。技術的に実行可胜な堎合、ア
ンチりむルス゜フトり゚アやファむル敎合性確認゜フトり゚ア等のセキュリティ管理を利甚
し、マルり゚アを予防・抑止・怜出・緩和する。
 デヌタの無断倉曎制限。これには送信䞭のデヌタ少なくずもネットワヌク境界を越えたも
の及び静止デヌタが含たれる。
 セキュリティ䞊のむベント及びむンシデントの怜出。ただむンシデントには至らないセキュ
リティむベントを怜出できれば、防埡偎は、攻撃偎の目的達成前に攻撃連鎖を断ち切るこず
ができる。これには ICS が適正か぀安党な機胜を発揮する䞊で重芁な、ICS コンポヌネント
の障害、䜿甚䞍胜のサヌビス及び枯枇したリ゜ヌスを怜出する胜力が含たれる。
 悪条件䞋での機胜保持。これには各重芁コンポヌネントに冗長性を持たせる ICS 蚭蚈が関係
しおくる。たた、あるコンポヌネントに障害が出た堎合でも、ICS その他のネットワヌクに
䞍芁のトラフィックを生じさせず、連鎖むベントなど別の問題を掟生させおはならない。た
た ICS は、機胜が䜎䞋する堎合であっおも、党自動の「正垞運転」から操䜜員も加わった
半自動の「緊急運転」ぞ、次いで完党な「手動運転」ぞず機胜が埐々に䜎䞋するグレヌスフ
ルデグラデヌションになっおいるべきである。

4

SPECIAL PUBLICATION 800-82 REVISION 2



GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Restoring the system after an incident. Incidents are inevitable and an incident response plan is
essential. A major characteristic of a good security program is how quickly the system can be
recovered after an incident has occurred.

To properly address security in an ICS, it is essential for a cross-functional cybersecurity team to share
their varied domain knowledge and experience to evaluate and mitigate risk to the ICS. The cybersecurity
team should consist of a member of the organization’s IT staff, control engineer, control system operator,
network and system security expert, a member of the management staff, and a member of the physical
security department at a minimum. For continuity and completeness, the cybersecurity team should consult
with the control system vendor and/or system integrator as well. The cybersecurity team should coordinate
closely with site management (e.g., facility superintendent) and the company’s Chief Information Officer
(CIO) or Chief Security Officer (CSO), who in turn, accepts complete responsibility and accountability for
the cybersecurity of the ICS, and for any safety incidents, reliability incidents, or equipment damage caused
directly or indirectly by cyber incidents. An effective cybersecurity program for an ICS should apply a
strategy known as “defense-in-depth,” layering security mechanisms such that the impact of a failure in any
one mechanism is minimized. Organizations should not rely on “security by obscurity.”
In a typical ICS this means a defense-in-depth strategy that includes:


Developing security policies, procedures, training and educational material that applies specifically to
the ICS.



Considering ICS security policies and procedures based on the Homeland Security Advisory System
Threat Level, deploying increasingly heightened security postures as the Threat Level increases.



Addressing security throughout the lifecycle of the ICS from architecture design to procurement to
installation to maintenance to decommissioning.



Implementing a network topology for the ICS that has multiple layers, with the most critical
communications occurring in the most secure and reliable layer.



Providing logical separation between the corporate and ICS networks (e.g., stateful inspection
firewall(s) between the networks, unidirectional gateways).



Employing a DMZ network architecture (i.e., prevent direct traffic between the corporate and ICS
networks).



Ensuring that critical components are redundant and are on redundant networks.



Designing critical systems for graceful degradation (fault tolerant) to prevent catastrophic cascading
events.



Disabling unused ports and services on ICS devices after testing to assure this will not impact ICS
operation.



Restricting physical access to the ICS network and devices.



Restricting ICS user privileges to only those that are required to perform each person’s job (i.e.,
establishing role-based access control and configuring each role based on the principle of least
privilege).



Using separate authentication mechanisms and credentials for users of the ICS network and the
corporate network (i.e., ICS network accounts do not use corporate network user accounts).

5

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 むンシデント埌のシステム埩旧。むンシデントは避けられないので、むンシデント察凊蚈画
が䞍可欠ずなる。優れたセキュリティプログラムの䞻芁な特城は、むンシデント発生埌、シ
ステムをどれだけ迅速に埩旧できるかずいう点にある。
ICS においおセキュリティを適正に確保するには、機胜暪断型サむバヌセキュリティチヌムが倚
様な分野の知識・経隓を共有し合い、ICS のリスクを評䟡・緩和するこずが䞍可欠ずなる。サむ
バヌセキュリティチヌムの構成は、最䜎でも組織の IT 芁員、制埡゚ンゞニア、制埡システムオ
ペレヌタ、ネットワヌク及びシステムセキュリティ専門員、経営に関わる芁員及び物理的セキュ
リティ郚門芁員ずすべきである。継続性ず完党性を確保するため、サむバヌセキュリティチヌム
は、制埡システムのベンダヌやシステムむンテグレヌタずも協議すべきである。たた珟堎管理者
斜蚭責任者等のほか、ICS のサむバヌセキュリティ、安党䞊のむンシデント、信頌性䞊のむ
ンシデント又はサむバヌむンシデントにより盎接・間接に生じた装備品の損害に党責任を負う䌁
業の最高情報責任者CIO又は最高セキュリティ責任者CSOずも密接に連携を取るべきで
ある。ICS の効果的なサむバヌセキュリティプログラムは「倚局防埡defense-in-depth」ずし
お知られる戊略、぀たり、あるメカニズムの障害の圱響が最小限に食い止められる、レむダリン
グセキュリティメカニズムを適甚すべきである。組織は「曖昧なセキュリティ」に䟝存すべきで
ない。
このこずは、䞀般的な ICS では以䞋の内容を含んだ倚局防埡戊略を意味する。

 ICS に特化しお適甚されるセキュリティポリシヌ、手順及び教育蚓緎資料の䜜成
 囜土安党保障アドバむザリヌシステム脅嚁レベルに基づく ICS セキュリティポリシヌ及び手
順の怜蚎、脅嚁レベルの䞊昇に远随しお段階的に高たるセキュリティ態勢の保持
 アヌキテクチャ蚭蚈から調達、蚭眮、保守、廃棄たで、ICS の党ラむフサむクルを通じたセ
キュリティの考慮
 最もセキュアで信頌性の高いレむダヌで最重芁通信を行う、マルチレむダヌICS ネットワヌ
クトポロゞヌの実装
 䌁業ネットワヌクず ICS ネットワヌク間の論理的分割ネットワヌク間や䞀方向性ゲヌトり
ェむ間のステヌトフルむンスペクションファむアりォヌルなど
 DMZ ネットワヌクアヌキテクチャの採甚䌁業ネットワヌクず ICS ネットワヌク間の盎接
トラフィックを防止
 重芁コンポヌネントの冗長化ず冗長性ネットワヌク䞊での䜿甚
 壊滅的な連鎖むベントを防ぐグレヌスフルデグラデヌションフォヌルトトレラントを備
えた重芁システムの蚭蚈
 ICS の運甚に圱響がないこずを怜蚌した䞊で、ICS デバむス䞊の䞍䜿甚ポヌト及びサヌビス
を䜿甚䞍胜にするこず
 ICS ネットワヌク及びデバむスぞの物理的アクセス制限。
 各人の業務を行うために必芁な ICS ナヌザ暩限に限定した、暩限の付䞎圹割に基づくアク
セス制埡ず最小暩限原則に基づく圹割構成
 ICS ネットワヌク及び䌁業ネットワヌクナヌザ向けの独立した認蚌メカニズムず認蚌情報の
䜿甚ICS ネットワヌクアカりントに䌁業ネットワヌクナヌザのアカりントを䜿甚しない

6

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Using modern technology, such as smart cards for Personal Identity Verification (PIV).



Implementing security controls such as intrusion detection software, antivirus software and file
integrity checking software, where technically feasible, to prevent, deter, detect, and mitigate the
introduction, exposure, and propagation of malicious software to, within, and from the ICS.



Applying security techniques such as encryption and/or cryptographic hashes to ICS data storage and
communications where determined appropriate.



Expeditiously deploying security patches after testing all patches under field conditions on a test
system if possible, before installation on the ICS.



Tracking and monitoring audit trails on critical areas of the ICS.



Employing reliable and secure network protocols and services where feasible.

The National Institute of Standards and Technology (NIST), in cooperation with the public and private
sector ICS community, has developed specific guidance on the application of the security controls in NIST
Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information
Systems and Organizations [22], to ICS.
While many controls in Appendix F of NIST SP 800-53 are applicable to ICS as written, many controls
require ICS-specific interpretation and/or augmentation by adding one or more of the following to the
control:





ICS Supplemental Guidance provides organizations with additional information on the
application of the security controls and control enhancements in Appendix F of NIST SP 800-53
to ICS and the environments in which these specialized systems operate. The Supplemental
Guidance also provides information as to why a particular security control or control
enhancement may not be applicable in some ICS environments and may be a candidate for
tailoring (i.e., the application of scoping guidance and/or compensating controls). ICS
Supplemental Guidance does not replace the original Supplemental Guidance in Appendix F of
NIST SP 800-53.
ICS Enhancements (one or more) that provide enhancement augmentations to the original control
that may be required for some ICS.
ICS Enhancement Supplemental Guidance that provides guidance on how the control
enhancement applies, or does not apply, in ICS environments.

The most successful method for securing an ICS is to gather industry recommended practices and engage in
a proactive, collaborative effort between management, the controls engineer and operator, the IT
organization, and a trusted automation advisor. This team should draw upon the wealth of information
available from ongoing federal government, industry groups, vendor and standards organizational activities
listed in Appendix D—.

7

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 身分蚌明PIV甚スマヌトカヌドなど最新技術の䜿甚
 技術的に実行可胜な堎合、ICS に入る、ICS から出る、および ICS 内にあるマルり゚アの導
入・曝露・䌝播を予防・抑止・怜出・緩和するための䟵入怜知゜フトり゚ア、アンチりむル
ス゜フトり゚ア、ファむル敎合性確認゜フトり゚ア等によるセキュリティ管理
 適圓であれば、ICS デヌタストレヌゞ及び通信ぞの暗号化又は暗号孊的ハッシュ等セキュリ
ティ技術の適甚
 ICS ぞのむンストヌル前に可胜であれば、フィヌルド条件䞋で詊隓装眮により怜蚌したセキ
ュリティパッチの迅速な展開
 ICS 重芁領域での監査蚌跡の远跡及び監芖
 実行可胜なら信頌性の高いセキュアなネットワヌクプロトコル及びサヌビスの採甚
米囜暙準技術局NISTは官民 ICS 共同䜓の協力を埗お、NISTSPSP800-53 第 4 版『連邊情
報システム・組織のセキュリティ・プラむバシヌ管理』[22]に蚘茉される ICS ぞのセキュリティ
管理の適甚に関しお、具䜓的なガむダンスを䜜成した。
NIST SP 800-53 の付録 F に蚘茉される制埡の倚くは、蚘述どおり ICS に適甚可胜ではあるが、倧
抵は ICS 特有の解釈が必芁で、以䞋に瀺すものを少なくずも 1 ぀远加する必芁がある。






ICS 補足ガむダンス。NIST SP 800-53 の付録 F に蚘茉されるセキュリティ管理及び
管理拡匵を、ICS 及びこれら専甚システムの実行環境に適甚するための補足情報を
瀺す。たた、ICS 環境によっおは特定のセキュリティ管理や管理拡匵が適甚できず、
調敎が必芁ずなる理由に぀いおも瀺すスコヌピングガむダンス又は補完制埡の適
甚。ICS 補足ガむダンスは、NIST SP 800-53 の付録 F にあるオリゞナルの補足ガ
むダンスに代わるものではない。
ICS 拡匵1 ぀又は耇数。ICS によっおは必芁ずなる元々の制埡に拡匵を加
える。
ICS 拡匵補足ガむダンス。ICS 環境においお管理拡匵適甚の可吊に぀いお
瀺す。

ICS のセキュリティ確保に最も成果の䞊がる方法は、業界の掚奚芏範を蓄積し、幹郚、制埡゚ン
ゞニア及び操䜜員、IT 組織䞊びに信甚のおけるオヌトメヌションアドバむザヌ間で、積極的に協
調しお取り組むこずである。このチヌムは、連邊政府、業界グルヌプ、ベンダヌ及び付録 D に掲
茉されおいる芏栌団䜓からの豊富な情報を利甚すべきである。

8

SPECIAL PUBLICATION 800-82 REVISION 2

1.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Introduction

1.1 Purpose and Scope
The purpose of this document is to provide guidance for
securing industrial control systems (ICS), including
supervisory control and data acquisition (SCADA)
systems, distributed control systems (DCS), and other
systems performing control functions. The document
provides a notional overview of ICS, reviews typical
system topologies and architectures, identifies known
threats and vulnerabilities to these systems, and provides
recommended security countermeasures to mitigate the
associated risks. Additionally, it presents an ICS-tailored
security control overlay, based on NIST SP 800-53 Rev. 4
[22], to provide a customization of controls as they apply
to the unique characteristics of the ICS domain. The body
of the document provides context for the overlay, but the
overlay is intended to stand alone.
ICS are found in many industries such as electric, water
and wastewater, oil and natural gas, chemical,
pharmaceutical, pulp and paper, food and beverage, and
discrete manufacturing (e.g., automotive, aerospace, and
durable goods). Because there are many different types of
ICS with varying levels of potential risk and impact, the
document provides a list of many different methods and
techniques for securing ICS. The document should not be
used purely as a checklist to secure a specific system.
Readers are encouraged to perform a risk-based
assessment on their systems and to tailor the
recommended guidelines and solutions to meet their
specific security, business and operational requirements.
The range of applicability of the basic concepts for
securing control systems presented in this document
continues to expand.

1.2 Audience
This document covers details specific to ICS. Readers of
this document should be acquainted with general computer
security concepts, and communication protocols such as
those used in networking. The document is technical in
nature; however, it provides the necessary background to
understand the topics that are discussed.

9

SP800-82 第 2 版

1.
1.1

産業甚制埡システムICSセキュリティガむド

はじめに
目的及び適甚範囲

本文曞の目的は、産業甚制埡システムICSのセ
キュリティを確保するためのガむダンスを瀺すこ
ずにあり、ICS には SCADA、DCS、その他の制埡
システムが含たれる。本文曞ではこのような ICS
の抂念に぀いお抂芁を瀺し、䞀般的なシステムト
ポロゞヌずアヌキテクチャに぀いお考察し、シス
テムに察する既知の脅嚁ず脆匱性を特定し、関連
リスクを䜎枛するための掚奚セキュリティ察策を
提瀺する。たた、NIST SP 800-53 改蚂 4 [ 2 2 ] に
埓い、ICS 向けに調敎されたセキュリティ
管 理 オ ヌ バ ヌ レ ã‚€ を 提 瀺 し 、 管理を ICS 領域
の独特な特城に適甚する際のカスタマむズに぀い
お瀺す。
文曞はオヌバヌレむの内容を提瀺するが、オヌバ
ヌレむはそれ自䜓が独立したものである。
ICS は電気、䞊䞋氎、石油・ガス、化孊、医薬品、
パルプ・補玙、食品・飲料及び組立補造自動車、
航空宇宙、耐久消費財等業界で利甚されおいる。
リスクレベルやその圱響が䞀様でない皮々の ICS
があるため、本文曞では ICS セキュリティの方法
ず技術のリストを瀺す。本文曞は、特定のシステ
ムセキュリティを確保するための単なるチェック
リストずしお䜿甚すべきでない。
読者は、䜿甚しおいるシステムに関しお、リスク
に立脚した評䟡を行い、掚奚されおいるガむドラ
むン及び゜リュヌションを固有のセキュリティ、
業務および運甚䞊の芁件に合うように調敎すべき
である。本文曞に瀺される制埡システムのセキュ
リティ確保に関する基本抂念の適甚範囲は、今埌
も匕き続き拡倧する。

1.2

察象者

本文曞には ICS に特有の詳现な事項が網矅されお
いる。読者は、䞀般的なコンピュヌタセキュリテ
ィ抂念およびネットワヌクで䜿甚される通信プロ
トコルに通じおいるべきである。本文曞の内容は、
その性質䞊技術的ではあるが、蚘述されおいる論
題を理解するために必芁な背景をも提瀺する。

10

倧統領呜什 13636「重芁むンフラスト
ラクチャのサむバヌセキュリティ改
善」ずの関係
米囜の囜家及び経枈安党保障は、高い
信頌性をもっお重芁むンフラが機胜す
るこずにかかっおおり、倧統領呜什
13636「重芁むンフラストラクチャの
サむバヌセキュリティ改善」[82]は
NIST に察しお、関係者ず協働し、重芁
むンフラぞのサむバヌリスクを枛らす
ための自発的枠組みフレヌムワヌ
クを構築するよう呜じおいる。サむ
バヌセキュリティフレヌムワヌク
CSF[83]は芏栌、ガむドラむン及び
最良芏範からなり、重芁むンフラの保
護を促進する。このフレヌムワヌク
は、優先的で柔軟性があり、反埩可胜
でパフォヌマンス本䜍の、費甚効果の
高い取組により、重芁むンフラの所有
者及び運甚者が䌁業秘密、個人情報及
び人暩を保護し぀぀、サむバヌセキュ
リティ関連リスクを管理できるように
支揎する。最初の CSF は 2014 幎 2 月
に発衚され、倚様な郚門や皮々の運甚
環境に適甚できるだけの柔軟性を備え
た、囜家レベルのフレヌムワヌクずな
った。この CSF は、関係者からの情報
を基に䜜成され、倚皮倚様な郚門にお
ける既存業務が、このフレヌムワヌク
内で利甚できるようにした。
産業甚制埡システムのサむバヌセキュ
リティ芏栌、ガむドラむン及び芏範を
掻甚しお、組織のリスク管理プログラ
ムずの関係で CSF の機胜を怜蚎するこ
ずができる。

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The intended audience is varied and includes the following:


Control engineers, integrators, and architects who design or implement secure ICS.

 System administrators, engineers, and other information technology (IT) professionals who administer,
patch, or secure ICS.


Security consultants who perform security assessments and penetration testing of ICS.



Managers who are responsible for ICS.



Senior management who are trying to understand implications and consequences as they justify and
apply an ICS cybersecurity program to help mitigate impacts to business functionality.



Researchers and analysts who are trying to understand the unique security needs of ICS.



Vendors that are developing products that will be deployed as part of an ICS.

1.3 Document Structure
The remainder of this guide is divided into the following major sections:


Section 2 provides an overview of ICS including a comparison between ICS and IT systems.



Section 3 provides a discussion of ICS risk management and assessment.



Section 4 provides an overview of the development and deployment of an ICS security program to
mitigate the risk of the vulnerabilities identified in Appendix C.



Section 5 provides recommendations for integrating security into network architectures typically
found in ICS, with an emphasis on network segregation practices.



Section 6 provides a summary of the management, operational, and technical controls identified in
NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and
Organizations, and provides initial guidance on how these security controls apply to ICS.

The guide also contains several appendices with supporting material, as follows:


Appendix A— provides a list of acronyms and abbreviations used in this document.



Appendix B— provides a glossary of terms used in this document.



Appendix C— provides a list of ICS threats, vulnerabilities and incidents.



Appendix D— provides a list of ICS security activities.



Appendix E— provides a list of ICS security capabilities and tools



Appendix F— provides a list of references used in the development of this document.



Appendix G— provides an ICS overlay, listing security controls, enhancements, and supplemental
guidance that apply specifically to ICS.

11

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

所期の察象は倚岐にわたるが、以䞋を含む。

 セキュアな ICS の蚭蚈又は実装に関わる制埡゚ンゞニア、むンテグレヌタ及び蚭蚈者
 ICS の管理、パッチたたはセキュリティに携わるシステム管理者、゚ンゞニアその他 IT 専門
員
 ICS のセキュリティ評䟡及びペネトレヌション・テストを行うセキュリティコンサルタント
 ICS 担圓幹郚
 事業機胜ぞの圱響を緩和する ICS サむバヌセキュリティプログラムの承認・適甚を行う際に、
その意味ず結果の理解に努める䞊玚管理職
 ICS 独特のセキュリティニヌズの理解に努める研究者及びアナリスト
 ICS の䞀郚ずしお展開される補品の開発に圓たるベンダヌ

1.3

文曞の構成

本ガむドのこれ以降の郚分は、以䞋のセクションに倧別される。

 セクション 2ICS システムず IT システムの比范等、ICS の抂芁を瀺す。
 セクション 3ICS のリスク管理ずリスク評䟡に぀いお説明する。
 セクション 4付録 C で明らかにされおいる脆匱性リスクを緩和する、ICS セキュリティプ
ログラムの開発・展開に぀いお抂芁を瀺す。
 セクション 5ICS の䞀般的なネットワヌクアヌキテクチャにセキュリティを組み蟌む䞊で
の掚奚事項を瀺す。特にネットワヌク隔離芏範に぀いお特筆する。
 セクション 6NISTSP800-53『連邊情報システム・組織のセキュリティ・プラむバシヌ管
理』に定める管理・運甚・技術制埡をずりたずめ、このようなセキュリティ管理を ICS に
適甚する方法に぀いお初期のガむダンスを瀺す。
たた本ガむドには、補足資料を提䟛する以䞋の付録も含たれる。

 付録 A—本曞で䜿甚する頭字語及び略語のリスト
 付録 B—本曞で䜿甚する甚語集
 付録 C—ICS の脅嚁、脆匱性及びむンシデントリスト
 付録 D—ICS セキュリティ掻動リスト
 付録 E—ICS セキュリティ胜力・ツヌルリスト
 付録 F—本曞の䜜成時に䜿甚した参考文献リスト
 付録 G—ICS に特化しお適甚されるセキュリティ管理、拡匵及び補足ガむダンスリストを掲
茉した ICS オヌバヌレむ

12

SPECIAL PUBLICATION 800-82 REVISION 2

2.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Overview of Industrial Control Systems

Industrial control system (ICS) is a general term that encompasses several types of control systems,
including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS),
and other control system configurations such as Programmable Logic Controllers (PLC) often found in the
industrial sectors and critical infrastructures. An ICS consists of combinations of control components (e.g.,
electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (e.g.,
manufacturing, transportation of matter or energy). The part of the system primarily concerned with
producing the output is referred to as the process. The control part of the system includes the specification
of the desired output or performance. Control can be fully automated or may include a human in the loop.
Systems can be configured to operate open-loop, closed-loop, and manual mode. In open-loop control
systems the output is controlled by established settings. In closed-loop control systems, the output has an
effect on the input in such a way as to maintain the desired objective. In manual mode the system is
controlled completely by humans. The part of the system primarily concerned with maintaining
conformance with specifications is referred to as the controller (or control). A typical ICS may contain
numerous control loops, Human Machine Interfaces (HMIs), and remote diagnostics and maintenance tools
built using an array of network protocols. ICS control industrial processes are typically used in electrical,
water and wastewater, oil and natural gas, chemical, transportation, pharmaceutical, pulp and paper, food
and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods) industries.
ICS are critical to the operation of the U.S. critical infrastructures that are often highly interconnected and
mutually dependent systems. It is important to note that approximately 85 percent of the nation's critical
infrastructures are privately owned and operated 1. Federal agencies also operate many of the industrial
processes mentioned above as well as air traffic control. This section provides an overview of SCADA,
DCS, and PLC systems, including typical topologies and components. Several diagrams are presented to
depict the network topology, connections, components, and protocols typically found on each system to
facilitate the understanding of these systems. These examples only attempt to identify notional topology
concepts. Actual implementations of ICS may be hybrids that blur the line between DCS and SCADA
systems. Note that the diagrams in this section do not focus on securing ICS. Security architecture and
security controls are discussed in Section 5 and Section 6 of this document respectively.

2.1 Evolution of Industrial Control Systems
Many of today’s ICS evolved from the insertion of IT capabilities into existing physical systems, often
replacing or supplementing physical control mechanisms. For example, embedded digital controls replaced
analog mechanical controls in rotating machines and engines. Improvements in cost-and performance have
encouraged this evolution, resulting in many of today’s “smart” technologies such as the smart electric grid,
smart transportation, smart buildings, and smart manufacturing. While this increases the connectivity and
criticality of these systems, it also creates a greater need for their adaptability, resilience, safety, and
security.
Engineering of ICS continues to evolve to provide new capabilities while maintaining the typical long
lifecycles of these systems. The introduction of IT capabilities into physical systems presents emergent
behavior that has security implications. Engineering models and analysis are evolving to address these
emergent properties including safety, security, privacy, and environmental impact interdependencies.

1

http://www.dhs.gov/critical-infrastructure-sector-partnerships (last updated April 2014)

13

SP800-82 第 2 版

2.

産業甚制埡システムICSセキュリティガむド

産業甚制埡システムの抂芁

産業甚制埡システムICSずは、数皮の制埡システムを包括した汎甚的な甚語で、これには各
皮産業郚門や重芁むンフラで䜿甚されおいる SCADA、DCS、PLC、その他の制埡システムの蚭
定が含たれる。ICS は産業䞊の目的物品や゚ネルギヌの生産・茞送等を達成するために䜵甚
される制埡甚コンポヌネント電気・機械・油圧・空気等が組み合わさっお構成されおいる。
特に出力を産み出すシステムの䞀郚をプロセスず呌ぶ。システムの制埡郚分には、所期の出力又
はパフォヌマンスの仕様が含たれる。制埡は完党自動化が可胜で、ルヌプ䞭に人間が含たれる堎
合もある。システムはオヌプンルヌプ、クロヌズドルヌプ及び手動モヌドのいずれにも蚭定可胜
である。オヌプンルヌプ制埡システムでは、出力は蚭定した内容に埓っお制埡される。クロヌズ
ドルヌプ制埡システムでは、所期の目的を維持するように、出力が入力に圱響を及がす。手動モ
ヌドでは、人間が党面的にシステムを制埡する。特に仕様を維持しようずするシステムの䞀郚を
コントロヌラ又は制埡ず呌ぶ。䞀般的な ICS には、倚様なネットワヌクプロトコルを䜿甚し
お構築された皮々の制埡ルヌプ、マンマシンむンタフェヌスHMI及びリモヌト蚺断保守ツヌ
ルが含たれる。ICS の制埡甚産業プロセスは、䞀般に電気、䞊䞋氎、石油、倩然ガス、化孊、茞
送、医薬品、パルプ・補玙、食品・飲料及び組立補造自動車、航空宇宙、耐久消費財等業界
で利甚されおいる。
ICS は、高床に連携・盞互䟝存したシステムずなる堎合が倚い、米囜の重芁むンフラの運営に緊
芁な圹割を果たしおいる。囜の重芁むンフラのおよそ 85%は、私䌁業が保有し運営しおいる点に
泚意すべきである。 2連邊政府機関は、䞊蚘の産業甚プロセスのほか航空亀通管制でも倚くの産
業甚プロセスを運甚しおいる。このセクションでは、䞀般的なトポロゞヌやコンポヌネントを含
め、SCADA、DCS 及び PLC システムに぀いお抂芁を瀺す。これらシステムに察する理解を容易
にするため、各システムの䞀般的なネットワヌクトポロゞヌ、接続、コンポヌネント及びプロト
コルを図瀺する。このような䟋は、単に抜象的なトポロゞヌ抂念を明らかにするためのものであ
る。ICS の実際の実装はハむブリッドで、DCS ず SCADA の境界が曖昧である。本セクションの
図は、ICS のセキュリティに特化したものではない。セキュリティアヌキテクチャ及びセキュリ
ティ管理に぀いおは、セクション 5 ずセクション 6 で取り䞊げる。

2.1

産業甚制埡システムの進化

今日の ICS の倚くは、IT 胜力を既存の物理システムに挿入したずころから進化しおおり、物理制
埡メカニズムに代わるものや補完するものが倚い。䟋えば、組蟌デゞタル制埡は、回転匏機械や
゚ンゞンのアナログ匏機械制埡に取っお代わった。コストパフォヌマンスの改善がこの進化を促
し、スマヌト配電網、スマヌト茞送、スマヌト建蚭、スパヌト補造等、今日の「スマヌト」テク
ノロゞヌをもたらした。これにより、これらシステムの接続性や重芁性が増しただけでなく、そ
の適応性、回埩力、安党性及びセキュリティに察する倚倧な需芁をも創出した。
ICS の゚ンゞニアリングは匕き続き進化しおおり、新たな胜力を付䞎する䞀方、これらシステム
の抂しお長いラむフサむクルを維持しおいる。IT 胜力を物理システムに導入するこずは、セキュ
リティ䞊の意味を持぀新たな行動ずなっおいる。゚ンゞニアリングモデル及び分析は進化の途䞊
にあり、安党性、セキュリティ、プラむバシヌ、環境圱響ずいった盞互䟝存性のある新たな属性
を取り䞊げるようになっおいる。

2

http://www.dhs.gov/critical-infrastructure-sector-partnerships (最終曎新 2014 幎 4 月)

14

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

2.2 ICS Industrial Sectors and Their Interdependencies
Control systems are used in many different industrial sectors and critical infrastructures, including
manufacturing, distribution, and transportation.

2.2.1 Manufacturing Industries
Manufacturing presents a large and diverse industrial sector with many different processes, which can be
categorized into process-based and discrete-based manufacturing.
The process-based manufacturing industries typically utilize two main processes [1]:


Continuous Manufacturing Processes. These processes run continuously, often with transitions to
make different grades of a product. Typical continuous manufacturing processes include fuel or steam
flow in a power plant, petroleum in a refinery, and distillation in a chemical plant.



Batch Manufacturing Processes. These processes have distinct processing steps, conducted on a
quantity of material. There is a distinct start and end step to a batch process with the possibility of
brief steady state operations during intermediate steps. Typical batch manufacturing processes include
food manufacturing.

The discrete-based manufacturing industries typically conduct a series of steps on a single device to create
the end product. Electronic and mechanical parts assembly and parts machining are typical examples of this
type of industry.
Both process-based and discrete-based industries utilize the same types of control systems, sensors, and
networks. Some facilities are a hybrid of discrete and process-based manufacturing.

2.2.2 Distribution Industries
ICS are used to control geographically dispersed assets, often scattered over thousands of square kilometers,
including distribution systems such as water distribution and wastewater collection systems, agricultural
irrigation systems, oil and natural gas pipelines, electrical power grids, and railway transportation systems.

2.2.3 Differences between Manufacturing and Distribution ICS
While control systems used in manufacturing and distribution industries are very similar in operation, they
are different in some aspects. Manufacturing industries are usually located within a confined factory or
plant-centric area, when compared to geographically dispersed distribution industries. Communications in
manufacturing industries are usually performed using local area network (LAN) technologies that are
typically more reliable and high speed as compared to the long-distance communication wide-area
networks (WAN) and wireless/RF (radio frequency) technologies used by distribution industries. The ICS
used in distribution industries are designed to handle long-distance communication challenges such as
delays and data loss posed by the various communication media used. The security controls may differ
among network types.

2.2.4 ICS and Critical Infrastructure Interdependencies
The U.S. critical infrastructure is often referred to as a “system of systems” because of the
interdependencies that exist between its various industrial sectors as well as interconnections between
business partners [8] [9]. Critical infrastructures are highly interconnected and mutually dependent in

15

SP800-82 第 2 版

2.2

産業甚制埡システムICSセキュリティガむド

ICS の産業郚門ずその盞互䟝存性

制埡システムは補造、物流、茞送等、皮々の産業郚門で䜿甚され、重芁なむンフラずなっおいる。

2.2.1 補造業界
䞀口に補造ずいっおも、倚皮倚様な郚門に様々なプロセスがあり、プロセス䞻䜓の補造ず組立䞻
䜓の補造に倧別される。
プロセス䞻䜓の補造業界は、䞀般的に次の 2 ぀の䞻芁プロセスを利甚する[1]。

 継続補造プロセス。継続的に実斜されるプロセスで、グレヌドが異なる単䞀の補品に移行す
るこずが倚い。䞀般的な継続補造プロセスには、発電所の燃料や蒞気の流れ、補油所の石油、
化孊プラントの蒞留液が含たれる。
 バッチ補造プロセス。倧量の資材に察しお、明確に分かれたステップからなる。バッチプロ
セスには明確な開始ステップず終了ステップがあり、その䞭間においおは短い定垞状態の業
務が行われる堎合がある。䞀般的なバッチ補造プロセスには食品補造が含たれる。
組立䞻䜓の補造業界は、䞀般に単䞀のデバむスで䞀連のステップを実行し、最終補品を生み出す。
電子郚品・機械郚品の組立や郚品の工䜜などはその兞型である。
プロセス䞻䜓の業界も組立䞻䜓の業界も、同皮の制埡システム、センサ及びネットワヌクを䜿甚
する。斜蚭によっおは、䞡方の補造を同時に行う所もある。

2.2.2 配送業界
ICS は地理的に分散した資産の管理に䜿甚され、ずきには範囲が数千キロ平米にもなるこずがあ
る。䟋えば䞊䞋氎道、灌挑、石油・倩然ガスパむプラむン、送電網、鉄道等である。

2.2.3 補造 ICS ず配送 ICS の盞違
補造業界ず配送業界の制埡システムの業務はずおもよく䌌おいるが、異なる面もいく぀かある。
補造業界は、通垞閉鎖された工堎やプラント䞭心の領域内にあるのに察し、配送業界は地理的に
分散しおいる。補造業界の通信は LAN を利甚しお通垞行われる。これは配送業界が利甚する長距
離の WAN 及び無線 RF 技術に比べお、䞀般に信頌性も速床にも優れる。配送業界の ICS は、利甚
する皮々の通信メディアに起因する遅延やデヌタ喪倱ずいった長距離通信の諞問題に察凊できる
ように蚭蚈される。セキュリティ管理は、ネットワヌクの皮類に応じお異なる。

2.2.4 ICS ず重芁むンフラの盞互䟝存性
米囜の重芁むンフラは、よく「耇数のシステムからなるシステム」ず呌ばれるが、理由は倚皮倚
様な業界・郚門が盞互に䟝存し合い、ビゞネスパヌトナヌ同士が盞互に関わり合っおいるからで
ある[8] [9]。重芁むンフラは、物理的にも倚数の情報・通信技術面でも、高床に盞互連携し、
耇雑に盞互䟝存し合っおいる。

16

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

complex ways, both physically and through a host of information and communications technologies. An
incident in one infrastructure can directly and indirectly affect other infrastructures through cascading and
escalating failures.
Both the electrical power transmission and distribution grid industries use geographically distributed
SCADA control technology to operate highly interconnected and dynamic systems consisting of thousands
of public and private utilities and rural cooperatives for supplying electricity to end users. Some SCADA
systems monitor and control electricity distribution by collecting data from and issuing commands to
geographically remote field control stations from a centralized location. SCADA systems are also used to
monitor and control water, oil and natural gas distribution, including pipelines, ships, trucks, and rail
systems, as well as wastewater collection systems.
SCADA systems and DCS are often networked together. This is the case for electric power control centers
and electric power generation facilities. Although the electric power generation facility operation is
controlled by a DCS, the DCS must communicate with the SCADA system to coordinate production output
with transmission and distribution demands.
Electric power is often thought to be one of the most prevalent sources of disruptions of interdependent
critical infrastructures. As an example, a cascading failure can be initiated by a disruption of the microwave
communications network used for an electric power transmission SCADA system. The lack of monitoring
and control capabilities could cause a large generating unit to be taken offline, an event that would lead to
loss of power at a transmission substation. This loss could cause a major imbalance, triggering a cascading
failure across the power grid. This could result in large area blackouts that could potentially affect oil and
natural gas production, refinery operations, water treatment systems, wastewater collection systems, and
pipeline transport systems that rely on the grid for electric power.

2.3 ICS Operation and Components
The basic operation of an ICS is shown in Figure 2-1 [2]. Some critical processes may also include safety
systems. Key components include the following:
A typical ICS contains numerous control loops, human interfaces, and remote diagnostics and maintenance
tools built using an array of network protocols on layered network architectures. A control loop utilizes
sensors, actuators, and controllers (e.g., PLCs) to manipulate some controlled process. A sensor is a device
that produces a measurement of some physical property and then sends this information as controlled
variables to the controller. The controller interprets the signals and generates corresponding manipulated
variables, based on a control algorithm and target set points, which it transmits to the actuators. Actuators
such as control valves, breakers, switches, and motors are used to directly manipulate the controlled
process based on commands from the controller.
Operators and engineers use human interfaces to monitor and configure set points, control algorithms, and
to adjust and establish parameters in the controller. The human interface also displays process status
information and historical information. Diagnostics and maintenance utilities are used to prevent, identify,
and recover from abnormal operation or failures.
Sometimes these control loops are nested and/or cascading –whereby the set point for one loop is based on
the process variable determined by another loop. Supervisory-level loops and lower-level loops operate
continuously over the duration of a process with cycle times ranging on the order of milliseconds to
minutes.

17

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

あるむンフラのむンシデントは、連鎖や障害の゚スカレヌションを通じお、他のむンフラにも盎
接・間接に圱響を及がす。
送電・配電業界では、いずれも地理的分散 SCADA 制埡技術を䜿甚しお、゚ンドナヌザに電気を䟛
絊するために、数千もの官民公共事業者及び地方協同組合からなる、高床に盞互連携した動的シ
ステムを運甚しおいる。遠隔制埡ステヌションに察しお䞀か所からコマンドを発行しおデヌタを
収集し、配電を監芖・制埡しおいる SCADA もある。たたパむプラむン、船舶、トラック、鉄道、
䞋氎道等、氎・石油・倩然ガスの配送を監芖・制埡する SCADA もある。
SCADA ず DCS はネットワヌク化されおいるこずが倚い。電力制埡センタヌず発電斜蚭がその䞀䟋
である。発電斜蚭は DCS で制埡されるが、DCS は SCADA ず通信を行い、送電・配電需芁に応じお
生産出力を調敎しなければならない。
電力は、盞互䟝存し合った重芁むンフラの厩壊をもたらす、最も普及した゜ヌスの䞀぀ず考えら
れおいる。䞀䟋ずしお、送電 SCADA 甚のマむクロ波通信網が厩壊すれば、連鎖障害の匕き金ずな
り埗る。監芖・制埡胜力の欠劂は、倧型発電装眮をオフラむンにし、倉電所の電力喪倱に至りか
ねない。こうした喪倱により倧きな䞍均衡が生じ、電力網党䜓の連鎖障害の匕き金ずなる。その
結果広域停電が生じ、電力網に䟝存する石油・倩然ガス生産、補油所業務、氎凊理システム、䞋
氎道及びパむプラむン搬送システムにも圱響が出よう。

2.3

ICS の操䜜及びコンポヌネント

ICS の基本操䜜を図 2-1 に瀺す[2]。重芁プロセスによっおは、安党システムを含めるものもあ
る。キヌコンポヌネントは以䞋のずおり。
䞀般的な ICS には数倚くの制埡ルヌプ、ヒュヌマンむンタフェヌスのほか、レむダヌドネットワ
ヌクアヌキテクチャヌの倚様なネットワヌクプロトコルを利甚しお䜜成したリモヌト蚺断・保守
ツヌルが含たれる。制埡ルヌプはセンサ、アクチュ゚ヌタ及びコントロヌラPLC 等を䜿甚し
お、制埡プロセスのいく぀かを操䜜する。センサは特定の物理特性を蚈枬し、その情報を制埡倉
数ずしおコントロヌラに送信するデバむスである。コントロヌラは信号を解釈し、制埡アルゎリ
ズムず目暙蚭定点を基に察応する操䜜倉数を生成し、アクチュ゚ヌタに送信する。アクチュ゚ヌ
タはバルブ、ブレヌカ、スむッチ、モヌタ等のこずで、コントロヌラからのコマンドに埓っお制
埡プロセスを盎接操䜜する。
操䜜員及び゚ンゞニアはヒュヌマンむンタフェヌスを利甚し、蚭定点、制埡アルゎリズムを監
芖・蚭定し、コントロヌラのパラメヌタを調敎・蚭定する。
たたヒュヌマンむンタフェヌスはプロセスのステヌタス情報及び履歎情報を衚瀺する。蚺断・保
守ナヌティリティは、異垞操䜜や障害の防止、特定及び回埩に利甚される。
このような制埡ルヌプはネストやカスケヌドになっおいるこずがあり、その堎合、あるルヌプの
蚭定点は別のルヌプにより決たるプロセス倉数に䟝存する。監芖レベルのルヌプず䜎レベルルヌ
プは 1 ぀のプロセス䞭継続的に機胜し、サむクル時間はミリ秒から分単䜍たでずなる。

18

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-1. ICS Operation

To support subsequent discussions, this section defines key ICS components that are used in control and
networking. Some of these components can be described generically for use in SCADA systems, DCS and
PLCs, while others are unique to one. The Glossary of Terms in Appendix B— contains a more detailed
listing of control and networking components. Additionally, Figure 2-5 and Figure 2-6 show SCADA
implementation examples; Figure 2-7 shows a DCS implementation example and Figure 2-8 shows a PLC
implementation example that incorporates these components.

2.3.1 ICS System Design Considerations
While Section 2.3 introduced the basic components of an ICS, the design of an ICS, including whether a
SCADA, DCS, or PLC-based topologies are used depends on many factors. This section identifies key
factors that drive design decisions regarding the control, communication, reliability, and redundancy
properties of the ICS. Because these factors heavily influence the design of the ICS, they will also help
determine the security needs of the system.


Control Timing Requirements. ICS processes have a wide range of time-related requirements,
including very high speed, consistency, regularity, and synchronization. Humans may not be able to
reliably and consistently meet these requirements; automated controllers may be necessary. Some
systems may require the computation to be performed as close to the sensor and actuators as possible
to reduce communication latency and perform necessary control actions on time.

19

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ヒュヌマン・マシン
むンタフェヌスHMI

リモヌト蚺断・保守

蚭定点、制埡アルゎリズム、
パラメヌタ制玄、
プロセスデヌタ
コントロヌラ
制埡倉数

操䜜倉数

センサ

アクチュ゚ヌタ

プロセス入力

制埡されたプロセス

プロセス出力

劚害

図 2-1.ICS の動䜜

以埌の説明の䟿宜䞊、このセクションでは制埡及びネットワヌクで䜿甚する ICS のキヌコンポヌ
ネントに぀いお明らかにする。SCADA、DCS 及び PLC で汎甚的に甚いるものもあれば、どれか 1
぀に特化しおいるものもある。付録 B の甚語集には、制埡コンポヌネント及びネットワヌクコン
ポヌネントの詳现なリストがある。たた図 2-5 ず図 2-6 には SCADA、図 2-7 には DCS、図 2-8 に
は PLC の実装䟋がそれぞれ瀺され、これらコンポヌネントが組み蟌たれおいる。

2.3.1 ICS のシステム蚭蚈䞊の考慮事項
セクション 2.3 には ICS の基本コンポヌネント、ICS の蚭蚈が玹介されおおり、SCADA、DCS、
PLC のいずれに基づくトポロゞヌを䜿甚すべきかは、倚くの芁因に䟝存する点も説明されおいる。
このセクションでは、ICS の制埡、通信、信頌性及び冗長特性に関する蚭蚈䞊の重芁芁因を明ら
かにする。そうした芁因は ICS の蚭蚈に倧きく圱響するため、システムのセキュリティ需芁を刀
定する䞊でも圹立぀。

 制埡のタむミング芁件。ICS のプロセスには、高速性、䞀貫性、芏則性、同期性等、広範な
時間関連の芁件がある。人間はこうした芁件に察しお、高い信頌性ず䞀貫性をもっお応える
こずはできないため、自動コントロヌラが必芁ずなる。システムによっおは、通信の埅ち時
間を短瞮し、必芁な制埡動䜜を時間どおりに行うため、センサずアクチュ゚ヌタをできるだ
け近づけお蚈算を行う必芁が生じる。

20

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Geographic Distribution. Systems have varying degrees of distribution, ranging from a small system
(e.g., local PLC-controlled process) to large, distributed systems (e.g., oil pipelines, electric power
grid). Greater distribution typically implies a need for wide area (e.g., leased lines, circuit switching,
and packet switching) and mobile communication.



Hierarchy. Supervisory control is used to provide a central location that can aggregate data from
multiple locations to support control decisions based on the current state of the system. Often a
hierarchical/centralized control is used to provide human operators with a comprehensive view of the
entire system.



Control Complexity. Often control functions can be performed by simple controllers and preset
algorithms. However, more complex systems (e.g., air traffic control) require human operators to
ensure that all control actions are appropriate to meet the larger objectives of the system.



Availability. The system’s availability (i.e., reliability) requirements are also an important factor in
design. Systems with strong availability/up-time requirements may require more redundancy or
alternate implementations across all communication and control.



Impact of Failures. The failure of a control function could incur substantially different impacts across
domains. Systems with greater impacts often require the ability to continue operations through
redundant controls, or the ability to operate in a degraded state. The design needs to address these
requirements.



Safety. The system’s safety requirements area also an important factor in design. Systems must be
able to detect unsafe conditions and trigger actions to reduce unsafe conditions to safe ones. In most
safety-critical operations, human oversight and control of a potentially dangerous process is an
essential part of the safety system.

2.3.2 SCADA Systems
SCADA systems are used to control dispersed assets where centralized data acquisition is as important as
control [3] [4]. These systems are used in distribution systems such as water distribution and wastewater
collection systems, oil and natural gas pipelines, electrical utility transmission and distribution systems, and
rail and other public transportation systems. SCADA systems integrate data acquisition systems with data
transmission systems and HMI software to provide a centralized monitoring and control system for
numerous process inputs and outputs. SCADA systems are designed to collect field information, transfer it
to a central computer facility, and display the information to the operator graphically or textually, thereby
allowing the operator to monitor or control an entire system from a central location in near real time. Based
on the sophistication and setup of the individual system, control of any individual system, operation, or task
can be automatic, or it can be performed by operator commands.
Typical hardware includes a control server placed at a control center, communications equipment (e.g.,
radio, telephone line, cable, or satellite), and one or more geographically distributed field sites consisting of
Remote Terminal Units (RTUs) and/or PLCs, which controls actuators and/or monitors sensors. The
control server stores and processes the information from RTU inputs and outputs, while the RTU or PLC
controls the local process. The communications hardware allows the transfer of information and data back
and forth between the control server and the RTUs or PLCs. The software is programmed to tell the system
what and when to monitor, what parameter ranges are acceptable, and what response to initiate when
parameters change outside acceptable values. An Intelligent Electronic Device (IED), such as a protective
relay, may communicate directly to the control server, or a local RTU may poll the IEDs to collect the data
and pass it to the control server. IEDs provide a direct interface to control and monitor equipment and
sensors. IEDs may be directly polled and controlled by the control server and in most

21

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 地理的な分散。システムの分散の皋床は、小芏暡なシステムロヌカル PLC 制埡プロセス
等から倧芏暡な分散システム石油パむプラむン、電力網等たで倚岐にわたる。分散の
皋床が倧きくなれば、通垞広域になり回線リヌス、回路切替、パケット切替等、移動通
信が必芁ずなる。
 階局。監芖制埡を利甚しお、耇数所圚地のデヌタを䞀か所から収集し、システムの珟状に基
づいお制埡の決定に圹立おるこずができる。階局・集䞭管理を利甚しお、システム党䜓を包
括的に芋ながら人間が操䜜を行うこずが倚い。
 制埡の耇雑性。制埡は単玔なコントロヌラずプリセットアルゎリズムで行われるこずが倚い。
しかし、より耇雑なシステム航空亀通管制等では、党おの制埡行為が適正で、より倧き
なシステム目暙に合臎させるため、操䜜員が必芁ずなる。
 可甚性。システムの可甚性すなわち信頌性芁件も、蚭蚈における重芁芁因ずなる。高い
可甚性/アップタむム芁件を持ったシステムには、通信及び制埡党般を通じおいっそうの冗長
性や代替実装が必芁ずなる。
 障害の圱響。制埡機胜の障害は、かなり倚様な圱響を党領域にもたらしかねない。圱響床の
倧きいシステムには、冗長制埡や退化状態での運甚胜力を通じお、運甚を継続する胜力が求
められるこずが倚い。蚭蚈ではそうした芁件を考慮に入れる必芁がある。
 安党性。システムの安党性芁件も蚭蚈の重芁芁玠ずなる。䞍安党状態を怜知しお、安党状態
に近づけるこずが求められる。最も安党性が求められる運甚では、朜圚的に危険なプロセス
に察する人間の監芖・制埡が安党性システムの䞍可欠郚分ずなる。
2.3.2 SCADA
SCADA は、集䞭デヌタ取埗が制埡ず同様に重芁な堎合に、分散化された資産を制埡するために䜿
甚する[3] [4]。䞊䞋氎道、石油・倩然ガスパむプラむン、送電・配電システム、鉄道その他の
公共茞送ずいった配送システムに䜿甚されおいる。SCADA は、デヌタ取埗システムをデヌタ送信
システムおよび HMI ゜フトり゚アず統合し、倚数のプロセスのむンプットずアりトプットのため
の集䞭的監芖・制埡システムずなる。SCADA は、珟堎の情報を収集しお䞭倮コンピュヌタ斜蚭ぞ
転送し、情報を図圢やテキスト圢匏で操䜜員に衚瀺し、システム党䜓をほずんどリアルタむムに
䞀か所から監芖・制埡できるようにする。個々のシステムを掗緎化しお蚭定するこずにより、
個々のシステム、動䜜又はタスクを自動化したり、オペレヌタのコマンドで実行したりするこず
ができる。
䞀般的なハヌドり゚アずしおは、コントロヌルセンタヌに蚭眮されたコントロヌルサヌバ、通信
装眮無線、電話回線、ケヌブル、サテラむト等のほか、遠隔端末装眮RTU又は PLC で構
成されたか所又は耇数の地理的に分散された珟堎が含たれ、アクチュ゚ヌタやセンサを監芖す
る。コントロヌルサヌバは、RTU の入出力情報を保存・凊理し、RTU 又は PLC はロヌカルプロセ
スを制埡する。通信ハヌドり゚アは、コントロヌルサヌバず RTU 又は PLC 間の情報転送ずデヌタ
の送受信を実珟する。゜フトり゚アはプログラム可胜で、監芖察象ず時期、受入れられるパラメ
ヌタの範囲、パラメヌタが範囲を逞脱した堎合に取るべき察凊を決定する。保護リレヌ等のむン
テリゞェント電子デバむスIEDが盎接コントロヌルサヌバず通信を行うか、ロヌカル RTU が
IED にポヌリングしおデヌタを収集し、それをコントロヌルサヌバに枡す。IED は、装備品及び
センサの制埡・監芖の盎接的なむンタフェヌスずなる。たたコントロヌルサヌバから盎接ポヌリ
ングず制埡を受け、ほずんどの堎合、コントロヌルセンタヌから盎接指瀺を受けずに IED を操䜜
するロヌカルプログラミングを有する。

22

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

cases have local programming that allows for the IED to act without direct instructions from the control
center. SCADA systems are usually designed to be fault-tolerant systems with significant redundancy built
into the system. Redundancy may not be a sufficient countermeasure in the face of malicious attack.
Figure 2-2 shows the components and general configuration of a SCADA system. The control center
houses a control server and the communications routers. Other control center components include the HMI,
engineering workstations, and the data historian, which are all connected by a LAN. The control center
collects and logs information gathered by the field sites, displays information to the HMI, and may generate
actions based upon detected events. The control center is also responsible for centralized alarming, trend
analyses, and reporting. The field site performs local control of actuators and monitors sensors (Note that
sensors and actuators are only shown in Figure 2-5). Field sites are often equipped with a remote access
capability to allow operators to perform remote diagnostics and repairs usually over a separate dial up
modem or WAN connection. Standard and proprietary communication protocols running over serial and
network communications are used to transport information between the control center and field sites using
telemetry techniques such as telephone line, cable, fiber, and radio frequency such as broadcast, microwave
and satellite.
SCADA communication topologies vary among implementations. The various topologies used, including
point-to-point, series, series-star, and multi-drop [5], are shown in Figure 2-3.
Point-to-point is functionally the simplest type; however, it is expensive because of the individual channels
needed for each connection. In a series configuration, the number of channels used is reduced; however,
channel sharing has an impact on the efficiency and complexity of SCADA operations. Similarly, the
series-star and multi-drop configurations’ use of one channel per device results in decreased efficiency and
increased system complexity.

Figure 2-2. SCADA System General Layout

23

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

通垞、SCADA は、フォヌルトトレラントシステムで、盞圓の冗長性が組蟌たれおいる。冗長性
は、悪意ある攻撃に察しおは十分な察策になり埗ないこずがある。
図 2-2 は SCADA のコンポヌネントず党䜓構成を瀺す。コントロヌルセンタヌには、コントロヌル
サヌバず通信ルヌタが蚭眮される。コントロヌルセンタヌのその他のコンポヌネントには HMI、
゚ンゞニアリングワヌクステヌション及びデヌタヒストリアンが含たれ、みな LAN で繋がっおい
る。コントロヌルセンタヌは、珟堎サむトが収集した情報を収集・蚘録し、HMI に衚瀺し、怜知
したむベントに応じおアクションを生成する。たた集䞭アラヌム、トレンド分析及び報告も担圓
する。珟堎サむトはアクチュ゚ヌタのロヌカル制埡を行い、センサを監芖するセンサ及びアク
チュ゚ヌタは図 2-5 にのみ瀺される。珟堎サむトは、操䜜員がリモヌト蚺断や修理を行えるよ
うにリモヌトアクセス胜力を備えたものが倚く、通垞は独立したダむアルアップモデムや WAN 接
続を利甚しおいる。シリアル通信及びネットワヌク通信で䜿甚する暙準プロトコル及び専甚プロ
トコルは、コントロヌルセンタヌず珟堎サむト間での情報通信に利甚され、この通信は、電話回
線、ケヌブル、ファむバヌ、無線呚波数ブロヌドキャスト、マむクロ波、サテラむト等ずい
ったテレメトリ技術を利甚しお行う。
SCADA 通信トポロゞヌは、実装によっお様々に異なっおいる。2 地点間、シリヌズ、シリヌズス
タヌ、マルチドロップ[5]等の、利甚される様々なトポロゞヌを図 2-3 に瀺す。
2 地点間は機胜的に最も単玔であるが、接続ごずにそれぞれのチャンネルが必芁であるこずから
コスト高になる。シリヌズ構成では、チャンネル数が少なくおすむが、チャンネルを共有するた
め、SCADA の動䜜の効率ず耇雑さに圱響する。
同様にシリヌズスタヌ及びマルチドロップ構成では、デバむスごずに 1 チャンネルを䜿甚するた
め、効率が䜎䞋し、システムが耇雑になる。
コントロヌル
センタヌ

HMI

珟堎サむト 1

゚ンゞニアリング
ワヌクステヌション

切替電話、リヌス
回線又は電力線
利甚通信

モデム

PLC

珟堎サむト 2
マむクロ波無線
又はセルラヌ
WAN カヌド

衛星

デヌタ
ヒストリアン

制埡サヌバ
SCADA-MTU

通信ルヌタ

IED

珟堎サむト 3

WAN
モデム

図 2-2.SCADA の党般レむアりト

24

RTU

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The four basic topologies Figure 2-3 can be further augmented using dedicated devices to manage
communication exchanges as well as message switching and buffering. Large SCADA systems containing
hundreds of RTUs often employee a sub-control server to alleviate the burden on the primary server. This
type of topology is shown in Figure 2-4.
Figure 2-5 shows an example of a SCADA system implementation. This particular SCADA system consists
of a primary control center and three field sites. A second backup control center provides redundancy in the
event of a primary control center malfunction. Point-to-point connections are used for all control center to
field site communications, with two connections using radio telemetry. The third field site is local to the
control center and uses the WAN for communications. A regional control center resides above the primary
control center for a higher level of supervisory control. The corporate network has access to all control
centers through the WAN, and field sites can be accessed remotely for troubleshooting and maintenance
operations. The primary control center polls field devices for data at defined intervals (e.g., 5 seconds, 60
seconds) and can send new set points to a field device as required. In addition to polling and issuing highlevel commands, the control server also watches for priority interrupts coming from field site alarm
systems.

Figure 2-3. Basic SCADA Communication Topologies

25

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

図 2-3 の 4 ぀の基本トポロゞヌは、専甚デバむスを䜿甚しお曎に増やし、通信亀換、メッセヌゞ
切替、バッファリングを管理するこずができる。数癟の RTU を持぀倧芏暡 SCADA は、サブコ
ントロヌルサヌバを採甚し、プラむマリサヌバの負荷を軜枛しおいるこずが倚い。この皮のトポ
ロゞヌは図 2-4 に瀺す。
図 2-5 は SCADA の実装䟋である。この特殊な SCADA は、プラむマリコントロヌルセンタヌず 3 ぀
の珟堎サむトで構成される。2 番目のバックアップコントロヌルセンタヌは、プラむマリコント
ロヌルセンタヌが䞍具合を起こしおいる堎合に冗長性を発揮する。2 地点間接続は、党おのコン
トロヌルセンタヌず珟堎サむト間の通信に䜿甚し、無線テレメトリによる接続が 2 ぀になっおい
る。3 番目の珟堎サむトはコントロヌルセンタヌに察しおロヌカルで、WAN 接続を利甚する。地
域コントロヌルセンタヌはプラむマリコントロヌルセンタヌの䞊䜍にあり、より高䜍の監芖制埡
を行う。䌁業ネットワヌクは WAN 経由でコントロヌルセンタヌにアクセスし、珟堎サむトは、リ
モヌトアクセスによりトラブルシュヌティングず保守䜜業を行えるようになっおいる。プラむマ
リコントロヌルセンタヌは、指定された間隔5 秒、60 秒等で珟堎のデバむスにデヌタのポヌ
リングを行い、必芁に応じお新たな蚭定点を珟堎のデバむスに送信する。ポヌリングずハむレベ
ルコマンドの発行に加えお、コントロヌルサヌバは、珟堎サむトのアラヌムシステムから送られ
る優先䞭断の監芖も行う。

コントロヌルセンタヌ

珟堎サむト
2 地点間

モデム

モデム

RTU/PLC

シリヌズ

モデム

モデム

RTU/PLC

モデム

モデム

RTU/PLC

シリヌズスタヌ
SCADA サヌバ
MTU
モデム

モデム

モデム

モデム

RTU/PLC

モデム

モデム

RTU/PLC

RTU/PLC

マルチドロップ
モデム

モデム

モデム

RTU/PLC

RTU/PLC

RTU/PLC

モデム

図 2-3. 基本的 SCADA 通信トポロゞヌ

26

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-4. Large SCADA Communication Topology

27

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

コントロヌルセンタヌ

侭間 SCADA

珟堎サむト
倚数のフィヌルド装眮

モデム

モデム

モデム

SCADA サヌバ
サブ MTU

モデム

モデム

モデム

倚数の遠隔ステヌション

SCADA サヌバ
MTU

モデム

モデム

モデム

サブ SCADA サヌバ
サブ MTU

モデム

モデム

モデム

図 2-4. 倧芏暡 SCADA 通信トポロゞヌ

28

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-5. SCADA System Implementation Example (Distribution Monitoring and Control)

Figure 2-6 shows an example implementation for rail monitoring and control. This example includes a rail
control center that houses the SCADA system and three sections of a rail system. The SCADA system polls
the rail sections for information such as the status of the trains, signal systems, traction electrification
systems, and ticket vending machines. This information is also fed to operator consoles at the HMI station
within the rail control center. The SCADA system also monitors operator inputs at the rail control center
and disperses high-level operator commands to the rail section components. In addition, the SCADA
system monitors conditions at the individual rail sections and issues commands based on these conditions
(e.g., stopping a train to prevent it from entering an area that has been determined to be flooded or occupied
by another train based on condition monitoring).

29

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

地域コントロヌルセンタヌ

バックアップコントロヌルセンタヌ
プラむマリコントロヌルセンタヌ
デヌタヒストリアン

HMI ステヌション

゚ンゞニアリングワヌ
クステヌション

制埡サヌバ
SCADA-MTU

䌁業ネットワヌク

モデム

HMI ステヌション

プリンタ

制埡サヌバ
SCADA-MTU

シリアルベヌス
無線通信
WAN
Card
モデム

バルブ

リモヌトアクセス

ポンプ

バルブ
モデム

レベル
センサ

流量
圧力
センサ センサ
遠隔
ステヌション

バルブ

モデム

ポンプ

コンピュヌタ
レベル
センサ

流量
圧力
センサ センサ
遠隔
ステヌション

図 2-5.

ポンプ

レベル
センサ

流量
圧力
センサ センサ
遠隔
ステヌション

SCADA の実装䟋分散監芖・制埡

図 2-6 は、鉄道監芖・制埡の実装䟋である。この䟋では、SCADA ず鉄道システムの 3 セクション
を有する鉄道制埡センタヌが含たれる。SCADA は鉄道のセクションに察し、列車の状態、信号装
眮、牜匕垯電装眮、乗車刞販売機等の情報のポヌリングを行う。この情報は、鉄道制埡センタヌ
内にある HMI ステヌションの操䜜員コン゜ヌルにも䟛絊される。たた SCADA は、鉄道制埡センタ
ヌにおける操䜜員の入力情報も監芖し、䞊䜍の操䜜員コマンドを鉄道セクションコンポヌネント
に発行する。加えお、個々の鉄道セクションにおける状態を監芖し、それに応じおコマンドを発
行する状態監芖に基づき、措氎ず刀定される地区やほかの列車がいる地区に進入しないように
列車を停止させるなど。

30

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-6. SCADA System Implementation Example (Rail Monitoring and Control)

2.3.3 Distributed Control Systems
DCS are used to control production systems within the same geographic location for industries such as oil
refineries, water and wastewater treatment, electric power generation plants, chemical manufacturing plants,
automotive production, and pharmaceutical processing facilities. These systems are usually process control
or discrete part control systems.
DCS are integrated as a control architecture containing a supervisory level of control overseeing multiple,
integrated sub-systems that are responsible for controlling the details of a localized process. A DCS uses a
centralized supervisory control loop to mediate a group of localized controllers that share the overall tasks
of carrying out an entire production process [6]. Product and process control are usually achieved by
deploying feedback or feedforward control loops whereby key product and/or process conditions are
automatically maintained around a desired set point. To accomplish the desired product and/or process
tolerance around a specified set point, specific process controllers, or more capable PLCs, are employed in
the field and are tuned to provide the desired tolerance as well as the rate of self-correction during process
upsets. By modularizing the production system, a DCS reduces the impact of a single fault on the

31

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

鉄道コントロヌルセンタヌ
デヌタヒストリアン

HMI ステヌション

䌁業ワヌクステヌション

LAN

プリンタ

制埡サヌバ
ルヌタ

SCADA MTU

リング型トポロゞヌ

鉄道セクション 1

Hub

鉄道セクション 3

Hub

鉄道セクション 2

Hub

信号発信

信号発信
信号発信

沿線制埡列車

牜匕垯電サブ
ステヌション

牜匕垯電
監芖制埡

沿線制埡列車

沿線制埡列車

鉄道電力

鉄道電力
牜匕垯電サブ
ステヌション

鉄道電力
列車

牜匕垯電サブ
ステヌション

絊電地元
電力䌚瀟

絊電地元
牜匕垯電
監芖制埡

列車

列車

電力䌚瀟

牜匕垯電
監芖制埡

絊電地元
電力䌚瀟

図 2-6. SCADA の実装䟋列車監芖・制埡

2.3.3 分散制埡システム
DCS は地理的に同じ堎所にある生産システムの制埡に䜿甚され、石油粟補、䞊䞋氎道凊理、発電
所、化孊プラント、自動車生産、医薬品凊理斜蚭等が含たれる。このようなシステムは、通垞プ
ロセス制埡システムや個別郚品制埡システムである。
DCS は、局圚プロセスの现郚を制埡する耇数の統合サブシステムに察する、監芖レベルでの制埡
を含めた制埡アヌキテクチャずしお統合される。DCS は集䞭監芖・制埡ルヌプを利甚しお、生産
プロセス党䜓の実行に関わる党タスクを共有する局圚コントロヌラの 1 グルヌプを仲介する[6]。
補品・プロセス制埡は、通垞フィヌドバック/フィヌドフォワヌド制埡ルヌプを展開しお行い、
重芁な補品やプロセスの状態は、所望の蚭定点付近に自動的に保たれる。所望の補品やプロセス
の蚱容誀差を指定された蚭定点付近に保぀ため、特殊プロセスコントロヌラ又はより高性胜の
PLC を珟堎に採甚しお調敎し、プロセス䞍調時に所望の蚱容誀差内に収たるようにしたり、自己
補正率を蚭定したりしおいる。生産システムをモゞュヌル化するこずで、DCS は、単䞀の障害が
システム党䜓に䞎える圱響を枛らす。

32

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

overall system. In many modern systems, the DCS is interfaced with the corporate network to give business
operations a view of production.
An example implementation showing the components and general configuration of a DCS is depicted in
Figure 2-7. This DCS encompasses an entire facility from the bottom-level production processes up to the
corporate or enterprise layer. In this example, a supervisory controller (control server) communicates to its
subordinates via a control network. The supervisor sends set points to and requests data from the distributed
field controllers. The distributed controllers control their process actuators based on control server
commands and sensor feedback from process sensors.
Figure 2-7 gives examples of low-level controllers found on a DCS system. The field control devices
shown include a PLC, a process controller, a single loop controller, and a machine controller. The single
loop controller interfaces sensors and actuators using point-to-point wiring, while the other three field
devices incorporate fieldbus networks to interface with process sensors and actuators. Fieldbus networks
eliminate the need for point-to-point wiring between a controller and individual field sensors and actuators.
Additionally, a fieldbus allows greater functionality beyond control, including field device diagnostics, and
can accomplish control algorithms within the fieldbus, thereby avoiding signal routing back to the PLC for
every control operation. Standard industrial communication protocols designed by industry groups such as
Modbus and Fieldbus [7] are often used on control networks and fieldbus networks.
In addition to the supervisory-level and field-level control loops, intermediate levels of control may also
exist. For example, in the case of a DCS controlling a discrete part manufacturing facility, there could be an
intermediate level supervisor for each cell within the plant. This supervisor would encompass a
manufacturing cell containing a machine controller that processes a part and a robot controller that handles
raw stock and final products. There could be several of these cells that manage field-level controllers under
the main DCS supervisory control loop.

33

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

最近のシステムには、DCS ず䌁業ネットワヌクのむンタフェヌスを確保しお、事業業務に生産的
な芳点を付䞎しおいるものが少なくない。
図 2-7 は、コンポヌネントず DCS の䞀般的な構成の䟋を瀺す。この DCS では、生産プロセスの底
蟺から䌁業局に至る党おの斜蚭が収められおいる。この䟋では、監芖コントロヌラ制埡サヌ
バが制埡ネットワヌクを介しお、埓属局ず通信を行うようになっおいる。スヌパヌバむザは、
分散フィヌルドコントロヌラぞの蚭定点ずそこからの芁求を送信する。分散コントロヌラは、制
埡サヌバのコマンド及びプロセスセンサからのセンサフィヌドバックを基に、プロセスアクチュ
゚ヌタを制埡する。
図 2-7 は、DCS システムに芋られる䜎レベルコントロヌラの䟋である。フィヌルドコントロヌラ
デバむスには、PLC、プロセスコントロヌラ、単䞀ルヌプコントロヌラ及びマシンコントロヌラ
が配眮されおいる。単䞀ルヌプコントロヌラは、2 地点間配線によりセンサずアクチュ゚ヌタの
むンタフェヌスずなり、それ以倖の 3 皮類のデバむスは、フィヌルドバスネットワヌクを䜿甚し
お、プロセスセンサずアクチュ゚ヌタのむンタフェヌスを確保しおいる。フィヌルドバスネット
ワヌクには、コントロヌラず個々のフィヌルドセンサやアクチュ゚ヌタ間の 2 地点間配線が䞍芁
である。たたフィヌルドバスは、フィヌルドデバむスの蚺断など、制埡以䞊の機胜を発揮するほ
か、フィヌルドバス内で制埡アルゎリズムを実珟し、制埡操䜜のたびに信号を PLC に返す必芁が
ない。制埡ネットワヌクやフィヌルドバスネットワヌクでは、Modbus and Fieldbus [7]等の業
界グルヌプが蚭蚈した暙準的な通信プロトコルが倚甚される。
監芖レベル及びフィヌルドレベルでの制埡ルヌプのほかに、䞭間レベルの制埡もある。䟋えば、
郚品組立補造斜蚭を制埡する DCS の堎合、プラント内のセルごずに䞭間レベルのスヌパヌバむザ
を配眮するこずがある。このスヌパヌバむザは補造セルを包含し、補造セルには郚品を凊理す
るマシンコントロヌラず原料圚庫ず最終補品を扱うロボットコントロヌラが含たれる。こ
のようなセルがいく぀かあるものもあり、各セルはメむン DCS 監芖制埡ルヌプの䞋で、フィヌル
ドレベルのコントロヌラを管理する。

34

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-7. DCS Implementation Example

2.3.4 Programmable Logic Controller Based Topologies
PLCs are used in both SCADA and DCS systems as the control components of an overall hierarchical
system to provide local management of processes through feedback control as described in the sections
above. In the case of SCADA systems, they may provide the same functionality of RTUs. When used in
DCS, PLCs are implemented as local controllers within a supervisory control scheme.
In addition to PLC usage in SCADA and DCS, PLCs are also implemented as the primary controller in
smaller control system configurations to provide operational control of discrete processes such as
automobile assembly lines and power plant soot blower controls These topologies differ from SCADA and
DCS in that they generally lack a central control server and HMI and, therefore, primarily provide closedloop control without direct human involvement. PLCs have a user-programmable memory for storing
instructions for the purpose of implementing specific functions such as I/O control, logic, timing, counting,
three mode proportional-integral-derivative (PID) control, communication, arithmetic, and data and file
processing.

35

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

分散
䌁業の倖郚䞖界
プラント
アプリケヌション
サヌバ

ワヌクステヌション

業務甚クラむアント
/サヌバ

無線デバむス

プリンタ

モデム

むンタヌネット
/WAN
生産実行システムMES、管理
情報システムMIS、䌁業資源蚈
画ERPシステムぞ

監芖レベル
冗長制埡サヌバ
制埡サヌバ

デヌタヒストリアン

䌁業ワヌクステヌション

メむン HMI

ロヌカルコントロヌル
ネットワヌク

HMI

プログラマブル論理
コントロヌラPLC

マシン
コントロヌラ
モデム
圧力センサ

モデム

タワヌ点灯

モヌション制埡

モデム
モヌタ ネットワヌク

DC サヌボ
駆動

サヌボ駆動
サヌボ駆動
圧力
レギュレヌタ

゜レノむドバルブ

センサ アクチュ゚ヌタ

近接センサ
可倉呚波数駆動

モヌタ
感光

サヌボ駆動

監芖レベル
単ルヌプ
コントロヌラ

プロセス
コントロヌラ

リモヌトアクセス
゜レノむド
バルブ

フィヌルドバス

サヌボバルブ
AC 駆動

モヌタ
論理制埡

枩床センサ

モデム

モデム
コンピュヌタ

圧力レギュレヌタ
圧力センサ

図 2-7.DCS の実装䟋

2.3.4 プログラム可胜論理コントロヌラベヌスのトポロゞヌ
PLC は SCADA ず DCS の䞡システムにおいお、階局システム党䜓の制埡コンポヌネントずしお䜿甚
され、前述のずおり、フィヌドバック制埡を通じおプロセスのロヌカル管理を行う。SCADA の堎
合、RTU ず同様の機胜を発揮する。DCS で䜿甚される堎合、PLC は監芖・制埡におけるロヌカル
コントロヌラずしお実装される。
SCADA ず DCS で䜿甚されるほか、PLC はより小芏暡の制埡システム構成におけるプラむマリコン
トロヌラずしおも利甚され、自動車組立ラむン等の組立プロセスや発電所の煀煙ブロアヌの制埡
など、操䜜を制埡する。SCADA や DCS ずのトポロゞヌの違いは、䞀般に䞭倮制埡サヌバず HMI が
ないこずで、そのため人間の盎接的な介圚なしに、䞻にクロヌズドルヌプ制埡を行っおいる。
PLC にはナヌザがプログラム可胜なメモリがあり、I/O 制埡、論理、タむミング、カりント、比
䟋・積分・埮分PID3 モヌド制埡、通信、挔算、デヌタやファむルの凊理等の具䜓的な機胜
を実装するための呜什を栌玍する。

36

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 2-8 shows control of a manufacturing process being performed by a PLC over a fieldbus network.
The PLC is accessible via a programming interface located on an engineering workstation, and data is
stored in a data historian, all connected on a LAN.

Figure 2-8. PLC Control System Implementation Example

37

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

図 2-8 は、フィヌルドバスネットワヌク経由で PLC が実斜する補造プロセス制埡を瀺す。
PLC にぱンゞニアリングワヌクステヌション䞊のプログラミングむンタフェヌスを介しおアク
セスでき、デヌタはヒストリアンに保管され、党お LAN で接続されおいる。

デヌタヒストリアン

゚ンゞニアリング
ワヌクステヌション

LAN
PLC

モデム
タワヌ点灯
可倉呚波数駆動

近接センサ
DC サヌボ
駆動

感光

フィヌルドバス
AC 駆動

図 2-8. PLC 制埡システムの実装䟋

38

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

2.4 Comparing ICS and IT Systems Security
ICS control the physical world and IT systems manage data. ICS have many characteristics that differ from
traditional IT systems, including different risks and priorities. Some of these include significant risk to the
health and safety of human lives, serious damage to the environment, and financial issues such as
production losses, and negative impact to a nation’s economy. ICS have different performance and
reliability requirements, and also use operating systems and applications that may be considered
unconventional in a typical IT network environment. Security protections must be implemented in a way
that maintains system integrity during normal operations as well as during times of cyber attack [17].
Initially, ICS had little resemblance to IT systems in that ICS were isolated systems running proprietary
control protocols using specialized hardware and software. Widely available, low-cost Ethernet and
Internet Protocol (IP) devices are now replacing the older proprietary technologies, which increases the
possibility of cybersecurity vulnerabilities and incidents. As ICS are adopting IT solutions to promote
corporate connectivity and remote access capabilities, and are being designed and implemented using
industry standard computers, operating systems (OS) and network protocols, they are starting to resemble
IT systems. This integration supports new IT capabilities, but it provides significantly less isolation for ICS
from the outside world than predecessor systems, creating a greater need to secure these systems. While
security solutions have been designed to deal with these security issues in typical IT systems, special
precautions must be taken when introducing these same solutions to ICS environments. In some cases, new
security solutions are needed that are tailored to the ICS environment.
The environments in which ICS and IT systems operate are constantly changing. The environments of
operation include, but are not limited to: the threat space; vulnerabilities; missions/business functions;
mission/business processes; enterprise and information security architectures; information technologies;
personnel; facilities; supply chain relationships; organizational governance/culture;
procurement/acquisition processes; organizational policies/procedures; organizational assumptions,
constraints, risk tolerance, and priorities/trade-offs).
The following lists some special considerations when considering security for ICS:


Timeliness and Performance Requirements. ICS are generally time-critical, with the criterion for
acceptable levels of delay and jitter dictated by the individual installation. Some systems require
reliable, deterministic responses. High throughput is typically not essential to ICS. In contrast, IT
systems typically require high throughput, and they can typically withstand some level of delay and
jitter. For some ICS, automated response time or system response to human interaction is very critical.
Some ICS are built on real-time operating systems (RTOS), where real-time refers to timeliness
requirements. The units of real-time are very application dependent and must be explicitly stated.



Availability Requirements. Many ICS processes are continuous in nature. Unexpected outages of
systems that control industrial processes are not acceptable. Outages often must be planned and
scheduled days or weeks in advance. Exhaustive pre-deployment testing is essential to ensure high
availability (i.e., reliability) for the ICS. Control systems often cannot be easily stopped and started
without affecting production. In some cases, the products being produced or equipment being used is
more important than the information being relayed. Therefore, the use of typical IT strategies such as
rebooting a component, are usually not acceptable solutions due to the adverse impact on the
requirements for high availability, reliability and maintainability of the ICS. Some ICS employ
redundant components, often running in parallel, to provide continuity when primary components are
unavailable.

39

SP800-82 第 2 版

2.4

産業甚制埡システムICSセキュリティガむド

ICS システムず IT システムのセキュリティ比范

ICS は物理的䞖界を制埡し、IT システムはデヌタを管理する。ICS は埓来の IT システムずは異
なる特城が倚く、リスクも優先床も異なる。䞭には人の健康や安党に倧きなリスクずなり、環境
を損ない、生産喪倱等の財政問題ずなり、囜家経枈に悪圱響を及がすものもある。ICS の性胜及
び信頌性芁件は異なっおおり、普通の IT ネットワヌク環境では奇異に芋える OS やアプリケヌシ
ョンを䜿甚する。セキュリティの保護は、正垞運甚時にもサむバヌ攻撃の際にもシステム保党を
維持できるように実装しなければならない。[17]
圓初 ICS は、特殊なハヌドり゚アず゜フトり゚アを䜿甚しお専甚制埡プロトコルを実行する隔絶
されたシステムだったため、IT システムずは類䌌点がほずんどなかった。昚今、広く利甚可胜
な䜎コストのむヌサネットやむンタヌネットプロトコルIPデバむスが旧匏の専甚技術に取っ
お代わり぀぀あるこずから、サむバヌセキュリティの脆匱性やむンシデントが生じる蓋然性が高
たっおいる。ICS は IT ゜リュヌションを採甚しお、䌁業の接続性やリモヌトアクセス胜力を促
進しおおり、たた、業界暙準コンピュヌタ、オペレヌティングシステムOS及びネットワヌク
プロトコルを䜿甚するように蚭蚈・実装されるようになっおいる。このため ICS は次第に IT シ
ステムず類䌌性を持぀ようになっおきた。このような統合化は新たな IT 胜力をサポヌトするが、
それ以前のシステムに比べるず、倖界からの隔絶性が栌段に劣るため、セキュリティの必芁性が
増す。
セキュリティ゜リュヌションは、䞀般的な IT システムにおけるセキュリティ問題を扱うように
できおいるが、こうした同じ゜リュヌションを ICS 環境に持ち蟌む堎合には特別な泚意が欠かせ
ない。堎合によっおは、その ICS 環境に特化した新しいセキュリティ゜リュヌションが必芁ずな
る。
ICS システムず IT システムの動䜜環境は絶えず倉化しおいる。䟋えば、脅嚁空間、脆匱性、任
務・ビゞネス機胜、任務・ビゞネスプロセス、䌁業・情報セキュリティアヌキテクチャ、情報技
術、人事、斜蚭、サプラむチェヌンの関係、組織のガバナンス/カルチャヌ、調達・取埗プロセ
ス、組織の方針・手順、組織の前提事項、制玄、リスク蚱容床、優先床/トレヌドオフ等がある。
ICS のセキュリティを怜蚎する際の特別な考慮事項を以䞋に列挙する。

 適時性芁件ず性胜芁件。ICS は緊急を芁するものが倚く、遅延やゞッタヌの蚱容床基準が
個々の装眮に応じお定められおいる。信頌性の高い決定論的応答を求めるシステムもある。
高いスルヌプットは䞀般に ICS には必須でない。反察に IT システムでは通垞、高いスルヌプ
ットが求められ、ある皋床の遅延やゞッタヌは蚱容される。ある皮の ICS では、人の盞互䜜
甚に察する自動応答時間やシステム応答は非垞に重芁ずなる。リアルタむムオペレヌティン
グシステムRTOS䞊に構築される ICS もあり、ここでいうリアルタむムが適時性芁件ず
なる。リアルタむムの単䜍はアプリケヌションに䟝存し、明瀺的に瀺す必芁がある。
 可甚性芁件。ICS プロセスの倚くは、その性質䞊継続的である。産業プロセスを制埡しおい
るシステムの予定倖の停止は受け入れられるものではない。停止の倚くは、数日又は数週間
前にあらかじめ蚈画・予定されたものでなければならない。ICS の高い可甚性すなわち信
頌性を確保するには、培底的な展開前詊隓の実斜が䞍可欠ずなる。生産に圱響を及がすこ
ずなく、制埡システムの停止・開始を容易に実行できるこずは少ない。生産䞭の補品や䜿甚
䞭の装備品の方が、䌝達する情報よりも重芁ずいうケヌスもある。したがっお、コンポヌネ
ントのリブヌトずいった䞀般的な IT 戊略の利甚は、ICS の高い可甚性・信頌性・保守性芁件
に悪圱響を及がすため、通垞受け入れられる解決策ずはならない。ICS では冗長コンポヌネ
ントを採甚しお同時運甚するこずが倚く、プラむマリコンポヌネントが利甚できない堎合の
継続性を確保しおいる。

40

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Risk Management Requirements. In a typical IT system, data confidentiality and integrity are
typically the primary concerns. For an ICS, human safety and fault tolerance to prevent loss of life or
endangerment of public health or confidence, regulatory compliance, loss of equipment, loss of
intellectual property, or lost or damaged products are the primary concerns. The personnel responsible
for operating, securing, and maintaining ICS must understand the important link between safety and
security. Any security measure that impairs safety is unacceptable.



Physical Effects. ICS field devices (e.g., PLC, operator station, DCS controller) are directly
responsible for controlling physical processes. ICS can have very complex interactions with physical
processes and consequences in the ICS domain that can manifest in physical events. Understanding
these potential physical effects often requires communication between experts in control systems and
in the particular physical domain.



System Operation. ICS operating systems (OS) and control networks are often quite different from IT
counterparts, requiring different skill sets, experience, and levels of expertise. Control networks are
typically managed by control engineers, not IT personnel. Assumptions that differences are not
significant can have disastrous consequences on system operations.



Resource Constraints. ICS and their real time OSs are often resource-constrained systems that do not
include typical contemporary IT security capabilities. Legacy systems are often lacking resources
common on modern IT systems. Many systems may not have desired features including encryption
capabilities, error logging, and password protection. Indiscriminate use of IT security practices in ICS
may cause availability and timing disruptions. There may not be computing resources available on ICS
components to retrofit these systems with current security capabilities. Adding resources or features
may not be possible.



Communications. Communication protocols and media used by ICS environments for field device
control and intra-processor communication are typically different from most IT environments, and
may be proprietary.



Change Management. Change management is paramount to maintaining the integrity of both IT and
control systems. Unpatched software represents one of the greatest vulnerabilities to a system.
Software updates on IT systems, including security patches, are typically applied in a timely fashion
based on appropriate security policy and procedures. In addition, these procedures are often automated
using server-based tools. Software updates on ICS cannot always be implemented on a timely basis.
These updates need to be thoroughly tested by both the vendor of the industrial control application and
the end user of the application before being implemented. Additionally, the ICS owner must plan and
schedule ICS outages days/weeks in advance. The ICS may also require revalidation as part of the
update process. Another issue is that many ICS utilize older versions of operating systems that are no
longer supported by the vendor. Consequently, available patches may not be applicable. Change
management is also applicable to hardware and firmware. The change management process, when
applied to ICS, requires careful assessment by ICS experts (e.g., control engineers) working in
conjunction with security and IT personnel.



Managed Support. Typical IT systems allow for diversified support styles, perhaps supporting
disparate but interconnected technology architectures. For ICS, service support is sometimes via a
single vendor, which may not have a diversified and interoperable support solution from another
vendor. In some instances, third-party security solutions are not allowed due to ICS vendor license and
service agreements, and loss of service support can occur if third party applications are installed
without vendor acknowledgement or approval.

41

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 リスク管理芁件。䞀般的な IT システムでは、通垞デヌタの機密性ず保党が䞻芁関心事ずなる。
ICS では、人呜の喪倱、公衆衛生・囜民の信頌の危機、遵法、装備品の損倱、知的財産の損
倱、補品の損害を防止するための人的安党性ずフォヌルトトレランスが䞻芁関心事である。
ICS の運甚・セキュリティ・保守担圓者は、安党性ずセキュリティの重芁な関係を理解しな
ければならない。いかなるセキュリティ察策も、安党性を阻害するのであれば受け入れられ
ない。
 物理的圱響。ICS のフィヌルドデバむスPLC、オペレヌタステヌション、DCS コントロヌ
ラ等は、物理的プロセスを盎接制埡しおいる。ICS ず物理的プロセスずの盞互䜜甚は極め
お耇雑で、ICS 領域における結果は物理的むベントずしお明らかになる。このような物理的
圱響を理解するには、制埡システムの専門員ず特定の物理的領域の専門員同士のコミュニケ
ヌションが必芁ずなる堎合が倚い。
 システム運甚。ICS の OS ず制埡ネットワヌクは、IT の堎合ず党く異なるこずが倚く、求め
られるスキル、経隓、専門知識レベルも異なる。制埡ネットワヌクは、通垞、IT 職員ではな
く制埡゚ンゞニアが管理しおいる。倧きな違いはないずいう認識でいるず、システム運甚に
悲惚な結果を招きかねない。
 リ゜ヌスの制玄。ICS ずそのリアルタむム OS はリ゜ヌス制玄のあるシステムであるこずが倚
く、これには最近の䞀般的なセキュリティ機胜は含たれない。レガシヌシステムには、最近
の IT システムず共通のリ゜ヌスがない。暗号化機胜、゚ラヌログ、パスワヌド保護ずいった
望たしい機胜が付いおいないシステムも倚い。ICS における IT セキュリティの芏範を芋境な
く䜿甚するず、可甚性やタむミングに問題が起きかねない。このようなシステムに珟行のセ
キュリティ機胜を付䞎し、ICS コンポヌネントに利甚できるコンピュヌティングリ゜ヌスは
ないであろう。リ゜ヌスや機胜の远加はできない。
 通信。フィヌルドデバむスの制埡やプロセッサ内通信甚に ICS 環境で䜿甚される通信プロト
コル及びメディアは、倧抵の IT 環境ずは異なり専甚のものが倚い。
 管理倉曎。管理倉曎は IT システムず制埡システムの保党に肝芁である。パッチを圓おおいな
い゜フトり゚アは、システムにずっお最も脆匱な点の 1 ぀ずなる。IT システムにおけるセキ
ュリティパッチ等の゜フトり゚ア曎新は、適正なセキュリティポリシヌず手順に埓っお、タ
むムリヌに行われる。たたこうした手順は、サヌバベヌスのツヌルを䜿甚しお自動化されお
いる堎合が倚い。ICS での゜フトり゚ア曎新は、必ずしもタむムリヌに行われるわけではな
い。曎新の実行前に、産業甚制埡アプリケヌションベンダヌずアプリケヌションの゚ンドナ
ヌザ双方による培底的な詊隓が必芁ずなる。たた ICS 所有者は数日から数週間前に、あらか
じめ停止の蚈画・予定を立おなければならない。たた曎新プロセスの䞀環ずしお、再怜蚌も
必芁ずなる。別の問題ずしお、ベンダヌがサポヌトを打ち切った OS の旧バヌゞョンを䜿甚
する ICS が倚いこずが挙げられる。その結果、入手可胜なパッチが適甚できないこずになる。
管理倉曎は、ハヌドり゚アやファヌムり゚アにも圓おはたる。倉曎管理のプロセスを ICS に
適甚する堎合は、ICS 専門員制埡゚ンゞニア等がセキュリティ職員や IT 職員ず連携しお、
慎重に評䟡を行う必芁がある。
 管理サポヌト。䞀般的な IT システムでは皮々のサポヌトスタむルが認められ、異なっおはい
おも盞互連接した技術アヌキテクチャをサポヌトしおいる。ICS では、サヌビスサポヌトを
ベンダヌ1 瀟が担圓し、ほかのベンダヌからの倚様で盞互運甚性のあるサポヌト゜リュヌシ
ョンが埗られないこずがある。たた ICS ベンダヌのラむセンス・サヌビス契玄により、サヌ
ドパヌティのセキュリティ゜リュヌションが認められない堎合もあり、ベンダヌの蚱可を埗
ずにサヌドパヌティのアプリケヌションをむンストヌルするず、サヌビスサポヌトが解玄に
なるこずもあり埗る。

42

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Component Lifetime. Typical IT components have a lifetime on the order of 3 to 5 years, with
brevity due to the quick evolution of technology. For ICS where technology has been developed in
many cases for very specific use and implementation, the lifetime of the deployed technology is often
in the order of 10 to 15 years and sometimes longer.



Component Location. Most IT components and some ICS are located in business and commercial
facilities physically accessible by local transportation. Remote locations may be utilized for backup
facilities. Distributed ICS components may be isolated, remote, and require extensive transportation
effort to reach. Component location also needs to consider necessary physical and environmental
security measures.

Table 2-1 summarizes some of the typical differences between IT systems and ICS.
Table 2-1. Summary of IT System and ICS Differences
Category
Performance
Requirements

Availability
(Reliability)
Requirements

Risk Management
Requirements

System Operation

Resource
Constraints

Information Technology System
Non-real-time
Response must be consistent
High throughput is demanded
High delay and jitter may be
acceptable
Less critical emergency
interaction
Tightly restricted access control
can be implemented to the degree
necessary for security
Responses such as rebooting are
acceptable
Availability deficiencies can often
be tolerated, depending on the
system’s operational requirements

Manage data
Data confidentiality and integrity is
paramount
Fault tolerance is less important –
momentary downtime is not a
major risk
Major risk impact is delay of
business operations
Systems are designed for use with
typical operating systems
Upgrades are straightforward with
the availability of automated
deployment tools
Systems are specified with
enough resources to support the
addition of third-party applications
such as security solutions

43

Industrial Control System
Real-time
Response is time-critical
Modest throughput is acceptable
High delay and/or jitter is not acceptable
Response to human and other emergency interaction
is critical
Access to ICS should be strictly controlled, but should
not hamper or interfere with human-machine
interaction
Responses such as rebooting may not be acceptable
because of process availability requirements
Availability requirements may necessitate redundant
systems
Outages must be planned and scheduled days/weeks
in advance
High availability requires exhaustive pre-deployment
testing
Control physical world
Human safety is paramount, followed by protection of
the process
Fault tolerance is essential, even momentary
downtime may not be acceptable
Major risk impacts are regulatory non-compliance,
environmental impacts, loss of life, equipment, or
production
Differing and possibly proprietary operating systems,
often without security capabilities built in
Software changes must be carefully made, usually by
software vendors, because of the specialized control
algorithms and perhaps modified hardware and
software involved
Systems are designed to support the intended
industrial process and may not have enough memory
and computing resources to support the addition of
security capabilities

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 コンポヌネントの寿呜。䞀般に IT コンポヌネントの寿呜は 35 幎で、技術進歩の速さから
短呜である。倚くの堎合、極めお特殊な䜿甚ず実装を目指しお技術開発された ICS では、寿
呜は 1015 幎で、堎合によっおはそれ以䞊になる。
 コンポヌネントの所圚堎所。ほずんどの IT コンポヌネント及びある皮の ICS コンポヌネント
は、地元の亀通機関を利甚しお物理的に立入可胜な事業・商甚斜蚭に眮かれおいる。遠隔地
はバックアップ斜蚭ずしお䜿甚される。分散 ICS コンポヌネントは隔絶され、離れおいるた
め、亀通にかなりの劎力が必芁ずなる。たたコンポヌネントの所圚堎所は、物理的・環境的
セキュリティ察策も考慮する必芁がある。
è¡š 2-1 は、IT システムず ICS ずの䞀般的な盞違を取りたずめたものである。
è¡š 2-1.IT システムず ICS の盞違点
カテゎリ

情報ITシステム

産業甚制埡システムICS

性胜芁件

リアルタむム䞍芁

リアルタむム

応答は䞀貫しおいるこず
ハむスルヌプット必須

応答は緊急を芁する

倧きな遅延ずゞッタヌは蚱容
重芁な緊急盞互䜜甚が少ないこず

倧きな遅延やゞッタヌは䞍可

セキュリティに必芁な皋床に厳栌
なアクセス制限を実装できるこず

ICS ぞのアクセスは厳重に制限されるが、マン
マシンむンタフェヌスを阻害・干枉しない

リブヌト等の応答は可

プロセスの可甚性芁件によりリブヌト等の応答
は䞍可

可甚性信頌
性甚件

䞭皋床のスルヌプットで可

可甚性の欠点はシステムの運甚芁
件に応じお蚱容されるこずが倚い

人その他の緊急盞互䜜甚ぞの応答が重芁

可甚性芁件から冗長システムが必芁ずなる堎合
あり
停止は数日又は数週間前にあらかじめ蚈画・予
定
高可甚性芁件により培底的な展開前詊隓が必芁

リスク管理芁件

デヌタを管理

物理䞖界の制埡

デヌタの機密性ず保党が肝芁

人の安党が肝芁、プロセスの保護はその次

フォヌルトトレランスはさほど重
芁でない瞬時のダりンタむムは
重倧リスクでない

フォヌルトトレランスが䞍可欠、瞬時のダりン
タむムも䞍可

重倧なリスク圱響は業務の遅延
システム運甚

システムは䞀般的 OS 䞊で䜿甚
アップグレヌドは自動展開ツヌル
を利甚するので容易

リ゜ヌスの制玄

システムはセキュリティ゜リュヌ
ション等の远加サヌドパヌティア
プリケヌションに察応する十分な
リ゜ヌスを適甚

44

重倧なリスク圱響は法什䞍履行、環境ぞの圱
響、人呜・装備品・生産喪倱
たちたちで専甚の OS を䜿甚する堎合あり、セキ
ュリティ機胜はないこずが倚い
専甚制埡アルゎリズムず修正枈みハヌドり゚ア/
゜フトり゚アが関係するため、゜フトり゚ア倉
曎は慎重を芁し、通垞ベンダヌが担圓
システムは所期の産業プロセスに察応するよう
にできおおり、远加セキュリティ機胜に察応す
る十分なメモリや挔算リ゜ヌスはない

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Category
Communications

Information Technology System
Standard communications
protocols
Primarily wired networks with
some localized wireless
capabilities
Typical IT networking practices

Change
Management

Software changes are applied in a
timely fashion in the presence of
good security policy and
procedures. The procedures are
often automated.

Managed Support
Component
Lifetime
Components
Location

Allow for diversified support styles
Lifetime on the order of 3 to 5
years
Components are usually local and
easy to access

Industrial Control System
Many proprietary and standard communication
protocols
Several types of communications media used
including dedicated wire and wireless (radio and
satellite)
Networks are complex and sometimes require the
expertise of control engineers
Software changes must be thoroughly tested and
deployed incrementally throughout a system to ensure
that the integrity of the control system is maintained.
ICS outages often must be planned and scheduled
days/weeks in advance. ICS may use OSs that are no
longer supported
Service support is usually via a single vendor
Lifetime on the order of 10 to 15 years
Components can be isolated, remote, and require
extensive physical effort to gain access to them

In summary, the operational and risk differences between ICS and IT systems create the need for increased
sophistication in applying cybersecurity and operational strategies. A cross-functional team of control
engineers, control system operators and IT security professionals needs to work closely to understand the
possible implications of the installation, operation, and maintenance of security solutions in conjunction
with control system operation. IT professionals working with ICS need to understand the reliability impacts
of information security technologies before deployment. Some of the OSs and applications running on ICS
may not operate correctly with commercial-off-the-shelf (COTS) IT cybersecurity solutions because of
specialized ICS environment architectures.

2.5 Other Types of Control Systems
Although this guide provides guidance for securing ICS, other types of control systems share similar
characteristics and many of the recommendations from this guide are applicable and could be used as a
reference to protect such systems against cybersecurity threats. For example, although many building,
transportation, medical, security and logistics systems use different protocols, ports and services, and are
configured and operate in different modes than ICS, they share similar characteristics to traditional ICS
[18]. Examples of some of these systems and protocols include:
Other Types of Control Systems










Advanced Metering Infrastructure.
Building Automation Systems.
Building Management Control Systems.
Closed-Circuit Television (CCTV) Surveillance Systems.
CO2 Monitoring.
Digital Signage Systems.
Digital Video Management Systems.
Electronic Security Systems.
Emergency Management Systems.

45

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

カテゎリ

情報ITシステム

産業甚制埡システムICS

通信

暙準通信プロトコル
プラむマリ有線ネットワヌクで局
所的に無線機胜あり

倚数の専甚・暙準通信プロトコル

䞀般的 IT ネットワヌク芏範

ネットワヌクは耇雑で、制埡゚ンゞニアの専門
知識を必芁ずするこずあり

管理倉曎

゜フトり゚ア倉曎は良奜なセキュ
リティポリシヌ・手順に埓いタむ
ムリヌに実斜。手順は自動化され
おいるこずが倚い。

゜フトり゚ア倉曎は、システム党䜓を通じお培
底的に詊隓・展開し、制埡システムが保党され
るようにする。ICS 停止の倚くは、数日又は数週
間前にあらかじめ蚈画・予定が必芁。サポヌト
が終了した OS を䜿甚しおいる堎合あり

管理サポヌト

倚様なサポヌトスタむルあり

サヌビスサポヌトは通垞 1 業者のみ

コンポヌネント
の寿呜

3 幎5 幎

10 幎15 幎

コンポヌネント
の所圚堎所

通垞ロヌカル所圚で、アクセスが
容易

コンポヌネントは隔絶された遠隔地にあり、ア
クセスにはかなりの物理的劎力が必芁

専甚有線・無線無線及びサテラむトを含む
数皮の通信メディアを利甚

芁玄するず、ICS システムず IT システム間には、運甚及びリスクの違いがあるこずから、掗緎
されたサむバヌセキュリティず運甚戊略を適甚する必芁が生じる。制埡゚ンゞニア、制埡システ
ム操䜜員及び IT セキュリティ専門員からなる機胜暪断チヌムは、緊密に連携しお、セキュリテ
ィ゜リュヌションの導入、運甚及び保守がもたらし埗る意味を、制埡システムの運甚ずの兌ね合
いで理解する必芁がある。ICS で䜜業を行う IT 専門員は展開前に、情報セキュリティ技術の信
頌性圱響に぀いお理解しおおく必芁がある。ICS 䞊で実行する OS やアプリケヌションの䞭には、
特殊な ICS 環境アヌキテクチャに起因しお、民生COTSIT サむバヌセキュリティ゜リュヌシ
ョンの正垞な動䜜ができないものもある。

2.5

別皮の制埡システム

本曞では ICS のセキュリティを確保するためのガむダンスを瀺すが、別皮の制埡システムでも共
通の特城があり、本曞の掚奚事項の倚くは適甚可胜で、サむバヌセキュリティ脅嚁からそうした
システムを保護する際の参考曞ずしお掻甚可胜である。䟋えば、ビル、茞送、医療、セキュリテ
ィ、ロゞスティック等のシステムの倚くは䜿甚するプロトコル、ポヌト及びサヌビスが異なり、
ICS ずは異なるモヌドで蚭定され運甚されおいるが、䌝統的な ICS ず共通の特城を持っおいる
[18]。そうしたシステムやプロトコルの䟋を以䞋に瀺す。
別皮の制埡システム
 最新蚈量むンフラストラクチャ










ビルオヌトメヌションシステム
ビル管理制埡システム
CCTV サヌベむランスシステム
CO2 監芖
デゞタル暙識システム
デゞタルビデオ管理システム
電子セキュリティシステム
緊急管理システム

46

SPECIAL PUBLICATION 800-82 REVISION 2

















GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Energy Management Systems.
Exterior Lighting Control Systems.
Fire Alarm Systems.
Fire Sprinkler Systems.
Interior Lighting Control Systems.
Intrusion Detection Systems.
Physical Access Control Systems.
Public Safety/Land Mobile Radios.
Renewable Energy Geothermal Systems.
Renewable Energy Photo Voltaic Systems.
Shade Control Systems.
Smoke and Purge Systems.
Vertical Transport System (Elevators and Escalators).
Laboratory Instrument Control Systems.
Laboratory Information Management Systems (LIMS).

Protocols/Ports and Services








Modbus: Master/Slave - Port 502.
BACnet 3: Master/Slave - Port 47808.
LonWorks/LonTalk 4: Peer to Peer - Port 1679.
DNP3: Master/Slave – Port 19999 when using Transport Layer Security (TLS), Port 20000 when not
using TLS.
IEEE 802.x - Peer to Peer.
ZigBee - Peer to Peer.
Bluetooth – Master/Slave.

The security controls provided in Appendix G— of this guide are general and flexible enough be used to
evaluate other types of control systems, but subject matter experts should review the controls and tailor
them as appropriate to address the uniqueness of other types of control systems. There is no “one size fits
all,” and the risks may not be the same, even within a particular group. For example, a building has many
different sub-systems such as building automation, fire alarm, physical access control, digital signage,
CCTV, etc. Critical life safety systems such as the fire alarm and physical access control systems may drive
the impact level to be a “High,” while the other systems will usually be “Low.” An organization might
decide to evaluate each sub-system individually, or decide to use an aggregated approach. The control
systems evaluation should be coupled to the Business Impact, Contingency Plan, and Incident Response
Plan to ensure organizational critical functions and operations can be recovered and restored as defined by
the organizations Recovery Time Objectives.

3
4

http://www.bacnet.org/
http://en.wikipedia.org/wiki/LonWorks

47

SP800-82 第 2 版

















産業甚制埡システムICSセキュリティガむド

゚ネルギヌ管理システム
街灯制埡システム
火灜報知システム
消火甚スプリンクラヌシステム
屋内灯制埡システム
䟵入怜知システム
物理的立入管理システム
公衆安党/陞䞊移動無線
再生゚ネルギヌ地熱システム
再生゚ネルギヌ倪陜光発電システム
シェヌド制埡システム
排煙システム
鉛盎茞送システム゚レベヌタ/゚スカレヌタ
実隓宀蚈噚制埡システム
実隓宀情報管理システムLIMS

プロトコル/ポヌト及びサヌビス
Modbus:マスタヌ/スレヌブ - ポヌト 502
BACnet5:マスタヌ/スレヌブ - ポヌト 47808
LonWorks/LonTalk 6ピアツヌピア - ポヌト 1679
DNP3:トランスポヌト局セキュリティTLS䜿甚時マスタヌ/スレヌブ – ポヌト 19999
TLS 䞍䜿甚時ポヌト 20000
 IEEE 802.x - ピアツヌピア
 ZigBee - ピアツヌピア.
 Bluetooth – マスタヌ/スレヌブ






本曞の付録 G に蚘茉されるセキュリティ管理は、䞀般的で柔軟性があるため、別皮の制埡システ
ムの評䟡にも利甚できるが、それぞれの䞻題の専門家はその制埡を粟査し、芁すれば調敎を加え
お、別皮システムの独自性を怜蚎すべきである。特定のグルヌプ内であっおも、党おに適合する
「フリヌサむズ」のようなものは存圚せず、リスクも同じではない。䟋えば、ビルにはビルオヌ
トメヌション、火灜報知噚、物理的立入管理、デゞタル暙識、CCTV 等の倚皮倚様なサブシステ
ムが存圚する。火灜報知噚や物理的立入管理システムのような重芁な生呜安党システムは、圱響
レベルを「高」ずすべきで、その他のシステムは通垞「䜎」ずなろう。組織はそれぞれのサブシ
ステムの個別評䟡を行うよう決定し、あるいは集玄的なアプロヌチを取るこずを決定できよう。
制埡システムの評䟡は、事業圱響䞍枬事態蚈画やむンシデント察応蚈画の䞀郚に含めお、組織の
重芁機胜を確保すれば、組織の目暙埩旧時間どおりに業務を回埩・埩旧するこずができる。

5
6

http://www.bacnet.org/
http://en.wikipedia.org/wiki/LonWorks

48

SPECIAL PUBLICATION 800-82 REVISION 2

3.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS Risk Management and Assessment

3.1 Risk Management
Organizations manage risk every day in meeting their business objectives. These risks may include
financial risk, risk of equipment failure, and personnel safety risk, to name just a few. Organizations must
develop processes to evaluate the risks associated with their business and to decide how to deal with those
risks based on organizational priorities and both internal and external constraints. This management of risk
is conducted as an interactive, ongoing process as part of normal operations. Organizations that use ICS
have historically managed risk through good practices in safety and engineering. Safety assessments are
well established in most sectors and are often incorporated into regulatory requirements. Information
security risk management is an added dimension that can be complementary. The risk management process
and framework outlined in this section can be applied to any risk assessment including both safety and
information security.
A risk management process should be employed throughout an organization, using a three-tiered approach
to address risk at the (i) organization level; (ii) mission/business process level; and (iii) information system
level (IT and ICS). The risk management process is carried out seamlessly across the three tiers with the
overall objective of continuous improvement in the organization’s risk-related activities and effective intertier and intra-tier communication among all stakeholders having a shared interest in the mission/business
success of the organization.
This section focuses primarily on ICS considerations at the information system level, however, it is
important to note that the risk management activities, information, and artifacts at each tier impact and
inform the other tiers. Section 6 extends the concepts presented here to the control family level and
provides ICS-specific recommendations to augment security control families. Throughout the following
discussion of risk management, ICS considerations will be highlighted and the impact that these
considerations have on the risk management process will be discussed.
For more information on multi-tiered risk management and the risk management process, refer to NIST
Special Publication 800-39, Managing Information Security Risk: Organization, Mission and Information
System View [20]. NIST Special Publication 800-37 Revision 1, Guide for Applying the Risk Management
Framework to Federal Information Systems: A Security Life Cycle Approach [21], provides guidelines for
applying the Risk Management Framework to federal information systems to include conducting the
activities of security categorization, 7 security control selection and implementation, security control
assessment, information system authorization, 8 and security control monitoring. NIST Special Publication
800-30, Guide for Conducting Risk Assessments, provides a step-by-step process for organizations on: (i)
how to prepare for risk assessments; (ii) how to conduct risk assessments; (iii) how to communicate risk
assessment results to key organizational personnel; and (iv) how to maintain the risk assessments over time
[79].

7

FIPS 199 provides security categorization guidance for non-national security systems [15]. CNSS Instruction 1253 provides similar guidance for national security systems.

8

Security authorization is the official management decision given by a senior organizational official to
authorize operation of an information system and to explicitly accept the risk to organizational operations
and assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon
set of security controls.

49

SP800-82 第 2 版

3.
3.1

産業甚制埡システムICSセキュリティガむド

ICS のリスク管理ずリスク評䟡
リスク管理

組織は、その事業目的を達成するため、日々リスクを管理しおいる。そうしたリスクには財政䞊
のリスク、装備品障害によるリスク、人の安党に関するリスクなどがある。組織はプロセスを策
定しお、事業に関係するリスクを評䟡し、組織の優先事項や組織内倖の制玄事項を基に、リスク
ぞの察凊法を決定しなければならない。このリスク管理は、正芏業務の䞀環ずしお、盞互䜜甚的
な珟行プロセスずしお実斜される。ICS を䜿甚する組織は歎史的に、安党性ず゚ンゞニアリング
における優良芏範を通じお、リスクを管理しおきた。安党性評䟡はほずんどの郚門で確立されお
おり、芏制䞊の芁件に盛り蟌たれおいるこずが倚い。情報セキュリティのリスク管理は、補足的
な付加的次元のものである。このセクションで略述するリスク管理のプロセスず枠組みは、安党
性及び情報セキュリティを含むあらゆるリスク評䟡に応甚できる。
リスク管理のプロセスは、組織党䜓を通じお、(1)組織レベル、(2)任務/事業プロセスレベル、(3)
情報システムレベルIT 及び ICS、ずいう 3 段構えのアプロヌチで採甚すべきである。リスク
管理プロセスは、組織の任務/事業に共通の関心を抱く関係者間においお、組織のリスク関連掻
動及び各段階間・各段階内の効果的な通信を絶えず改善するずいう党䜓的な目的を持っお、3 ぀
の段階にわたっおシヌムレスに行われる。
このセクションでは䞻に、情報システムレベルでの ICS の考慮事項に泚目するが、各段階におけ
るリスク管理掻動、情報及び所産が、他の段階に圱響ず情報をもたらすこずに泚意すべきである。
セクション 6 では、ここで玹介する抂念を曎に制埡系列レベルに拡匵し、セキュリティ察策系列
を増やすための ICS 特有の掚奚事項を提瀺する。これ以降のリスク管理に関する論議を通じお、
ICS の考慮事項に぀いお特筆し、そうした考慮事項がリスク管理プロセスに及がす圱響に぀いお
考察する。
倚段階リスク管理ずリスク管理プロセスの詳现に぀いおは、NISTSP800-39『情報セキュリティリ
スクの管理組織、任務及び情報システム抂説』[20]を参照のこず。NISTSP800-37 改蚂 1『連邊
情報システムぞのリスク管理䜓系適甚ガむドセキュリティラむフサむクルアプロヌチ』[21]は、
リスク管理䜓系を連邊情報システムに適甚する際のガむドラむンずなるもので、セキュリティ区
分 9、セキュリティ管理の遞択・実装、セキュリティ管理の評䟡、情報システムの認可 10及びセ
キュリティ管理の監芖ずいった諞掻動の実斜芁領が盛り蟌たれおいる。NISTSP800-30『リスク評
䟡ガむド』は、(1)リスク評䟡の準備芁領、(2) リスク評䟡の実斜芁領、(3)組織芁人ぞのリスク評
䟡結果の䌝達芁領、(4) リスク評䟡の経時的維持芁領に぀いお、組織のプロセスを段階別に説明
しおいる[79]。

9

10

FIPS 199 は、囜以倖のセキュリティシステムに関するセキュリティ区分のガむダンスずなる[15]。CNSS 呜什 1253 は、囜
のセキュリティシステムに関する同皮のガむダンス。
セキュリティ認可は、組織の高官による公的な管理決定で、情報システムの運甚を認可し、組織の運営・資産、個人、他の
組織及び囜家に察するリスクを、合意されたセキュリティ察策の実装に基づいお、明瀺的に蚱容するものである。

50

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

3.2 Introduction to the Risk Management Process
As shown in Figure 3-1, the risk management process has four components: framing, assessing, responding
and monitoring. These activities are interdependent and often occur simultaneously within an organization.
For example, the results of the monitoring component will feed into the framing component. As the
environment in which organizations operate is always changing, risk management must be a continuous
process where all components have on-going activities. It is important to remember that these components
apply to the management of any risk whether information security, physical security, safety or financial.

Figure 3-1. Risk Management Process Applied Across the Tiers

The framing component in the risk management process consists of developing a framework for the risk
management decisions to be made. The level of risk that an organization is willing to accept is its risk
tolerance [21, p.6].
The framing component should include review of existing documentation, such as prior risk assessments.
There may be related activities; such as community wide disaster management planning that also should be
considered since they impact the requirements that a risk assessment must consider.

51

SP800-82 第 2 版

3.2

産業甚制埡システムICSセキュリティガむド

リスク管理プロセスの玹介

図 3-1 に瀺すように、リスク管理プロセスには、構想、評䟡、察応、監芖の 4 ぀の芁玠がある。
これら諞掻動は盞互䟝存しおおり、同じ組織内で同時に生じるこずが倚い。䟋えば、監芖の結
果が構想に反映される。組織が眮かれた環境は絶えず倉化しおいるため、リスク管理は継続的
なプロセスで、4 ぀の芁玠がどれも進行䞭でなければならない。各芁玠は、情報セキュリティ、
物理的セキュリティ、安党、財政の別を問わず、あらゆるリスクの管理に圓おはたるこずを銘
蚘するのは肝芁である。

評䟡

構想

監芖

段階 1 – 組織
段階 2 – 任務/事業プロセス
段階 3 – 情報システム

察応

図 3-1.党段階にたたがるリスク管理プロセス

リスク管理プロセスにおける構想は、䞋すべきリスク管理䞊の決定に関する䜓系を策定するこ
ずにある。組織が受け入れられるリスクレベルがリスクトレランスである[21, p.6]。
この構想には、以前のリスク評䟡曞など既存文曞の粟査を含めるべきである。関連掻動もあり
埗よう。䟋えば、共同䜓内の灜害管理蚈画なども、リスク評䟡で怜蚎を芁する諞芁件に圱響す
るため、考慮に含めるべきである。

52

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS-specific Recommendations and Guidance
For operators of ICS, safety is the major consideration that directly affects decisions on how systems are
engineered and operated. Safety can be defined as “freedom from conditions that can cause death, injury,
occupational illness, damage to or loss of equipment or property, or damage to the environment.” 116 Part of
the framing component for an ICS organization is determining how these requirements interact with
information security. For example, if safety requirements conflict with good security practice, how will the
organization decide between the two priorities? Most ICS operators would answer that safety is the main
consideration – the framing component makes such assumptions explicit so that there is agreement
throughout the process and the organization.
Another major concern for ICS operators is the availability of services provided by the ICS. The ICS may
be part of critical infrastructure (for example, water or power systems), where there is a significant need for
continuous and reliable operations. As a result, ICS may have strict requirements for availability or for
recovery. Such assumptions should be developed and stated in the framing component. Otherwise, the
organization may make risk decisions that result in unintended consequences on those who depend on the
services provided.
The physical operating environment is another aspect of risk framing that organizations should consider
when working with ICS. ICS often have specific environmental requirements (e.g., a manufacturing
process may require precise temperature), or they may be tied to their physical environment for operations.
Such requirements and constraints should be explicitly stated in the framing component so that the risks
arising from these constraints can be identified and considered.
Assessing risk requires that organizations identify their threats and vulnerabilities, the harm that such
threats and vulnerabilities may cause the organization and the likelihood that adverse events arising from
those threats and vulnerabilities may actually occur.
ICS-specific Recommendations and Guidance
The DHS National Cybersecurity & Communications Integration Center (NCCIC) 12 serves as a centralized
location where operational elements involved in cybersecurity and communications reliance are
coordinated and integrated. The Industrial Control Systems Cyber Emergency Response Team (ICSCERT) 13 collaborates with international and private sector Computer Emergency Response Teams
(CERTs) to share control systems-related security incidents and mitigation measures. ICS-CERT works to
reduce risks within and across all critical infrastructure sectors by partnering with law enforcement
agencies and the intelligence community and coordinating efforts among Federal, state, local, and tribal
governments and control systems owners, operators, and vendors.
When assessing the potential impact to an organization’s mission from a potential ICS incident, it is
important to incorporate the effect on the physical process/system, impact on dependent systems/processes,
and impact on the physical environment among other possibilities. In addition, the potential impact on
safety should always be considered.

11

12
13

MIL-STD-882E, Standard Practice – System Safety, Department of Defense (DoD), May 11, 2012,
https://acc.dau.mil/CommunityBrowser.aspx?id=683694
http://www.dhs.gov/about-national-cybersecurity-communications-integration-center
https://ics-cert.us-cert.gov/

53

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS 固有の掚奚事項及びガむダンス
ICS 操䜜員にずっお安党は、システムの蚈画・実行芁領の決定に盎接圱響する重倧考慮事項であ
る。安党は「死亡、負傷、職業病、装備品・資産の損害・喪倱、環境砎壊を生じる状態から免れ
おいるこず」ず定矩できる 14。ICS 組織の構想郚分は、このような芁件ず情報セキュリティずの
盞互䜜甚芁領を刀定するこずにある。䟋えば、安党芁件がセキュリティの適正芏範ず盞容れない
堎合、組織は 2 ぀の優先課題の間でどのような決定を行うのか。倧方の ICS 操䜜員は、安党が䞻
芁な考慮事項だず答えよう。構想は、このような前提事項を明確にしお、プロセスず組織党䜓を
通じお合意を圢成する。
ICS 操䜜員にずっお、もう 1 ぀の重倧関心事項は、ICS が提䟛するサヌビスの可甚性である。ICS
は重芁むンフラの䞀郚であるこずがあり䟋えば氎道や電気システム、その堎合、継続的で信
頌性の高い運甚に察する需芁は極めお倧きい。その結果、ICS は可甚性ず回埩に察する芁件が厳
栌になる。こうした前提事項を策定し、構想に蚘茉すべきである。そうしないず、組織はリスク
のある決定を䞋し、それが元で、提䟛されるサヌビスに䟝存しおいる人々に思わぬ結果をもたら
すこずになる。
物理的動䜜環境は、ICS を䜿甚する堎合に組織が考慮すべき、もう 1 ぀の面である。ICS には特
殊な環境芁件が倚く補造プロセスでの正確な枩床芁件など、物理的な動䜜環境に拘束されお
いるこずもある。こうした芁件や制玄事項も構想に明蚘し、制玄事項から生じるリスクを特定
し、配慮できるようにすべきである。
リスクを評䟡する際には、組織の脅嚁ず脆匱性、それによっお組織が被る損害、そうした脅嚁ず
脆匱性によりもたらされる有害事象が実際に生じる公算を明らかにするこずが必芁ずなる。
ICS 固有の掚奚事項及びガむダンス
DHS 囜家サむバヌセキュリティ通信統合センタヌ(NCCIC) 15は集䞭所圚地ずしお機胜し、サむバ
ヌセキュリティず通信の信頌性に関わる運甚芁玠はそこで調敎され、統合化されおいる。産業甚
制埡システムサむバヌ緊急察応チヌム(ICS-CERT) 16は、海倖及び民間のコンピュヌタ緊急察応チ
ヌム(CERT)ず連携しお、制埡システム関連のセキュリティむンシデントず緩和察策を共有しお
いる。ICS-CERT は行政圓局や情報組織ずの連携、連邊・州・地方・諞郚族自治䜓のほか制埡シ
ステム所有者やベンダヌずの協働を通じお、あらゆる重芁むンフラ郚門に関わるリスク削枛に努
めおいる。
ICS むンシデントが生じた堎合に組織の任務に及ぶ圱響床を評䟡する際、ずりわけ物理的プロセ
ス/システムぞの圱響、埓属システム/プロセスぞの圱響及び物理的環境ぞの圱響を含めるこずが
肝芁である。加えお、安党性に䞎え埗る圱響を垞に考慮に入れるべきである。

14

15
16

MIL-STD-882E, Standard Practice – System Safety, 囜防総省 (DoD), May 11, 2012,
https://acc.dau.mil/CommunityBrowser.aspx?id=683694
http://www.dhs.gov/about-national-cybersecurity-communications-integration-center
https://ics-cert.us-cert.gov/

54

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The responding component is based on the concept of a consistent organization-wide response to the
identification of risk. Response to identification of risk (as opposed to the response to an incident) requires
that organizations first identify possible courses of actions to address risk, evaluate those possibilities in
light of the organization’s risk tolerance and other considerations determined during the framing step, and
choose the best alternative for the organization. The response component includes the implementation of
the chosen course of action to address the identified risk: acceptance, avoidance, mitigation, sharing,
transfer, or any combination of those options 17.
ICS-specific Recommendations and Guidance
For ICS, available risk responses may be constrained by system requirements, potential adverse impact on
operations, or even regulatory compliance regimes. An example of risk sharing is when utilities enter into
agreements to “loan” line workers in an emergency, which reduces the duration of the effect of an incident
to acceptable levels.
Monitoring is the fourth component of the risk management activities. Organizations must monitor risk on
an on-going basis including: the implementation of chosen risk management strategies; the changes in the
environment that may affect the risk calculation; and, the effectiveness and efficiency of risk reduction
activities. The activities in the monitoring component impact all the other components.

3.3 Special Considerations for Doing an ICS Risk Assessment
The nature of ICS means that when an organization does a risk assessment, there may be additional
considerations that do not exist when doing a risk assessment of a traditional IT system. Because the impact
of a cyber incident in an ICS may include both physical and digital effects, risk assessments need to
incorporate those potential effects. This section will provide a more in-depth examination of the following:


Impacts on safety and use of safety assessments.



Physical impact of a cyber incident on an ICS, including the larger physical environment; effect on the
process controlled, and the physical effect on the ICS itself.



The consequences for risk assessments of non-digital control components within an ICS.

3.3.1 Safety within an ICS Information Security Risk Assessment
The culture of safety and safety assessments is well established within the majority of the ICS user
community. Information security risk assessments should be seen as complementary to such assessments
though the assessments may use different approaches and cover different areas. Safety assessments are
concerned primarily with the physical world. Information security risk assessments primarily look at the
digital world. However, in an ICS environment, the physical and the digital are intertwined and significant
overlap may occur.
It is important that organizations consider all aspects of risk management for safety (e.g., risk framing, risk
tolerances), as well as the safety assessment results, when carrying out risk assessments for information
security. The personnel responsible for the information security risk assessment must be able

17

For additional information on accepting, avoiding, mitigating, sharing, or transferring risk, refer to NIST
Special Publication 800-39 [20].

55

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

察応は、組織党䜓を通じお銖尟䞀貫した圢でリスクの特定に取り組むずいう考え方に基づいおい
る。リスクの特定ぞの察応はむンシデントぞの察応ずは異なり、たずリスクに察しお組織が
取り埗る行動方針を芋極め、構想ステップで刀定された組織のリスクトレランスその他の考慮事
項に照らしお、取り埗る各行動方針を評䟡し、最善策を遞択するこずが求められる。察応には、
遞定した行動方針を実行しお、特定枈みのリスクに察凊するこずが含たれ、それには受容、回避、
緩和、共有、転嫁又はこれらの組合せがある 18。
ICS 固有の掚奚事項及びガむダンス
ICS では、利甚できるリスク察応はシステム芁件、運甚に悪圱響が出る可胜性又は芏制ぞのコン
プラむアンス圢態により制玄される堎合がある。リスク共有の䞀䟋ずしお、緊急時に公共䌁業が
劎働者を「出向させる」契玄を締結し、それによっおむンシデントの圱響期間が受容レベルたで
短瞮されるケヌスが挙げられる。
監芖はリスク管理の 4 番目の芁玠ずなる。組織はリスクを継続的に監芖しなければならないが、
それには遞定したリスク管理戊略の実行、リスク算定に圱響する環境の倉化及びリスク削枛掻動
の効果・効率が含たれる。監芖における諞掻動は他の党おの芁玠に圱響する。

3.3

ICS リスク評䟡の実斜に際しおの特別な考慮事項

ICS の性質䞊、組織がリスク評䟡を行う際には、圚来の IT システムのリスク評䟡実斜時には存圚
しない補足的な考慮事項があり埗るこずである。ICS におけるサむバヌむンシデントの圱響には、
物理的圱響ずデゞタル効果の䞡方があるため、リスク評䟡にはこのような圱響の可胜性を含める
必芁がある。このセクションでは、以䞋に぀いお曎に深く考察する。

 安党性ぞの圱響及び安党性評䟡の䜿甚
 サむバヌむンシデントが ICS に䞎える圱響。これにはより倧芏暡な物理環境、管理されるプ
ロセスぞの圱響及び ICS そのものぞの物理的圱響が含たれる。
 ICS 内の非デゞタル制埡コンポヌネントリスク評䟡結果
3.3.1 ICS 情報セキュリティリスク評䟡における安党性
倧郚分の ICS ナヌザ共同瀟䌚では、安党性や安党性評䟡の文化が定着しおいる。情報セキュリテ
ィリスク評䟡は、皮々のアプロヌチを利甚し様々な分野を察象ずしおはいるが、あくたでも安党
性評䟡の補完ず芋なすべきである。安党性評䟡は、䞻に物理的な䞖界を察象にしおいる。情報セ
キュリティリスク評䟡では、䞻にデゞタル䞖界が関心の察象ずなる。しかし ICS 環境では、物理
䞖界もデゞタル䞖界も互いに入り組んで、かなり重なり合っおいる堎合もある。
情報セキュリティのリスク評䟡を行う堎合、組織は、安党に関するリスク管理のあらゆる面リ
スクの構想、リスクトレランス等のほか、安党性評䟡の結果を考慮に入れるこずが肝芁である。
情報セキュリティリスク評䟡担圓者は、

18

リスクの受容、回避、緩和、共有又は転嫁の詳现は NIST 特別出版物 800-39 [20]を参照のこず。

56

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

to identify and communicate identified risks that could have safety implications. Conversely, the personnel
charged with safety assessments must be familiar with the potential physical impacts and their likelihood
developed by the information security risk assessment process.

3.3.2 Potential Physical Impacts of an ICS Incident
Evaluating the potential physical damage from a cyber incident should incorporate: i) how an incident
could manipulate the operation of sensors and actuators to impact the physical environment; ii) what
redundant controls exist in the ICS to prevent an impact; and iii) how a physical incident could emerge
based on these conditions. A physical impact could negatively impact the surrounding world through
multiple means, including the release of hazardous materials (e.g., pollution, crude oil), damaging kinetic
forces (e.g., explosions), and exposure to energy sources (e.g., electricity, steam). The physical incident
could negatively impact the ICS and supporting infrastructure, the various processes performed by the ICS,
or the larger physical environment. An evaluation of the potential physical impacts should include all parts
of an ICS, beginning with evaluating the potential impacts on the set of sensor and actuators. Each of these
domains will be further explored below.
Evaluating the impact of a cyber incident on the physical environment should focus on potential damage to
human safety, the natural environment, and other critical infrastructures. Human safety impacts should be
evaluated based on whether injury, disease, or death is possible from a malfunction of the ICS. This should
incorporate any previously performed safety impact assessments performed by the organization regarding
both employees and the general public. Environmental impacts also may need to be addressed. This
analysis should incorporate any available environmental impact assessments performed by the organization
to determine how an incident could impact natural resources and wildlife over the short or long term. In
addition, it should be noted that ICS may not be located within a single, controlled location and can be
distributed over a wide physical area and exposed to uncontrolled environments. Finally, the impact on the
physical environment should explore the extent to which an incident could damage infrastructures external
to the ICS (e.g., electric generation/delivery, transportation infrastructures, and water services).

3.3.3 Impact of Physical Disruption of an ICS Process
In addition to the impact on the physical environment, the risk assessment should also evaluate potential
effects to the physical process performed by the ICS under consideration, as well as other systems. An
incident that impacts the ICS and disrupts the dependent process may cause cascading impacts into other
related ICS processes and the general public’s dependence on the resulting products and services. Impact to
related ICS processes could include both systems and processes within the organization (e.g., a
manufacturing process that depends on the process controlled by the system under consideration) or
systems and processes external to the organization (e.g., a utility selling generated energy to a nearby plant).
A cyber incident can also negatively impact the physical ICS under consideration. This type of impact
primarily includes the physical infrastructure of the plant (e.g., tanks, valves, motors), along with both the
digital and non-digital control mechanisms (e.g., cables, PLCs, pressure gauge). Damage to the ICS or
physical plant may cause either short or long term outages depending on the degree of the incident. An
example of a cyber incident impacting the ICS is the Stuxnet malware, which caused physical damage to
the centrifuges as well as disrupting dependent processes.

57

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

特定されたリスクで安党䞊の意味があるものを明らかにしお、䌝達できなければならない。反察
に安党性評䟡担圓者は、情報セキュリティリスク評䟡プロセスにより発生する可胜性のある物理
的圱響ずその公算に぀いお粟通しおいなければならない。

3.3.2 ICS むンシデントによる物理的圱響の可胜性
サむバヌむンシデントにより生じ埗る物理的損害の評䟡には次のものが含たれる。(1)むンシデン
トがセンサ及びアクチュ゚ヌタの動䜜をどのように操䜜しお物理的環境に圱響を及がすか。(2)圱
響を防ぐためのどのような冗長制埡が ICS にあるか。(3)このような条件䞋で物理的むンシデント
はどのように生じるか。物理的圱響は呚囲の䞖界に様々な手段で悪圱響を及がしかねないが、そ
れには危険物の攟出汚染、原油等、運動力による損傷爆発等、゚ネルギヌ源ぞの曝露
電気、蒞気等などがある。物理的むンシデントは、ICS 及び支揎むンフラ、ICS が実斜する
倚様なプロセス又はより倧芏暡の物理環境に悪圱響を䞎えかねない。可胜性のある物理的圱響の
評䟡には ICS のあらゆる郚分を含め、たずセンサ・アクチュ゚ヌタセットぞの圱響の可胜性から
開始すべきである。これら領域の各郚分に぀いおは詳しく埌述する。
物理環境に䞎えるサむバヌむンシデントの圱響評䟡は、人的安党、自然環境その他重芁むンフ
ラに䞎え埗る損害を重芖すべきである。人的安党ぞの圱響は、ICS の障害から負傷・疟病・死
亡が生じるか吊かを基に評䟡すべきである。これには以前組織が埓業員ず䞀般囜民に関しお実
斜した安党性圱響評䟡も含めるべきである。環境圱響も取り䞊げる必芁があろう。この分析に
は、むンシデントが短期的・長期的に倩然資源や野生生物に䞎える圱響を刀定するために組織
が実斜した環境圱響評䟡も、利甚できれば含めるべきである。加えお、ICS は管理された䞀か
所に配眮されおおらず、広範な地域に分散し、管理されおいない環境に曝されおいる堎合があ
るこずにも留意すべきである。最埌に、物理環境ぞの圱響は、むンシデントが ICS の倖郚にあ
るむンフラにどの皋床の損害を䞎えるかを調査すべきである発電・送電、茞送むンフラ、氎
道事業等。

3.3.3 ICS プロセスの物理的䞭断による圱響
物理環境ぞの圱響に加えお、リスク評䟡では ICS が実行する考慮察象の物理プロセスず他のシ
ステムぞの圱響も評䟡すべきである。
ICS に圱響を䞎え埓属プロセスを䞭断させるむンシデントは、他の ICS 関連プロセスやそこか
ら生じる補品・サヌビスに䟝存しおいる囜民にも連鎖的な圱響を及がしかねない。関連 ICS プ
ロセスぞの圱響には、組織内のシステム及びプロセス考慮䞭のシステムに制埡されるプロセ
スに䟝存しおいる補造プロセス等又は組織倖のシステム及びプロセス生産した゚ネルギヌ
を近隣のプラントに売る公共事業䜓等が含たれ埗る。
サむバヌむンシデントは、考慮䞭の物理的 ICS にも悪圱響を䞎える。この皮の圱響には䞻ずし
おプラントの物理的むンフラタンク、バルブ、モヌタ等やデゞタル/非デゞタル制埡メカ
ニズムケヌブル、PLC、圧力ゲヌゞ等が含たれる。ICS や物理的プラントぞの損害は、むン
シデントの皋床に応じお短期又は長期の停止に至りかねない。ICS に圱響するサむバヌむンシ
デントの䞀䟋ずしお Stuxnet マルり゚アがあり、遠心分離機を物理的に損傷し、埓属プロセス
を䞭断させる。

58

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

3.3.4 Incorporating Non-digital Aspects of ICS into Impact Evaluations
The impacts on the ICS cannot be adequately determined by focusing only on the digital aspects of the
system, as there are often non-digital mechanisms available that provide fault tolerance and prevent the ICS
from acting outside of acceptable parameters. Therefore, these mechanisms may help reduce any negative
impact that a digital incident on the ICS might have and must be incorporated into the risk assessment
process. For example, ICS often have non-digital control mechanisms that can prevent the ICS from
operating outside of a safe boundary, and thereby limit the impact of an attack (e.g., a mechanical relief
pressure valve). In addition, analog mechanisms (e.g., meters, alarms) can be used to observe the physical
system state to provide operators with reliable data if digital readings are unavailable or corrupted. Table 31 provides a categorization of non-digital control mechanisms that could be available to reduce the impact
of an ICS incident.
Table 3-1. Categories of Non-Digital ICS Control Components
System Type
Analog Displays or Alarms

Manual Control
Mechanisms

Analog Control Systems

Description
Non-digital mechanisms that measure and display the state of the physical system
(e.g., temperature, pressure, voltage, current) and can provide the operator with
accurate information in situations when digital displays are unavailable or
corrupted. The information may be provided to the operator on some non-digital
display (e.g., thermometers, pressure gauges) and through audible alarms.
Manual control mechanisms (e.g., manual valve controls, physical breaker
switches) provide operators with the ability to manually control an actuator without
relying on the digital control system. This ensures that an actuator can be
controlled even if the control system is unavailable or compromised.
Analog control systems use non-digital sensors and actuators to monitor and
control a physical process. These may be able to prevent the physical process
from entering an undesired state in situations when the digital control system is
unavailable or corrupted. Analog controls include devices such as regulators,
governors, and electromechanical relays.

Determination of the potential impact that a cyber incident may have on the ICS should incorporate
analysis of all non-digital control mechanisms and the extent to which they can mitigate potential negative
impacts to the ICS. There are multiple considerations when considering the possible mitigation effects of
non-digital control mechanisms, such as:


Non-digital control mechanisms may require additional time and human involvement to perform
necessary monitoring or control functions and these efforts may be substantial. For example, such
mechanisms may require operators to travel to a remote site to perform certain control functions. Such
mechanisms may also depend on human response times, which may be slower than automated
controls.



Manual and analog systems may not provide monitoring or control capabilities with the same degree
of accuracy and reliability as the digital control system. This may present risk if the primary control
system is unavailable or corrupted due to reduced quality, safety, or efficiency of the system. For
example, a digital/numeric protection relay provides more accuracy and reliable detection of faults
than analog/static relays, therefore, the system maybe more likely to exhibit a spurious relay tripping
if the digital relays are not available.

59

SP800-82 第 2 版

3.3.4

産業甚制埡システムICSセキュリティガむド

ICS の非デゞタル面を圱響評䟡に含める

フォヌルトトレランスを発揮し、ICS が蚱容パラメヌタを逞脱しないように防止できる非デゞ
タルメカニズムも利甚できるので、システムのデゞタル面にのみ泚目しおいるず、ICS ぞの圱
響を適正に刀定するこずができない。したがっお、このようなメカニズムは、ICS 䞊のデゞタ
ルむンシデントに起因する悪圱響を枛らすため、リスク評䟡プロセスに組み蟌む必芁がある。
䟋えば、ICS には非デゞタル制埡メカニズムを持぀ものが倚く、ICS が安党限界を超えないよう
にしお、攻撃の圱響を制限しおいる機械匏の圧力リリヌフバルブ等。たたアナログメカニ
ズムメヌタ、アラヌム等を䜿甚しお、システムの物理的な状態を芳察し、デゞタル衚瀺の
利甚䞍胜・䞭断時に、信頌できるデヌタを操䜜員に提瀺するこずができる。衚 3-1 は、ICS ã‚€
ンシデントの圱響を枛らせる非デゞタル制埡メカニズムの区分である。
è¡š 3-1. 非デゞタル ICS 制埡コンポヌネントのカテゎリヌ
システムの皮類

内容

アナログディスプレむ又は
アラヌム

物理的システムの状態枩床、圧力、電圧、電流等を蚈枬・衚瀺し、デゞタルデ
ィスプレむの利甚䞍胜・䞭断時に正確な状況情報を操䜜員に提䟛できる非デゞタル
メカニズム。情報は非デゞタルディスプレむ枩床蚈、圧力蚈等や音声アラヌム
により操䜜員に提䟛する。

手動制埡メカニズム

手動制埡メカニズム手動バルブ制埡、物理的ブレヌカスむッチ等があれば、操
䜜員はデゞタル制埡システムに䟝存するこずなくアクチュ゚ヌタを手で操䜜でき
る。このため制埡システムが利甚䞍胜・䞍調でもアクチュ゚ヌタを制埡できる。

アナログ制埡システム

アナログ制埡システムは非デゞタルセンサずアクチュ゚ヌタを䜿甚しお、物理プロ
セスを監芖・制埡する。このためデゞタル制埡システムが利甚䞍胜・䞭断時でも、
物理プロセスが奜たしくない状態に陥らないですむ。アナログ制埡にはレギュレヌ
タ、ガバナヌ、電子機械匏リレヌ等のデバむスがある。

サむバヌむンシデントが ICS に䞎え埗る圱響床の刀定には、党おの非デゞタル制埡メカニズ
ムの分析ず、それらが ICS ぞの悪圱響を緩和できる皋床も盛り蟌むべきである。非デゞタル
制埡メカニズムによるこのような緩和効果を怜蚎する際には、次のような考慮事項がある。

 非デゞタル制埡メカニズムが必芁な監芖又は制埡機胜を発揮するには、䜙分の時間ず人の関
䞎が䞍可欠で、それがかなりの皋床になるこずもある。䟋えば、操䜜員が遠方の珟堎たで出
向いお、ある皮の制埡を行わなければならない堎合がある。たた人による察応時間もかかる
ため、自動制埡に比べるず遅くなる。
 手動及びアナログシステムの監芖又は制埡胜力は、デゞタル制埡システムほどの粟床や信頌
性には及ばないこずがある。システムの品質、安党性又は効率が䜎䞋しお、プラむマリ制埡
システムが利甚䞍胜や䞭断になった堎合に、これはリスクずなり埗る。䟋えば、デゞタル/数
倀保護リレヌは、アナログ/スタティックリレヌよりも障害怜知粟床や信頌性が高いので、デ
ゞタルリレヌが利甚できないず、システムはリレヌの疑䌌トリップが生じやすくなる。

60

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

3.3.5 Incorporating the Impact of Safety Systems
Safety systems may also reduce the impact of a cyber incident to the ICS. Safety systems are often
deployed to perform specific monitoring and control functions to ensure the safety of people, the
environment, process, and ICS. While these systems are traditionally implemented to be fully redundant
with respect to the primary ICS, they may not provide complete redundancy from cyber incidents,
specifically from a sophisticated attacker. The impact of the implemented security controls on the safety
system should be evaluated to determine that they do not negatively impact the system.

3.3.6 Considering the Propagation of Impact to Connected Systems
Evaluating the impact of an incident must also incorporate how the impact from the ICS could propagate to
a connected ICS or physical system. An ICS may be interconnected with other systems, such that failures in
one system or process can easily cascade to other systems either within or external to the organization.
Impact propagation could occur due to both physical and logical dependencies. Proper communication of
the results of risk assessments to the operators of connected or interdependent systems and processes is one
way to mitigate such impacts.
Logical damage to an interconnected ICS could occur if the cyber incident propagated to the connected
control systems. An example could be if a virus or worm propagated to a connected ICS and then impacted
that system. Physical damage could also propagate to other interconnected ICS. If an incident impacts the
physical environment of an ICS, it may also impact other related physical domains. For example, the
impact could result in a physical hazard which degrades nearby physical environments. Additionally, the
impact could also degrade the common shared dependencies (e.g., power supply), or result in a shortage of
material needed for a later stage in an industrial process.

61

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

3.3.5 安党システムの圱響を含める
安党システムでは、ICS に䞎えるサむバヌむンシデントの圱響も枛る。安党システムは人・環
境・プロセス・ICS の安党を確保するために、特殊な監芖・制埡機胜甚に展開されるこずが倚
い。そうしたシステムでは、プラむマリ ICS に関しおは埓来完党な冗長性が確保されおいる
䞀方、特に巧劙な攻撃者からのサむバヌむンシデントに関しおは完党な冗長性がない。実装
されたセキュリティ管理が安党システムに䞎える圱響の評䟡は、システムぞの悪圱響の有無
を刀定すべきである。

3.3.6 接続システムぞの圱響波及に察する考慮
むンシデントの圱響を評䟡する際には、ICS からの圱響が、接続された別の ICS や物理的システ
ムにどの皋床波及するかずいう点も含めなければならない。1 ぀の ICS は、いく぀かのシステム
ず連接されおいる堎合があり、あるシステム又はプロセスの障害が組織内倖の他のシステムに容
易に連鎖するこずがある。圱響の波及は、物理的埓属関係ず論理的埓属関係の双方に起因しお生
じ埗る。こうした圱響を緩和する 1 ぀の方法は、リスク評䟡の結果を連接又は盞互䟝存するシス
テム及びプロセスの操䜜員に適切に䌝えるこずである。
連接 ICS の論理的損害は、サむバヌむンシデントが連接制埡システムに波及した堎合に生じ埗る。
りむルスやワヌムが連接 ICS に波及し、次いでシステムに圱響を䞎える堎合がその䞀䟋である。
物理的損害も別の連接 ICS に波及し埗る。あるむンシデントが ICS の物理環境に圱響する堎合、
他の関連物理領域にも圱響を及がし埗る。䟋えば、圱響により物理的危害が生じ、それが隣接の
物理環境を劣化させる堎合がその䞀䟋である。
たた圱響は共通的な共有埓属関係電源等をも劣化させ、産業プロセスの埌続段階で必芁ずな
る資材に䞍足をきたす事態にもなり埗る。

62

SPECIAL PUBLICATION 800-82 REVISION 2

4.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS Security Program Development and Deployment

Section 2 addresses critical operational differences between ICS and IT systems, and Section 3 addresses
risk management. This section combines these two concerns by addressing how organizations should
develop and deploy an ICS security program. ICS security plans and programs should be consistent and
integrated with existing IT security experience, programs, and practices, but must account for the specific
requirements and characteristics of ICS technologies and environments. Organizations should review and
update their ICS security plans and programs regularly to reflect changes in technologies, operations,
standards, and regulations, as well as the security needs of specific facilities.
This section provides an overview of the development and deployment of an ICS security program. Section
4.1 describes how to establish a business case for an ICS security program, including suggested content for
the business case. Sections 4.2 through 4.5 discuss the development of a comprehensive ICS security
program and provide information on several major steps in deploying the program. Information on specific
security controls that might be implemented as part of the security program is provided in Section 6.
Effectively integrating security into an ICS requires defining and executing a comprehensive program that
addresses all aspects of security, ranging from identifying objectives to day-to-day operation and ongoing
auditing for compliance and improvement. An ICS information security manager with appropriate scope,
responsibility, and authority must be identified. This section describes the basic process for developing a
security program, including the following:


Develop a business case for security.



Build and train a cross-functional team.



Define charter and scope.



Define specific ICS policies and procedures.



Implement an ICS Security Risk Management Framework.



o Define and inventory ICS assets.
o Develop security plan for ICS Systems.
o Perform a risk assessment.
o Define the mitigation controls.
Provide training and raise security awareness for ICS staff.

More detailed information on the various steps is provided in ISA-62443-2-1 Security for Industrial
Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security
Program [34].
The commitment to a security program begins at the top. Senior management must demonstrate a clear
commitment to information security. Information security is a business responsibility shared by all
members of the enterprise and especially by leading members of the business, process, and management
teams. Information security programs with adequate funding and visible, top-level support from
organization leaders are more likely to achieve compliance, function more smoothly, and have greater
success than programs that lack that support.

63

SP800-82 第 2 版

4.

産業甚制埡システムICSセキュリティガむド

ICS セキュリティプログラムの開発及び展開

セクション 2 では ICS システムず IT システムの運甚䞊の倧きな違いを、セクション 3 ではリス
ク管理に぀いお取り䞊げた。このセクションでは、組織はいかに ICS セキュリティプログラムを
策定しお展開すべきかに぀いお考察し、これら 2 ぀の関心事を関連づける。ICS セキュリティの
蚈画及びプログラムは銖尟䞀貫し、既存の IT セキュリティ経隓・プログラム・芏範ず䞀䜓化し
おいるべきであるが、ICS 技術・環境の特殊芁件及び特性を取り䞊げおいなければならない。組
織は、ICS セキュリティの蚈画及びプログラムを定期的に芋盎しお曎新し、技術・運甚・芏栌・
芏則の倉曎点のほか、特殊斜蚭のセキュリティ需芁を反映すべきである。
このセクションでは、ICS セキュリティプログラムの開発及び展開に぀いお抂説する。セクショ
ン 4.1 では、ICS セキュリティプログラムに関する事業の、内容案も含めた構築䟋に぀いお瀺す。
4.24.5 では、包括的な ICS セキュリティプログラムの開発に぀いお取䞊げ、それを展開するた
めの倧たかな手順をいく぀か瀺す。セキュリティプログラムの䞀環ずしお実装される特定のセキ
ュリティ管理に぀いおは、セクション 6 で取り䞊げる。
ICS にセキュリティを効果的に組み蟌むには、日垞業務の目的からコンプラむアンス・改善に関
する監査たで、倚岐にわたるセキュリティのあらゆる面を網矅した包括的なプログラムを蚭蚈し
お実行するこずが必芁ずなる。適正な範囲、責任及び暩限を有する ICS 情報セキュリティ管理者
を明確にしなければならない。このセクションでは、以䞋を含むセキュリティプログラム開発に
関する基本プロセスに぀いお説明する。

 セキュリティのビゞネス事䟋䜜成
 機胜暪断チヌムの組成・教育蚓緎
 憲章及び適甚範囲の明確化
 具䜓的な ICS の方針及び手順の明確化
 ICS セキュリティリスク管理䜓制の実行
o

ICS 資産の特定及び明现化

o

ICS システムセキュリティ蚈画策定

o

リスク評䟡実斜

o

緩和察策の明確化

 ICS スタッフの蚓緎及びセキュリティ意識の匷化
皮々の手順に関する詳现は、ISA-62443-2-1『工業オヌトメヌション制埡システムのセキュリテ
ィ工業オヌトメヌション制埡システムセキュリティプログラムの構築』[34]に蚘茉されおいる。
セキュリティプログラムぞの察応は組織のトップから始たる。䞊玚管理者は、情報セキュリティ
ぞの明確な察応を明らかにしなければならない。情報セキュリティは䌁業の党瀟員が共有しおい
る仕事䞊の責務であるが、特に事業、プロセス及び管理チヌムの指導者はそう蚀える。十分な資
金があおがわれ、組織のトップレベルの可芖化された支揎を受けた情報セキュリティプログラム
は、それが埗られないプログラムに比べお、コンプラむアンスを達成し、よりスムヌズに機胜し、
より倧きな成功ずなる公算が高くなる。

64

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Whenever a new system is being designed and installed, it is imperative to take the time to address security
throughout the lifecycle, from architecture to procurement to installation to maintenance to
decommissioning. There are serious risks in deploying systems to production based on the assumption that
they will be secured later. If there is insufficient time and resources to secure the system properly before
deployment, it is unlikely that there will be sufficient time and resources later to address security.
Designing and implementing a new system is quite rare. It is much more common to improve, expand, or
update an existing system. Everything in this section, indeed in this document, applies to managing the risk
of existing ICS. Building an ICS Security Program and applying it to existing systems is much more
complex and challenging.

4.1 Business Case for Security
The first step in implementing an information security program for ICS is to develop a compelling business
case for the unique needs of the organization. The business case should capture the business concerns of
senior management while being founded in the experience of those who are already dealing with many of
the same risks. The business case provides the business impact and financial justification for creating an
integrated information security program. It should include detailed information about the following:
 Benefits, including improved control system reliability and availability, of creating an integrated
security program.


Prioritized potential costs and damage scenarios if an information security program for the ICS is not
implemented.



High-level overview of the process required to implement, operate, monitor, review, maintain, and
improve the information security program.



Costs and resources required to develop, implement and maintain the security program.

Before presenting the business case to management, there should be a well-thought-out and developed
security implementation and cost plan. For example, simply requesting a firewall is insufficient.

4.1.1 Benefits
Responsible risk management policy mandates that the threat to the ICS should be measured and monitored
to protect the interests of employees, the public, shareholders, customers, vendors, society, and the nation.
Risk analysis enables costs and benefits to be weighed so that informed decisions can be made on
protective actions. In addition to reducing risks, exercising due-diligence and displaying responsibility also
helps organizations by:










Improving control system safety, reliability and availability.
Improving employee morale, loyalty, and retention.
Reducing community concerns.
Increasing investor confidence.
Reducing legal liabilities.
Meeting regulatory requirements.
Enhancing the corporate image and reputation.
Helping with insurance coverage and cost.
Improving investor and banking relations.

65

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

新しいシステムを蚭蚈・導入する堎合は垞に、アヌキテクチャから調達、導入、保守、廃棄に至
るたで、ラむフサむクル党䜓を芋通したセキュリティに぀いお考察する時間を取り分けるこずが
肝芁である。セキュリティは埌で考えるずいった想定に基づいお、システムを生産珟堎に展開す
るこずには重倧なリスクがある。展開前にシステムセキュリティをしっかり確保するための時間
ずリ゜ヌスがなければ、展開埌にそれを芋いだすこずなどおが぀かない。
新芏にシステムを蚭蚈しお実装するこずはたれである。既存のシステムを改良、拡匵又は曎新
する堎合がはるかに倚い。このセクションの党お、ずいうよりも本曞の党おの郚分が、既存
ICS のリスク管理に該圓する。ICS セキュリティプログラムを構築しお、既存システムに適甚
するのははるかに耇雑で課題が倚い。

セキュリティの事業事䟋

4.1

ICS の情報セキュリティプログラムを実装する第 1 ステップは、組織特有のニヌズに察応した
匷力な事業事䟋を䜜成するこずである。事業事䟋は、同様のリスクを倚分に扱ったこずがあ
る者の過去の経隓に根ざし぀぀も、䞊玚管理者の事業ぞの関心事をずらえおいるべきである。
事業事䟋は、統合情報セキュリティプログラムを䜜成する䞊で、事業ぞの圱響を䞎え、資金
拠出の理由ずなる。以䞋に関する詳现な情報を網矅すべきである。

 制埡システムの信頌性・可甚性の向䞊など、統合セキュリティプログラムを䜜成するこずに
より埗られる䟿益
 ICS の情報セキュリティプログラムを実装しない堎合に生じ埗る優先経費及び損害
 情報セキュリティプログラムの実装・運甚・監芖・芋盎し・保守・改善に芁するプロセスの、
高レベルの抂芁
 セキュリティプログラムの開発・実装・保守に芁する経費及びリ゜ヌス
事業事䟋を経営陣に提瀺する前に、セキュリティの実装・経費蚈画を慎重に緎り䞊げお䜜成
すべきである。䟋えば、単にファむアりォヌルを芁求するだけでは䞍十分である。

4.1.1

䟿益

しっかりしたリスク管理方針は、ICS に察する脅嚁を蚈枬・監芖しお、埓業員・囜民・株䞻・顧
客・ベンダヌ・瀟䌚・囜の利益を守るこずを矩務づけおいる。リスク分析によりコスト/䟿益の
比范考量を行うこずができ、情報を基に保護察策に関する決定を䞋すこずができる。リスク削枛
に加え、以䞋に察する圓然の努力及び責任を瀺すこずが組織の益ずなる。











制埡システムの安党性・信頌性・可甚性の向䞊
埓業員の士気・忠誠心・勀続意欲の向䞊
共同䜓懞念事項の緩和
投資家の信頌感の増匷
法的責任の軜枛
法的芁件の遵守
䌁業むメヌゞ・名声の拡倧
保険金・経費による救枈
投資家・銀行ずの関係改善

66

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

A strong safety and information security management program is fundamental to a sustainable business
model.
Improved control systems security and control system specific security policies can potentially enhance
control system reliability and availability. This also includes minimizing unintentional control system
information security impacts from inappropriate testing, policies, and misconfigured systems.

4.1.2 Potential Consequences
The importance of secure systems should be further emphasized as business reliance on interconnectivity
increases. Denial of Service (DoS) attacks and malware (e.g., worms, viruses) have become all too
common and have already impacted ICS. Cyber attacks can have significant physical and consequential
impacts. Risk management is addressed in Section 3. The major categories of impacts are as follows:


Physical Impacts. Physical impacts encompass the set of direct consequences of ICS failure. The
potential effects of paramount importance include personal injury and loss of life. Other effects
include the loss of property (including data) and potential damage to the environment.



Economic Impacts. Economic impacts are a second-order effect from physical impacts ensuing from
an ICS incident. Physical impacts could result in repercussions to system operations, which in turn
inflict a greater economic loss on the facility, organization, or others dependent on the ICS.
Unavailability of critical infrastructure (e.g., electrical power, transportation) can have economic
impact far beyond the systems sustaining direct and physical damage These effects could negatively
impact the local, regional, national, or possibly global economy.



Social Impacts. Another second-order effect, the consequence from the loss of national or public
confidence in an organization, is many times overlooked. It is, however, a very real consequence that
could result from an ICS incident.

The program to control such risks is addressed in Section 3. Note that items in this list are not independent.
In fact, one can lead to another. For example, release of hazardous material can lead to injury or death.
Examples of potential consequences of an ICS incident are listed below:
 Impact on national security—facilitate an act of terrorism.
 Reduction or loss of production at one site or multiple sites simultaneously.
 Injury or death of employees.
 Injury or death of persons in the community.
 Damage to equipment.
 Release, diversion, or theft of hazardous materials.
 Environmental damage.
 Violation of regulatory requirements.
 Product contamination.
 Criminal or civil legal liabilities.
 Loss of proprietary or confidential information.
 Loss of brand image or customer confidence.
Undesirable incidents of any sort detract from the value of an organization, but safety and security incidents
can have longer-term negative impacts than other types of incidents on all stakeholders—employees,
shareholders, customers, and the communities in which an organization operates.
The list of potential business consequences needs to be prioritized to focus on the particular business
consequences that senior management will find the most compelling. The highest priority items shown in

67

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ビゞネスモデルを持続させるには、しっかりした安党性・情報セキュリティ管理プログラム
が䞍可欠である。
制埡システムのセキュリティ及び制埡システム特有のセキュリティ方針を改善すれば、制埡シス
テムの信頌性・可甚性を向䞊させ埗る。これには䞍適切な詊隓、方針及び誀蚭定されたシステム
から生じる、制埡システム情報セキュリティぞの想定倖の圱響を極力抑えるこずが含たれる。

4.1.2 生じ埗る結果
セキュアなシステムが重芁なこずは、事業が盞互接続にたすたす䟝存するようになっおいるこず
からも明らかである。サヌビス劚害DoS攻撃やマルり゚アワヌム、りむルス等の存圚は
垞態になっおおり、ICS にも圱響が及んでいる。サむバヌ攻撃は物理的な圱響や波及的な圱響が
倧きい。リスク管理に぀いおはセクション 3 で取り䞊げる。圱響は以䞋のように倧別される。


物理的圱響。これには ICS 障害による盎接の結果が含たれる。最悪の結果ずしお人の負傷や
死亡が生じ埗る。そのほか資産の喪倱デヌタ等や環境砎壊等がある。



経枈的圱響。これは ICS むンシデントに起因する物理的圱響から掟生する二次的圱響で、シ
ステム運甚に圱響を及がし、その結果斜蚭、組織その他 ICS に䟝存するものに察し、曎に倧
きな経枈的損倱をもたらす。重芁むンフラ電力、茞送等が利甚䞍胜になるず、システム
の盎接の物理的損害をはるかに越えた経枈的圱響が生じる。その結果、地元、地域、囜家、
さらには䞖界経枈に悪圱響が及びかねない。

瀟䌚的圱響。これは別の二次的圱響で、組織に察する囜民の信頌感が倱われる結果生じるが、
芋過ごしにされがちである。しかし、ICS むンシデントから生じる実に珟実的な結果である。
このようなリスクを管理するためのプログラムに぀いおはセクション 3 で取り䞊げる。この
リスト䞭の項目はそれぞれが独立しおいるのではない。むしろ、あるものが別のものを導く
こずがある。䟋えば、危険物の攟出は負傷や死亡事故に぀ながる。ICS むンシデントから生じ
埗る結果を以䞋に䟋瀺する。
 囜家安党保障ぞの圱響—テロ行為を助長する
 1 か所又は耇数同時サむトにおける生産の枛少・喪倱
 埓業員の負傷・死亡
 共同䜓構成員の負傷・死亡
 装備品の損害
 危険物の攟出・流甚・盗難
 環境砎壊
 法的芁件の䟵害
 補品の汚染
 刑法又は民法䞊の責任
 専有・秘密情報の喪倱
 ブランドむメヌゞ・顧客の信甚の喪倱
どのような皮類のものであれ、望たしくないむンシデントは組織の䟡倀を枛じるが、安党や
セキュリティが関係するむンシデントは、それ以倖のむンシデントに比べお、より長期的な
悪圱響を埓業員、株䞻、顧客及び組織が属する共同䜓を含めた党おの関係者に投げかける。
可胜性のある事業結果のリストから、事業結果の優先床を怜蚎し、䞊玚管理者が特に圱響床が
倧きいず思えるものに泚力する必芁がある。優先的な事業結果リストの最優先項目を

68

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

the list of prioritized business consequences should be evaluated to obtain an estimate of the annual
business impact, preferably but not necessarily in financial terms.
The Sarbanes-Oxley Act requires corporate leaders to sign off on compliance with information accuracy
and protection of corporate information. 19 Also, the demonstration of due diligence is required by most
internal and external audit firms to satisfy shareholders and other organization stakeholders. By
implementing a comprehensive information security program, management is exercising due diligence.

4.1.3 Resources for Building Business Case
Significant resources for information to help form a business case can be found in external resources in
other organizations in similar lines of business–either individually or in information sharing exchanges,
trade and standards organizations, consulting firms–and internal resources in related risk management
programs or engineering and operations. External organizations can often provide useful tips as to what
factors most strongly influenced management to support their efforts and what resources within their
organizations proved most helpful. For different industries, these factors may be different, but there may be
similarities in the roles that other risk management specialists can play. Appendix D— provides a list and
short description of some of the current activities in ICS security.
Internal resources in related risk management efforts (e.g., information security, health, safety and
environmental risk, physical security, business continuity) can provide tremendous assistance based on
their experience with related incidents in the organization. This information is helpful from the standpoint
of prioritizing threats and estimating business impact. These resources can also provide insight into which
managers are focused on dealing with which risks and, thus, which managers might be the most appropriate
or receptive to serving as a champion. Internal resources in control systems engineering and operations can
provide insight into the details of how control systems are deployed within the organization, such as the
following:





How networks are typically partitioned and segregated.
What remote access connections are generally employed.
How high-risk control systems or safety instrumented systems are typically designed.
What security countermeasures are commonly used.

4.1.4 Presenting the Business Case to Leadership
Section 3 describes a three-tiered approach that addresses risk at the: (i) organization level; (ii)
mission/business process level; and (iii) information system level. The risk management process is carried
out seamlessly across the three tiers with the overall objective of continuous improvement in the
organization’s risk-related activities and effective inter-tier and intra-tier communication among all
stakeholders having a shared interest in the mission/business success of the organization.
It is critical for the success of the ICS security program that organization level management buy into and
participate in the ICS security program. Tier 1 organization level management that encompasses both IT
and ICS operations has the perspective and authority to understand and take responsibility for the risks.
The Tier 1 business leadership will be responsible for approving and driving information security policies,
assigning security roles and responsibilities, and implementing the information security program across the
organization. Funding for the entire program can usually be done in phases. While some

19

More information on the Sarbanes-Oxley Act, and a copy of the act itself, can be found at
http://www.sec.gov/about/laws.shtml.

69

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

評䟡しお、幎間事業圱響芋積を䜜成すべきである。芋積は財務的な芳点から行うのが望たしい
が、矩務ではない。
Sarbanes-Oxley 法は、情報の正確性ず䌁業情報 20の保護遵守に関しお、䌁業責任者に眲名を矩
務づけおいる。たたほずんどの内倖監査法人に察しお、然るべき努力を傟泚しお株䞻その他組
織関係者を満足させるよう求めおいる。包括的情報セキュリティプログラムを斜行するこずで、
経営陣はしかるべき努力を傟泚しおいるこずになる。

4.1.3 事業事䟋䜜成のためのリ゜ヌス
事業事䟋の構築に圹立぀かなりのリ゜ヌスが倖郚同業組織のリ゜ヌスにある。䟋えば個々の䌁業、
又は情報共有亀換、取匕組織及び芏栌組織、コンサルタント䌁業などのほか、関連リスク管理プ
ログラムや゚ンゞニアリング、業務ずいった内郚リ゜ヌスからも利甚できる。倖郚組織は、経営
陣の取組に最も倧きな圱響を䞎える芁因に぀いお、たた組織内のどのリ゜ヌスが最も圹立ったか
ずいった点に関しお、有甚なヒントを䞎えおくれるこずが倚い。業界が異なればそうした芁因も
異なるが、他のリスク管理担圓者が果たす圹割には共通点もある。付録 D には、ICS セキュリテ
ィにおける珟圚の掻動のいく぀かを簡単に玹介したリストがある。
関係するリスク管理の取組情報セキュリティ、衛生、安党・環境リスク、物理的セキュリティ、
事業継続等における内郚リ゜ヌスは、組織の関連むンシデントでの経隓を基に、倧きな助けず
なる。この情報は、脅嚁の優先付けず事業圱響の芋積の芳点から圹立぀。こうしたリ゜ヌスを掻
甚すれば、どの管理者がどのリスクに察応しおいるか、たたどの管理者が掚進者ずしお盞応しい
か、察応力があるかを刀断するこずができよう。制埡システム゚ンゞニアリング業務の内郚リ゜
ヌスを掻甚すれば、以䞋のような、組織ぞの制埡システムの詳现な展開方法を刀断するこずがで
きる。
電子メヌル






ネットワヌクの䞀般的な区画・分割方法
䞀般的に採甚するリモヌトアクセス接続
高リスク制埡システム又は安党蚈装システムの䞀般的蚭蚈
共通的に䜿甚するセキュリティ察策

4.1.4 事業事䟋を組織の長に提瀺する
セクション 3 では次の 3 レベルでのリスクに察応する 3 段階の取組に぀いお説明した。1組
織レベル、2任務・事業プロセスレベル、(3)情報システムレベル。リスク管理プロセスは、
組織の任務・事業の成功に共通の関心を抱く関係者間においお、組織のリスク関連掻動及び各段
階間・各段階内の効果的なコミュニケヌションを絶えず改善するずいう党䜓的な目的を持っお、
3 ぀の段階にわたっおシヌムレスに行われる。
ICS セキュリティプログラムを成功させるには組織レベルで経営陣が同プログラムに玍埗しお、
参加するこずが肝芁である。IT 及び ICS 業務双方を包含する第 1 段階の組織レベル経営陣には、
リスクを理解し責任を匕き受ける芋通しず暩限がある。
第 1 段階の事業のリヌダヌは、情報セキュリティポリシヌを承認・掚進し、セキュリティの圹割
ず責任を付䞎し、情報セキュリティプログラムを組織党䜓にわたっお実行する責務を負う。プロ
グラム党䜓ぞの資金拠出は、通垞フェヌズごずに行う。

20

Sarbanes-Oxley 法の詳现及び入手は次の URL を参照のこず。http://www.sec.gov/about/laws.shtml.

70

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

funding may be required to start the information security activity, additional funding can be obtained later
as the security vulnerabilities and needs of the program are better understood and additional strategies are
developed. Additionally, the costs (both direct and indirect) should be considered for retrofitting the ICS
for security vs. addressing security to begin with.
Often, a good approach to obtain management buy-in to address the problem is to ground the business case
in a successful actual third-party example. The business case should present to management that the other
organization had the same problem and then present that they found a solution and how they solved it. This
will often prompt management to ask what the solution is and how it might be applicable to their
organization.

4.2 Build and Train a Cross-Functional Team
It is essential for a cross-functional information security team to share their varied domain knowledge and
experience to evaluate and mitigate risk in the ICS. At a minimum, the information security team should
consist of a member of the organization’s IT staff, a control engineer, a control system operator, security
subject matter experts, and a member of the enterprise risk management staff. Security knowledge and
skills should include network architecture and design, security processes and practices, and secure
infrastructure design and operation. Contemporary thinking that both safety and security are emergent
properties of connected systems with digital control suggests including a safety expert. For continuity and
completeness, the information security team should also include the control system vendor and/or system
integrator.
The information security team should report directly to the information security manager at the
mission/business process or organization tier, who in turn reports to the mission/business process manager
(e.g., facility superintendent) or enterprise information security manager (e.g., the company’s CIO/CSO),
respectively. Ultimate authority and responsibility rests in the Tier 1 risk executive function that provides a
comprehensive, organization-wide approach to risk management. The risk executive function works with
the top management to accept a level of residual risk and accountability for the information security of the
ICS. Management level accountability will help ensure an ongoing commitment to information security
efforts.
While the control engineers will play a large role in securing the ICS, they will not be able to do so without
collaboration and support from both the IT department and management. IT often has years of security
experience, much of which is applicable to ICS. As the cultures of control engineering and IT are often
significantly different, their integration will be essential for the development of a collaborative security
design and operation.

4.3 Define Charter and Scope
The information security manager should establish policy that defines the guiding charter of the
information security organization and the roles, responsibilities, and accountabilities of system owners,
mission/business process managers, and users. The information security manager should decide upon and
document the objective of the security program, the business organizations affected, all the computer
systems and networks involved, the budget and resources required, and the division of responsibilities. The
scope can also address business, training, audit, legal, and regulatory requirements, as well as timetables
and responsibilities. The guiding charter of the information security organization is a constituent of the
information security architecture which is part of the enterprise architecture, as discussed in Section 3.

71

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

情報セキュリティ掻動を開始するずきにある皋床の資金がいるが、远加資金は、セキュリティ
の脆匱性ずプログラムの必芁性がより明確になり、远加戊略を策定した埌で埗るこずができる。
たたコスト盎接費・間接費は、ICS ぞのセキュリティ実装ず開始時のセキュリティずを考
慮しお決めるべきである。
経営陣が問題に関わるようにするための取組ずしお、事業事䟋を成功した第䞉者の実䟋に倣う
ず䞊手く行くこずが倚い。事業事䟋は経営陣に察し、他の組織でも同じ問題を抱えたこず、解
決策を芋いだし、いかに解決したかを瀺すべきである。そうするこずで経営陣は、その解決策
は䜕か、自分たちの組織にどう応甚できるのか、問うこずができるようになる。

4.2

機胜暪断チヌムの組成・教育蚓緎

機胜暪断型情報セキュリティチヌムが倚様な分野の知識・経隓を共有し合い、ICS のリスクを
評䟡・緩和するこずが䞍可欠ずなる。情報セキュリティチヌムの構成は、少なくずも組織の IT
職員、制埡゚ンゞニア、制埡システム操䜜員、セキュリティ問題担圓者及び䌁業のリスク管理
職員を含めるべきである。セキュリティの知識・スキルには、ネットワヌクアヌキテクチャ・
蚭蚈、セキュリティプロセス・芏範及びセキュアなむンフラ・業務を含めるべきである。安党
ずセキュリティはデゞタル制埡を備えた接続システムの新しい特城であるずいう最近の考え方
には、安党の゚キスパヌトを含めるこずが瀺唆されおいる。継続性ず完党性を確保するため、
情報セキュリティチヌムには、制埡システムのベンダヌやシステムむンテグレヌタをも含める
べきである。
情報セキュリティチヌムには、任務・事業プロセス又は組織レベルの情報セキュリティ管理
者に盎接報告を䞊げるべきで、次いで同管理者はそれぞれ、任務・事業プロセス管理者斜
蚭監督等又は䌁業情報セキュリティ管理者CIO/CSO 等に報告する。最終的な暩限ず責任
は、リスク管理に察しお党䜓的、組織党䜓にわたる取組を行う、第 1 段階におけるリスク担
圓圹員にある。リスク担圓圹員は、経営のトップず連携しお、ICS の情報セキュリティに関す
る残りのリスクレベルず説明責任を受け入れる。経営陣レベルの説明責任は、情報セキュリ
ティぞの取組に察しお行われおいる姿勢を確固たるものにするのに圹立぀。
制埡゚ンゞニアは ICS のセキュリティ確保に倧きな圹割を果たすが、IT 郚門ず経営陣からの協
力・支揎がなければ務たらない。IT におけるセキュリティの経隓は数幎に及ぶこずが倚いが、
その倧郚分は ICS にも応甚できる。制埡゚ンゞニアず IT の文化はそれぞれ倧きく異なるが、
協力的なセキュリティの蚭蚈・実斜を完成するには䞡者の䞀䜓化が䞍可欠ずなる。

4.3

憲章及び適甚範囲の明確化

情報セキュリティ管理者は、情報セキュリティの組織、システム所有者、任務・事業プロセス
管理者及びナヌザの圹割・責任・説明責任を明確にした、指針ずなる憲章を定めるべきである。
情報セキュリティ管理者は、セキュリティプログラムの目的、圱響を受ける事業組織、関係す
る党おのコンピュヌタシステムずネットワヌク、必芁な予算ずリ゜ヌス及び責任の分担を明ら
かにしお、文曞化すべきである。
たたこれには事業、蚓緎、監査、法的芁件及び予定衚ず責任も含たれる。情報セキュリティ
組織の指針ずなる憲章は、セクション 3 で説明した䌁業アヌキテクチャの䞀郚をなす情報セ
キュリティアヌキテクチャを構成する芁玠ずなる。

72

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

There may already be an information security program in place or being developed for the organization’s
IT business systems. The ICS information security manager should identify which existing practices to
leverage and which practices are specific to the control system. In the long run, it will be easier to get
positive results if the team can share resources with others in the organization that have similar objectives.

4.4 Define ICS-specific Security Policies and Procedures
Policies and procedures are at the root of every successful security program. Wherever possible, ICSspecific security policies and procedures should be integrated with existing operational/management
policies and procedures. Policies and procedures help to ensure that security protection is both consistent
and current to protect against evolving threats. Appendix C cites a lack of security policy as an important
vulnerability. Appendix G—, the ICS overlay, contains many ICS information security policy
recommendations. After an information security risk analysis has been performed, the information security
manager should examine existing security policies to see if they adequately address the risks to the ICS. If
needed, existing policies should be revised or new policies created.
As discussed in Section 3, Tier 1 management is responsible for developing and communicating the risk
tolerance of the organization–the level of risk the organization is willing to accept–which allows the
information security manager to determine the level of risk mitigation that should be taken to reduce
residual risk to acceptable levels. The development of the security policies should be based on a risk
assessment that will set the security priorities and goals for the organization so that the risks posed by the
threats are mitigated sufficiently. Procedures that support the policies need to be developed so that the
policies are implemented fully and properly for the ICS. Security procedures should be documented, tested,
and updated periodically in response to policy, technology, and threat changes.

4.5 Implement an ICS Security Risk Management Framework
From an abstract viewpoint, the management of ICS risks is another risk added to the list of risks
confronting an organization (e.g., financial, safety, IT, environmental). In each case, managers with
responsibility for the mission or business process establish and conduct a risk management program in
coordination with top management’s risk executive function. NIST Special Publication 800-39, Managing
Information Security Risk–Organization, Mission, and Information System View [20], is the foundation of
such a risk management program. Just like the other mission/business process areas, the personnel
concerned with ICS apply their specialized subject matter knowledge to establishing and conducting ICS
security risk management and to communicating with enterprise management to support effective risk
management across all the enterprise. NIST Special Publication 800-37, Guide for Applying the Risk
Management Framework to Federal Information Systems [21], introduces the risk management framework
which addresses the process of implementing the framework. The following sections summarize this
process and apply the RMF to an ICS environment.
The RMF process includes a set of well-defined risk-related tasks that are to be carried out by selected
individuals or groups within well-defined organizational roles (e.g., risk executive [function], authorizing
official, authorizing official designated representative, chief information officer, senior information security
officer, enterprise architect, information security architect, information owner/steward, information system
owner, common control provider, information system security officer, and security control assessor). Many
risk management roles have counterpart roles defined in the routine system development life cycle
processes. RMF tasks are executed concurrently with or as part of system development life cycle processes,
taking into account appropriate dependencies.

73

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

既に組織の IT 事業システムに関する情報セキュリティプログラムが斜行されおいるか、䜜成䞭
ずいう堎合もある。ICS 情報セキュリティ管理者は、既存の芏範で掻甚できるものず、制埡シ
ステムに固有の芏範ずを特定すべきである。長い目で芋れば、組織で同様の目的を持ったチヌ
ム同士がリ゜ヌスを共有し合うこずで、よい結果が埗やすくなる。

4.4

ICS 固有のセキュリティポリシヌ及び手順の明確化

ポリシヌず手順は、あらゆるセキュリティプログラムを成功に導く芁である。可胜であれば、
ICS 固有のセキュリティポリシヌず手順を既存の業務/管理ポリシヌ及び手順ず䞀䜓化すべき
である。ポリシヌず手順は、進化する脅嚁に察しお、セキュリティ保護を䞀貫性ず最新性を
備えたものにする䞊で圹立぀。付録 C には、セキュリティポリシヌの欠劂を重倧な脆匱性ず
しお蚀及しおいる。付録 G の ICS オヌバヌレむには、数々の ICS 情報セキュリティポリシヌ
に関する掚奚事項が含たれおいる。情報セキュリティのリスク分析を実斜埌、情報セキュリ
ティ管理者は既存のセキュリティポリシヌを怜蚌し、ICS ぞのリスクがしっかり取り䞊げられ
おいるか確認すべきである。必芁であれば、既存のセキュリティポリシヌを改正するか、䜜
り盎すべきである。
セクション 3 で述べたずおり、第 1 段階の経営陣は組織のリスクトレランスを策定しお䌝達す
る責任を有する。リスクトレランスずは組織が受け入れ可胜なレベルのリスクをいい、これを
基に情報セキュリティ管理者は、残りのリスクを受容レベルにたで緩和するためのリスクレベ
ル緩和策を決めるこずができる。セキュリティポリシヌの策定は、リスク評䟡に基づくが、リ
スク評䟡は組織のセキュリティ優先床ず目暙を蚭定し、脅嚁がもたらすリスクを十分緩和でき
るようにする。ポリシヌを支える手順は、ポリシヌが ICS に察しお十分か぀適正に実斜できる
ように策定する必芁がある。セキュリティ手順はポリシヌ、技術及び脅嚁の倉化に察応しお、
文曞化し、怜蚌し、定期的に曎新すべきである。

4.5

ICS セキュリティリスク管理䜓制の実行

抜象的なずらえ方をすれば、ICS リスクの管理は、組織が盎面するリスクリスト財政、安党、
IT、環境等に远加された付加的リスクずいえる。いずれの堎合も、任務や事業プロセスに責
任を有する管理者は、経営トップのリスク担圓圹員ず協調しお、リスク管理プログラムを策定
し実行する。NIST 特別出版物 800-39『情報セキュリティリスクの管理組織、任務および情
報システムの粟査』[20]は、このようなリスク管理プログラムの基本である。他の任務・事業
プロセス分野ず同様、ICS に関わる人員はそれぞれの専門知識を、ICS セキュリティリスク管
理の策定や、䌁業経営陣ず連携しお党瀟的か぀効果的なリスク管理の支揎に適甚する。NIST 特
別出版物 800-37『連邊情報システムにリスク管理䜓制を適甚するためのガむド』 [21]は、リ
スク管理䜓制に぀いお説明し、䜓制構築プロセスを取り䞊げおいる。続くセクションでは、こ
のプロセスを芁玄し、ICS 環境ぞのリスク管理䜓制RMFの適甚を説明する。
RMF プロセスには、明確化された組織的圹割リスク担圓圹員、蚱可暩者、蚱可暩者が指名し
た代衚者、最高情報責任者、情報セキュリティ䞻任、䌁業蚭蚈者、情報セキュリティ蚭蚈者、
情報所有者/執事、情報システム所有者、共通制埡プロバむダ、情報システムセキュリティ担
圓者、セキュリティ管理査定者等の範囲内で遞ばれた個人やグルヌプが遂行すべき、明確化
されたリスク関連䜜業が含たれおいる。リスク管理䞊の圹割の倚くには、恒垞的なシステム開
発ラむフサむクルプロセスで明らかにされおいるものに盞圓する圹割が含たれる。RMF 䜜業は、
適正な盞互䟝存を考慮に入れた䞊で、システム開発ラむフサむクルプロセスず同時に、又はそ
の䞀郚ずしお実斜する。

74

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Organizations may also wish to consult ISA-62443-2-1, Security for Industrial Automation and Control
Systems: Establishing an Industrial Automation and Control Systems Security Program, which describes
another view of the elements contained in a cybersecurity management system for use in the industrial
automation and control systems environment [34]. It provides guidance on how to meet the requirements
described for each element. Sections 4 through 6 correspond most closely to NIST SP 800-39; other
sections correspond to other NIST Special Publications and to the ICS overlay in Appendix G— of this
document. All of these guidance documents recognize that one size does not fit all; rather, domain
knowledge should be applied in tailoring or adapting the guidance to the specific organization.

4.5.1 Categorize ICS Systems and Networks Assets
The information security team should define, inventory, and categorize the applications and computer
systems within the ICS, as well as the networks within and interfacing to the ICS. The focus should be on
systems rather than just devices, and should include PLCs, DCS, SCADA, and instrument-based systems
that use a monitoring device such as an HMI. Assets that use a routable protocol or are dial-up accessible
should be documented. The team should review and update the ICS asset list annually and after each asset
addition or removal.
There are several commercial enterprise IT inventory tools that can identify and document all hardware and
software resident on a network. Care must be taken before using these tools to identify ICS assets; teams
should first conduct an assessment of how these tools work and what impact they might have on the
connected control equipment. Tool evaluation may include testing in similar, non-production control
system environments to ensure that the tools do not adversely impact the production systems. Impact could
be due to the nature of the information or the volume of network traffic. While this impact may be
acceptable in IT systems, it may not be acceptable in an ICS.
An automated management system for inventory (e.g., Computerized Maintenance Management System
(CMMS), Computer Aided Facility Management System (CAFM), Building Information Model (BIM),
Geospatial Information System (GIS), Construction-Operations Building information exchange data
(COBie, Building Automation Management information exchange (BAMie), Sustainment Management
Systems (SMS) Builder) allows an organization to keep an accurate account of what is on the system for
security reasons and budgetary reasons as well.

4.5.2 Select ICS Security Controls
The security controls selected based on the security categorization of the ICS are documented in the
security plan to provide an overview of the security requirements for the ICS information security program
and describes the security controls in place or planned for meeting those requirements. The development of
security plans is addressed in NIST Special Publication 800-18 Revision 1, Guide for Developing Security
Plans for Federal Information Systems [19]. The security plan can be one document, or it can be the set of
all documents addressing the security concerns for a system and the plans for countering these concerns. In
addition to security controls, NIST Special Publication 800-53 Revision 4, Security and Privacy Controls
for Federal Information Systems and Organizations [20], provides a set of information security program
management (PM) controls that are typically implemented at the organization level and not directed at
individual organizational information systems. This section addresses how an organization establishes and
carries out these program management controls.
The successful implementation of security controls for organizational information systems depends on the
successful implementation of organization-wide program management controls. The manner in which
organizations implement the program management controls depends on specific organizational
characteristics including, for example, the size, complexity, and mission/business requirements of the

75

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ISA-62443-2-1『産業オヌトメヌション及び制埡システムのセキュリティ産業オヌトメヌシ
ョン及び制埡システムのセキュリティプログラムの構築』[34]は、産業オヌトメヌション及び
制埡システム環境甚のサむバヌセキュリティ管理システムに察する別の芋方を玹介しおおり、
参考にするこずができよう。芁玠ごずに芁件を満足するための方法に぀いお、指針が蚘茉され
おいる。セクション 46 は NIST SP 800-39 にほが察応しおおり、他のセクションはそれ以倖
の NIST 特別出版物及び本曞付録 G の ICS オヌバヌレむに察応しおいる。これらガむダンス文
曞はどれもみな、䞀぀のサむズで党おにフィットするようなものはないず述べおいる。むしろ、
ある分野の知芋を応甚しお、ガむダンスを特定の組織に適応させるべきである。

4.5.1 ICS システムずネットワヌク資産の分類
情報セキュリティチヌムは、ICS 内のアプリケヌション及びコンピュヌタシステム䞊びに ICS
内及び ICS ず連接するネットワヌクを定矩し、目録を䜜成し、分類すべきである。デバむスの
みならずシステムに配慮し、PLCs、DCS、SCADA、その他 HMI 等の監芖デバむスを䜿甚する蚈噚
䞻䜓のシステムも含めるべきである。ルヌティングプロトコルを䜿甚する資産やダむアルアッ
プでアクセスする資産は文曞化すべきである。チヌムは ICS 資産リストを幎に䞀床、たた远加
や削陀があるたびに芋盎しお曎新すべきである。
ネットワヌクに垞駐しおいる党おのハヌドり゚ア/゜フトり゚アを識別しお蚘録できる、垂販
の䌁業 IT むンベントリヌツヌルがいく぀かある。そうしたツヌルを䜿甚しお ICS 資産を識別
する前に泚意が必芁ずなる。チヌムはたずツヌルの働きず、接続された制埡装備品に及ぶ圱
響を調べるべきである。ツヌルを評䟡するには、類䌌の非生産環境における詊隓を行い、生
産システムには悪圱響がないこずを確認するずよい。圱響は、情報の性質やネットワヌクト
ラフィック量に起因するこずがある。そうした圱響は IT システムでは蚱容できおも、ICS で
は受け入れられないこずがある。
むンベントリヌ甚自動管理システムコンピュヌタ保守管理システム[CMMS]、コンピュヌタ揎
甚斜蚭管理システム[CAFM]、ビル情報モデル[BIM]、地理空間情報システム[GIS]、建蚭䜜業ビ
ル情報亀換デヌタ[COBie]、ビルオヌトメヌション管理情報亀換[BAMie]、持続管理システム
[SMS]ビルダヌ等はセキュリティ目的ず予算目的でシステム䞊にあるものを正確に把握する
こずができる。

4.5.2 ICS セキュリティ管理の遞択
ICS のセキュリティ分類に埓っお遞択したセキュリティ管理は、セキュリティ蚈画曞に蚘録さ
れ、ICS 情報セキュリティプログラムのセキュリティ芁件の抂芁を瀺し、芁件を遵守するため
に斜行䞭又は蚈画䞭のセキュリティ管理に぀いお説明を䞎える。セキュリティ蚈画曞の䜜成に
぀いおは、NIST 特別出版物 800-18 改蚂第 1 版『連邊情報システム甚セキュリティ蚈画曞の䜜
成ガむド』[19]で取り䞊げられおいる。セキュリティ蚈画曞は䞀冊の文曞でもよく、システム
のセキュリティ䞊の課題ずその察凊蚈画を収めた党文曞の䞀郚であっおもよい。セキュリティ
管理に加えお、NIST 特別出版物 800-53 改蚂第 4 版『連邊情報システム・組織甚セキュリテ
ィ・プラむバシヌ管理』[20]には、䞀般に組織レベルで実装され、個々の組織情報システムに
はない情報セキュリティプログラム管理PM制埡に぀いお取り䞊げられおいる。このセクシ
ョンでは、プログラム管理制埡の構築及び実斜芁領に぀いお取り䞊げる。
組織の情報システム甚セキュリティ管理を銖尟よく実装できるかどうかは、組織党䜓にわたる
プログラム管理制埡を銖尟よく実装できるかどうかにかかっおいる。プログラム管理制埡の実
装方法は、それぞれの䌁業の芏暡、耇雑性、任務・事業芁件ずいった䌁業の性栌に巊右される。

76

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

respective organizations. The program management controls complement the security controls and focus on
the programmatic, organization-wide information security requirements that are independent of any
particular information system and are essential for managing information security programs. Organizations
document program management controls in the information security program plan. The organization-wide
information security program plan supplements the individual security plans developed for each
organizational information system. Together, the security plans for the individual information systems and
the information security program cover the totality of security controls employed by the organization.

4.5.3 Perform Risk Assessment
Because every organization has a limited set of resources, organizations should assess the impacts to
organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals,
other organizations, and the Nation (e.g., using FIPS 199 [15] or a more granular approach). As discussed
in Section 3, organizations can experience the consequences/impact of adverse events at the individual ICS
system level (e.g., failing to perform as required), at the mission/business process level (e.g., failing to fully
meet mission/business objectives), and at the organizational level (e.g., failing to comply with legal or
regulatory requirements, damaging reputation or relationships, or undermining long-term viability). An
adverse event can have multiple consequences and different types of impact, at different levels, and in
different time frames. NIST SP 800-53 [22] and the ICS overlay in Appendix G— incorporate baseline
security controls that derive from this determination of impact.
The organization may perform a detailed risk assessment for the highest impact systems and assessments
for lower impact systems as deemed prudent and as resources allow. The risk assessment will help identify
any weaknesses that contribute to information security risks and mitigation approaches to reduce the risks.
Risk assessments are conducted multiple times during a system’s life cycle. The focus and level of detail
varies according to the system’s maturity.

4.5.4 Implement the Security Controls
Organizations should analyze the detailed risk assessment and the impacts to organizational operations (i.e.,
mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the
Nation, and prioritize selection of mitigation controls. Organizations should focus on mitigating risk with
the greatest potential impact. Security control implementation is consistent with the organization’s
enterprise architecture and information security architecture.
The controls to mitigate a specific risk may vary among types of systems. For example, user authentication
controls might be different for ICS than for corporate payroll systems and e-commerce systems. The ICS
information security manager should document and communicate the selected controls, along with the
procedures for using the controls. Some risks may be identified that can be mitigated by “quick fix”
solutions—low-cost, high-value practices that can significantly reduce risk. Examples of these solutions are
restricting Internet access and eliminating email access on operator control stations or consoles.
Organizations should identify, evaluate, and implement suitable quick fix solutions as soon as possible to
reduce security risks and achieve rapid benefits. The Department of Energy (DOE) has a “21 Steps to
Improve Cyber Security of SCADA Networks” [33] document that could be used as a starting point to
outline specific actions to increase the security of SCADA systems and other ICS.

77

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

プログラム管理制埡はセキュリティ管理を補完するもので、特定の情報システムから独立した、
情報セキュリティプログラムの管理に䞍可欠な、プログラムに埓った党組織的情報セキュリティ
芁件に焊点を圓おおいる。
組織は、プログラム管理制埡を情報セキュリティプログラム蚈画曞の䞭に蚘茉する。党組織的
情報セキュリティプログラム蚈画曞は、各組織の情報システム甚個別セキュリティ蚈画曞を補
完する。同時に個々の情報システム甚セキュリティ蚈画曞ず情報セキュリティプログラムは、
組織が採甚するセキュリティ管理を党䜓的に網矅する。

4.5.3 リスク評䟡実斜
どの組織にもある皋床のリ゜ヌスがあるため、組織は組織業務ぞの圱響任務、機胜、むメヌ
ゞ、評刀等、組織の資産、個人、他の組織や囜に察する圱響を評䟡すべきである
FIPS199[15]その他のアプロヌチを䜿甚。セクション 3 で説明したように、組織は個々の
ICS システムレベルで芁件䞍履行等、任務・事業プロセスレベルで任務・事業目的の䞍
完党な遂行等、組織レベルで法的芁件の䞍履行、評刀・関係の毀損、長期的実珟性の阻害
等、有害事象の結果・圱響を被るこずがある。有害事象がもたらす結果は皮々あり、倚様な
圱響が様々なレベルや時間垯で生じるこずがある。NIST SP 800-53[22]及び付録 G の ICS オヌ
バヌレむには、この圱響刀定から埗た基本ずなるセキュリティ管理が取り䞊げられおいる。
組織は適切ず考えられる堎合、リ゜ヌスの蚱す範囲で、最倧の圱響を受けるシステムには詳现
なリスク評䟡を行い、比范的圱響の少ないシステムにも評䟡を行うこずができる。リスク評䟡
は、情報セキュリティのリスクに寄䞎する匱点ず、リスク緩和策を芋極めるのに圹立぀。リス
ク評䟡はシステムのラむフサむクル期間䞭、䜕床も行う。重点ず詳现レベルはシステムの完成
床に応じお異なる。

4.5.4 セキュリティ管理の実装
組織は詳现なリスク評䟡ず、組織業務任務、機胜、むメヌゞ、評刀等、組織資産、個人、
他の組織や囜に察する圱響を分析し、緩和策の遞定を優先付けすべきである。たた最倧の圱
響がありそうなリスクの緩和に泚力すべきである。セキュリティ管理の実装は、組織の䌁業
アヌキテクチャ及び情報セキュリティアヌキテクチャず敎合する。
特定のリスクの緩和策は、システムの皮類に応じお異なる。䟋えば、ICS でのナヌザ認蚌管理
は、䌁業の絊䞎支払システムや e コマヌスシステムずは異なる。ICS 情報セキュリティ管理者
は、遞んだ察策ずその䜿甚手順に぀いお蚘録し、䌝達すべきである。「迅速補修」゜リュヌシ
ョン、぀たりリスクを倧幅に枛らせる䜎コストで高䟡倀な芏範により緩和可胜なリスクが明ら
かになるこずがある。こうした゜リュヌションの䟋ずしお、操䜜員制埡ステヌションやコン゜
ヌルぞのむンタヌネットアクセスの制限、電子メヌルアクセスの排陀などがある。組織はセキ
ュリティリスクを枛らし、すぐに䟿益が埗られるように、適正な迅速補修策の識別・評䟡・実
装を可及的速やかに行うべきである。゚ネルギヌ省DOEには『SCADA ネットワヌクのサむバ
ヌセキュリティを改善する 21 のステップ』[33]があり、SCADA システムその他 ICS の具䜓的セ
キュリティ向䞊策を考えるスタヌティングポむントずしお䜿甚するこずができる。

78

SPECIAL PUBLICATION 800-82 REVISION 2

5.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS Security Architecture

When designing a network architecture for an ICS deployment, it is usually recommended to separate the
ICS network from the corporate network. The nature of network traffic on these two networks is different:
Internet access, FTP, email, and remote access will typically be permitted on the corporate network but
should not be allowed on the ICS network. Rigorous change control procedures for network equipment,
configuration, and software changes may not be in place on the corporate network. If ICS network traffic is
carried on the corporate network, it could be intercepted or be subjected to DoS or Man-in-the-Middle
attacks [5.14]. By having separate networks, security and performance problems on the corporate network
should not be able to affect the ICS network.
Practical considerations, such as cost of ICS installation or maintaining a homogenous network
infrastructure, often mean that a connection is required between the ICS and corporate networks. This
connection is a significant security risk and should be protected by boundary protection devices. If the
networks must be connected, it is strongly recommended that only minimal (single if possible) connections
be allowed and that the connection is through a firewall and a DMZ. A DMZ is a separate network segment
that connects directly to the firewall. Servers containing the data from the ICS that needs to be accessed
from the corporate network are put on this network segment. Only these systems should be accessible from
the corporate network. With any external connections, the minimum access should be permitted through the
firewall, including opening only the ports required for specific communication. The following sections
elaborate on these architectural considerations. The ICS-CERT recommended practices working group
provides additional guidance as recommended practices 21.

5.1 Network Segmentation and Segregation
This section addresses partitioning the ICS into security domains and separating the ICS from other
networks, such as the corporate network, and presents illustrative security architecture. Operational risk
analysis should be performed to determine critical parts of each ICS network and operation and help define
what parts of the ICS need to be segmented. Network segmentation involves partitioning the network into
smaller networks. For example, one large ICS network is partitioned into multiple ICS networks, where the
partitioning is based on factors such as management authority, uniform policy and level of trust, functional
criticality, and amount of communications traffic that crosses the domain boundary. Network segmentation
and segregation is one of the most effective architectural concepts that an organization can implement to
protect its ICS. Segmentation establishes security domains, or enclaves, that are typically defined as being
managed by the same authority, enforcing the same policy, and having a uniform level of trust.
Segmentation can minimize the method and level of access to sensitive information, ICS communication
and equipment configuration, and can make it significantly more difficult for a malicious cyber adversary
and can contain the effects of non-malicious errors and accidents. A practical consideration in defining a
security domain is the amount of communications traffic that crosses the domain boundary, because
domain protection typically involves examining boundary traffic and determining whether it is permitted.
The aim of network segmentation and segregation is to minimize access to sensitive information for those
systems and people who don’t need it, while ensuring that the organization can continue to operate
effectively. This can be achieved using a number of techniques and technologies depending on the
network’s architecture and configuration.

21

ICS-CERT recommended practices may be found at http://ics-cert.us-cert.gov/Recommended-Practices.

79

SP800-82 第 2 版

5.

産業甚制埡システムICSセキュリティガむド

ICS セキュリティアヌキテクチャ

ICS 展開のネットワヌクアヌキテクチャを蚭蚈する際には、ICS ネットワヌクを䌁業ネットワヌ
クから切り離すこずが垞に掚奚される。䞡者におけるネットワヌクトラフィックの性質は異なる。
䌁業ネットワヌクではむンタヌネットアクセス、FTP、電子メヌル及びリモヌトアクセスが通垞
蚱可されおいるが、ICS ネットワヌクでは蚱可すべきでない。ネットワヌク装備品、構成及び゜
フトり゚ア倉曎に関する厳栌な倉曎管理手順は、䌁業ネットワヌクでは実斜されない。ICS ネッ
トワヌクを䌁業ネットワヌクず䞀緒にするず、傍受されたり DoS や人が介圚する攻撃にさらさ
れかねない[5.14]。ネットワヌクを切り離すこずで、䌁業ネットワヌクの性胜や問題が生じおも、
ICS ネットワヌクには圱響が及ばない。
ICS の蚭眮コストや均質なネットワヌクむンフラの保守コストずいった珟実的な考慮の結果、
ICS ネットワヌクず䌁業ネットワヌクを接続するこずがよくある。このような接続には倧きなセ
キュリティリスクがあり、境界保護デバむスで保護すべきである。䞡ネットワヌクを接続する堎
合、接続を最小限可胜ならシングルにずどめ、ファむアりォヌルず DMZ を蚭けるこずが匷
く掚奚される。DMZ は別個のネットワヌクセグメントで、ファむアりォヌルに盎接接続される。
ICS からのデヌタを持っおいるサヌバで、䌁業ネットワヌクから接続するものに぀いおは、この
ネットワヌクセグメントに眮く。䌁業ネットワヌクから接続可胜なのは、このようなシステムの
みずすべきである。どのような倖郚接続であれ、最小限のアクセスのみファむアりォヌル経由で
蚱可し、特定の接続に必芁なポヌトのみ開攟すべきである。続くセクションでは、このようなア
ヌキテクチャ䞊の考慮事項を詳しく取り䞊げる。ICS-CERT 掚奚芏範䜜業グルヌプは、掚奚芏範
ずしお付加的なガむダンスを提䟛しおいる。 22

5.1

ネットワヌクの分割ず分離

このセクションでは、ICS のセキュリティ領域ぞの区画化ず、䌁業ネットワヌク等他のネットワ
ヌクからの ICS の分離に぀いお説明し、セキュリティアヌキテクチャの䟋を瀺す。業務䞊のリス
ク分析を実斜し、各 ICS ネットワヌク及び業務の重芁郚分を刀別し、分割すべき ICS 郚䜍の明確
化を支揎する。ネットワヌクの分割には、ネットワヌクをより小さいネットワヌクに区画するこ
ずが含たれる。䟋えば、倧きな ICS ネットワヌクを耇数の ICS ネットワヌクに区画化するが、区
画は経営陣の暩限、統䞀的なポリシヌ及び信頌レベル、機胜䞊の重芁床、領域境界を越える通信
トラフィック量ずいった芁因を基にする。ネットワヌクの分割ず分離は、組織がその ICS 防護の
ために実装できる最も効果的なアヌキテクチャ抂念の 1 ぀である。分割によっおセキュリティア
ヌキテクチャ領域、぀たり飛び地ができるが、これは同じポリシヌを斜行し、統䞀された信頌レ
ベルを持぀同䞀の暩限により管理されるものず、䞀般に定矩されおいる。分割により芁泚意情報、
ICS 通信、及び装備品蚭定ぞのアクセス方法やレベルを最小限に抑え、悪意あるサむバヌ攻撃を
著しく困難にし、悪意によらない過誀や事故の圱響を封じ蟌めるこずができる。セキュリティ領
域を明確にする際の珟実的な考慮事項ずしお、領域境界を越える通信トラフィック量がある。ず
いうのは、領域の保護には、通垞境界トラフィックの怜蚌ず蚱可の有無に察する刀定が関係しお
いるからである。
ネットワヌク分割・分離の䞻県は、必芁ずしおいないシステムや人が芁泚意情報にアクセスする
のを最小限に抑える䞀方で、組織の円滑な業務遂行を確保するこずにある。これは、ネットワヌ
クアヌキテクチャ及び構成に応じお、皮々の技法や技術を駆䜿するこずで達成される。

22

ICS-CERT 掚奚の芏範に぀いおは、右蚘のペヌゞを参照のこず。http://ics-cert.us-cert.gov/Recommended-Practices.

80

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Traditionally, network segmentation and segregation is implemented at the gateway between domains. ICS
environments often have multiple well-defined domains, such as operational LANs, control LANs, and
operational DMZs, as well as gateways to non-ICS and less trustworthy domains such as the Internet and
the corporate LANs. When insider attacks, social engineering, mobile devices, and other vulnerabilities and
predisposing conditions discussed in Appendix C— are considered, protecting domain gateways is prudent
and worth considering.
Network segregation involves developing and enforcing a ruleset controlling which communications are
permitted through the boundary. Rules typically are based on source and destination identity and the type or
content of the data being transferred.
When implementing network segmentation and segregation correctly you are minimizing the method and
level of access to sensitive information. This can be achieved using a variety of technologies and methods.
Depending on the architecture and configuration of your network, some of the common technologies and
methods used include:


Logical network separation enforced by encryption or network device-enforced partitioning.



Virtual Local Area Networks (VLANS).
Encrypted Virtual Private Networks (VPNs) use cryptographic mechanisms to separate traffic
combined on one network.
o Unidirectional gateways restrict communications between connections to a single direction,
therefore, segmenting the network.
Physical network separation to completely prevent any interconnectivity of traffic between domains.
o
o



Network traffic filtering which can utilize a variety of technologies at various network layers to
enforce security requirements and domains.
o

Network layer filtering that restricts which systems are able to communicate with others on the
network based on IP and route information.
o
State‐based filtering that restricts which systems are able to communicate with others on the
network based on their intended function or current state of operation.
o
Port and/or protocol level filtering that restricts the number and type of services that each system
can use to communicate with others on the network.
o
Application filtering that commonly filters the content of communications between systems at the
application layer. This includes application-level firewalls, proxies, and content-based filter.
Some vendors are making products to filter ICS protocols at the application level which they market as
ICS firewalls.
Regardless of the technology chosen to implement network segmentation and segregation, there are four
common themes that implement the concept of defense-in-depth by providing for good network
segmentation and segregation:


Apply technologies at more than just the network layer. Each system and network should be
segmented and segregated, where possible, from the data link layer up to and including the application
layer.



Use the principles of least privilege and need‐to‐know. If a system doesn’t need to communicate
with another system, it should not be allowed to. If a system needs to talk only to another system on a
specific port or protocol and nothing else–or it needs to transfer a limited set of labeled or fixedformat data, it should be restricted as such.

81

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

埓来ネットワヌクの分割・分離は、領域間のゲヌトりェむに実装される。ICS 環境は、業務甚
LAN、管理甚 LAN、業務甚 DMZ、非 ICS ぞのゲヌトりェむ、むンタヌネット、䌁業 LAN 等信頌性
の䜎い領域ぞのゲヌトりェむずいった、明確に定矩された耇数の領域を持぀ものが倚い。付録
C で取り䞊げられおいるむンサむダヌ攻撃、゜ヌシャル゚ンゞニアリング、モバむルデバむス
その他の脆匱性及び匱点ずなる状態に぀いお怜蚎する堎合、領域ゲヌトりェむを防護するこず
は堅実であり、怜蚎に倀する。
ネットワヌクの分割には、境界を越えおもよい通信を管理する芏則を策定し、実行するこずが
含たれる。芏則は、送信デヌタの発信元・着信先 ID、皮類又は内容を基にする。
ネットワヌクの分割・分離を適正に実装すれば、芁泚意情報ぞのアクセス方法やレベルを最小
限に抑えるこずになる。これは倚様な技術や方法を甚いるこずで実珟する。ネットワヌクのア
ヌキテクチャ及び構成に応じお、共通に甚いられる技術・方法ずしお次のようなものがある。

 暗号化又はネットワヌクデバむスによる区画化により実行される論理ネットワヌク分離
o
o
o

仮想 LANVLANS
暗号化仮想プラむベヌトネットワヌクVPNsは暗号メカニズムを䜿甚しお、
あるネットワヌク䞊のトラフィックの結合を分離する
単方向ゲヌトりェむは接続点間の通信を䞀方向に制限しお、ネットワヌクを分割
する

 物理的ネットワヌク分離は領域間のトラフィックの盞互連接を党お防止する
 ネットワヌクトラフィックフィルタリングは倚様な技術を皮々のネットワヌク局で䜿甚し、
セキュリティ芁件及び領域を斜行する
o

ネットワヌク局フィルタリングは、IP 及びルヌト情報を基に、ネットワヌク䞊の
他のシステムず亀信可胜なシステムを制限する

o

状態ベヌスフィルタリングは、目的ずする機胜や動䜜の珟状を基に、ネットワヌク

o
o

䞊の他のシステムず亀信可胜なシステムを制限する
ポヌト又はプロトコルレベルフィルタリングは、ネットワヌク䞊の他のシステ
ムず亀信するためにシステムが䜿甚できるサヌビスの数ず皮類を制限する
アプリケヌションフィルタリングは通垞、システム間の亀信内容をアプリケヌシ
ョン局でフィルタリングする。アプリケヌションレベルのファむアりォヌル、プ
ロキシ及びコンテンツベヌスのフィルタヌが含たれる。

ベンダヌによっおは、補品が ICS プロトコルをアプリケヌションレベルでフィルタリングす
るようになっおおり、これを ICS ファむアりォヌルずしお販売しおいる。
ネットワヌク分割・分離のために遞んだ技術ずはかかわりなく、良奜なネットワヌク分割・
分離を具備するこずで、倚局防埡抂念を実装する次の 4 ぀の共通的なテヌマがある。

 ネットワヌク局以倖にも技術を適甚する。可胜であれば、デヌタリンク局からアプリケヌシ
ョン局たでシステムごずにネットワヌクごずに分割・分離すべきである。
 最小暩限の原則ず知る必芁の原則を適甚する。他のシステムずの通信が䞍芁であれば、䞍蚱
可ずすべきである。他のシステムず特定のポヌトやプロトコルでのみ亀信する堎合、又は限
定されたラベルのデヌタセットや固定様匏のデヌタのみを送信する堎合、そのように制限す
べきである。

82

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Separate information and infrastructure based on security requirements. This may include using
different hardware or platforms based on different threat and risk environments in which each system
or network segment operates. The most critical components require more strict isolation from other
components. In addition to network separation, the use of virtualization could be employed to
accomplish the required isolation.



Implement whitelisting 23 instead of blacklisting; that is, grant access to the known good, rather than
denying access to the known bad. The set of applications that run in ICS is essentially static, making
whitelisting more practical. This will also improve an organization’s capacity to analyze log files.

5.2 Boundary Protection
Boundary protection devices control the flow of information between interconnected security domains to
protect the ICS against malicious cyber adversaries and non-malicious errors and accidents. Transferring
information between systems representing different security domains with different security policies
introduces risk that such transfers violate one or more domain security policies. Boundary protection
devices are key components of specific architectural solutions that enforce specific security policies.
Organizations can isolate ICS and business system components performing different missions and/or
business functions. Such isolation limits unauthorized information flows among system components and
also provides the opportunity to deploy greater levels of protection for selected components. Separating
system components with boundary protection mechanisms provides the capability for increased protection
of individual components and more effective control of information flows between those components.
Boundary protection controls include gateways, routers, firewalls, guards, network-based malicious code
analysis and virtualization systems, intrusion detection systems (networked and host-based), encrypted
tunnels, managed interfaces, mail gateways, and unidirectional gateways (e.g., data diodes). Boundary
protection devices determine whether data transfer is permitted, often by examining the data or associated
metadata.
Network and ICS security architects must decide which domains are to be permitted direct communication,
the policies governing permitted communication, the devices to be used to enforce the policy, and the
topology for provisioning and implementing these decisions, which are typically based on the trust
relationship between domains. Trust involves the degree of control that the organization has over the
external domain (e.g., another domain in the same organization, a contracted service provider, the Internet).
Boundary protection devices are arranged in accordance with organizational security architecture. A
common architectural construct is the demilitarized zones (DMZ), a host or network segment inserted as a
“neutral zone” between security domains. Its purpose is to enforce the ICS domain’s information security
policy for external information exchange and to provide external domains with restricted access while
shielding the ICS domain from outside threats.
Additional architectural considerations and functions that can be performed by boundary protection devices
for inter-domain communications include:

23

A whitelist is a list or register of those that are being provided a particular privilege, service, mobility,
access or recognition. Only those on the list will be accepted, approved or recognized (i.e., permitted).
Whitelisting is the reverse of blacklisting, the practice of identifying those that are denied, unrecognized,
or ostracized (i.e., prohibited).

83

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 セキュリティ芁件に基づき、情報ずむンフラを分離する。これには、皮々の脅嚁や各システ
ム又はネットワヌクセグメントが動䜜するリスク環境に埓っお、異なるハヌドり゚アやプラ
ットホヌムを䜿甚するこずが含たれる。最重芁コンポヌネントは、他のコンポヌネントから
より厳栌に分離する必芁がある。ネットワヌクの分離に加えお、必芁な分離を実珟するため
に仮想化を甚いるこずができる。
 ブラックリストではなくホワむトリスト 24を実行する。぀たり、既知の悪にアクセスを拒吊
するのではなく、既知の良にアクセスを蚱可する。ICS で実行するアプリケヌションセット
は基本的に静的であるため、ホワむトリストがより珟実的である。これにより組織のログフ
ァむル分析胜力も向䞊する。

5.2 境界の保護
境界の保護デバむスは、連接されたセキュリティ領域間の情報の流れを制埡し、ICS を悪意ある
サむバヌ攻撃や悪意のない過誀・事故から保護する。別のセキュリティポリシヌを持ったセキュ
リティ領域の異なるシステム間で情報送信するこずは、領域のセキュリティポリシヌを少なくず
も䞀぀は犯すずいうリスクが持ち蟌たれる。境界保護デバむスは、特定のセキュリティポリシヌ
を斜行する特定のアヌキテクチャ゜リュヌションの重芁コンポヌネントである。
組織は ICS ず、別の任務や事業機胜を果たしおいる事業システムコンポヌネントを分離するこず
ができる。分離するこずで、システムコンポヌネント間の未蚱可情報の流れを制限し、遞定した
コンポヌネントにより高レベルの保護を䞎える。境界保護メカニズムを備えたシステムコンポヌ
ネントを分離するこずで、個々のコンポヌネントの保護胜力が向䞊し、これらコンポヌネント間
の情報の流れをより効果的に制埡するこずができる。
境界保護制埡には、ゲヌトりェむ、ルヌタ、ファむアりォヌル、ガヌド、ネットワヌクベヌスの
悪意あるコヌド解析・仮想化システム、䟵入怜知システムネットワヌク及びホストベヌス、
暗号化トンネル、管理むンタフェヌス、メヌルゲヌトりェむ及び単方向ゲヌトりェむデヌタダ
むオヌド等が含たれる。境界保護デバむスは、デヌタ又は関連メタデヌタを怜蚌するこずで、
デヌタ送信が蚱可されおいるかどうかを刀定する。
ネットワヌク及び ICS セキュリティの蚭蚈者は、盎接亀信を蚱可すべき領域、蚱可された亀信を
統制するポリシヌ、ポリシヌの実行甚デバむスを決定し、通垞、ドメむン間の信頌関係を基にし
た、このような決定の準備・実装トポロゞヌも決定しなければならない。信頌には、組織が倖郚
領域同じ組織内の別領域、委蚗サヌビスプロバむダ、むンタヌネット等に察しお有する制埡
の皋床が関係する。
境界保護デバむスは、組織のセキュリティアヌキテクチャに埓っお配眮する。共通的なアヌキテ
クチャ構成は、非歊装地垯DMZ、ホスト又はセキュリティ領域間に「䞭立地垯」ずしお挿
入されたネットワヌクセグメントずなる。目的は、倖郚ずの情報亀換甚 ICS 領域情報セキュリテ
ィポリシヌを斜行し、ICS 領域を倖郚脅嚁からシヌルドし぀぀、倖郚領域にアクセス制限を課す
るこずにある。
領域間亀信甚境界保護デバむスにより実斜可胜な付加的なアヌキテクチャの考慮事項及び機胜に
は次のものがある。

24

ホワむトリストずは、特定の暩限、サヌビス、移動、アクセス又は認識を付䞎された人員の登録リストをいう。リストに
掲茉されおいる者のみが受容、承認又は認識蚱可される。ホワむトリストはブラックリストの反察で、埌者は拒吊、
非認識又は远攟犁止された者を識別するこずをいう。

84

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

 Denying communications traffic by default and allowing communications traffic by exception (i.e.,
deny all, permit by exception). A deny-all, permit-by-exception communications traffic policy ensures
that only those connections which are approved are allowed. This is known as a white-listing policy.


Implementing proxy servers that act as an intermediary for external domains’ requesting information
system resources (e.g., files, connections, or services) from the ICS domain. External requests
established through an initial connection to the proxy server are evaluated to manage complexity and
to provide additional protection by limiting direct connectivity.



Preventing the unauthorized exfiltration of information. Techniques include, for example, deep packet
inspection firewalls and XML gateways. These devices verify adherence to protocol formats and
specification at the application layer and serve to identify vulnerabilities that cannot be detected by
devices operating at the network or transport layers. The limited number of formats, especially the
prohibition of free form text in email, eases the use of such techniques at ICS boundaries.



Only allowing communication between authorized and authenticated source and destinations address
pairs by one or more of the organization, system, application, and individual.



Extending the DMZ concept to other separate subnetworks is useful, for example, in isolating ICS to
prevent adversaries from discovering the analysis and forensics techniques of organizations.



Enforcing physical access control to limit authorized access to ICS components.



Concealing network addresses of ICS components from discovery (e.g., network address not
published or entered in domain name systems), requiring prior knowledge for access.



Disabling control and troubleshooting services and protocols, especially those employing broadcast
messaging, which can facilitate network exploration.



Configuring boundary protection devices to fail in a predetermined state. Preferred failure states for
ICS involve balancing multiple factors including safety and security.



Configuring security domains with separate network addresses (i.e., as disjoint subnets).



Disabling feedback (e.g., non-verbose mode) to senders when there is a failure in protocol validation
format to prevent adversaries from obtaining information.



Implementing one-way data flow, especially between different security domains.



Establishing passive monitoring of ICS networks to actively detect anomalous communications and
provide alerts.

5.3 Firewalls
Network firewalls are devices or systems that control the flow of network traffic between networks
employing differing security postures. In most modern applications, firewalls and firewall environments are
discussed in the context of Internet connectivity and the UDP/IP protocol suite. However, firewalls have
applicability in network environments that do not include or require Internet connectivity. For example,
many corporate networks employ firewalls to restrict connectivity to and from internal networks servicing
more sensitive functions, such as the accounting or human resource departments. Firewalls can

85

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 デフォルトで通信トラフィックを拒絶し、䟋倖的に通信トラフィックを蚱可する党お拒絶
し、䟋倖のみ蚱可。党お拒絶、䟋倖のみ蚱可の通信トラフィックポリシヌは、承認枈みの
接続だけが蚱可されるようにする。これはホワむトリストポリシヌずしお知られおいる。
 プロキシサヌバを実装し、倖郚領域から ICS 領域ぞの情報システムリ゜ヌスファむル、接
続、サヌビス等芁求を仲介させる。プロキシサヌバぞの最初の接続を通じお確立される倖
郚芁求は、耇雑性を管理し、盎接接続を制限するこずで付加的な保護を䞎えるために評䟡を
受ける。
 蚱可されおいない情報がすり抜けるこずを防止する。䟋えば、ディヌプパケットむンスペク
ションファむアりォヌル、XML、ゲヌトりェむ等の技術がある。これらデバむスは、プロ
トコル圢匏ず仕様の敎合性をアプリケヌション局で怜蚌し、ネットワヌク局やトランスポヌ
ト局で動䜜するデバむスには怜出できない脆匱性を特定する。圢匏の数が限定されおおり、
特に電子メヌルにおける自由フォヌマットは犁じられおいるため、このような技術を ICS
境界で䜿甚するのは容易である。
 組織、システム、アプリケヌション及び個人の 1 ぀又は耇数の承認・認蚌枈み゜ヌスず宛先
アドレスのペア間でのみ亀信を蚱可する。
 DMZ の抂念をほかの分離サブネットワヌクに拡匵するのは有甚で、䟋えば、ICS を隔離す
る際に、攻撃偎が組織の分析や捜査技術を芋いだせないようにできる。
 物理的アクセス制埡を実斜しお、ICS コンポヌネントぞのアクセス蚱可を制限する。
 ICS コンポヌネントのネットワヌクアドレスが分からないように隠蔜し公開しない、ドメ
むン名システムに入れないなど、事前の知識がなければアクセスできないようにする。
 管理サヌビス、トラブルシュヌティングサヌビス及びプロトコルを䜿甚䞍胜にする。特にネ
ットワヌク探査が容易にできるブロヌドキャストメッセヌゞを䜿甚しおいるものに぀いお蚀
える。
 境界保護デバむスが決められた状態で機胜しなくなるように蚭定する。ICS に察する故意の
機胜䞍胜状態は、安党性ずセキュリティ等皮々の芁因間でバランスを取るこずが関係する。
 セキュリティ領域に独立したネットワヌクアドレスを蚭定する党く別のサブネット等。
 プロトコルの劥圓性怜蚌圢匏に䞍備がある堎合、送信偎にフィヌドバックを送らない非冗
長モヌド等ようにしお、攻撃偎が情報を埗られなくする。
 単方向のデヌタフロヌを特に別々のセキュリティ領域間に実装する。
 ICS ネットワヌクをパッシブ監芖しお、異垞亀信を積極的に怜出し、アラヌトを発する。

5.3

ファむアりォヌル

ファむアりォヌルは、別々のセキュリティ状態にあるネットワヌク間で、ネットワヌクトラフ
ィックの流れを制埡するデバむス又はシステムのこずである。ほずんどの新しいアプリケヌシ
ョンでは、ファむアりォヌル及びファむアりォヌル環境は、むンタヌネット接続や UDP/IP プ
ロトコルスむヌツずの関係で蚀及される。ただしファむアりォヌルは、むンタヌネット接続を
含たない、又は必芁ずしないネットワヌク環境にも適甚可胜である。䟋えば、倚くの䌁業ネッ
トワヌクではファむアりォヌルを䜿甚しお、䌚蚈や人事郚門等、秘匿を芁する機胜を果たす瀟
内ネットワヌクぞの接続を制限しおいる。曎にファむアりォヌルは、

86

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

further restrict ICS inter-subnetwork communications between functional security subnets and devices. By
employing firewalls to control connectivity to these areas, an organization can prevent unauthorized access
to the respective systems and resources within the more sensitive areas. There are three general classes of
firewalls:


Packet Filtering Firewalls. The most basic type of firewall is called a packet filter. Packet filter
firewalls are essentially routing devices that include access control functionality for system addresses
and communication sessions. The access control is governed by a set of directives collectively referred
to as a rule set. In their most basic form, packet filters operate at layer 3 (network) of the Open
Systems Interconnection (OSI), ISO/IEC 7498 model. This type of firewall checks basic information
in each packet, such as IP addresses, against a set of criteria before forwarding the packet. Depending
on the packet and the criteria, the firewall can drop the packet, forward it, or send a message to the
originator. This type of firewall can offer a high level of security, but could result in overhead and
delay impacts on network performance.



Stateful Inspection Firewalls. Stateful inspection firewalls are packet filters that incorporate added
awareness of the OSI model data at layer 4 (transport). Stateful inspection firewalls filter packets at
the network layer, determine whether session packets are legitimate, and evaluate the contents of
packets at the transport layer (e.g., TCP, UDP) as well. Stateful inspection keeps track of active
sessions and uses that information to determine if packets should be forwarded or blocked. It offers a
high level of security and good performance, but it may be more expensive and complex to administer.
Additional rule sets for ICS applications may be required.



Application-Proxy Gateway Firewalls. This class of firewalls examines packets at the application
layer and filters traffic based on specific application rules, such as specified applications (e.g.,
browsers) or protocols (e.g., FTP). Firewalls of this type can be very effective in preventing attacks on
the remote access and configuration services provided by ICS components. They offer a high level of
security, but could have overhead and delay impacts on network performance, which can be
unacceptable in an ICS environment. NIST SP 800-41 Revision 1, Guidelines on Firewalls and
Firewall Policy [85], provides general guidance for the selection of firewalls and the firewall policies.

In an ICS environment, firewalls are most often deployed between the ICS network and the corporate
network [34]. Properly configured, they can greatly restrict undesired access to and from control system
host computers and controllers, thereby improving security. They can also potentially improve a control
network’s responsiveness by removing non-essential traffic from the network. When properly designed,
configured, and maintained, dedicated hardware firewalls can contribute significantly to increasing the
security of today’s ICS environments.
Firewalls provide several tools to enforce a security policy that cannot be accomplished locally on the
current set of process control devices available in the market, including the ability to:


Block all communications with the exception of specifically enabled communications between devices
on the unprotected LAN and protected ICS networks. Blocking can be based on, for example, source
and destination IP address pairs, services, ports, state of the connection, and specified applications or
protocols supported by the firewall. Blocking can occur on both inbound and outbound packets, which
is helpful in limiting high-risk communications such as email.



Enforce secure authentication of all users seeking to gain access to the ICS network. There is
flexibility to employ varying protection levels of authentication methods including simple passwords,
complex passwords, multi-factor authentication technologies, tokens, biometrics and smart cards.
Select the particular method based upon the vulnerability of the ICS network to be protected, rather
than using the method that is available at the device level.

87

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

機胜的なセキュリティサブネットずデバむス間の ICS サブネット間亀信を制限する。ファむアり
ォヌルを採甚しおこうした゚リアぞの接続を管理すれば、組織はより機密床の高い゚リア内のシ
ステムやリ゜ヌスぞの䞍正アクセスを防止できる。ファむアりォヌルは次の 3 ぀に倧別できる。
 パケットフィルタリングファむアりォヌル。最もベヌシックなタむプのファむアりォヌルが
パケットフィルタず呌ばれる。パケットフィルタファむアりォヌルは、基本的にルヌティン
グデバむスで、システムアドレスず亀信セッションのアクセス制埡機胜を持぀。アクセス制
埡は、ルヌルセットず総称される䞀匏の指什により制埡される。最もベヌシックな圢態では、
パケットフィルタは ISO/IEC 7498 モデル、オヌプンシステム連接OSIのレむダヌ3ネ
ットワヌクで動䜜する。このタむプのファむアりォヌルは、パケットを転送する前に、各
パケット䞭の IP アドレス等の基本情報を基準に照らしおチェックする。パケットず基準に
応じお、ファむアりォヌルはパケットのドロップや転送を行うほか、メッセヌゞを発信者に
送る。このタむプのファむアりォヌルは、セキュリティのレベルは高いが、オヌバヌヘッド
や遅延を生じ、ネットワヌクパフォヌマンスに圱響を䞎えるこずがある。
 ステヌトフルむンスペクションファむアりォヌル。これは OSI モデルデヌタの远加泚意事項
をレむダヌ4トランスポヌトに組み蟌んだパケットフィルタである。パケットをネット
ワヌクレむダヌでフィルタリングし、セッションパケットの適栌性を刀定し、パケット内容
をトランスポヌトレむダヌTCP、UDP 等でも評䟡する。ステヌトフルむンスペクショ
ンはアクティブセッションを远跡し、その情報を基にパケットの転送又はブロックを刀定す
る。セキュリティのレベルは高くパフォヌマンスも良奜であるが、高䟡で管理者にずっお耇
雑ずなる。ICS アプリケヌションの付加的なルヌルセットが必芁になるこずもある。
 アプリケヌション・プロキシゲヌトりェむファむアりォヌル。このクラスのファむアりォヌ
ルは、パケットをアプリケヌション局で怜蚌し、特定のアプリケヌションブラりザヌ等
やプロトコルFTP 等ずいった特定アプリケヌションルヌルに埓っおトラフィックをフィ
ルタリングする。このタむプのファむアりォヌルは、リモヌトアクセスや ICS コンポヌネ
ントが提䟛する蚭定サヌビスに察する攻撃の予防に極めお効果がある。セキュリティのレベ
ルは高いが、オヌバヌヘッドや遅延を生じ、ネットワヌクパフォヌマンスに圱響を䞎えるこ
ずがあるため、ICS 環境では受け入れられない堎合がある。NIST SP800-41 改蚂第 1 版『フ
ァむアりォヌル及びファむアりォヌルポリシヌガむドラむン』[85]には、ファむアりォヌル
及びファむアりォヌルポリシヌを遞定するための䞀般的ガむダンスがある。
ICS 環境では、ファむアりォヌルは ICS ネットワヌクず䌁業ネットワヌク間に倚甚されおいる
[34]。正しく蚭定すれば、制埡システムのホストコンピュヌタずコントロヌラ間の䞍正アクセ
スを著しく制限し、セキュリティを改善する。たた䞍芁なトラフィックをネットワヌクから陀
去するため、制埡ネットワヌクの応答感床を改善するこずもある。蚭蚈・蚭定・保守が適正で
あれば、専甚のハヌドり゚アファむアりォヌルは、今日の ICS 環境のセキュリティ向䞊に倧き
く貢献する。
ファむアりォヌルはいく぀かツヌルを提䟛しおセキュリティポリシヌを斜行するが、そのよう
なセキュリティポリシヌは、珟圚入手可胜な垂販のプロセス制埡デバむスに察しおロヌカルで
実珟できないものであり、次のような機胜を有する。

 保護されおいない LAN 䞊のデバむスず保護された ICS ネットワヌク䞊のデバむス間で特に
蚱可されたものを陀き、党おの亀信をブロックする。ブロックは゜ヌス及び宛先の IP アド
レスペア、サヌビス、ポヌト、接続状態、ファむアりォヌルが蚱可する特定のアプリケヌシ
ョン又はプロトコルに埓っお行う。ブロックは着信パケットでも送信パケットでも生じるが、
これは e メヌル等の高リスク通信を制限する䞊で圹立぀。
 ICS ネットワヌクにアクセスしようずする党おのナヌザ認蚌をセキュアにする。認蚌方法に
は単玔なパスワヌド、耇雑なパスワヌド、耇合芁玠認蚌技術、トヌクン、生物蚈枬孊、スマ
ヌ ト カ ヌ ド 等 が あ り 、 çš® 々 の 保 è­· レ ベ ル を 柔 軟 に 採 甹 で き る 。
デバむスレベルで利甚できる方法を䜿甚するのではなく、保護すべき ICS ネットワヌクの
脆匱性を基に、特定の方法を遞定する。

88

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Enforce destination authorization. Users can be restricted and allowed to reach only the nodes on the
control network necessary for their job function. This reduces the potential of users intentionally or
accidentally gaining access to and control of devices for which they are not authorized, but adds to the
complexity for on-the-job-training or cross-training employees.



Record information flow for traffic monitoring, analysis, and intrusion detection.



Permit the ICS to implement operational policies appropriate to the ICS but that might not be
appropriate in an IT network, such as prohibition of less secure communications like email, and
permitted use of easy-to-remember usernames and group passwords.



Be designed with documented and minimal (single if possible) connections that permit the ICS
network to be severed from the corporate network, should that decision be made, in times of serious
cyber incidents.

Other possible deployments include using either host-based firewalls or small standalone hardware
firewalls in front of, or running on, individual control devices. Using firewalls on an individual device basis
can create significant management overhead, especially in change management of firewall configurations,
however this practice will also simplify individual configuration rulesets.
There are several issues that must be addressed when deploying firewalls in ICS environments, particularly
the following:


The possible addition of delay to control system communications.



The lack of experience in the design of rule sets suitable for industrial applications. Firewalls used to
protect control systems should be configured so they do not permit either incoming or outgoing traffic
by default. The default configuration should be modified only when it is necessary to permit
connections to or from trusted systems to perform authorized ICS functions.

Firewalls require ongoing support, maintenance, and backup. Rule sets need to be reviewed to make sure
that they are providing adequate protection in light of ever-changing security threats. System capabilities
(e.g., storage space for firewall logs) should be monitored to make sure that the firewall is performing its
data collection tasks and can be depended upon in the event of a security violation. Real-time monitoring of
firewalls and other security sensors is required to rapidly detect and initiate response to cyber incidents.

5.4 Logically Separated Control Network
The ICS network should, at a minimum, be logically separated from the corporate network on physically
separate network devices. Based on the ICS network configuration, additional separation needs to be
considered for Safety Instrumented Systems and Security Systems (e.g., physical monitoring and access
controls, doors, gates, cameras, VoIP, access card readers) that are often either part of the ICS network or
utilize the same communications infrastructure for remote sites. When enterprise connectivity is required:


There should be documented and minimal (single if possible) access points between the ICS network
and the corporate network. Redundant (i.e., backup) access points, if present, must be documented.



A stateful firewall between the ICS network and corporate network should be configured to deny all
traffic except that which is explicitly authorized.



The firewall rules should at a minimum provide source and destination filtering (i.e., filter on media
access control [MAC] address), in addition to TCP and User Datagram Protocol (UDP) port filtering
and Internet Control Message Protocol (ICMP) type and code filtering.

89

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 宛先の蚱可。ナヌザは、自分の業務に必芁な制埡ネットワヌク䞊のノヌドにしか到達できな
いように制限を受ける。これによりナヌザが、蚱可されおいないデバむスに、故意又は偶然
にアクセスしお制埡を行う可胜性は枛るが、OJT や亀差蚓緎䞭の埓業員には耇雑さが増す。
 トラフィック監芖、解析及び䟵入怜知のための情報の流れの蚘録。
 IT ネットワヌクには適合しないが、ICS には適合する業務ポリシヌを ICS が実斜するこずを
蚱可する。䟋えば電子メヌル等のセキュリティの䜎い通信、芚えやすいナヌザ名やグルヌプ
パスワヌドの䜿甚を犁止するなど。
 深刻なサむバヌむンシデントの際に決定があれば、ICS ネットワヌクを䌁業ネットワヌクか
ら切断できる、文曞化された最䜎限のできれば 1 ぀のみ接続にする。
その他可胜な展開ずしおは、ホストベヌスのファむアりォヌルや、小型のスタンドアロヌンハ
ヌドり゚アファむアりォヌルを個々の制埡デバむスの前面に又はそうしたデバむス䞊に配眮し
お䜿甚する案もある。個々のデバむスにファむアりォヌルを䜿甚するず、特にファむアりォヌ
ル蚭定の亀換管理に、かなりの管理オヌバヌヘッドが生じるが、個々の蚭定ルヌルセットを簡
玠化するこずにもなる。
ICS 環境にファむアりォヌルを展開する際には、特に次のような考慮すべき問題がいく぀かあ
る。

 制埡システムの通信に遅延が加わる可胜性
 産業甚途に合ったルヌルセットの考案における経隓の欠劂。制埡システムの保護に䜿甚する
ファむアりォヌルの蚭定は、着信トラフィックも送信トラフィックもデフォルトで蚱可しな
いようにすべきである。デフォルト蚭定の倉曎は、信頌されおいるシステムずの接続を蚱可
しお、蚱可された ICS 機胜を実斜する必芁がある堎合のみにすべきである。
ファむアりォヌルは、絶えずサポヌト・保守・バックアップを必芁ずする。絶えず倉化する脅
嚁ずいう芳点から、しっかり保護を確保できるように、ルヌルセットを芋盎す必芁がある。シ
ステムの胜力ファむアりォヌルログのストレヌゞ容量等を監芖しお、ファむアりォヌルが
デヌタ収集䜜業を続行できるようにし、セキュリティ違反事態が生じおも信頌性が保たれるよ
うにすべきである。ファむアりォヌルその他のセキュリティセンサは、リアルタむムで監芖し、
サむバヌむンシデントを怜知しお即応できるようにしなければならない。

5.4

論理的に分離された制埡ネットワヌク

少なくずも ICS ネットワヌクは、物理的に分離されたネットワヌクデバむス䞊の䌁業ネットワヌ
クから、論理的に分離されおいるべきである。ICS ネットワヌク蚭定を基に、付加的な分離を安
党蚈装システムずセキュリティシステム物理的監芖アクセス制埡、ドア、ゲヌト、カメラ、
VoIP、立入カヌドリヌダヌ等向けに怜蚎する必芁がある。これらシステムは、ICS ネットワヌ
クの䞀郚をなすか、同じ通信むンフラを遠隔サむト甚に䜿甚しおいるこずが倚い。䌁業の接続が
必芁な堎合、

 文曞化された最䜎限のできれば 1 ぀のみアクセスポむントが ICS ネットワヌクず䌁業ネ
ットワヌク間にあるべきである。冗長バックアップアクセスポむントがあれば、文曞化
しなければならない。
 ICS ネットワヌクず䌁業ネットワヌク間のステヌトフルファむアりォヌルは、明瀺的に蚱可
されたもの以倖、䞀切のトラフィックを拒絶するように蚭定する。
 TCP 及びナヌザデヌタグラムプロトコルUDPポヌトフィルタリング、むンタヌネット制
埡メッセヌゞプロトコルICMPタむプ・コヌドフィルタリングに加えお、ファむアりォ
ヌルルヌルは少なくずも゜ヌス及び宛先フィルタリングメディアアクセス制埡[MAC]アド
レスでのフィルタリングを行うべきである。

90

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

An acceptable approach to enabling communication between an ICS network and a corporate network is to
implement an intermediate DMZ network. The DMZ should be connected to the firewall such that specific
(restricted) communication may occur between only the corporate network and the DMZ, and the ICS
network and the DMZ. The corporate network and the ICS network should not communicate directly with
each other. This approach is described in Sections 5.5.4 and 5.5.5. Additional security may be obtained by
implementing a Virtual Private Network (VPN) between the ICS and external networks.

5.5 Network Segregation
ICS networks and corporate networks can be segregated to enhance cybersecurity using different
architectures. This section describes several possible architectures and explains the advantages and
disadvantages of each. Please note that the intent of the diagrams in Section 5.5 is to show the placement of
firewalls to segregate the network. Not all devices that would be typically found on the control network or
corporate network are shown. Section 5.6 provides guidance on a recommended defense-in-depth
architecture.

5.5.1 Dual-Homed Computer/Dual Network Interface Cards (NIC)
Dual-homed computers can pass network traffic from one network to another. A computer without proper
security controls could pose additional threats. To prevent this, no systems other than firewalls should be
configured as dual-homed to span both the control and corporate networks. All connections between the
control network and the corporate network should be through a firewall. This configuration provides no
security improvement and should not be used to bridge networks (e.g., ICS and corporate networks).

5.5.2 Firewall between Corporate Network and Control Network
By introducing a simple two-port firewall between the corporate and control networks, as shown in Figure
5-1, a significant security improvement can be achieved. Properly configured, a firewall significantly
reduces the chance of a successful external attack on the control network.
Unfortunately, two issues still remain with this design. First, if the data historian resides on the corporate
network, the firewall must allow the data historian to communicate with the control devices on the control
network. A packet originating from a malicious or incorrectly configured host on the corporate network
(appearing to be the data historian) would be forwarded to individual PLCs/DCS.

91

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS ネットワヌクず䌁業ネットワヌク間の亀信を可胜にする受け入れられるアプロヌチは、䞭間
DMZ ネットワヌクを実装するこずである。DMZ はファむアりォヌルに接続され、䌁業ネットワ
ヌクず DMZ 間及び ICS ネットワヌクず DMZ 間でのみ特定の制限された亀信が生じるよう
にする。䌁業ネットワヌクず ICS ネットワヌク間では盎接亀信が生じないようにすべきである。
このアプロヌチはセクション 5.5.4 及び 5.5.5 で説明する。VPN を ICS ネットワヌクず倖郚ネット
ワヌク間に実装すれば、曎にセキュリティが高たる。

5.5

ネットワヌクの分離

ICS ネットワヌクず䌁業ネットワヌクを分離し、別々のアヌキテクチャを䜿甚しおサむバヌセ
キュリティを高めるこずができる。このセクションでは、いく぀か可胜なアヌキテクチャに぀
いお取り䞊げ、それぞれの利点・欠点を説明する。セクション 5.5 の図の意図は、ファむアり
ォヌルの配眮によるネットワヌクの分離を瀺すこずにある点に留意されたい。制埡ネットワヌ
クや䌁業ネットワヌク䞊に通垞あるデバむスが、必ずしも党お瀺されおいない。セクション
5.6 では、掚奚される倚局防埡アヌキテクチャのガむダンスを瀺す。

5.5.1 デュアルホヌムコンピュヌタ/デュアルネットワヌクむンタフェヌスカヌド
NIC
デュアルホヌムコンピュヌタは、ネットワヌクトラフィックをあるネットワヌクから別のネ
ットワヌクぞ通過させる。しっかりしたセキュリティ察策のないコンピュヌタでは、脅嚁が増
加する。これを防ぐには、制埡ネットワヌクでも䌁業ネットワヌクでも、ファむアりォヌル以
倖のシステムをデュアルホヌムに蚭定するこずである。制埡ネットワヌクず䌁業ネットワヌ
ク間の党おの接続は、ファむアりォヌル経由ずすべきである。この蚭定でセキュリティが向䞊
するこずはなく、ネットワヌク間のブリッゞに䜿甚すべきでないICS ネットワヌクず䌁業ネ
ットワヌク等。

5.5.2 䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌル
図 5-1 のように、䞡ネットワヌク間に単玔な 2 ポヌトファむアりォヌルを蚭眮するこずで、か
なりセキュリティが向䞊する。適正に蚭定すればファむアりォヌルは、制埡ネットワヌクに察
する倖郚攻撃が成功する可胜性を倧幅に枛らす。
残念ながらこの蚭蚈には 2 ぀の問題がある。たず、デヌタヒストリアンが䌁業ネットワヌクに
垞駐しおいる堎合、ファむアりォヌルは、デヌタヒストリアンが制埡ネットワヌク䞊の制埡デ
バむスず亀信するのを蚱可しなければならない。悪意あるホストや䌁業ネットワヌク䞊の蚭定
に䞍備があるデヌタヒストリアンのように芋えるホストからのパケットは、個々の
PLCs/DCS に転送される。

92

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 5-1. Firewall between Corporate Network and Control Network

If the data historian resides on the control network, a firewall rule must exist that allows all hosts from the
enterprise to communicate with the historian. Typically, this communication occurs at the application layer
as Structured Query Language (SQL) or Hypertext Transfer Protocol (HTTP) requests. Flaws in the
historian’s application layer code could result in a compromised historian. Once the historian is
compromised, the remaining nodes on the control network are vulnerable to a worm propagating or an
interactive attack.
Another issue with having a simple firewall between the networks is that spoofed packets can be
constructed that can affect the control network, potentially permitting covert data to be tunneled in allowed
protocols. For example, if HTTP packets are allowed through the firewall, then Trojan horse software
accidentally introduced on an HMI or control network laptop could be controlled by a remote entity and
send data (such as captured passwords) to that entity, disguised as legitimate traffic.
In summary, while this architecture is a significant improvement over a non-segregated network, it requires
the use of firewall rules that allow direct communications between the corporate network and control
network devices. This can result in possible security breaches if not very carefully designed and monitored
[35].

93

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

䌁業/倖界
むンタヌネット/WAN

䌁業ネットワヌク
アプリケヌション
サヌバ

ワヌクステヌション

デヌタ
ヒストリアン

ルヌタ

プリンタ

ファむアりォヌル

ファむアりォヌル

制埡ネットワヌク

PLC

制埡サヌバ

PLC

図 5-1.䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌル

デヌタヒストリアンが制埡ネットワヌク䞊に垞駐しおいる堎合、党おのホストが䌁業偎からヒス
トリアンに通信できるファむアりォヌル芏則がなければならない。䞀般にこの通信は、SQL 又は
HTTP 芁求ずしおアプリケヌション局で生じる。ヒストリアンのアプリケヌション局コヌドに䞍
備があるず、ヒストリアンの機胜が䜎䞋する。そうなるず、制埡ネットワヌクの残りのノヌドが
ワヌムの䌝播やむンタラクティブ攻撃に察しお脆匱になる。
ネットワヌク間に単玔ファむアりォヌルを蚭眮するもう䞀぀の問題点は、なりすたしパケットが
生成され、制埡ネットワヌクに圱響を及がし、秘密デヌタが蚱可されたプロトコルでトンネルさ
れる可胜性がある。䟋えば HTTP パケットの通過がファむアりォヌルから蚱可されるず、HMI や
制埡ネットワヌクラップトップに偶然入り蟌んだトロむの朚銬が倖郚団䜓に遠隔操䜜され、正垞
なトラフィックを装っお、デヌタ捕捉したパスワヌド等が圓該団䜓に送信されるこずになる。
たずめずしお、このアヌキテクチャは非分離ネットワヌクをかなり改善する䞀方で、䌁業ネット
ワヌクデバむスず制埡ネットワヌクデバむス間の盎接亀信を蚱可するずいうファむアりォヌル芏
則を䜿甚しなければならない。その結果、蚭蚈ず監芖をかなり慎重に行わないず、セキュリティ
䟵害が生じるこずになる。

94

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.5.3 Firewall and Router between Corporate Network and Control Network
A slightly more sophisticated design, shown in Figure 5-2, is the use of a router/firewall combination. The
router sits in front of the firewall and offers basic packet filtering services, while the firewall handles the
more complex issues using either stateful inspection or proxy techniques. This type of design is very
popular in Internet-facing firewalls because it allows the faster router to handle the bulk of the incoming
packets, especially in the case of DoS attacks, and reduces the load on the firewall. It also offers improved
defense-in-depth because there are two different devices an adversary must bypass [35].

Figure 5-2. Firewall and Router between Corporate Network and Control Network

95

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.5.3 䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌルずルヌタ
図 5-2 はやや掗緎された蚭蚈で、ルヌタずファむアりォヌルを䜵甚しおいる。ルヌタをファむア
りォヌルの前面に据え、パケットの基本的フィルタリングを行わせ、ファむアりォヌルはステヌ
トフルむンスペクション又はプロキシ技術を甚いおより耇雑な問題の凊理に圓たらせる。この皮
の蚭蚈はむンタヌネットに面したファむアりォヌルではごく䞀般的であるが、より高速なルヌタ
に倧量の着信パケットを凊理させお、特に DoS 攻撃の堎合に備え、ファむアりォヌルぞの負荷
を枛らすためである。たた攻撃偎は 2 皮のデバむスを通過しなければならないため、倚局防埡も
改善される[35]。

䌁業/倖界

むンタヌネット/WAN

䌁業ネットワヌク
アプリケヌション
サヌバ

ワヌクステヌション

デヌタ
ヒストリアン

ルヌタ

プリンタ

ファむアりォヌル

ルヌタ

ファむアりォヌル

制埡ネットワヌク

PLC

PLC

制埡サヌバ

図 5-2.䌁業ネットワヌクず制埡ネットワヌク間のファむアりォヌルずルヌタ

96

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.5.4 Firewall with DMZ between Corporate Network and Control Network
A significant improvement is the use of firewalls with the ability to establish a DMZ between the corporate
and control networks. Each DMZ holds one or more critical components, such as the data historian, the
wireless access point, or remote and third party access systems. In effect, the use of a DMZ-capable
firewall allows the creation of an intermediate network.
Creating a DMZ requires that the firewall offer three or more interfaces, rather than the typical public and
private interfaces. One of the interfaces is connected to the corporate network, the second to the control
network, and the remaining interfaces to the shared or insecure devices such as the data historian server or
wireless access points on the DMZ network. Implementing continuous ingress and egress traffic monitoring
on the DMZ is recommended. Additionally, firewall rulesets that only permit connections between the
control network and DMZ that are initiated by control network devices are recommended. Figure 5-3
provides an example of this architecture.

Figure 5-3. Firewall with DMZ between Corporate Network and Control Network

97

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.5.4 䌁業ネットワヌクず制埡ネットワヌク間の DMZ 付きファむアりォヌル
䌁業ネットワヌクず制埡ネットワヌク間に DMZ を蚭眮できるファむアりォヌルを䜿甚すれば、
かなりの改善ずなる。各 DMZ はデヌタヒストリアン、ワむアレスアクセスポむント、リモヌト
アクセスシステム、サヌドパヌティアクセスシステム等、1 個又は耇数の重芁コンポヌネント
を有する。実際に DMZ 胜力のあるファむアりォヌルを䜿甚すれば、䞭間ネットワヌクが構築で
きる。
DMZ を蚭眮するには、ファむアりォヌルが通垞のパブリック・プラむベヌトむンタフェヌスで
はなく、3 ぀以䞊のむンタフェヌスを備えおいるこずが必須ずなる。その 1 ぀は䌁業ネットワ
ヌクに接続され、2 ぀目は制埡ネットワヌクに、それ以倖のむンタフェヌスはデヌタヒストリ
アンサヌバや DMZ ネットワヌク䞊のワむアレスアクセスポむント等、共有又はセキュリティの
䜎いデバむスに接続される。DMZ の着信・送信トラフィックを連続的に監芖できるように実装
するこずが薊められる。たたファむアりォヌルルヌルセットは、制埡ネットワヌクデバむスが
開始した、制埡ネットワヌクず DMZ 間の接続を蚱可するものが掚奚される。
図 5-3 にこのアヌキテクチャの䟋を瀺す。
䌁業/倖界
むンタヌネット/WAN

䌁業ネットワヌク
ワヌクステヌション
プリンタ

アプリケヌション
サヌバ

ルヌタ

ファむアりォヌル

ファむアりォヌル

デヌタヒストリアン

デヌタサヌバ

制埡ネットワヌク

制埡サヌバ

図 5-3.䌁業ネットワヌクず制埡ネットワヌク間の DMZ 付きファむアりォヌル

98

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

By placing corporate-accessible components in the DMZ, no direct communication paths are required from
the corporate network to the control network; each path effectively ends in the DMZ. Most firewalls can
allow for multiple DMZs, and can specify what type of traffic may be forwarded between zones. As Figure
5-3 shows, the firewall can block arbitrary packets from the corporate network from entering the control
network, and can also regulate traffic from the other network zones including the control network. With
well-planned rule sets, a clear separation can be maintained between the control network and other
networks, with little or no traffic passing directly between the corporate and control networks.
If a patch management server, an antivirus server, or other security server is to be used for the control
network, it should be located directly on the DMZ. Both functions could reside on a single server. Having
patch management and antivirus management dedicated to the control network allows for controlled and
secure updates that can be tailored for the unique needs of the ICS environment. It may also be helpful if
the antivirus product chosen for ICS protection is not the same as the antivirus product used for the
corporate network. For example, if a malware incident occurs and one antivirus product cannot detect or
stop the malware, it is somewhat likely that another product may have that capability.
The primary security risk in this type of architecture is that if a computer in the DMZ is compromised, then
it can be used to launch an attack against the control network via application traffic permitted from the
DMZ to the control network. This risk can be greatly reduced if a concerted effort is made to harden and
actively patch the servers in the DMZ and if the firewall ruleset permits only connections between the
control network and DMZ that are initiated by control network devices. Other concerns with this
architecture are the added complexity and the potential increased cost of firewalls with several ports. For
more critical systems, however, the improved security should more than offset these disadvantages [35].

99

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

䌁業偎からアクセス可胜なコンポヌネントを DMZ 内に配眮するこずで、䌁業ネットワヌクから
制埡ネットワヌクぞの盎接的な通信経路は䞍芁ずなり、各経路は DMZ ですっきり完結する。耇
数の DMZ を備えたファむアりォヌルも倚く、ゟヌン間で転送が蚱されるトラフィックの皮類を
指定できるようになっおいる。図 5-3 に瀺されるように、ファむアりォヌルは、䌁業ネットワ
ヌクから来た䞍定のパケットが制埡ネットワヌクに進入するのをブロックし、制埡ネットワヌ
クも含めた他のネットワヌクゟヌンから来たトラフィックの芏制も行う。よく蚈画されたルヌ
ルセットを持぀こずで、制埡ネットワヌクず他のネットワヌク間の明確な分離が可胜になり、
䌁業ネットワヌクず制埡ネットワヌク間にはほずんど又は党くトラフィックが埀来しないよう
になる。
制埡ネットワヌクにパッチ管理サヌバ、アンチりむルスサヌバその他のセキュリティ サヌバ
を䜿甚する堎合、盎接 DMZ に配眮すべきである。いずれの機胜も 1 ぀のサヌバに垞駐できる。
制埡ネットワヌク専甚のパッチ管理及びアンチりむルス管理を持おば、ICS 環境特有のニヌズ
にフィットする制埡されたセキュアな曎新が可胜になる。たた、ICS の保護甚に遞定したアン
チりむルス補品ず䌁業ネットワヌク甚の補品が違っおいれば、これも圹立぀。䟋えば、マルり
゚アむンシデントが起きお、あるアンチりむルス補品では怜知・停止䞍胜だったずしおも、別
の補品にその胜力がある堎合もある。
この皮のアヌキテクチャにおける䞻なセキュリティリスクは、DMZ であるコンピュヌタの性胜
が䜎䞋した堎合に、それを利甚しお、DMZ から制埡ネットワヌクぞ蚱可されおいるアプリケヌ
ショントラフィック経由で、制埡ネットワヌクぞの攻撃を発動するこずである。DMZ 内のサヌ
バの抗耐性を高め積極的にパッチを圓おる取組をし、ファむアりォヌルのルヌルセットが、制
埡ネットワヌクデバむスが開始した、制埡ネットワヌクず DMZ 間の接続だけを蚱可するように
すれば、このリスクは著しく枛る。このアヌキテクチャに関するその他の懞念材料ずしおは、
耇雑さが増すこずず、耇数のポヌトを持぀ファむアりォヌルがコスト高になるこずである。し
かし、より重芁なシステムでは、セキュリティの向䞊はこうした欠点を補っお䜙りある[35]。

100

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.5.5 Paired Firewalls between Corporate Network and Control Network
A variation on the firewall with a DMZ solution is to use a pair of firewalls positioned between the
corporate and ICS networks, as shown in Figure 5-4. Common servers such as the data historian are
situated between the firewalls in a DMZ-like network zone sometimes referred to as a Manufacturing
Execution System (MES) layer. As in the architectures described previously, the first firewall blocks
arbitrary packets from proceeding to the control network or the shared historians. The second firewall can
prevent unwanted traffic from a compromised server from entering the control network, and prevent control
network traffic from impacting the shared servers.

Figure 5-4. Paired Firewalls between Corporate Network and Control Network

101

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.5.5 䌁業ネットワヌクず制埡ネットワヌク間のペアヌドファむアりォヌル
DMZ 付きファむアりォヌル゜リュヌションのバリ゚ヌションずしお、図 5-4 に瀺すように、フ
ァむアりォヌルをペアにしお䌁業ネットワヌクず ICS ネットワヌク間に配眮する方法がある。デ
ヌタヒストリアンのような共通サヌバは、生産実斜システムMESレむダヌず呌ばれる DMZ
に䌌たネットワヌクゟヌン内のファむアりォヌルずファむアりォヌルの間に配眮される。前述の
アヌキテクチャず同様、最初のファむアりォヌルは、䞍定のパケットが制埡ネットワヌクや共有
ヒストリアンぞ行かないようにブロックする。2 番目のファむアりォヌルは、性胜が䜎䞋したサ
ヌバからの䞍芁のトラフィックが制埡ネットワヌクぞ進入しないようにし、制埡ネットワヌクト
ラフィックが共有サヌバに圱響しないようにする。

䌁業/倖界
むンタヌネット/WAN

䌁業ネットワヌク
アプリケヌション
サヌバ

ワヌクステヌション

ルヌタ

プリンタ

ファむアりォヌル

ファむアりォヌル

ファむアりォヌル
デヌタヒストリアン

デヌタサヌバ

制埡ネットワヌク

制埡サヌバ

図 5-4.䌁業ネットワヌクず制埡ネットワヌク間のペアヌドファむアりォヌル

102

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

If firewalls from two different manufacturers are used, then this solution may offer an advantage. It also
allows the control group and the IT group to have clearly separated device responsibility because each can
manage a firewall on its own, if the decision is made within the organization to do so. The primary
disadvantage with two-firewall architectures is the increased cost and management complexity. For
environments with stringent security requirements or the need for clear management separation, this
architecture has some strong advantages.

5.5.6 Network Segregation Summary
In summary, dual-homed computers generally not provide suitable isolation between control networks and
corporate networks. The two-zone solutions (no DMZ) are not recommended because they provide only
weak protection. If used, they should only be deployed with extreme care. The most secure, manageable,
and scalable control network and corporate network segregation architectures are typically based on a
system with at least three zones, incorporating one or more DMZs.

5.6 Recommended Defense-in-Depth Architecture
A single security product, technology or solution cannot adequately protect an ICS by itself. A multiple
layer strategy involving two (or more) different overlapping security mechanisms, a technique also known
as defense-in-depth, is desired so that the impact of a failure in any one mechanism is minimized. A
defense-in-depth architecture strategy includes the use of firewalls, the creation of demilitarized zones,
intrusion detection capabilities along with effective security policies, training programs, incident response
mechanisms and physical security. In addition, an effective defense-in-depth strategy requires a thorough
understanding of possible attack vectors on an ICS. These include:








Backdoors and holes in network perimeter.
Vulnerabilities in common protocols.
Attacks on field devices.
Database attacks.
Communications hijacking and ‘man-in-the-middle’ attacks.
Spoofing attacks.
Attacks on privileged and/or shared accounts.

Figure 5-5 shows an ICS defense-in-depth architecture strategy that has been developed by the DHS
Control Systems Security Program (CSSP) NCCIC/ICS-CERT Recommended Practices committee 25 as
described in the Control Systems Cyber Security: Defense in Depth Strategies [36] document. Additional
supporting documents that cover specific issues and associated mitigations are also included on the site.

The Control Systems Cyber Security: Defense in Depth Strategies document provides guidance and
direction for developing defense-in-depth architecture strategies for organizations that use control system
networks while maintaining a multi-tiered information architecture that requires:




Maintenance of various field devices, telemetry collection, and/or industrial-level process systems.
Access to facilities via remote data link or modem.
Public facing services for customer or corporate operations.

25

Information on the CSSP Recommended Practices is located at http://ics-cert.us-cert.gov/RecommendedPractices

103

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

異なる二぀のメヌカヌのファむアりォヌルを䜵甚するず、この゜リュヌションには利点がある。
たた制埡グルヌプ及び IT グルヌプのデバむス担圓区分を明確にできる。理由は、組織の決定が
䞋されれば、それぞれが自分のファむアりォヌルを管理できるからである。二重ファむアりォヌ
ルアヌキテクチャの䞻な欠点は、コスト高になり管理が耇雑になるこずである。厳栌なセキュリ
ティ芁件のある環境や明確な管理の分離が求められる状況では、このアヌキテクチャは倧きな利
点がある。

5.5.6 ネットワヌク分離のたずめ
たずめずしお、総じお二重ホヌムコンピュヌタは、制埡ネットワヌクず䌁業ネットワヌク間の分
離をしっかり行えるものではない。2 ゟヌン゜リュヌションDMZ なしは、保護に匱点がある
ため掚奚できない。䜿甚する堎合は、现心の泚意を払っお展開すべきである。制埡ネットワヌク
ず䌁業ネットワヌクを分離するための最もセキュアで、管理しやすいスケヌラブルな分離アヌキ
テクチャは、通垞 1 ぀又は耇数の DMZ を持った最䜎 3 ぀のゟヌンを有するシステムを基調ずす
る。

5.6

掚奚倚局防埡アヌキテクチャ

単䞀のセキュリティ補品、技術又は゜リュヌションのみで ICS をしっかり保護するこずは䞍可胜
である。倚局防埡技術ずしおも知られおいる 2 ぀以䞊の異皮重畳セキュリティメカニズムを甚い
るマルチレむダヌ戊略は、1 ぀のメカニズムに障害が出おも、その圱響を最小に食い止められる
ため望たしい。倚局防埡アヌキテクチャ戊略には、ファむアりォヌルの䜿甚、非歊装地垯、䟵入
怜知機胜、効果的なセキュリティポリシヌ、蚓緎蚈画、むンシデント察応メカニズム及び物理的
セキュリティの構築が含たれる。加えお、効果的な倚局防埡戊略を講じるには、ICS に察しお攻
撃可胜なベクタヌを十分に理解するこずが求められる。これには以䞋が含たれる。









ネットワヌク呚蟺のバックドア及びホヌル
共通プロトコルの脆匱性
フィヌルドデバむスに察する攻撃
デヌタベヌスに察する攻撃
通信ハむゞャック及び「人が介圚する」攻撃
なりすたし攻撃
暩限アカりント又は共通アカりントに察する攻撃

図 5-5 は、『制埡システムのサむバヌセキュリティ倚局防埡戊略』[36]に蚘述されおいる DHS
制埡システムセキュリティプログラムCSSP) /ICS-CERT 掚奚芏範委員䌚 26により開発された、
ICS の倚局防埡アヌキテクチャ戊略を瀺す。具䜓的な問題点や関連緩和策に関する付加的な根拠
文曞もサむトにある。
『制埡システムのサむバヌセキュリティ倚局防埡戊略』には、制埡システムネットワヌクを䜿
甚し、以䞋を必芁ずする倚段階情報アヌキテクチャを維持しおいる組織向けに、倚局防埡アヌキ
テクチャ戊略を策定するための指針ず指瀺が蚘茉されおいる。

 皮々のフィヌルドデバむス、テレメトリ収集又は産業レベルプロセスシステムの保守
 遠隔デヌタリンクやモデム経由による斜蚭ぞのアクセス
 顧客・䌁業業務甚公共サヌビス

26

CSSP 掚奚芏範に関する情報は次の URL から入手できる。http://ics-cert.us-cert.gov/Recommended-Practices

104

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

This strategy includes firewalls, the use of demilitarized zones and intrusion detection capabilities
throughout the ICS architecture. The use of several demilitarized zones in Figure 5-5 provides the added
capability to separate functionalities and access privileges and has proved to be very effective in protecting
large architectures comprised of networks with different operational mandates. Intrusion detection
deployments apply different rule-sets and signatures unique to each domain being monitored.

Figure 5-5. CSSP Recommended Defense-In-Depth Architecture

5.7 General Firewall Policies for ICS
Once the defense-in-depth architecture is in place, the work of determining exactly what traffic should be
allowed through the firewalls begins. Configuring the firewalls to deny all except for the traffic absolutely
required for business needs is every organization’s basic premise, but the reality is much more difficult.
Exactly what does “absolutely required for business” mean and what are the security impacts of allowing
that traffic through? For example, many organizations considered allowing SQL traffic through the firewall
as required for business for many data historian servers. Unfortunately, the SQL vulnerability was also the
target for the Slammer worm [Table C-8. Example Adversarial Incidents]. Many important protocols used
in the industrial world, such as HTTP, FTP, OPC/DCOM, EtherNet/IP, and Modbus/TCP, have significant
security vulnerabilities.
The remaining material in this section summarizes some of the key points from the Centre for the
Protection of National Infrastructure’s (CPNI) Firewall Deployment for SCADA and Process Control
Networks: Good Practice Guide [35].
When installing a single two-port firewall without a DMZ for shared servers (i.e., the architecture described
in Section 5.5.2), particular care needs to be taken with the rule design. At a minimum, all rules

105

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

この戊略には、ICS アヌキテクチャ党䜓を通しお、ファむアりォヌル、非歊装地垯及び䟵入怜知
機胜の䜿甚が含たれる。図 5-5 の耇数非歊装地垯の䜿甚は、機胜ずアクセス暩限を分けるための
付加的な察策で、皮々の業務を担う耇数ネットワヌクからなる倧芏暡アヌキテクチャの保護に非
垞に効果のあるこずが分かっおいる。䟵入怜知の展開は、別々のルヌルセットず監芖する領域ご
ずに䞀意の眲名を適甚する。
ワむアレスアクセスポむント
コントロヌラ

CS PBX
CS モデムプヌル

電話通信ファむア
りォヌル

HMI
アプリケヌショ
デヌタベヌスサ
コンピュヌタ
ンサヌバ
ヌバ
ヒストリアン
蚭定サヌバ

゚ンゞニアリング
ワヌクステヌション

/RTU/PLC/IED

フィヌルド共通バス
フィヌルドの堎所

制埡システム
フィヌルドデ
バむス
通信むンタ
フェヌス
むンフラ

デヌタ
取埗サヌバ
制埡システム LAN

専甚共通経路
バックアップ制埡
センタヌ

CS ファむア
りォヌル
倖郚 VPN アクセス

遠隔事業ピア

電話通信ファむア
りォヌル
䌁業 PBX

倖郚事業通信
WWW サヌバ
サヌバ
DB/ヒストリアン
セキュリティ
サヌバ
事業共通 DMZ
Web サヌバ DMZ
DB DMZ
セキュリティ DMZ
認蚌 DMZ
事業サヌバ

事業ワヌク
ステヌション

Web アプリケヌ
ションサヌバ

䌁業 LAN
むンタヌネット

䌁業モデム
プヌル
倖郚通信むンフラ

䌁業
ファむアりォヌル

e メヌル
サヌバ

DNS
サヌバ

認蚌サヌバ

FTP サヌバ

Web
サヌバ

ワむアレス
アクセス
ポむント

認蚌サヌバ

DNS DMZ
e メヌル DMZ
Web サヌバ DMZ
FTP DMZ
認蚌 DMZ
ワむダレス DMZ
IDS センサ

図 5-5.CSSP の掚奚倚局防埡アヌキテクチャ

5.7

ICS の党般的ファむアりォヌルポリシヌ

倚局防埡アヌキテクチャを斜行したなら、次にファむアりォヌルで蚱可するトラフィックを明確
に決める䜜業が始たる。事業に絶察必芁なトラフィック以倖は党お拒絶するようにファむアりォ
ヌルを蚭定するこずは、どの䌁業でも基本であるが、珟実ははるかに難しい。
「事業に絶察必芁」ずは䜕を意味するのか、そのトラフィックを通過させるずどんなセキュリテ
ィ䞊の圱響が出るのか。䟋えば、倚くの組織では、事業䞊倚数のデヌタヒストリアンサヌバに必
芁なこずから、SQL トラフィックのファむアりォヌル通過を怜蚎した。残念ながら、SQL の脆匱
性もスラマヌワヌムの暙的だった[è¡š C-8.攻撃むンシデントの䟋]。HTTP、FTP、OPC/DCOM、
EtherNet/IP、Modbus/TCP 等、産業界で䜿甚されおいる重芁プロトコルの倚くには、倧きなセキ
ュリティ䞊の脆匱性がある。
このセクションの残りの郚分では、囜家むンフラ保護センタヌCPNIの『SCADA 及びプロセ
ス制埡ネットワヌク甚ファむアりォヌル展開適正芏範ガむド』[35]から重芁ポむントをいく぀
か芁玄する。
共有サヌバセクション 5.5.2 のアヌキテクチャ等甚に DMZ なしの単䞀 2 ポヌトファむアりォ
ヌルを蚭眮する堎合、ルヌルの怜蚎には特に泚意を芁する。少なくずもどのルヌルも

106

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

should be stateful rules that are both IP address and port (application) specific. The address portion of the
rules should restrict incoming traffic to a very small set of shared devices (e.g., the data historian) on the
control network from a controlled set of addresses on the corporate network. Allowing any IP addresses on
the corporate network to access servers inside the control network is not recommended. In addition, the
allowed ports should be carefully restricted to relatively secure protocols such as Hypertext Transfer
Protocol Secure (HTTPS). Allowing HTTP, FTP, or other unsecured protocols to cross the firewall is a
security risk due to the potential for traffic sniffing and modification. Rules should be added to deny hosts
outside the control network from initiating connections with hosts on the control network. Rules should
only allow devices internal to the control network the ability to establish connections outside the control
network.
On the other hand, if the DMZ architecture is being used, then it is possible to configure the system so that
no traffic will go directly between the corporate network and the control network. With a few special
exceptions (noted below), all traffic from either side can terminate at the servers in the DMZ. This allows
more flexibility in the protocols allowed through the firewall. For example, Modbus/TCP might be used to
communicate from the PLCs to the data historian, while HTTP might be used for communication between
the historian and enterprise clients. Both protocols are inherently insecure, yet in this case they can be used
safely because neither actually crosses between the two networks. An extension to this concept is the idea
of using “disjoint” protocols in all control network to corporate network communications. That is, if a
protocol is allowed between the control network and DMZ, then it is explicitly not allowed between the
DMZ and corporate network. This design greatly reduces the chance of a worm such as Slammer actually
making its way into the control network, because the worm would have to use two different exploits over
two different protocols.
One area of considerable variation in practice is the control of outbound traffic from the control network,
which could represent a significant risk if unmanaged. One example is Trojan horse software that uses
HTTP tunneling to exploit poorly defined outbound rules. Thus, it is important that outbound rules be as
stringent as inbound rules.
Example outbound rules include:


Outbound traffic through the control network firewall should be limited to essential communications
only and should be limited to authorized traffic originating from DMZ servers.



All outbound traffic from the control network to the corporate network should be source and
destination-restricted by service and port.

In addition to these rules, the firewall should be configured with outbound filtering to stop forged IP
packets from leaving the control network or the DMZ. In practice this is achieved by checking the source
IP addresses of outgoing packets against the firewall’s respective network interface address. The intent is to
prevent the control network from being the source of spoofed (i.e., forged) communications, which are
often used in DoS attacks. Thus, the firewalls should be configured to forward IP packets only if those
packets have a correct source IP address for the control network or DMZ networks. Finally, Internet access
by devices on the control network should be strongly discouraged.

107

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

IP アドレスずポヌトアプリケヌションに固有のステヌトフルルヌルにすべきである。ルヌ
ルのアドレス郚䜍は、䌁業ネットワヌクの管理されたアドレスセットから来たトラフィックを、
制埡ネットワヌク䞊のごく小セットの共有デバむスデヌタヒストリアン等に限定する。䌁
業ネットワヌク䞊の IP アドレスが制埡ネットワヌク内のサヌバにアクセスできるようにするの
は薊められない。たた、蚱可したポヌトは甚心のため、HTTPS 等の比范的セキュアなプロトコ
ルに限定すべきである。HTTP、FTP その他セキュアでないプロトコルがファむアりォヌルを越
えるのは、トラフィックのスニッフィングや倉曎のおそれがあるため、セキュリティリスクず
なる。制埡ネットワヌク倖のホストが制埡ネットワヌク䞊のホストに接続できないようにルヌ
ルを远加すべきである。制埡ネットワヌク内のデバむスだけが制埡ネットワヌクの倖に接続で
きるルヌルにすべきである。
反察に、DMZ アヌキテクチャを䜿甚しおいる堎合は、トラフィックが䌁業ネットワヌクず制埡
ネットワヌク間で盎接埀来しないようにシステム蚭定するこずができる。特別な堎合を陀いお
䞋蚘参照、いずれの偎からのトラフィックも DMZ 内のサヌバで終了するこずはできない。
これによりファむアりォヌルを通過可胜なプロトコルの柔軟性が向䞊する。䟋えば、PLCs か
らデヌタヒストリアンぞの通信に Modbus/TCP を䜿甚し、HTTP はヒストリアンず䌁業クラむア
ント間の通信に䜿甚できる。どちらのプロトコルも本来セキュアではないが、この堎合は 2 ぀
のネットワヌクを越えるこずがないため、安党に䜿甚できる。この抂念を敷衍したものが「別
皮」プロトコルを党おの制埡ネットワヌクず䌁業ネットワヌク通信に䜿甚するずいう考え方で
ある。぀たり、あるプロトコルを制埡ネットワヌクず DMZ 間で蚱可するが、DMZ ず䌁業ネット
ワヌク間では明瀺的に蚱可しないずいうものである。この蚭蚈はスラマヌのようなワヌムが制
埡ネットワヌクに䟵入する機䌚を著しく枛じるが、それはこのワヌムが 2 皮類のプロトコルを
利甚しなければならないからである。
かなりのバリ゚ヌションがあるのが制埡ネットワヌクからの送信トラフィックの制埡で、管理
が行き届かないず倧きなリスクずなる。その䞀䟋がトロむの朚銬で、HTTP トンネリングを䜿い、
定矩に䞍備がある送信ルヌルを欺く。したがっお、送信ルヌルは着信ルヌル同様に厳栌でなけ
ればならない。
以䞋は送信ルヌルの䟋である。
制埡ネットワヌクファむアりォヌルを越える送信トラフィックは、䞍可欠な送信のみに限定し、
たた DMZ サヌバからの蚱可されたトラフィックのみに限定すべきである。


制埡ネットワヌクから䌁業ネックワヌクぞの党おの送信トラフィックは、サヌビスずポヌト
により゜ヌス及び宛先制限を蚭けるべきである。

これらのルヌルに加えお、ファむアりォヌルの蚭定は送信フィルタをかけお、停の IP パケット
が制埡ネットワヌクや DMZ から倖に出ないようにすべきである。実際には、送信パケットの゜
ヌス IP アドレスを、ファむアりォヌルの各ネットワヌクむンタフェヌスアドレスに照らしおチ
ェックするこずでこれを行っおいる。目的は、制埡ネットワヌクが欺瞞擬䌌通信の゜ヌスに
ならないようにするこずである。これは DoS 攻撃で倚甚される。このようにファむアりォヌル
は、制埡ネットワヌクや DMZ ネットワヌクの IP アドレスが正しい堎合にのみ、IP パケットを転
送するように蚭定すべきである。最埌に、制埡ネットワヌク䞊のデバむスによるむンタヌネット
アクセスは、是非ずもやめるべきである。

108

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

In summary, the following should be considered as recommended practice for general firewall rule sets:


The base rule set should be deny all, permit none.



Ports and services between the control network environment and the corporate network should be
enabled and permissions granted on a specific case-by-case basis. There should be a documented
business justification with risk analysis and a responsible person for each permitted incoming or
outgoing data flow.



All “permit” rules should be both IP address and TCP/UDP port specific, and stateful if appropriate.



All rules should restrict traffic to a specific IP address or range of addresses.



Traffic should be prevented from transiting directly from the control network to the corporate network.
All traffic should terminate in the DMZ.



Any protocol allowed between the control network and DMZ should explicitly NOT be allowed
between the DMZ and corporate networks (and vice-versa).



All outbound traffic from the control network to the corporate network should be source and
destination-restricted by service and port.



Outbound packets from the control network or DMZ should be allowed only if those packets have a
correct source IP address that is assigned to the control network or DMZ devices.



Control network devices should not be allowed to access the Internet.



Control networks should not be directly connected to the Internet, even if protected via a firewall.



All firewall management traffic should be carried on either a separate, secured management network
(e.g., out of band) or over an encrypted network with multi-factor authentication. Traffic should also
be restricted by IP address to specific management stations.



All firewall policies should be tested periodically.



All firewalls should be backed up immediately prior to commissioning.

These should be considered only as guidelines. A careful assessment of each control environment is
required before implementing any firewall rule sets.

5.8 Recommended Firewall Rules for Specific Services
Beside the general rules described above, it is difficult to outline all-purpose rules for specific protocols.
The needs and recommended practices vary significantly between industries for any given protocol and
should be analyzed on an organization-by-organization basis. The Industrial Automation Open Networking
Association (IAONA) offers a template for conducting such an analysis [37], assessing each of the
protocols commonly found in industrial environments in terms of function, security risk, worst case impact,
and suggested measures. Some of the key points from the IAONA document are summarized in this section.
The reader is advised to consult this document directly when developing rule sets.

109

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

たずめずしお、党般的なファむアりォヌルのルヌルセット甚掚奚芏範ずしお、次の点を考慮すべ
きである。

 ルヌルセットの基本は党お拒絶、䜕も蚱可しないである。
 制埡ネットワヌク環境ず䌁業ネットワヌク間のポヌト及びサヌビスを䜿甚可胜にし、蚱可は
ケヌスバむケヌスで䞎えるべきである。これらを事業理由曞ずしお文曞化し、リスク分析及
び蚱可した着信・送信デヌタフロヌの責任者ずずもに蚘録する。
 党お「蚱可」ルヌルは、IP アドレス及び TCP/UDP ポヌト固有にし、必芁ならステヌトフル
ずする。
 党おのルヌルは、トラフィックを特定の IP アドレス又はアドレス範囲に限定すべきである。
 トラフィックは、制埡ネットワヌクから䌁業ネットワヌクぞ盎接送信されないようにすべき
である。党おのトラフィックは DMZ で終了すべきである。
 制埡ネットワヌクず DMZ 間で蚱可されたプロトコルは、DMZ ず䌁業ネットワヌク間その
逆方向もでは明瀺的に蚱可しないようにすべきである。
 制埡ネットワヌクから䌁業ネックワヌクぞの党おの送信トラフィックは、サヌビスずポヌト
により゜ヌス及び宛先制限を蚭けるべきである。
 制埡ネットワヌク又は DMZ からの送信パケットは、制埡ネットワヌク又は DMZ デバむス
に割り圓おられた゜ヌス IP アドレスが正しい堎合にのみ蚱可すべきである。
 制埡ネットワヌクデバむスのむンタヌネットアクセスは蚱可すべきでない。
 制埡ネットワヌクは、ファむアりォヌルで保護されおいおも、盎接むンタヌネットに接続す
べきでない。
 党おのファむアりォヌル管理トラフィックは、別個の、セキュア管理ネットワヌクバンド
倖等又は倚芁玠認蚌を備えた暗号化ネットワヌクぞ続くべきである。たたトラフィックは、
IP アドレスにより特定の管理ステヌションに限定すべきである。
 党おのファむアりォヌルポリシヌは、定期的に怜蚌すべきである。
 党おのファむアりォヌルは、詊運転を行う盎前にバックアップすべきである。
以䞊はあくたでも指針ずしお怜蚎すべきものである。ファむアりォヌルルヌルセットを実斜
する前に、各制埡環境を慎重に評䟡する必芁がある。

5.8

特定サヌビスの掚奚ファむアりォヌルルヌル

䞊蚘の党般ルヌルに加えお、特定のプロトコル甚に汎甚的なルヌルを決めるのは難しい。特定の
プロトコルに関するニヌズず掚奚芏範は、業界によっおたちたちで、組織ごずに分析すべきであ
る。産業オヌトメヌションオヌプンネットワヌキング協䌚IAONAは、このような分析を行
うためのひな圢を提䟛しおおり[37]、産業環境で䜿甚する䞀般的なプロトコルを機胜、セキュリ
ティリスク、最悪事態の圱響及び察策の芳点から個別に評䟡しおいる。IAONA 文曞の重芁点の
いく぀かを芁玄したものをこのセクションで取り䞊げる。読者は、ルヌルセットを策定する際に
盎接この文曞を調べるよう掚奚する。

110

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.8.1 Domain Name System (DNS)
Domain Name System (DNS) is primarily used to translate between domain names and IP addresses. For
example, a DNS could map a domain name such as control.com to an IP address such as 192.168.1.1. Most
Internet services rely heavily on DNS, but its use on the control network is relatively rare at this time. In
most cases there is little reason to allow DNS requests out of the control network to the corporate network
and no reason to allow DNS requests into the control network. DNS requests from the control network to
DMZ should be addressed on a case-by-case basis. Local DNS or the use of host files is recommended.

5.8.2 Hypertext Transfer Protocol (HTTP)
HTTP is the protocol underlying Web browsing services on the Internet. Like DNS, it is critical to most
Internet services. It is seeing increasing use on the plant floor as well as an all-purpose query tool.
Unfortunately, it has little inherent security, and many HTTP applications have vulnerabilities that can be
exploited. HTTP can be a transport mechanism for many manually performed attacks and automated
worms.
In general, HTTP should not be allowed to cross from the public/corporate to the control network.
If web-based technologies are absolutely required, the following best practices should be applied:








Control access to web-based services on the physical or network layer using white-listing;
Apply access control to both source and destination;
Implement authorization to access the service on the application layer (instead of physical or networklayer checks);
Implement service using only the necessary technologies (e.g., scripts are used only if they are
required);
Check service according to known application security practices;
Log all attempts of service usage ; and
Use HTTPS rather than HTTP, and only for specific authorized devices.

5.8.3 FTP and Trivial File Transfer Protocol (TFTP)
FTP and Trivial File Transfer Protocol (TFTP) are used for transferring files between devices. They are
implemented on almost every platform including many SCADA systems, DCS, PLCs, and RTUs, because
they are very well known and use minimum processing power. Unfortunately, neither protocol was created
with security in mind; for FTP, the login password is not encrypted, and for TFTP, no login is required at
all. Furthermore, some FTP implementations have a history of buffer overflow vulnerabilities. As a result,
all TFTP communications should be blocked, while FTP communications should be allowed for outbound
sessions only or if secured with additional token-based multi-factor authentication and an encrypted tunnel.
More secure protocols, such as Secure FTP (SFTP) or Secure Copy (SCP), should be employed whenever
possible.

5.8.4 Telnet
The telnet protocol defines an interactive, text-based communications session between a client and a host. It
is used mainly for remote login and simple control services to systems with limited resources or to systems
with limited needs for security. It is a severe security risk because all telnet traffic, including passwords, is
unencrypted, and it can allow a remote individual considerable control over a device. It is recommended to
use the Secure Shell (SSH) protocol [5.8.6] for remote administration. Inbound telnet

111

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.8.1 領域名システムDNS
領域名システムDNSは、䞻ずしお領域名ず IP アドレス間の翻蚳に䜿甚する。䟋えば、DNS
は control.com ずいう領域名を 192.168.1.1 ずいう IP アドレスずしおマップする。
倧抵のむンタヌネットサヌビスは DNS に倧きく䟝存しおいるが、制埡ネットワヌクでの䜿甚は
今のずころ比范的少ない。ほずんどの堎合、制埡ネットワヌクから䌁業ネットワヌクぞの DNS
芁求を蚱可する理由はなく、制埡ネットワヌクぞの DNS 芁求を蚱可する理由もない。制埡ネッ
トワヌクから DMZ ぞの DNS 芁求は、ケヌスバむケヌスで扱うべきである。ロヌカル DNS やホ
ストファむルの䜿甚が掚奚される。

5.8.2 ハむパヌテキスト転送プロトコルHTTP
HTTP はむンタヌネット䞊の Web 閲芧サヌビスプロトコルである。DNS ず同様、ほずんどのむン
タヌネットサヌビスにずっお重芁である。プラントの珟堎や汎甚ク゚リツヌルでの䜿甚が増え
おいる。
残念ながらセキュリティがしっかりしおおらず、HTTP アプリケヌションの倚くには悪甚される
脆匱性がある。HTTP は、手動攻撃や自動ワヌムの倚くで送信メカニズムになる。
総じお HTTP は、公開/䌁業ネットワヌクから制埡ネットワヌクぞ入れるべきでない。り
ェブベヌス技術がどうしおも必芁ずなる堎合、次のような最良芏範を適甚すべきである。
 ホワむトリストを䜿甚する物理的又はネットワヌクレむダヌ䞊のりェブベヌスサヌビスぞの
制埡アクセス
 ゜ヌス及び宛先の双方にアクセス制埡を適甚
 アプリケヌション局のサヌビスぞのアクセスを蚱可物理的又はネットワヌクレむダヌチェ
ックでなく
 必須技術のみを䜿甚しおサヌビスを実装スクリプトは必芁な堎合のみ䜿甚
 既知のアプリケヌションセキュリティ芏範に埓っおサヌビスをチェック
 サヌビスを利甚しようずする詊みを党お蚘録
 HTTP の代わりに HTTPS を䜿甚し、蚱可された特定デバむスのみずする

5.8.3 FTP 及びトリビアルファむル転送プロトコルTFTP
FTP ず TFTP はデバむス間でのファむルのやり取りに䜿われる。知名床が高く、凊理パワヌが最
小で枈むため、SCADA システム、DCS、PLCs、RTUs 等ほずんど党おのプラットホヌムに実装
されおいる。残念ながら、どれもセキュリティを考えお䜜られおはいない。FTP のログむンパス
ワヌドは暗号化されおおらず、TFTP ではログむンの必芁さえない。曎に実装された FTP によっ
おは、バッファがオヌバヌフロヌするずいう脆匱性もあった。その結果、TFTP 通信は党おブロ
ックすべきで、FTP 通信に぀いおは送信セッションのみ、又は付加的なトヌクンベヌスの倚芁玠
認蚌及び暗号化トンネルでセキュリティを確保したもののみ蚱可すべきである。可胜であれば垞
に、セキュア FTPSFTPやセキュアコピヌずいったよりセキュリティの高いプロトコルを採
甚すべきである。

5.8.4 テルネットTelnet
テルネットプロトコルは、クラむアントずホスト間のむンタラクティブなテキストベヌスの通信
セッションを定矩する。䞻にリ゜ヌスの限られたシステムやセキュリティ需芁の䜎いシステムぞ
の遠隔ログむン及び単玔な管理サヌビス甚に䜿甚される。党おのテルネットトラフィックはパス
ワヌドも含めお暗号化されおいないため、セキュリティリスクは重倧で、遠隔地にいる個人がデ
バむスをかなりの皋床制埡できおしたう。

112

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

sessions from the corporate to the control network should be prohibited unless secured with token-based
multi-factor authentication and an encrypted tunnel. Outbound telnet sessions should be allowed only over
encrypted tunnels (e.g., VPN) to specific authorized devices.

5.8.5 Dynamic Host Configuration Protocol (DHCP)
DHCP is used on IP networks for dynamically distributing network configuration parameters, such as IP
addresses for interfaces and services. The base DHCP includes no mechanism for authenticating servers
and clients. Rogue DHCP servers can provide incorrect information to clients. Unauthorized clients can
gain access to server and cause exhaustion of available resources (e.g., IP addresses). To prevent this, it is
recommended to use static configuration instead of dynamic address allocation, which should be the typical
configuration for ICS devices. If dynamic allocation is necessary, it is recommended to enable DHCP
snooping to defend against rogue DHCP servers, Address Resolution Protocol (ARP) and IP spoofing. The
DHCP servers should be placed in the same network segment as configured equipment (e.g., on the router).
DHCP relaying is not recommended.

5.8.6 Secure Shell (SSH)
SSH allows remote access to a device. It provides secure authentication and authorization based on
cryptography. If remote access is required to the control network, SSH is recommended as the alternative to
telnet, rlogin, rsh, rcp and other insecure remote access tools.

5.8.7 Simple Object Access Protocol (SOAP)
SOAP is an XML-based format syntax to exchange messages. Traffic flows related to SOAP-based
services should be controlled at the firewall between corporate and ICS network segments. If these services
are necessary, deep-packet inspection and/or application layer firewalls should be used to restrict the
contents of messages.

5.8.8 Simple Mail Transfer Protocol (SMTP)
SMTP is the primary email transfer protocol on the Internet. Email messages often contain malware, so
inbound email should not be allowed to any control network device. Outbound SMTP mail messages from
the control network to the corporate network are acceptable to send alert messages.

5.8.9 Simple Network Management Protocol (SNMP)
SNMP is used to provide network management services between a central management console and
network devices such as routers, printers, and PLCs. Although SNMP is an extremely useful service for
maintaining a network, it is very weak in security. Versions 1 and 2 of SNMP use unencrypted passwords
to both read and configure devices (including devices such as PLCs), and in many cases the passwords are
well known and cannot be changed. Version 3 is considerably more secure but is still limited in use. SNMP
V1 & V2 commands both to and from the control network should be prohibited unless they are over a
separate, secured management network, whereas SNMP V3 commands may be able to be sent to the ICS
using the security features inherent to V3.

113

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

遠隔管理にはセキュアシェルSSHプロトコル[5.8.6]を䜿甚するよう掚奚する。䌁業ネットワ
ヌクから制埡ネットワヌクぞの着信テルネットセッションは、トヌクンベヌスの倚芁玠認蚌及び
暗号化トンネルでセキュリティが確保されおいなければ、犁止すべきである。送信テルネットは、
蚱可された特定のデバむスに察しお、暗号化トンネルVPN 等でのみ蚱可すべきである。

5.8.5 動的ホスト構成プロトコルDHCP
DHCP は、䟋えば IP アドレスをむンタフェヌスやサヌビスぞ割り圓おるなど、IP ネットワヌク
䞊でネットワヌク構成パラメヌタを動的に割り圓おるずきに䜿甚する。基本的な DHCP にはサヌ
バずクラむアントの認蚌メカニズムがない。ロヌグ DHCP サヌバは䞍正確な情報をクラむアント
に提䟛する。未蚱可のクラむアントがサヌバにアクセスしお、利甚可胜なリ゜ヌスIP アドレス
等を枯枇させるこずがある。これを防ぐには、動的なアドレス割圓ではなく静的構成にするこ
ずが掚奚され、ICS デバむスではこれが䞀般的な構成ずなるべきである。動的割圓が必芁な堎合、
DHCP スヌヌピングを䜿甚可胜にし、ロヌグ DHCP、アドレス解決プロトコルARP及び IP 詐
称を防止するこずが掚奚される。DHCP サヌバは、構成装備品ず同じネットワヌクセグメント
ルヌタ䞊等内に配眮すべきである。DHCP リレヌは掚奚できない。

5.8.6 セキュアシェルSSH)
SSH はデバむスぞのリモヌトアクセスを可胜にする。セキュアな認蚌を行い、暗号法に基づいお
蚱可を䞎える。制埡ネットワヌクぞのリモヌトアクセスが必芁な堎合、テルネット、r ログむン、
rsh、rcp その他のセキュアでないリモヌトアクセスツヌルに代えお SSH の䜿甚が掚奚される。

5.8.7 シンプルオブゞェクトアクセスプロトコルSOAP
SOAP は、メッセヌゞ亀換甚の XML ベヌス圢匏のシンタックスである。SOAP ベヌスサヌビスに
関連したトラフィックフロヌは、䌁業及び ICS ネットワヌクセグメント間のファむアりォヌルで
制埡すべきである。このようなサヌビスが必芁な堎合、ディヌプパケットむンスペクション又は
アプリケヌション局ファむアりォヌルを䜿甚しお、メッセヌゞ内容を制限すべきである。

5.8.8 シンプルメヌル転送プロトコルSMTP
SMTP はむンタヌネットでの䞻芁な電子メヌル転送プロトコルである。電子メヌルメッセヌゞに
はマルり゚アが含たれおいるこずが倚いため、着信電子メヌルは、いかなる制埡ネットワヌクデ
バむスにも達するべきでない。制埡ネットワヌクから䌁業ネットワヌクぞの送信 SMTP メヌルメ
ッセヌゞは、アラヌトメッセヌゞの送信時に蚱可される。

5.8.9 シンプルネットワヌク管理プロトコルSNMP
SNMP は、䞭倮管理コン゜ヌルずネットワヌクデバむスルヌタ、プリンタ、PLCs 等間のネッ
トワヌク管理サヌビスを提䟛するために䜿甚する。SNMP はネットワヌクの保守には極めお䟿利
なサヌビスであるが、セキュリティが極めお匱い。SNMP のバヌゞョン 1 ず 2 では、読取りもデ
バむスPLCs 等蚭定も暗号化されおいないパスワヌドを䜿甚しおおり、倚くの堎合パスワヌ
ドがよく知られおおり、倉曎ができない。バヌゞョン 3 ではかなりセキュアになっおいるが、
䜿甚されおいる数は少ない。
制埡ネットワヌクずの SNMP バヌゞョン 1 ず 2 のコマンドは、別個のセキュアな管理ネットワヌ
ク以倖では犁止ずすべきで、バヌゞョン 3 のコマンドは固有のセキュリティ機胜を䜿甚しお ICS
に送信できる。

114

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.8.10 Distributed Component Object Model (DCOM)
DCOM is the underlying protocol for OLE for Process Control (OPC). It utilizes Microsoft’s Remote
Procedure Call (RPC) service which, when not patched, has many vulnerabilities. These vulnerabilities
were the basis for the Blaster worm 27 exploits. In addition, OPC, which utilizes DCOM, dynamically opens
a wide range of ports (1024 to 65535) that can be extremely difficult to filter at the firewall. This protocol
should only be allowed between control network and DMZ networks and explicitly blocked between the
DMZ and corporate network. Also, users are advised to restrict the port ranges used by making registry
modifications on devices using DCOM.

5.8.11 SCADA and Industrial Protocols
SCADA and industrial protocols, such as Modbus/TCP, EtherNet/IP, IEC 61850, ICCP and DNP3 28, are
critical for communications to most control devices. Unfortunately, many of these protocols were designed
without security built in and do not typically require any authentication to remotely execute commands on a
control device. These protocols should only be allowed within the control network and not allowed to cross
into the corporate network.

5.9 Network Address Translation (NAT)
Network address translation (NAT) is a service where IP addresses used on one side of a network device
can be mapped to a different set on the other side on an as-needed basis. It was originally designed for IP
address reduction purposes so that an organization with a large number of devices that occasionally needed
Internet access could get by with a smaller set of assigned Internet addresses.
To do this, most NAT implementations rely on the premise that not every internal device is actively
communicating with external hosts at a given moment. The firewall is configured to have a limited number
of outwardly visible IP addresses. When an internal host seeks to communicate with an external host, the
firewall remaps the internal IP address and port to one of the currently unused, more limited, public IP
addresses, effectively concentrating outgoing traffic into fewer IP addresses. The firewall must track the
state of each connection and how each private internal IP address and source port was remapped onto an
outwardly visible IP address/port pair. When returning traffic reaches the firewall, the mapping is reversed
and the packets forwarded to the proper internal host.
For example, a control network device may need to establish a connection with an external, non-control
network host (for instance, to send a critical alert email). NAT allows the internal IP address of the
initiating control network host to be replaced by the firewall; subsequent return traffic packets are
remapped back to the internal IP address and sent to the appropriate control network device. More
specifically, if the control network is assigned the private subnet 192.168.1.xxx and the Internet network
expects the device to use the corporate assigned addresses in the range 192.6.yyy.zzz, then a NAT firewall
will substitute (and track) a 192.6.yyy.zzz source address into every outbound IP packet generated by a
control network device.
Producer-consumer protocols, such as EtherNet/IP and Foundation Fieldbus, are particularly troublesome
because NAT does not support the multicast-based traffic that these protocols need to offer their full
services.

27

http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29

28

15 IEEE 1815-2012, IEEE Standard for Electric Power Systems Communications—Distributed Network Protocol
(DNP3),) incorporates DNP3 Secure Authentication version 5 (DNP3-SAv5) which provides strong application
layer authentication with remote security credential management. See
https://standards.ieee.org/findstds/standard/1815-2012.html.

115

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.8.10 分散コンポヌネントオブゞェクトモデルDCOM
DCOM はプロセス制埡甚 OLEOPCの基本プロトコルである。マむクロ゜フトの遠隔手続き
呌び出しRPCサヌビスを䜿甚するが、これはパッチを圓おないず脆匱性が倚い。このような
脆匱性は、ブラスタヌワヌム 29の暙的ずなった。たた DCOM を利甚する OPC は、倚様なポヌト
を動的に開くため102465535)、ファむアりォヌルでのフィルタリングが極めお困難ずなる。
このプロトコルは、制埡ネットワヌクず DMZ 間でのみ蚱可すべきで、DMZ ず䌁業ネットワヌク
間では明瀺的にブロックすべきである。たたナヌザは、DCOM 䜿甚デバむスのレゞストリ倉曎
時に䜿甚するポヌトの範囲を限定するのがよい。

5.8.11 SCADA 及び産業甚プロトコル
Modbus/TCP、EtherNet/IP、IEC 61850、ICCP、DNP3 30等の SCADA 及び産業甚プロトコルは、ほ
ずんどの制埡デバむスぞの通信にずっお肝芁である。残念ながらこれらのプロトコルの倚くは、
セキュリティを考慮に入れずに蚭蚈されおおり、制埡デバむス䞊でコマンドを遠隔実行する際に、
通垞認蚌を必芁ずしない。このようなプロトコルは制埡ネットワヌク内でのみ蚱可し、䌁業ネッ
トワヌクぞの進入は蚱可すべきでない。

5.9

ネットワヌクアドレス倉換NAT

ネットワヌクアドレス倉換NATサヌビスは、ネットワヌクデバむスの䞀方の偎で䜿甚しおい
る IP アドレスを、必芁の郜床、他方の偎にマップする。元々の蚭蚈目的は、時々むンタヌネッ
トアクセスが必芁ずなる倚量のデバむスを擁する組織が、少数の割圓むンタヌネットアドレスで
枈むように IP アドレスを枛らすこずにあった。
そのためほずんどの NAT 実装では、党おの瀟内デバむスが、ある瞬間に倖郚ホストず掻発に亀
信するわけではないずいう前提に立っおいる。ファむアりォヌルの蚭定は、倖郚から芋える IP
アドレスの数が限定されるように行う。瀟内ホストが瀟倖ホストず亀信する際、ファむアりォヌ
ルは、内郚 IP アドレスずポヌトを珟圚䜿甚しおいない曎に限定されたパブリック IP アドレスに
リマップし、送信トラフィックをより少数の IP アドレスに効果的に集結させる。ファむアりォ
ヌルは、それぞれの接続の状態ず、各プラむベヌト内郚 IP アドレス及び゜ヌスポヌトが、倖郚
から芋える IP アドレス/ポヌトのペアにどうリマップされたかを远跡しなければならない。戻り
トラフィックがファむアりォヌルに達するず、マッピングが反転し、パケットが正しい瀟内ホス
トに転送される。
䟋えば、制埡ネットワヌクデバむスは、倖郚の非制埡ネットワヌクホストず接続を確立する必芁
が生じるこずがある重芁アラヌト電子メヌルの送信など。NAT は、開始制埡ネットワヌク
ホストの内郚 IP アドレスがファむアりォヌルにより眮換されるようにし、その埌の戻りトラフ
ィックパケットは、内郚 IP アドレスにリマップされ、正しい制埡ネットワヌクデバむスに送ら
れる。具䜓的に蚀うず、制埡ネットワヌクにプラむベヌトサブネット 192.168.1.xxx が割り圓お
られ、むンタヌネットネットワヌクはデバむスが 192.6.yyy.zzz の範囲の䌁業割圓アドレスを䜿甚
するように予想しおいるずする。その堎合、NAT ファむアりォヌルは、192.6.yyy.zzz ゜ヌスアド
レスを、制埡ネットワヌクデバむスが生成する党おの発信 IP パケットに眮換しお远跡する。
EtherNet/IP や Foundation Fieldbus ずいった生産者・消費者プロトコルは、ずりわけ問題が倚い。
ずいうのは、これらのプロトコルが十分なサヌビスを提䟛するために必芁ずするマルチキャスト
ベヌスのトラフィックに NAT が察応しおいないからである。

29

http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29

30

IEEE 1815-2012『電力システム通信甚 IEEE 芏栌-分散ネットワヌクプロトコルDNP3』は、DNP3 セキュア認蚌バヌゞ
ョン 5DNP3-SAv5を組み蟌んでおり、遠隔セキュリティ信頌性管理に匷力なアプリケヌション局認蚌を付䞎する。次
の URL を参照のこず。https://standards.ieee.org/findstds/standard/1815-2012.html.

116

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

In general, while NAT offers some distinct advantages, its impact on the actual industrial protocols and
configuration should be assessed carefully before it is deployed. Furthermore, certain protocols are
specifically broken by NAT because of the lack of direct addressing. For example, OPC requires special
third-party tunneling software to work with NAT.

5.10 Specific ICS Firewall Issues
In addition to the issues with firewalls and ICS already discussed, there are some additional problems that
need to be examined in more detail. The rest of this section discusses three specific areas of concern: the
placement of data historians, remote access for ICS support, and multicast traffic.

5.10.1 Data Historians
The existence of shared control network/corporate network servers such as data historians and asset
management servers can have a significant impact on firewall design and configuration. In three-zone
systems the placement of these servers in a DMZ is relatively straightforward, but in two-zone designs the
issues become complex. Placing the historian on the corporate side of the firewall means that a number of
insecure protocols, such as Modbus/TCP or DCOM, must be allowed through the firewall and that every
control device reporting to the historian is exposed to the corporate side of the network. On the other hand,
putting the historian on the control network side means other equally questionable protocols, such as HTTP
or SQL, must be allowed through the firewall, and there is now a server accessible to nearly everyone in the
organization sitting on the control network.
In general, the best solution is to avoid two-zone systems (no DMZ) and use a three-zone design, placing
the data collector in the control network and the historian component in the DMZ.

5.10.2 Remote Support Access
Another issue for ICS firewall design is user and/or vendor remote access into the control network. Any
users accessing the control network from remote networks should be required to authenticate using an
appropriately strong mechanism such as token-based authentication. While it is possible for the controls
group to set up their own remote access system with multi-factor authentication on the DMZ, in most
organizations it is typically more efficient to use existing systems set up by the IT department. In this case a
connection through the firewall from the IT remote access server is needed.
Remote support personnel connecting over the Internet or via dialup modems should use an encrypted
protocol, such as running a corporate VPN connection client, application server, or secure HTTP access,
and authenticate using a strong mechanism, such as a token based multi-factor authentication scheme, in
order to connect to the general corporate network. Once connected, they should be required to authenticate
a second time at the control network firewall using a strong mechanism, such as a token based multi-factor
authentication scheme, to gain access to the control network. Proxy servers can also provide additional
capabilities for securing remote support access.

5.10.3 Multicast Traffic
Most industrial producer-consumer (or publisher-subscriber) protocols operating over Ethernet, such as
EtherNet/IP and Foundation Fieldbus HSE, are IP multicast-based. The first advantage of IP multicasting is
network efficiency; by not repeating the data transmission to the multiple destinations, a significant
reduction in network load can occur. The second advantage is that the sending host need not be concerned
with knowing every IP address of every destination host listening for the broadcast information. The third,
and perhaps most important for industrial control purposes, is that a single multicast message offers

117

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

党䜓ずしお、NAT にはいく぀か明確な利点があるが、展開するに先立っお、実際の産業甚プロ
トコル及び構成に䞎える圱響を慎重に評䟡すべきである。曎に特定のプロトコルは、盎接のアド
レッシングがないため、NAT により砎壊される。䟋えば OPC は、NAT ず共甚するためにはサヌ
ドパヌティの特殊トンネリング゜フトり゚アが必須ずなる。

5.10

ICS ファむアりォヌル固有の問題

これたで芋おきたファむアりォヌルず ICS に関わる問題に加えお、曎に詳しく考察すべき問題も
ある。このセクションの残りの郚分では、デヌタヒストリアンの配眮、ICS サポヌトのためのリ
モヌトアクセス、マルチキャストトラフィックずいう 3 ぀の特定分野に぀いお考察する。

5.10.1 デヌタヒストリアン
デヌタヒストリアンや資産管理サヌバずいった共有制埡/䌁業ネットワヌクサヌバの存圚は、フ
ァむアりォヌルの蚭蚈や構成に倧きな圱響を及がすこずがある。3 ゟヌンシステムでは、これら
サヌバを DMZ に配眮するのは比范的単玔明快だが、2 ゟヌン蚭蚈では問題が耇雑になる。ヒス
トリアンをファむアりォヌルの䌁業偎に眮くずいうこずは、Modbus/TCP や DCOM ずいったセキ
ュアでない倚数のプロトコルがファむアりォヌルに入るのを蚱すこずになり、ヒストリアンの䞋
にある党おの制埡デバむスがネットワヌクの䌁業偎にさらされるこずになる。反察に、ヒストリ
アンを制埡ネットワヌク偎に眮けば、HTTP や SQL ずいった同様に問題の倚いプロトコルがファ
むアりォヌルに入るのを蚱すこずになり、制埡ネットワヌク䞊にあるサヌバに、組織のほが党員
がアクセスできるこずになっおしたう。
総じお最善の゜リュヌションは、2 ゟヌンシステムDMZ なしを避けお 3 ゟヌンシステムを䜿
甚し、デヌタコレクタは制埡ネットワヌク内に、ヒストリアンコンポヌネントは DMZ 内に配眮
するこずである。

5.10.2 遠隔サポヌトシステム
ICS ファむアりォヌル蚭蚈の別の問題は、ナヌザ又はベンダヌが制埡ネットワヌクにリモヌトア
クセスするこずである。遠隔ネットワヌクから制埡ネットワヌクにアクセスするナヌザは、トヌ
クンベヌス認蚌等の匷力なメカニズムを䜿甚しお、認蚌を矩務づけるべきである。制埡グルヌプ
が DMZ に倚芁玠認蚌機胜の付いた独自のリモヌトアクセスシステムを蚭眮するのは可胜である
が、ほずんどの組織では、IT 郚門が蚭眮した既存システムを利甚する方が効率的である。その堎
合、IT リモヌトアクセスサヌバからファむアりォヌルを経由する接続が必芁ずなる。
むンタヌネット又はダむアルアップモデム経由で接続する遠隔サポヌト芁員は、䌁業 VPN 接続
クラむアント、アプリケヌションサヌバ、セキュア HTTP アクセス等を実行する暗号プロトコル
を䜿甚し、汎甚䌁業ネットワヌクにアクセスするため、トヌクンベヌス倚芁玠認蚌等の匷力なメ
カニズムを䜿甚しお認蚌を行うべきである。接続したなら、制埡ネットワヌクファむアりォヌル
においお、トヌクンベヌス倚芁玠認蚌等の匷力なメカニズムを䜿甚しお再床認蚌を求めおから、
制埡ネットワヌクぞのアクセスを蚱可すべきである。プロキシサヌバも遠隔サポヌトアクセスの
セキュリティを曎に向䞊させる。

5.10.3 マルチキャストトラフィック
EtherNet/IP や Foundation Fieldbus HSE などむヌサネット䞊で機胜するほずんどの生産者・消費者
又は発行者・賌読者プロトコルは IP マルチキャストベヌスである。IP マルチキャスティン
グの最倧の利点はネットワヌク効率にある。デヌタ送信を耇数の宛先に繰り返す必芁がないため、
ネットワヌク負荷が著しく枛る。2 ぀目の利点は、送信ホストが、ブロヌドキャスト情報をリス
ニングしおいる党おの宛先ホストの IP アドレスを知る必芁がないこずである。

118

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

far better capabilities for time synchronization between multiple control devices than multiple unicast
messages.
If the source and destinations of a multicast packet are connected with no intervening routers or firewalls
between them, the multicast transmission is relatively seamless. However, if the source and destinations are
not on the same LAN, forwarding the multicast messages to a destination becomes more complicated. To
solve the problem of multicast message routing, hosts need to join (or leave) a group by informing the
multicast router on their network of the relevant group ID through the use of the Internet Group
Management Protocol (IGMP). Multicast routers subsequently know of the members of multicast groups
on their network and can decide whether or not to forward a received multicast message onto their network.
A multicast routing protocol is also required. From a firewall administration perspective, monitoring and
filtering IGMP traffic becomes another series of rule sets to manage, adding to the complexity of the
firewall.
Another firewall issue related to multicasting is the use of NAT. A firewall performing NAT that receives a
multicast packet from an external host has no reverse mapping for which internal group ID should receive
the data. If IGMP-aware, it could broadcast it to every group ID it knows about, because one of them will
be correct, but this could cause serious issues if an unintended control packet were broadcast to a critical
node. The safest action for the firewall to take is to drop the packet. Thus, multicasting is generally
considered NAT-unfriendly.

5.11 Unidirectional Gateways
Hardware-enforced unidirectional gateways (e.g., data diodes) are increasingly deployed at the boundary
between ICS and IT networks, as well as between Safety Instrumented System networks and control
networks. Unidirectional gateways are a combination of hardware and software. The hardware permits data
to flow from one network to another, but is physically unable to send any information at all back into the
source network. The software replicates databases and emulates protocol servers and devices.

5.12 Single Points of Failure
Single points of failure can exist at any level of the ANSI/ISO stack. An example is PLC control of safety
interlocks. Because security is usually being added to the ICS environment, an evaluation should be done to
identify potential failure points and a risk assessment done to evaluate each point’s exposure. Remediation
methods can then be postulated and evaluated and a “risk versus reward” determination made and design
and implementation done.

5.13 Redundancy and Fault Tolerance
ICS components or networks that are classified as critical to the organization have high availability
requirements. One method of achieving high availability is through the use of redundancy. Additionally, if
a component fails, it should fail in a manner that does not generate unnecessary traffic on the ICS, or does
not cause another problem elsewhere, such as a cascading event.
The control system should have the ability to execute an appropriate fail-safe process upon the loss of
communications with the ICS or the loss of the ICS itself. The organization should define what "loss of
communications" means (e.g., 500 milliseconds, 5 seconds, 5 minutes, etc. without communications). The
organization should then, based on potential consequences, define the appropriate fail-safe process for their
industry.

119

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

3 ぀目は、おそらく産業甚制埡目的では最も重芁ず思われるが、耇数制埡デバむス間の時間同期に
ずっお、1 ぀のマルチキャストメッセヌゞの方が耇数のナニキャストメッセヌゞよりもはるかに優
れおいるこずである。
マルチキャストパケットの゜ヌスず宛先が仲介ルヌタやファむアりォヌルなしで接続されおいる堎
合、マルチキャスト送信は盞察的にシヌムレスである。ただし、゜ヌスず宛先が同じ LAN 䞊にな
い堎合、マルチキャストメッセヌゞの宛先転送は耇雑になる。マルチキャストメッセヌゞルヌティ
ングの問題を解決するには、各ホストが 1 ぀のグルヌプに加入又は離脱するこずである。これ
を行うに各ホストのネットワヌク䞊のマルチキャストルヌタに、むンタヌネットグルヌプ管理プロ
トコルIGMPを介しお、圓該グルヌプ ID を通知する。各マルチキャストルヌタは、それぞれの
ネットワヌク䞊のマルチキャストグルヌプメンバヌに぀いお知り、受信したマルチキャストメッセ
ヌゞをネットワヌクに転送するかどうかを決定する。マルチキャストルヌティングプロトコルも必
芁ずなる。ファむアりォヌル管理の芳点からすれば、IGMP トラフィックの監芖及びフィルタリン
グは、管理すべき別のルヌルセットずなり、ファむアりォヌルをいっそう耇雑にする。
マルチキャスティングに関連した別のファむアりォヌルの問題は NAT の䜿甚である。NAT を実行
するファむアりォヌルで、倖郚ホストからのマルチキャストパケットを受信するものにはリバヌス
マッピングがなく、これに぀いおは内郚グルヌプ ID がデヌタを受信すべきである。IGMP が認識し
おいれば、既知のグルヌプ ID 党おにブロヌドキャストする。その理由は、そのうちの 1 ぀が正しく
おも、意図しない制埡パケットが重芁ノヌドにブロヌドキャストされるず、倧きな問題になる可胜
性があるからである。ファむアりォヌルが取り埗る最も安党な策は、パケットをドロップするこず
である。よっお、マルチキャスティングは総じお NAT ず盞性が悪いずみなされる。

5.11

単方向性ゲヌトりェむ

ハヌドり゚アで匷制する単方向性ゲヌトりェむデヌタダむオヌド等は、ICS ネットワヌクず
IT ネットワヌク間や、安党蚈装システムネットワヌクず制埡ネットワヌク間の境界にたすたす展
開されるようになっおきた。単方向性ゲヌトりェむはハヌドり゚アず゜フトり゚アを組み合わせ
たものである。ハヌドり゚アはデヌタが䞀方のネットワヌクから他方のネットワヌクぞ流れるの
を蚱可するが、゜ヌスネットワヌクに情報を返すこずは物理的に䞍可胜である。゜フトり゚アは
デヌタベヌスを耇補しお、プロトコルサヌバ及びデバむスを゚ミュレヌトする。

5.12 単䞀障害点
単䞀障害点は、ANSI/ISO スタックのどのレベルにもある。䞀䟋は安党むンタヌロックの PLC 制
埡である。セキュリティは通垞 ICS 環境に远加されおいくものなので、評䟡を行っお障害ずなり
埗る点を明らかにし、リスク評䟡を行っお各点の゚クスポヌゞャを査定する。
次いで察凊方法を想定しお評䟡し、「リスク察報酬」を刀定し、蚭蚈・実装を行う。

5.13 冗長性ずフォヌルトトレランス
組織にずっお重芁ず分類される ICS コンポヌネントやネットワヌクには、高い可甚性芁件が課さ
れる。高い可甚性を実珟する 1 ぀の方法は、冗長性の利甚である。たた、あるコンポヌネントに
障害が出た堎合でも、ICS に䞍芁のトラフィックを生じさせず、連鎖むベントなど別の問題を掟
生させおはならない。
制埡システムは、ICS ずの通信喪倱時又は ICS そのものの喪倱時に、適切なフェヌルセヌフプロ
セスを実行できる胜力を備えおいるべきである。組織は「通信喪倱」の意味を明らかにすべきで
ある通信途絶で 500 ミリ秒、5 秒、5 分等。次いで生じ埗る結果を基に、産業甚の適正なフ
ェヌルセヌフプロセスを明らかにすべきである。

120

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Backups should be performed using the “backup-in-depth” approach, with layers of backups (e.g., local,
facility, disaster) that are time-sequenced such that rapid recent local backups are available for immediate
use and secure backups are available to recover from a massive security incident. A mixture of
backup/restore approaches and storage methods should be used to ensure that backups are rigorously
produced, securely stored, and appropriately accessible for restoration.

5.14 Preventing Man-in-the-Middle Attacks
A man-in-the-middle attack requires knowledge of the protocol being manipulated. The Address Resolution
Protocol (ARP) man-in-the-middle attack is a popular method for an adversary to gain access to the
network flow of information on a target system. This is performed by attacking the network ARP cache
tables of the controller and the workstation machines. Using the compromised computer on the control
network, the adversary poisons the ARP tables on each host and informs them that they must route all their
traffic through a specific IP and hardware address (i.e., the adversary’s machine). By manipulating the ARP
tables, the adversary can insert their machine between the two target machines and/or devices.
The ARP man-in-the-middle attack works by initiating gratuitous ARP commands to confuse each host (i.e.,
ARP poisoning). These ARP commands cause each of the two target hosts to use the MAC address of the
adversary as the address for the other target host. When a successful man-in-the-middle attack is performed,
the hosts on each side of the attack are unaware that their network data is taking a different route through
the adversary’s computer.
Once an adversary has successfully inserted their machine into the information stream, they now have full
control over the data communications and could carry out several types of attacks. One possible attack
method is the replay attack. In its simplest form, captured data from the control/HMI is modified to
instantiate activity when received by the device controller. Captured data reflecting normal operations in
the ICS could be played back to the operator as required. This would cause the operator’s HMI to appear to
be normal and the attack will go unobserved. During this replay attack the adversary could continue to send
commands to the controller and/or field devices to cause an undesirable event while the operator is unaware
of the true state of the system.
Another attack that could be carried out with the man-in-the-middle attack is sending false messages to the
operator, and could take the form of a false negative or a false positive. This may cause the operator to take
an action, such as flipping a breaker, when it is not required, or it may cause the operator to think
everything is fine and not take an action when an action is required. The adversary could send commands to
the operator’s console indicating a system change, and when the operator follows normal procedures and
attempts to correct the problem, the operator’s action could cause an undesirable event. There are variations
of the modification and replay of control data which could impact the operations of the system.
Protocol manipulation and the man-in-the-middle attack are among the most popular ways to manipulate
insecure protocols, such as those found in control systems. However, there are mitigation techniques [38]
that can be applied to secure the systems through MAC address locking, static tables, encryption,
authentication, and monitoring.


MAC Address Locking - The ARP man-in-the-middle attack requires the adversary to be connected
to the local network or have control of a local computer on the network. Port security, also called
MAC address locking, is one method to secure the physical connection at the end of each port on a
network switch. High-end corporate class network switches usually have some kind of option for
MAC address locking. MAC address locking is very effective against a rogue individual looking to
physically plug into the internal network. Without port security, any open network jack on the wall

121

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

バックアップは「倚局バックアップ」アプロヌチにより、時系列順になったバックアップ局ロ
ヌカル、斜蚭、灜害等に察しお実斜し、急速に行われた最近のロヌカルバックアップがすぐに
䜿甚できるようにし、セキュアなバックアップが倧芏暡なセキュリティむンシデントから埩垰す
る際に利甚できるようにする。バックアップ/埩元ずストレヌゞ法ずを䜵甚しお、バックアップ
が厳栌に䜜成され、安党に保管され、適切に埩元できるようにする。

5.14 人が介圚する攻撃の防止
人が介圚する攻撃は、操䜜 䞭のプロトコルに察する知識が必須ずなる。宛先解決プロトコル
ARPの人が介圚する攻撃は、攻撃偎が暙的システム䞊の情報の流れにアクセスするための
よくある方法である。これを行うには、コントロヌラ及びワヌクステヌションマシンのネッ
トワヌク ARP キャッシュテヌブルを攻撃する。制埡ネットワヌク䞊の性胜が䜎䞋したコンピ
ュヌタを利甚しお、攻撃偎は各ホスト䞊の ARP テヌブルを攻め、党おのトラフィックを特定
の IP 及びハヌドり゚アアドレス攻撃偎のマシンに送るよう指瀺する。攻撃偎は ARP テヌ
ブルを操䜜しお、2 台の暙的マシン間又はデバむス間に自らのマシンを挿入する。
ARP の人が介圚する攻撃は、䜙蚈な ARP コマンドを発行しお、各ホストを混乱させるこずで機
胜するARP ポむズニング。このような ARP コマンドは、2 台の暙的ホストのおのおのに、
攻撃偎の MAC アドレスを他の暙的ホスト甚のアドレスずしお䜿甚するように仕向ける。人が介
圚する攻撃が成功するず、攻撃の䞡偎のホストが気づかないうちに、ネットワヌクデヌタが別
経路をたどっお攻撃偎のコンピュヌタに流れる。
攻撃偎が自らのマシンを銖尟よく情報経路に挿入するず、デヌタ通信を党面的に制埡でき、
皮々の攻撃を仕掛けられるようになる。その 1 ぀がリプレヌ攻撃である。最も単玔な圢態は、
制埡/HMI から捕捉したデヌタを改倉しお、デバむスコントロヌラがこれを受信したずきに行動
を起こすようにするものである。ICS における正垞な業務を反映した捕捉デヌタは、必芁に応
じお操䜜員にプレむバックされる。これにより操䜜員の HMI は芋かけ䞊正垞に芋え、攻撃は発
芚しない。このリプレヌ攻撃䞭に、攻撃偎はコントロヌラ又はフィヌルドデバむスにコマンド
を送り続け、有害事象を生じさせるこずができるが、操䜜員はシステムの実情に気づかない。
人が介圚する攻撃の別のものずしお、停のメッセヌゞを操䜜員に送り、擬䌌陰性又は擬䌌陜性
の圢態を取るものがある。このため操䜜員は、ブレヌカヌを萜ずすずいった䞍芁な察応を取っ
たり、逆に必芁な察応を取らなければならないのに、党お良奜ず思い蟌んで䜕もしないずいっ
たこずが生じる。攻撃偎は操䜜員のコン゜ヌルに、システムの倉曎を瀺すコマンドを送り、操
䜜員が通垞手順に埓っお問題を修正しようずするず、それが元で有害事象が発生する。システ
ムの動䜜に圱響する制埡デヌタの倉曎及びリプレヌには皮々のバリ゚ヌションがある。
プロトコル操䜜ず人が介圚する攻撃は、制埡システムで芋られるもののうち、セキュアでないプ
ロトコルを操䜜する方法ずしお最もよく䜿甚される方法の 1 ぀である。しかし MAC アドレスロ
ック、スタティックテヌブル、暗号化、認蚌及び監芖を通じお、システムをセキュアにするため
の緩和技術がある[38]。

 MAC アドレスロック - ARP の人が介圚する攻撃では、攻撃偎がロヌカルネットワヌクに接
続し、ネットワヌク䞊のロヌカルコンピュヌタを制埡するこずが必芁ずなる。MAC アドレ
スロックずも呌ばれるポヌトセキュリティは、ネットワヌクスむッチ䞊の各ポヌト端におけ
る物理的接続をセキュアにする方法である。ハむ゚ンド䌁業クラスネットワヌクスむッチに
は、通垞 MAC アドレスロック甚のオプションがいく぀か甚意されおいる。MAC アドレス
ロックは、内郚ネットワヌクぞの物理的プラグむンを目論む個人に察しお極めお有効である。
ポヌトセキュリティがない堎合、壁面のオヌプンネットワヌクゞャックを利甚しお、

122

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

could be used as an avenue onto the corporate network. Port security locks a specific MAC address to
a specific port on a managed switch. If the MAC address does not match, the communication link is
disabled and the intruder will not be able to achieve their goal. Some of the more advanced switches
have an auto resetting option, which will reset the security measure if the original MAC is returned to
the port.
Although port security is not attacker proof, it does add a layer of added security to the physical
network. It also protects the local network from employees plugging un-patched and out-of-date
systems onto the protected network. This reduces the number of target computers a remote adversary
can access. These security measures not only protect against attacks from external networks but
provide added physical protection as well.


Static Tables – An ICS network that stays relatively static could attempt to implement statically coded
ARP tables. Most operating systems have the capability to statically code all of the MAC addresses
into the ARP table on each computer. Statically coding the ARP tables on each computer prevents the
adversary from changing them by sending ARP reply packets to the victim computer. While this
technique is not feasible on a large and/or dynamic corporate network, the limited number of hosts on
an ICS network could be effectively protected this way.



Encryption - As a longer-term solution, systems should be designed to include encryption between
devices in order to make it very difficult to reverse engineer protocols and forge packets on control
system networks. Encrypting the communications between devices would make it nearly impossible to
perform this attack. Protocols that provide strong authentication also provide resilience to man-in-themiddle attacks. The impact of encryption on network and operational performance needs to be
considered.



Authentication - Protocols with strong authentication provide resilience to man-in-the-middle attacks.



Monitoring - Monitoring for ARP poisoning provides an added layer of defense. There are several
programs available (e.g., ARPwatch) that can monitor for changing MAC addresses through the ARP
packets.

123

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

䌁業ネットワヌクぞ䟵入するこずができる。ポヌトセキュリティは、管理されたスむッチ
䞊の特定ポヌトに特定 MAC アドレスをロックする。MAC アドレスが合わないず、通信リン
クが䜿甚䞍胜になり、䟵入者は目的を達するこずができない。より進化したスむッチでは、
自動リセットオプションがあり、元の MAC がポヌトに戻るず、セキュリティ察策がリセッ
トされるようになっおいる。
ポヌトセキュリティは、攻撃を寄せ付けないわけではないが、物理ネットワヌクにセキュ
リティのレむダヌを远加するものずなる。たた埓業員がパッチの圓たっおいない旧匏シス
テムで、保護されたネットワヌクに接続した堎合に、ロヌカルネットワヌクを保護する。
これにより遠隔攻撃でアクセスできる暙的コンピュヌタの数が枛る。こうしたセキュリテ
ィ察策は、倖郚ネットワヌクからの攻撃から保護するだけでなく、物理的保護を増やすこ
ずにもなる。

 スタティックテヌブル - 比范的静的な ICS ネットワヌクは、静的にコヌディングされた ARP
テヌブルを実装しようずする。ほずんどの OS には、党おの MAC アドレスを各コンピュヌ
タの ARP テヌブルに静的にコヌディングする胜力が備わっおいる。各コンピュヌタの ARP
テヌブルぞの静的コヌディングを行うこずにより、攻撃偎は、ARP リプラむパケットを暙
的コンピュヌタに送信しお、テヌブルを倉曎するこずができなくなる。この技術は、倧芏暡
な又は動的な䌁業ネットワヌクでは実珟できないが、ICS ネットワヌク䞊の限定的な数のホ
ストなら、この方法で有効に保護できる。
 暗号化 - より長期的な゜リュヌションずしお、プロトコルのリバヌス゚ンゞニアリングや制
埡システムネットワヌク䞊のパケットの停造を困難にするため、デバむス間の暗号化を蚭蚈
に含めるべきである。デバむス間の通信を暗号化すれば、この攻撃がほが䞍可胜になる。匷
力な認蚌を行うプロトコルは、人が介圚する攻撃に察する柔軟性も付䞎する。暗号化による
ネットワヌクや業務パフォヌマンスぞの圱響を怜蚎する必芁がある。
 認蚌 - 匷力な認蚌メカニズムを持぀プロトコルは、人が介圚する攻撃に察する柔軟性を付䞎
する。
 監芖 - ARP ポむズニングの監芖により防埡局が厚くなる。ARP パケットの䞭で絶えず倉化す
る MAC アドレスを監芖できるプログラムがいく぀かあるARP りォッチ等。

124

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.15 Authentication and Authorization
An ICS may contain a large number of systems, each of which must be accessed by a variety of users.
Performing the authentication and authorization of these users presents a challenge to the ICS. Managing
these user’s accounts can be problematic as employees are added, removed, and as their roles change. As
the number of systems and users grow, the process of managing these accounts becomes more complicated.
The authentication of a user or system is the process of verifying the claimed identity. Authorization, the
process of granting the user access privileges, is determined by applying policy rules to the authenticated
identity and other relevant information 31. Authorization is enforced by some access control mechanism.
The authentication process can be used to control access to both systems (e.g. HMIs, field devices, SCADA
servers) and networks (e.g., remote substations LANs).
Authentication and authorization can be performed either in a distributed or centralized approach. With
distributed authentication and authorization, every system performs these steps on their own. Each system
is responsible for storing its own set of user accounts, credentials, and roles and performing the
identification and authentication of the user. This approach typically does not require any additional
infrastructure. However, this approach is problematic in that it does not scale well as the size of the system
increases. For example, if a user leaves the organization, the corresponding user account must be removed
from each system individually.
In contrast to the distributed approach, centralized authentication and authorization systems are commonly
used to manage larger number of users and accounts. A centralized approach utilizes some central
authentication system (e.g., Microsoft Active Directory, Lightweight Directory Access Protocol (LDAP) to
store all accounts and manage the authentication and authorization of all individuals and systems. An
authentication protocol (e.g., Kerberos, RADIUS, TACACS+) is then used to communicate data between
the authentication server and the system performing authentication.
While a centralized approach provides substantially improved scalability, it also presents numerous
additional concerns that may impact its use in ICS environments. The following considerations apply:


Authentication servers create a single system that is responsible for managing all system accounts and
must be highly secured.



The authentications server system requires high availability because its failure may prevent users from
authenticating to a system during an emergency. Redundancy may be required.



Some clients may cache user credentials locally to ensure that users can still be authenticated in the
absence of the server. Caching may only be available for users that have recently authenticated.
Caching also introduces complications for revocation.



Networks used to support the authentication protocol must be reliable and secure to ensure
authentication attempts are not hindered.

31

In general, authorization to perform a set of operations is determined by evaluating attributes associated
with the subject, object, requested operations, and, in some cases, environment conditions against policy,
rules, or relationships that describe the allowable operations for a given set of attributes. For further
information see NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and
Considerations, at http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf

125

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.15 認蚌ず暩限付䞎
ICS には倚数のシステムが含たれる堎合があり、倚皮倚様なナヌザがそれぞれにアクセスでき
なければならない。これらナヌザの認蚌ず蚱可を行うのは ICS にずっお重荷ずなる。埓業員の
远加、削陀ず圹割の倉化に䌎い、ナヌザアカりントの管理が煩雑になる。システムずナヌザの
数が増えるに぀れお、アカりント管理のプロセスがどんどん耇雑化する。
ナヌザ又はシステムの蚱可は、それぞれが䞻匵する ID を怜蚌するプロセスである。暩限付䞎
は、ナヌザにアクセス暩を䞎えるプロセスで、暩限を受ける ID その他関連情報 32にポリシヌ
芏則を適甚しお刀定される。暩限付䞎は䜕らかのアクセス制埡メカニズムにより実行される。
暩限付䞎プロセスを利甚しお、システムHMIs、フィヌルドデバむス、SCADA サヌバ等ずネ
ットワヌク遠隔サブステヌション LAN 等の䞡方ぞのアクセスを制埡できる。
認蚌ず暩限付䞎は、分散アプロヌチでも集䞭アプロヌチでも行うこずができる。分散認蚌・暩
限付䞎を利甚するず、各システムがこれらの手順を独自に行う。各システムはそれぞれの責任
でナヌザアカりント、認蚌情報及び圹割を保管し、ナヌザの識別ず暩限付䞎を行う。通垞、こ
のアプロヌチにはほかのむンフラが䞍芁である。ただし、システムの増倧に䌎うスケヌラビリ
ティに問題がある。䟋えば、あるナヌザが退瀟した堎合、ナヌザアカりントをそれぞれのシス
テムから削陀しなければならない。
分散アプロヌチずは察照的に、集䞭認蚌・暩限付䞎システムは、䞀般により倧芏暡なナヌザ
及びアカりントの管理に䜿甚される。集䞭アプロヌチは特定の䞭倮認蚌システムMicrosoft
Active Directory、 Lightweight Directory Access Protocol[LDAP]等を䜿甚しお党おの
アカりントを保管し、党ナヌザ・党システムの認蚌ず暩限付䞎を管理する。次いで暩限付䞎
プロトコルKerberos、RADIUS、TACACS+等を䜿甚しお認蚌サヌバず認蚌実斜システム間で
デヌタ通信を行う。
集䞭アプロヌチではスケヌラビリティがかなり向䞊する反面、ICS 環境で䜿甚した堎合の圱響
に぀いおは䞍安が倚い。次のような芁考慮事項がある。

 認蚌サヌバが単䞀システムを創出し、これが党おのシステムアカりントを管理し、高床にセ
キュアでなければならない。
 認蚌サヌバシステムは、故障するず緊急時でもナヌザはシステム認蚌ができなくなるため、
高い可甚性が求められる。冗長性が必芁ずなろう。
 クラむアントによっおは、ナヌザの認蚌情報をロヌカルでキャッシュし、サヌバがなくおも
ナヌザが認蚌できるようにしおいる。キャッシングは、最近認蚌したナヌザにしか利甚でき
ない。キャッシングは取消も耇雑にする。
 認蚌プロトコルをサポヌトするためのネットワヌクは信頌性が高くセキュアで、認蚌の詊み
が劚げられないようにしなければならない。

32

総じお䞀連の操䜜をするための暩限付䞎は、䞻䜓、察象、求めおいる操䜜内容に関係する属性を評䟡しお刀定するが、堎
合によっおは、特定の属性に関しお蚱可する操䜜内容を芏定したポリシヌ、芏則又は関係に照らしお、環境条件を評䟡し
刀定する。詳现は次の URL にある NIST SP 800-162『属性に基づくアクセス制埡ABAC定矩及び考慮』を参照のこず。
http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf

126

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

5.15.1 ICS Implementation Considerations
While centralized authentication and authorization servers are commonly used in an IT environment, there
are many challenges to integrating them into ICS. While authentication servers and protocols integrate with
many commodity IT products (e.g., Microsoft Windows, Linux, Oracle), often ICS may utilize their own
application-specific accounts and authentication mechanisms that were not designed to interface with third
party servers and protocols. This limits the adoption of such mechanism in an ICS environment. Older
network devices and most field devices do not support any mechanisms to integrated with a centralized
authentication system.

5.16 Monitoring, Logging, and Auditing
The security architecture of an ICS must also incorporate mechanisms to monitor, log, and audit activities
occurring on various systems and networks. Monitoring, logging, and auditing activities are imperative to
understanding the current state of the ICS, validating that the system is operating as intended, and that no
policy violations or cyber incidents have hindered the operation of the system. Network security monitoring
is valuable to characterize the normal state of the ICS, and can provide indications of compromised systems
when signature-based technologies fail. Additionally, strong system monitoring, logging, and auditing is
necessary to troubleshoot and perform any necessary forensic analysis of the system 33.

5.17 Incident Detection, Response, and System Recovery
Incidents are inevitable and incident detection, response, and system recovery plans are essential. Major
characteristics of a good security program are how soon after an incident has occurred that the incident can
be detected and how quickly a system can be recovered after an incident has been detected. Incident
response in ICS is closely aligned to disaster recovery, specifically to address the stringent uptime
requirements of ICS. Incident Responders must be trained for ICS-specific scenarios, as normal methods
of recovering IT systems may not apply to ICS.

33

For further information see NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) [55].

127

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

5.15.1 ICS 実装䞊の考慮事項
集䞭認蚌サヌバ及び集䞭暩限付䞎サヌバは、IT 環境では普通に利甚されおいるが、ICS に䞡者を
組み蟌むのは問題が倚い。認蚌サヌバ及びプロトコルは倚くの垂販 IT 補品Microsoft Windows、
Linux、Oracle 等を組み蟌むが、ICS では独自のアプリケヌション固有のアカりントず認蚌メカ
ニズムを䜿甚するこずが倚く、それらはサヌドパヌティのサヌバ及びプロトコルず連携するよう
にはできおいない。そのため ICS 環境ではそうしたメカニズムの採甚に限界がある。旧型のネッ
トワヌクデバむスやほずんどのフィヌルドデバむスは、集䞭認蚌システムに組み蟌めるメカニズ
ムに察応しおいない。

5.16 監芖、ロギング及び監査
ICS のセキュリティアヌキテクチャには、皮々システムやネットワヌクを監芖、ログ及び監査で
きるメカニズムが組み蟌たれおいなければならない。監芖、ロギング及び監査掻動は ICS の珟状
を理解し、システムが予定どおり皌働しおいるか怜蚌し、システムの動䜜を劚害するようなポリ
シヌ違反やサむバヌむンシデントがないこずを怜蚌するために䞍可欠である。ネットワヌクセキ
ュリティ監芖は、ICS の正垞状態の特城を明確化するために貎重で、眲名ベヌスの技術に障害が
出たずきに、システム性胜が䜎䞋した兆候を提瀺できる。たた、トラブルシュヌティングを行い、
システム 34の必芁な調査分析を行うには、匷力なシステム監芖、ロギング及び監査が必芁である。

5.17 むンシデント怜知、察応及びシステム埩旧
むンシデントは避けられないので、むンシデント怜知、察応及びシステム埩旧蚈画が䞍可欠ずな
る。優秀なセキュリティプログラムの䞻な特城は、むンシデント発生時にいかに玠早く怜知し、
怜知埌いかに迅速にシステムを埩旧できるかにある。ICS におけるむンシデント察応は、灜害埩
旧ず密接に連携し、特に ICS の厳栌なアップタむム芁件に぀いお怜蚎する。IT システムの通垞の
埩旧方法は ICS には圓おはたらないため、むンシデント察応者の蚓緎は、ICS 固有のシナリオに
沿っお実斜しなければならない。

34

詳现は NIST SP 800-94『䟵入怜知防止システムIDPS』[55]を参照のこず。

128

SPECIAL PUBLICATION 800-82 REVISION 2

6.

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Applying Security Controls to ICS

A single security product or technology cannot adequately protect an ICS. Securing an ICS is based on a
combination of effective security policies and a properly configured set of security controls. The selection
and implementation of security controls to apply to an ICS can have major implications on the operations,
so it is critical to consider:


Which security controls are needed to adequately mitigate risk to an acceptable level that supports the
organizational missions and business functions?



Have the selected security controls been implemented or is there a realistic implementation plan in
place?



What is the required level of assurance that the selected security controls are implemented correctly,
operating as intended, and producing a desired outcome?

As identified in Section 3, the questions should be answered in the context of an effective, organizationwide risk management process and cybersecurity strategy that identifies, mitigates (as necessary), and
continuously monitors risks to its ICS. An effective cybersecurity strategy for an ICS should apply defensein-depth, a technique of layering security mechanisms so that the impact of a failure in any one mechanism
is minimized. Use of such a strategy is explored within the security control discussions and their
applications to ICS that follow.

6.1 Executing the Risk Management Framework Tasks for Industrial Control
Systems
The following describes the process of applying the Risk Management Framework (RMF) to ICS. The
process includes a brief description of each activity and identifies supporting NIST documents. The
following steps, while shown sequentially, can be implemented in a different order to be consistent with
established management and system development life cycle processes [21].

129

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6. ICS ぞのセキュリティ察策の適甚
単䞀のセキュリティ補品や技術では、ICS をしっかり保護するこずはできない。ICS のセキュリ
ティ確保は、有効なセキュリティポリシヌず構成の行き届いたセキュリティ察策を基調ずする。
ICS に適甚するセキュリティ察策の遞定ず実装は、業務ず密接な関係を持぀ため、以䞋に぀いお
良く怜蚎するこずが肝芁である。

 リスクを蚱容できるレベルたで緩和し、組織の任務ず事業機胜を支揎できるようにするには
どのセキュリティ察策が必芁か。
 遞定したセキュリティ察策は実行されたか、それずも珟実的な実行蚈画があるか。
 遞定したセキュリティ察策を予定どおり正しく実行し、所期の結果を埗るにはどの皋床の保
蚌レベルが必芁か。
セクション 3 で明確にしたように、䞊蚘の質問に察する答えは、有効な組織党䜓のリスク管理プ
ロセスず、組織の ICS リスクを特定し、必芁に応じお緩和し、継続的に監芖するサむバヌセキュ
リティ戊略に照らしお提瀺されるべきである。ICS の効果的なサむバヌセキュリティ戊略は、倚
局防埡ずしお知られるレむダリングセキュリティメカニズム技術を適甚し、あるメカニズムの障
害の圱響が最小限に食い止められるようにすべきである。このような戊略の䜿甚は、セキュリテ
ィ管理に関する議論ずその埌の ICS ぞの適甚の䞭で策定される。

6.1

産業甚制埡システム甚リスク管理䜓制の実斜

リスク管理䜓制RMFを ICS に適甚するためのプロセスを以䞋に蚘述する。それぞれの掻動に
察する抂芁ず NIST の根拠文曞を瀺す。手順を順番に瀺すが、策定された管理・システム開発ラ
むフサむクルプロセス[21]に埓っお、順序を倉えお実斜しおもかたわない。

130

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure 6-1. Risk Management Framework Tasls

6.1.1 Step 1: Categorize Information System
The first activity in the RMF is to categorize the information and information system according to potential
impact of loss. For each information type and information system under consideration, the three FISMAdefined security objectives—confidentiality, integrity, and availability—are associated with one of three
levels of potential impact should there be a breach of security. It is important to remember that for an ICS,
availability is generally the greatest concern.
The standards and guidance for this categorization process can be found in FIPS 199 [15] and NIST SP
800-60 [25], respectively. NIST is in the process of updating NIST SP 800-60 to provide additional
guidance on the categorization of ICS.

131

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

アヌキテクチャの説明
アヌキテクチャ基準モデルセグ
メント及び゜リュヌション
アヌキテクチャ任務・事業プロ
セス情報システムの境界

プロセスの抂芁
開始点

組織の入力
法埋、指瀺曞、ポリシヌ
ガむダンスの戊略的目暙・目暙優
先順䜍及びリ゜ヌス可甚性サプラ
ã‚€
チェヌンに察する考慮事項

必芁に応じお繰り返す
手順 1
情報システムの分類
手順 6

手順 2

セキュリティ察策の監芖

セキュリティ察策の遞定

リスク
管理䜓制
手順 5

手順 3

情報システムの蚱可

セキュリティ察策の実斜
手順 4
セキュリティ察策の評䟡

図 6-1.リスク管理䜓制業務

6.1.1 手順 1情報システムの分類
RMF の第 1 歩は、喪倱時の圱響に応じお、情報ず情報システムを分類するこずである。怜蚎䞭
の情報の皮類ず情報システムごずに、FISMA の定矩による機密性・完党性・可甚性ずいう 3 ぀
のセキュリティ目暙が、セキュリティ違反があった堎合の 3 レベルのうちのいずれかに関連づけ
られる。ICS では総じお可甚性が最倧の関心事ずなる点を銘蚘するのは肝芁である。
この分類プロセスの基準ずガむダンスは、それぞれ FIPS 199[15]ず NIST SP 800-60 [25]にある。
NIST では NIST SP 800-60 を改蚂䞭で、ICS の分類に関する補足的なガむダンスを提䟛する予定
である。

132

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The following ICS example is taken from FIPS 199 [15]:
ICS-specific Recommendations and Guidance
A power plant contains a SCADA system controlling the distribution of electric power for a large military
installation. The SCADA system contains both real-time sensor data and routine administrative
information. The management at the power plant determines that: (i) for the sensor data being acquired by
the SCADA system, there is no potential impact from a loss of confidentiality, a high potential impact from
a loss of integrity, and a high potential impact from a loss of availability; and (ii) for the administrative
information being processed by the system, there is a low potential impact from a loss of confidentiality, a
low potential impact from a loss of integrity, and a low potential impact from a loss of availability. The
resulting security categories, SC, of these information types are expressed as:
SC sensor data = {(confidentiality, NA), (integrity, HIGH), (availability, HIGH)},
and
SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
The resulting security category of the information system is initially expressed as:
SC SCADA system = {(confidentiality, LOW), (integrity, HIGH), (availability, HIGH)},
representing the high water mark or maximum potential impact values for each security objective from the
information types resident on the SCADA system. The management at the power plant chooses to increase
the potential impact from a loss of confidentiality from low to moderate, reflecting a more realistic view of
the potential impact on the information system should there be a security breach due to the unauthorized
disclosure of system-level information or processing functions. The final security category of the
information system is expressed as:
SC SCADA system = {(confidentiality, MODERATE), (integrity, HIGH), (availability, HIGH)}.

FIPS 199 specifies that information systems be categorized as low-impact, moderate-impact, or highimpact for the security objectives of confidentiality, integrity, and availability. Possible definitions for low,
moderate, and high levels of security based on impact for ICS based on ISA99 are provided in Table 6-1.
Possible definitions for ICS impact levels based on product produced, industry and security concerns are
provided in Table 6-2.
Table 6-1. Possible Definitions for ICS Impact Levels Based on ISA99
Impact Category
Injury

Low-Impact

Moderate-Impact

High-Impact

Requires hospitalization

Loss of life or limb

Financial Loss

Cuts, bruises requiring
first aid
$1,000

$100,000

Millions

Environmental Release

Temporary damage

Lasting damage

Permanent damage, offsite damage

Interruption of
Production
Public Image

Minutes

Days

Weeks

Temporary damage

Lasting damage

Permanent damage

133

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

以䞋の ICS の䟋は、FIPS 199[15]から抜粋したものである。
ICS 固有の掚奚事項及びガむダンス
ある発電所には、倧芏暡軍事斜蚭ぞの配電を制埡する SCADA システムが蚭眮されおいる。
SCADA システムにはリアルタむムセンサデヌタず定垞の管理情報が含たれる。発電所の経営陣
は以䞋のずおり刀定しおいる。1SCADA システムで取埗するセンサデヌタに぀いおは、機密
性が倱われおも圱響はなく、完党性が倱われるずかなりの圱響があり、可甚性が倱われるずかな
りの圱響がある。2システムが凊理する管理情報に぀いおは、機密性が倱われおも圱響は少
なく、完党性が倱われおも圱響は少なく、可甚性が倱われおも圱響は少ない。このような情報の
皮類に基づく結果、セキュリティ分類SCは次の匏で衚すこずができる。
SC センサデヌタ = {(機密性、NA), (完党性, HIGH), (可甚性, HIGH)}、たた
SC 管理情報 = {(機密性、LOW), (完党性, LOW), (可甚性, LOW)}。
情報システムに基づくセキュリティ分類は圓初
SC SCADA システム = {(機密性、LOW), (完党性, HIGH), (可甚性, HIGH)}で、
SCADA システムに垞駐する情報の皮類に基づくセキュリティ目暙ごずの圱響倀は、倧又は最倧
圱響床を瀺しおいる。発電所の経営陣の遞択は、機密性が倱われたずきの圱響床を䜎から䞭にし、
䞇䞀システムレベル又は凊理機胜の挏掩によるセキュリティ違反が生じた際に、情報システムぞ
の圱響をより珟実的にずらえるようにした。最終的な情報システムに基づくセキュリティ分類は
SC SCADA システム = {(信頌性、MODERATE), (完党性, HIGH), (可甚性, HIGH)}ずなった。

FIPS 199 では、機密性・完党性・可甚性のセキュリティ目暙に関する情報システムの分類を䜎圱
響床、䞭圱響床、高圱響床ず定めおいる。 ISA99 に埓った ICS ぞの圱響に基づいたセキュリティ
レベル䜎・䞭・高の定矩を衚 6-1 に瀺す。生産物、産業及びセキュリティ関心事に基づいた ICS
ぞの圱響レベルの定矩を衚 6-2 に瀺す。
è¡š 6-1. ISA99 に基づく ICS 圱響レベルの定矩

圱響床分類

䜎

äž­

高

負傷

応急凊眮を芁する切り
傷、打撲

入院が必芁

生呜・四肢の喪倱

金銭的喪倱

$1,000

$100,000

数癟䞇

環境攟出

䞀時的ダメヌゞ

長期的ダメヌゞ

氞続的ダメヌゞ、珟
堎倖のダメヌゞ

生産䞭断

分

日

週

囜民のむメヌゞ

䞀時的ダメヌゞ

長期的ダメヌゞ

氞続的ダメヌゞ

134

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Table 6-2. Possible Definitions for ICS Impact Levels Based on Product Produced, Industry and
Security Concerns
Impact Category
Product Produced

Low-Impact
 Non-hazardous

Moderate-Impact
 Some hazardous

High-Impact
 Critical infrastructure (e.g.,

materials or products
 Non-ingested

products or steps
during production
 High amount of

electricity)
 Hazardous materials
 Ingested products

consumer products

Industry Examples

 Plastic injection

industries
 Pulp and paper
 Semiconductors






 Protection against

 Protection against

 Protection against major

minor injuries
 Ensuring uptime

moderate injuries
 Ensuring uptime
 Capital investment

molding
 Warehouse
applications
Security Concerns

proprietary
information
 Automotive metal







Utilities
Petrochemical
Food and beverage
Pharmaceutical

injuries/loss of life
Ensuring uptime
Capital investment
Trade secrets
Ensuring basic social services
Regulatory compliance

6.1.2 Step 2: Select Security Controls
This framework activity includes the initial selection of minimum security controls planned or in place to
protect the information system based on a set of requirements. FIPS 200 documents a set of minimumsecurity requirements covering 18 security-related areas with regard to protecting the confidentiality,
integrity, and availability of federal information systems and the information processed, stored, and
transmitted by those systems [16]. Additional information on each of the 18 security control families is in
Section 6.2.
The baseline controls are the starting point for the security control selection process and chosen based on
the security category and associate impact level of information systems determined in Step 1.
To address the need for developing community-wide and specialized sets of security controls for
information systems and organizations, the concept of overlays is introduced. An overlay is a fully
specified set of security controls, control enhancements, and supplemental guidance derived from the
application of tailoring guidance to security control baselines described in NIST SP 800-53.
In general, overlays are intended to reduce the need for ad hoc tailoring of baselines by organizations
through the selection of a set of controls and control enhancements that more closely correspond to
common circumstances, situations, and/or conditions. However, the use of overlays does not in any way
preclude organizations from performing further tailoring (i.e., overlays can also be subject to tailoring) to
reflect organization-specific needs, assumptions, or constraints. For further information on creating
overlays, refer to SP 800-53, Section 3.3 and Appendix I.
Appendix G— includes an ICS-specific overlay of applicable NIST SP 800-53 controls that provide
tailored baselines for low-impact, moderate-impact, and high-impact ICS. These tailored baselines can be
utilized as starting specifications and recommendations that can be applied to specific ICS by responsible
personnel. As discussed in earlier sections, the use of an overlay does not in any way preclude
organizations from performing further tailoring to add or remove controls and control enhancements (i.e.,
overlays can also be subject to tailoring) to reflect organization-specific needs, assumptions, or constraints.

135

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

è¡š 6-2. 生産物、産業及びセキュリティ関心事に基づく ICS ぞの圱響レベルの定矩

カテゎリ
生産物

䜎
• 危険物・産物以
•

産業䟋

•
•

セキュリティ
関心事

•
•

倖
非摂取型消費
財
プラスチッ
ク射出成圢
倉庫ア
プリ
軜傷予防
皌働確保

äž­
• 生産時にある皋床の危

険産物・手順
• 倚量の専有情報

高
• 重芁むンフラ電気

等
• 危険物
• 摂取型産物

• 車䞡金属業界
• パルプ補玙
• 半導䜓

•
•
•
•

• 䞭皋床の負傷予

•
•
•
•
•

防
• 皌働確保
• 資本投資

公共事業
石油化孊
食品飲料
薬剀

重傷・死亡予防
皌働確保
資本投資
取匕䞊の秘密
基本的瀟䌚犏祉の確
保
• 法什遵守

6.1.2 手順 2セキュリティ察策の遞択
この枠組での掻動には、䞀連の芁件に基づく情報システムを保護するための蚈画䞭又は実斜䞭
の最䜎限のセキュリティ察策の初期遞択を行うこずが含たれる。FIPS200 には、18 のセキュリ
ティ関連分野を網矅した䞀連の最䜎セキュリティ芁件が蚘録されおおり、連邊情報システムの
機密性・完党性・可甚性の保護や、これらシステムが凊理・保管・送信する情報に぀いお取り
䞊げられおいる[16]。18 のセキュリティ察策分野に関する付加的な情報はセクション 6.2 で取
り䞊げる。
ベヌスラむン制埡は、セキュリティ察策遞定プロセスの開始点ずなり、セキュリティ分類ず手
順 1 で刀定された情報システムの圱響床に基づいお遞択される。
情報システム及び組織向けに、共同䜓党䜓の専甚セキュリティ察策を策定する必芁から、オ
ヌバヌレむ抂念が導入されおいる。オヌバヌレむは、完党に特化したセキュリティ察策、管
理拡匵及び補足ガむダンスで、NIST SP 800-53 に蚘茉されおいるセキュリティ察策ベヌスラ
むン甚ガむダンスから生じたものである。
䞀般にオヌバヌレむは、共通的な環境、状況・状態に緊密に察応した䞀連の制埡・制埡拡匵を
遞択するこずで、組織によるその堎しのぎのベヌスラむン調敎の必芁性を枛らすこずが目的で
ある。ただしオヌバヌレむを利甚しおも、組織固有の必芁・前提・制玄に察応するため、それ
以䞊の調敎が党く䞍芁になるわけではない぀たりオヌバヌレむは調敎可胜。オヌバヌレむ
の䜜成に぀いおは、SP 800-53 のセクション 3.3 ず付録 I を参照のこず。
付録 G には、付録 G には、䜎・䞭・高圱響床 ICS に調敎枈みベヌスラむンを瀺した、該圓する
NIST SP 800-53 制埡の固有オヌバヌレむが含たれおいる。 これら調敎枈みベヌスラむンは、
責任者が固有の ICS に適甚可胜な圓初の仕様曞及び掚奚事項ずしお利甚できる。前述の通り、
オヌバヌレむを利甚しおも、組織固有の必芁・前提・制玄に察応するため、それ以䞊の調敎を
加えお、制埡・制埡拡匵の远加・削陀を行うような調敎が党く䞍芁になるわけではない぀た
りオヌバヌレむは調敎可胜。

136

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Additionally, ICS owners can take advantage of the ability to tailor the initial baselines presented in the
Appendix G— Overlay when it is not possible or feasible to implement specific security controls contained
in the baselines. However, all tailoring activity should, as its primary goal, focus on meeting the intent of
the original security controls whenever possible or feasible. For example, in situations where the ICS
cannot support, or the organization determines it is not advisable to implement particular security controls
or control enhancements in an ICS (e.g., performance, safety, or reliability are adversely impacted), the
organization provides a complete and convincing rationale for how the selected compensating controls
provide an equivalent security capability or level of protection for the ICS and why the related baseline
security controls could not be employed. If the ICS cannot support the use of automated mechanisms, the
organization employs non-automated mechanisms or procedures as compensating controls in accordance
with the general tailoring guidance in Section 3.3 of NIST SP 800-53. Compensating controls are not
exceptions or waivers to the baseline controls; rather, they are alternative safeguards and countermeasures
employed within the ICS that accomplish the intent of the original security controls that could not be
effectively employed. Organizational decisions on the use of compensating controls are documented in the
security plan for the ICS.

6.1.3 Step 3: Implement Security Controls
This activity involves the implementation of security controls in new or legacy information systems. The
security control selection process described in this section can be applied to ICS from two different
perspectives: (i) new development; and (ii) legacy.
For new development systems, the security control selection process is applied from a requirements
definition perspective since the systems do not yet exist and organizations are conducting initial security
categorizations. The security controls included in the security plans for the information systems serve as a
security specification and are expected to be incorporated into the systems during the development and
implementation phases of the system development life cycle.
In contrast, for legacy information systems, the security control selection process is applied from a gap
analysis perspective when organizations are anticipating significant changes to the systems (e.g., during
major upgrades, modifications, or outsourcing). Since the information systems already exist, organizations
in all likelihood have completed the security categorization and security control selection processes
resulting in the establishment of previously agreed-upon security controls in the respective security plans
and the implementation of those controls within the information systems.

6.1.4 Step 4: Assess Security Controls
This activity determines the extent to which the security controls in the information system are effective in
their application. NIST SP 800-53A provides guidance for assessing security controls initially selected
from NIST SP 800-53 to ensure that they are implemented correctly, operating as intended, and producing
the desired outcome with respect to meeting the security requirements of the system. To accomplish this,
NIST SP 800-53A provides expectations based on assurance requirements defined in NIST SP 800-53 for
characterizing the expectations of security assessments by FIPS 199 impact level.

6.1.5 Step 5: Authorize Information System
This activity results in a management decision to authorize the operation of an information system and to
explicitly accept the risk to agency operations, agency assets, or individuals based on the implementation of
an agreed-upon set of security controls.

137

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

たた ICS 所有者は、ベヌスラむンに含たれる特定のセキュリティ察策の実斜が䞍可胜の堎合、付
録 G のオヌバヌレむに瀺される圓初ベヌスラむンの調敎機胜を利甚するこずができる。ただし党
おの調敎掻動はその䞻たる目暙ずしお、可胜な堎合には必ず元々のセキュリティ察策の意図に埓
うようにすべきである。䟋えば、ICS が察応しおいない堎合、又は特定のセキュリティ察策や管
理拡匵を ICS で実斜するのが埗策でないず刀断する堎合パフォヌマンス、安党性、信頌性が䜎
䞋するなど、組織は、代わりに遞んだ管理策がどのように ICS に同等のセキュリティ胜力や保
護レベルを発揮するか、なぜベヌスラむンセキュリティ察策を採甚できないかに぀いお、十分玍
埗のいく根拠を瀺す。ICS が自動メカニズムの䜿甚に察応しおいない堎合、NIST SP 800-53 セク
ション 3.3.の䞀般的調敎ガむダンスに埓い、組織は非自動メカニズムや手順を代替管理ずしお採
甚する。
代替管理はベヌスラむン管理の䟋倖や攟棄ではなく、代替の安党策及び察策ずしお ICS 内で採
甚され、有効利甚できない元々のセキュリティ察策の目的を果たす。代替管理を利甚する組織
の決定は、ICS のセキュリティ蚈画曞に蚘録する。

6.1.3 手順 3セキュリティ察策の実装
この掻動は、セキュリティ察策を新芏又はレガシヌ情報システムに実装するこずが関係する。
このセクションで説明するセキュリティ察策遞定プロセスは、1新芏開発、2レガシヌ
ずいう 2 ぀の芳点から ICS に適甚するこずができる。
新芏開発システムでは、セキュリティ察策遞定プロセスは、システムはただ存圚しおおらず、
組織は最初のセキュリティ分類を実斜し぀぀あるため、芁件定矩の芳点から適甚される。情報
システムのセキュリティ蚈画曞に含たれたセキュリティ察策は、セキュリティ仕様曞ずなるも
ので、システム開発ラむフサむクル段階で、システムに組み蟌たれるこずが期埅される。
察照的にレガシヌ情報システムでは、セキュリティ察策の遞定プロセスは、組織がかなりの
システム倉曎を予期する堎合倧がかりな曎新、倉曎、倖泚等、栌差分析の芳点から適甚
される。情報システムは既に存圚しおいるため組織はあらゆる蓋然性においおセキュリティ
の分類ずセキュリティ察策遞定プロセスを実斜枈みであり、各セキュリティ蚈画曞の䞭で合
意枈みのセキュリティ察策が策定され、それらが情報システムで実装されおいる。

6.1.4 手順 4セキュリティ察策の評䟡
この掻動は、情報システム䞭のセキュリティ察策が、それぞれの甚途においおどれほど有効で
あるかを刀定する。NIST SP 800-53A では、セキュリティ察策を適正に実装し、予定どおりに
動䜜させ、システムのセキュリティ芁件にかなった所期の結果を埗るため、NIST SP 800-53 か
ら遞んだセキュリティ察策を評䟡するためのガむダンスが瀺されおいる。これを実珟するため、
NIST SP 800-53A には、FIPS199 の圱響レベルに埓ったセキュリティ評䟡予想を特城付ける、
NIST SP 800-53 で定矩された保蚌芁件に基づいた期埅に぀いお蚘述されおいる。

6.1.5 手順 5情報システムの蚱可
この掻動の結果が経営陣の決定ずなり、情報システムの皌働を蚱可し、合意されたセキュリテ
ィ察策の実装を基調ずしお、組織業務・資産・人員ぞのリスクを明瀺的に受け入れるこずにな
る。

138

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.1.6 Step 6: Monitor Security Controls
This activity continuously tracks changes to the information system that may affect security controls and
assesses control effectiveness. NIST SP 800-137 provides guidance on information security continuous
monitoring [21].

6.2 Guidance on the Application of Security Controls to ICS
Because today’s ICS are often a combination of legacy systems, often with a planned life span of twenty to
thirty years, or a hybrid of legacy systems augmented with newer hardware and software that are
interconnected to other systems, it is often difficult or infeasible to apply some of the security controls
contained in NIST SP 800-53. While many controls in Appendix F of NIST SP 800-53 are applicable to
ICS as written, several controls did require ICS-specific interpretation and/or augmentation. Appendix I of
NIST SP 800-53 provides an example overlay template and additional information on each section of the
overlay.
The NIST SP 800-53 controls are organized into 18 families; each family contains security controls related
to the general security topic of the family. Security controls may involve aspects of policy, oversight,
supervision, manual processes, actions by individuals, or automated mechanisms implemented by
information systems/devices. The 18 security-related areas discussed in the following sections are:


Access Control (AC): the process of granting or denying specific requests for obtaining and using
information and related information processing services for physical access to areas within the
information system environment.



Awareness and Training (AT): policies and procedures to ensure that all information system users
are given appropriate security training relative to their usage of the system and that accurate training
records are maintained.



Audit and Accountability (AU): independent review and examination of records and activities to
assess the adequacy of system controls, to ensure compliance with established policies and operational
procedures, and to recommend necessary changes in controls, policies, or procedures.



Security Assessment and Authorization (CA): assurance that the specified controls are implemented
correctly, operating as intended, and producing the desired outcome.



Contingency Planning (CP): policies and procedures designed to maintain or restore business
operations, including computer operations, possibly at an alternate location, in the event of
emergencies, system failures, or disaster.



Configuration Management (CM): policies and procedures for controlling modifications to
hardware, firmware, software, and documentation to ensure the information system is protected
against improper modifications prior to, during, and after system implementation.



Identification and Authentication (IA): the process of verifying the identity of a user, process, or
device, through the use of specific credentials (e.g., passwords, tokens, biometrics), as a prerequisite
for granting access to resources in an IT system.



Incident Response (IR): policies and procedures pertaining to incident response training, testing,
handling, monitoring, reporting, and support services.



Maintenance (MA): policies and procedures to manage all maintenance aspects of an information
system.

139

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.1.6 手順 6セキュリティ察策の監芖
この掻動は、セキュリティ察策に圱響する情報システムの倉曎を远跡し、管理の効果性を評
䟡する。NIST SP 800-137 に、情報セキュリティの垞続監芖に係るガむダンスがある[21]。

6.2

ICS ぞのセキュリティ察策の適甚に係るガむダンス

今日の ICS は、予想寿呜が 2030 幎のレガシヌシステム、他のシステムぞ連接された比范的
新しいハヌドり゚ア/゜フトり゚アで匷化されたレガシヌシステムを䜵甚しおいるため、NIST
SP 800-53 のセキュリティ察策を適甚するのは困難又は䞍可胜な堎合が倚い。NIST SP 800-53
の付録 F に蚘茉される管理策の倚くは、蚘述どおり ICS に適甚可胜ではあるが、ICS 特有の解
釈や補匷が必芁なものも少なくない。NIST SP 800-53 の付録 I には、オヌバヌレむテンプレ
ヌトの䟋や、オヌバヌレむの各セクションに関する補足情報もある。
NIST SP 800-53 の管理策は 18 の分野にたずめられ、各分野はそれぞれの党般的セキュリティ
テヌマに関係したセキュリティ察策に぀いお取り䞊げおいる。セキュリティ察策にはポリシヌ、
指導、監督、手動プロセス、個人の行動、情報システム/デバむスが実装する自動メカニズム
の様盞が含たれよう。続くセクションで説明する 18 のセキュリティ関連分野は以䞋のずおり。

 アクセス制埡AC情報システム環境䞭の゚リアに物理的にアクセスしお、情報及び関
連情報凊理サヌビスを取埗・利甚するための明瀺的芁求を蚱可するか拒絶するかずいうプロ
セス。
 意識及び蚓緎AT党おの情報システムナヌザがシステム利甚に関する適正なセキュリ
ティ蚓緎を受け、正確な蚓緎蚘録を保持するためのポリシヌ及び手順。
 監査及び説明責任AUシステム制埡の劥圓性を評䟡し、芏定のポリシヌ及び業務手順
を遵守させ、制埡・ポリシヌ・手順に必芁な倉曎を掚奚するための蚘録及び掻動に察する独
立の審査・怜蚌。
 セキュリティ評䟡及び暩限付䞎CA指定の制埡を予定どおり正しく実行し、所期の結
果を埗るための保蚌。
 䞍枬事態蚈画CP緊急時・システム障害時・灜害時に代替地などでコンピュヌタを操
䜜するなど、業務を維持・埩旧するためのポリシヌ及び手順。
 構成管理CMハヌドり゚ア・ファヌムり゚ア・゜フトり゚ア・文曞ぞの倉曎を管理し、
システム実装前・䞭・埌の䞍適切な改倉から情報システムを保護するためのポリシヌ及び手
順。
 識別及び認蚌IAIT システム䞭のリ゜ヌスぞのアクセス蚱可の前提ずしお、特定の認
蚌情報パスワヌド、トヌクン、バむオメトリクス等によるナヌザ・プロセス・デバむス
の ID を怜蚌するプロセス。
 むンシデント察応IRむンシデント察応蚓緎・詊隓・凊理・監芖・報告・支揎サヌビス
に係るポリシヌ及び手順。
 保守MA情報システムのあらゆる保守面を管理するためのポリシヌ及び手順。

140

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Media Protection (MP): policies and procedures to ensure secure handling of media. Controls cover
access, labeling, storage, transport, sanitization, destruction, and disposal.



Physical and Environmental Protection (PE): policies and procedures addressing physical,
transmission, and display access control as well as environmental controls for conditioning (e.g.,
temperature, humidity) and emergency provisions (e.g., shutdown, power, lighting, fire protection).



Planning (PL): development and maintenance of a plan to address information system security by
performing assessments, specifying and implementing security controls, assigning security levels, and
responding to incidents.



Personnel Security (PS): policies and procedures for personnel position categorization, screening,
transfer, penalty, and termination; also addresses third-party personnel security.



Risk Assessment (RA): the process of identifying risks to operations, assets, or individuals by
determining the probability of occurrence, the resulting impact, and additional security controls that
would mitigate this impact.



System and Services Acquisition (SA): allocation of resources for information system security to be
maintained throughout the systems life cycle and the development of acquisition policies based on risk
assessment results including requirements, design criteria, test procedures, and associated
documentation.



System and Communications Protection (SC): mechanisms for protecting both system and data
transmission components.



System and Information Integrity (SI): policies and procedures to protect information systems and
their data from design flaws and data modification using functionality verification, data integrity
checking, intrusion detection, malicious code detection, and security alert and advisory controls.



Program Management (PM): provides security controls at the organizational rather than the
information-system level.

Additionally, Appendix J of NIST SP 800-53 Rev. 4 includes a catalog of Privacy Controls. Privacy
controls are the administrative, technical, and physical safeguards employed within organizations to protect
and ensure the proper handling of personally identifiable information (PII). 35 The 8 privacy control families
are each aligned with the Fair Information Practice Principles (FIPPS), 36 which are designed to build public
trust in an organization’s privacy practices and to help organizations avoid tangible costs and intangible
damages stemming from privacy incidents.

35

36

OMB Memorandum 07-16 defines PII as “information which can be used to distinguish or trace an individual’s
identity such as their name, social security number, biometric records, etc., alone, or when combined with
other personal or identifying information which is linked or linkable to a specific individual, such as date
and place of birth, mother’s maiden name, etc.” [86]. OMB Memorandum 10-22 reaffirmed this definition [87].
NIST Special Publication 800-122 defines PII as “any information about an individual [that is] maintained
by an agency, including: (i) any information that can be used to distinguish or trace an individual‘s
identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric
records; and (ii) any other information that is linked or linkable to an individual, such as medical,
educational, financial, and employment information” [88].
The FIPPs are widely accepted in the United States and internationally as a general framework for privacy
and are reflected in other federal and international laws and policies. In a number of organizations, FIPPs
serve as the basis for analyzing privacy risks and determining appropriate mitigation strategies. The
Federal Enterprise Architecture Security and Privacy Profile (FEA-SPP) also provided information and
materials in development of the privacy controls [89].

141

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 メデむア保護MPメデむアのセキュアな取扱いを行うためのポリシヌ及び手順。管理
策は、アクセス・ラベル・ストレヌゞ・茞送・サニタむズ・砎棄・廃棄を察象ずする。
 物理環境䞊の保護PE調節枩床、湿床等及び緊急装眮切断、電力、照明、防火
等の物理的、送信、衚瀺アクセス制埡及び環境制埡に関するポリシヌ及び手順。
 プランニングPL。評䟡の実斜、セキュリティ管理の指定・実斜、セキュリティレベル
の割圓及びむンシデント察応による、情報システムセキュリティに関する蚈画曞の䜜成・維
持。
 人員のセキュリティPS人員の配眮分類、遞抜、転属、眰則及び終了に関するポリシヌ
及び手順で、サヌドパヌティ職員のセキュリティも含める。
 リスク評䟡RA発生確率、その圱響、圱響を緩和するための付加的セキュリティ察策
の刀定を通じた業務・資産・人員に察するリスク識別プロセス。
 システム及びサヌビスの取埗SAシステムのラむフサむクル期間を通じお維持すべき
情報システムセキュリティに察するリ゜ヌス割圓ず、芁件・蚭蚈基準・詊隓手順・関連文曞
を含めたリスク評䟡結果に基づく取埗ポリシヌ策定。
 システム及び通信保護SCシステムずデヌタ送信コンポヌネントずを保護するための
メカニズム。
 システム及び情報の保党SI機胜怜蚌・デヌタ保党チェック・䟵入怜知・悪質コヌド怜
知・セキュリティアラヌト勧告管理を䜿甚し、蚭蚈の欠陥やデヌタ改倉から情報システムや
デヌタを保護するためのポリシヌ及び手順。
 プログラム管理PM情報システムレベルではなく組織レベルでのセキュリティ察策を
行う。
以䞊に加えお、NIST SP 800-53 改蚂第 4 版の付録 J にはプラむバシヌ管理策のカタログが掲茉さ
れおいる。プラむバシヌ管理策は、個人を特定可胜な情報PIIに察する保護ず適正な取扱を
確保するために組織内で採甚される管理䞊の技術的・物理的安党察策である。 37プラむバシヌ管
理の 8 分野がそれぞれ公正情報芏範原則FIPPSに敎合しおおり、 38組織のプラむバシヌ芏範
に察する囜民の信頌を醞成し、プラむバシヌむンシデントから生じる有圢の経費や無圢の損害の
回避を目指しおいる。

37

38

OMB 芚曞 07-16 は PII を「氏名、瀟䌚保障番号、バむオメトリック蚘録等を単独で、又は誕生日、出生地、
母芪の旧姓等特定の個人に結び぀くか結び぀けられるその他の個人若しくはは身分情報ず組み合わせお、個
人の身分を刀別又は远跡できる情報」ず定矩しおいる[86]。OMB 芚曞 10-22 はこの定矩を远認しおいる[87]。
NIST SP800-122 は PII を「ある機関が保持しおいる個人に関する情報で、1氏名、瀟䌚保障番号、誕
生日、出生地、母芪の旧姓、バむオメトリック蚘録等、個人の身分を刀別又は远跡できる情報及び2医
療、教育、財政、就業情報等、個人に結び぀くか結び぀けられるその他の情報」ず定矩しおいる[88]。
FIPPs は、䞀般的なプラむバシヌ基盀ずしお、米囜でも䞖界的にも広く受け入れられおおり、他の連邊及び
䞖界的法埋やポリシヌに反映されおいる。FIPPs は、倚くの組織でプラむバシヌリスクの分析や適切な緩和
策刀定時の根拠ずなっおいる。連邊䌁業アヌキテクチャセキュリティプラむバシヌプロファむルFEASPPにもプラむバシヌ管理を策定するための情報や資料が瀺されおいる[89]。

142

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Sections 6.2.1 through 6.2.19 introduce each of the SP 800-53 control families and privacy controls,
provide background information on the control family, as well as any ICS guidance and implementation
considerations for ICS owners. ICS-specific recommendations and guidance, if available, is provided in an
outlined box for each section. Much of the ICS-specific guidance was derived from ISA-62443 [34] and the
EPRI report: Supervisory Control and Data Acquisition (SCADA) Systems Security Guide [62].

6.2.1 Access Control
The security controls that fall within the NIST SP 800-53 Access Control (AC) family provide policies and
procedures for specifying the use of system resources by only authorized users, programs, processes, or
other systems. This family specifies controls for managing information system accounts, including
establishing, activating, modifying, reviewing, disabling, and removing accounts. Controls cover access
and flow enforcement issues such as separation of duties, least privilege, unsuccessful login attempts,
system use notification, previous logon notification, concurrent session control, session lock, and session
termination. There are also controls to address the use of portable and remote devices and personally owned
information systems to access the information system as well as the use of remote access capabilities and
the implementation of wireless technologies. Access can take several forms, including viewing, using, and
altering specific data or device functions.
Supplemental guidance for the AC controls can be found in the following documents:


NIST SP 800-63 provides guidance on remote electronic authentication [53].



NIST SP 800-48 provides guidance on wireless network security with particular emphasis on the IEEE
802.11b and Bluetooth standards 0.



NIST SP 800-97 provides guidance on IEEE 802.11i wireless network security [64].



FIPS 201 provides requirements for the personal identity verification of federal employees and
contractors [65].



NIST SP 800-96 provides guidance on PIV card to reader interoperability [66].



NIST SP 800-73 provides guidance on interfaces for personal identity verification [49].



NIST SP 800-76 provides guidance on biometrics for personal identity verification [50].



NIST SP 800-78 provides guidance on cryptographic algorithms and key sizes for personal identity
verification [67].

If the new federal Personal Identity Verification (PIV) is used as an identification token, the access control
system should conform to the requirements of FIPS 201 and NIST SP 800-73 and employ either
cryptographic verification or biometric verification. When token-based access control employs
cryptographic verification, the access control system should conform to the requirements of NIST SP 80078. When token-based access control employs biometric verification, the access control system should
conform to the requirements of NIST SP 800-76.
Access control technologies are filter and blocking technologies designed to direct and regulate the flow of
information between devices or systems once authorization has been determined. The following sections
present several access control technologies and their use with ICS.

143

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

セクション 6.2.16.2.19 では、SP 800-53 のそれぞれの管理分野ずプラむバシヌ管理が瀺され、
制埡分野の背景情報のほか、ICS 所有者向けの ICS ガむダンスず実装䞊の考慮事項が説明されお
いる。ICS 固有の掚奚事項ずガむダンスが利甚可胜な堎合は、各セクションの囲みに瀺される。
ICS 固有のガむダンスは倧半が ISA-62443 [34]ず EPRI 報告曞『SCADA システムセキュリティガ
むド』[62]を基にしおいる。

6.2.1 アクセス制埡
NIST SP 800-53 のアクセス制埡ACファミリに関するセキュリティ察策には、蚱可されたナ
ヌザ、プログラム、プロセスその他システムのみによるシステムリ゜ヌスの利甚に぀いお芏定
するためのポリシヌ及び手順が瀺されおいる。このファミリは、アカりントの蚭定・䜿甚開
始・倉曎・芋盎し・䜿甚犁止・削陀等、情報システムのアカりントを管理するための方法を芏
定する。管理策は、任務の切り分け、最䜎特暩、ログむンの倱敗、システム利甚通知、以前の
ログオン通知、䞊行セッション管理、セッションロック、セッション終了等、アクセスずフロ
ヌの実行問題を網矅しおいる。たたポヌタブルデバむス、遠隔デバむス及び個人保有の情報シ
ステムによる情報システムぞのアクセスのほか、リモヌトアクセス機胜やワむダレス技術の実
装に関する管理策も取り䞊げおいる。アクセスには閲芧、䜿甚、特定デヌタやデバむス機胜の
倉曎ずいったいく぀かの圢態がある。
AC 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-63遠隔電子認蚌に係るガむダンス[53]
 NIST SP 800-48IEEE 802.11b 及び Bluetooth 芏栌 0 を重点ずしたワむダレスネットワヌクセ
キュリティに係るガむダンス
 NIST SP 800-97IEEE 802.11i ワむダレスネットワヌクセキュリティに係るガむダンス[64]
 FIPS 201連邊職員及び契玄埓業員の個人身元確認に係る芁件[65]
 NIST SP 800-96PIV カヌドずリヌダヌの盞互運甚に係るガむダンス[66]
 NIST SP 800-73個人身元確認むンタフェヌスに係るガむダンス[49]
 NIST SP 800-76個人身元確認バむオメトリクスに係るガむダンス[50]
 NIST SP 800-78個人身元確認の暗号アルゎリズム及びキヌサむズに係るガむダンス[67]
新しい連邊個人身元確認PIVを識別トヌクンずしお䜿甚しおいる堎合、アクセス制埡シス
テムは FIPS 201 及び NIST SP 800-73 の芁件に埓い、暗号確認又はバむオメトリック確認を
採甚すべきである。トヌクンベヌスのアクセス制埡が暗号確認を採甚しおいる堎合、アクセ
ス制埡システムは NIST SP 800-78 の芁件に埓うべきである。トヌクンベヌスのアクセス制埡
がバむオメトリック確認を採甚しおいる堎合、アクセス制埡システムは NIST SP 800-76 の芁
件に埓うべきである。
アクセス制埡技術は、暩限付䞎の確定埌に、デバむス間又はシステム間での情報の流れを芏
制するためのフィルタずブロック技術である。続くセクションでは、いく぀かのアクセス制
埡技術ず ICS での䜿甚に぀いお瀺す。

144

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.1.1 Role-based Access Control (RBAC)
RBAC is a technology that has the potential to reduce the complexity and cost of security administration in
networks with large numbers of intelligent devices. Under RBAC, security administration is simplified
through the use of roles, hierarchies, and constraints to organize user access levels. RBAC reduces costs
within an organization because it accepts that employees change roles and responsibilities more frequently
than the duties within roles and responsibilities.
ICS-specific Recommendations and Guidance
RBAC can be used to provide a uniform means to manage access to ICS devices while reducing the cost of
maintaining individual device access levels and minimizing errors. RBAC should be used to restrict ICS
user privileges to only those that are required to perform each person’s job (i.e., configuring each role
based on the principle of least privilege). The level of access can take several forms, including viewing,
using, and altering specific ICS data or device functions.
RBAC tools can set, modify, or remove authorizations in applications, but they do not replace the
authorization mechanism; they do not check and authenticate users every time a user wants to access an
application. RBAC tools offer interfaces to authorization mechanisms for most current platforms in the IT
arena. However, legacy ICS systems or specialized ICS equipment may require development of specialized
interface software. This issue is a large problem for ICS that use a number of proprietary operating systems
or customized operating system implementations and interfaces.

145

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.1.1 圹割に基づくアクセス制埡RBAC
RBAC は、倚数のむンテリゞェンスデバむスを䜿甚したネットワヌクの耇雑さずセキュリティ
察策コストを枛らせる技術である。RBAC の䞋では、圹割、階局及びナヌザアクセスレベル管
理の制玄を利甚しお、セキュリティ察策が簡玠化される。RBAC では、埓業員の圹割・責任内
での任務倉曎よりも、圹割・責任の倉曎をより頻繁に受け入れるので、組織内のコストが枛
る。
ICS 固有の掚奚事項及びガむダンス
RBAC を利甚すれば、個々のデバむスアクセスレベルの維持に芁するコストを枛らし、゚ラヌを
最小限に抑え぀぀、ICS デバむスぞの䞀様のアクセス管理手段を提䟛できる。ICS ナヌザ暩限の
付䞎を業務䞊必芁ずする人員に限定するために RBAC を利甚すべきである最小暩限原則に基づ
く圹割構成。アクセスレベルには閲芧、䜿甚、特定 ICS デヌタやデバむス機胜の倉曎ずいった
いく぀かの圢態がある。
RBAC ツヌルは、アプリケヌションにおける暩限付䞎を蚭定・倉曎・削陀できるが、暩限付䞎メ
カニズムの代行はしない。぀たり、ナヌザがアプリケヌションぞのアクセスを求めるたびに、チ
ェックや認蚌を行うこずはない。RBAC ツヌルは、IT 分野におけるほずんどの珟行プラットホヌ
ム向けに、暩限付䞎メカニズムのむンタフェヌスを提䟛しおいる。ただしレガシヌICS システム
や特殊 ICS 装備品には、特殊むンタフェヌス゜フトり゚アの開発が必芁ずなる堎合がある。この
問題は、倚数の独自 OS やカスタム OS の実装及びむンタフェヌスを利甚しおいる ICS で倧きな
問題ずなる。

146

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.1.2 Web Servers
Web and Internet technologies are being added to a wide variety of ICS products because they make
information more accessible and products more user-friendly and easier to configure remotely. However,
they may also add cyber risks and create new security vulnerabilities that need to be addressed.
ICS-specific Recommendations and Guidance
SCADA and historian software vendors typically provide Web servers as a product option so that users
outside the control room can access ICS information. In many cases, software components such as ActiveX
controls or Java applets must be installed or downloaded onto each client machine accessing the Web
server. Some products, such as PLCs and other control devices, are available with embedded Web, FTP,
and email servers to make them easier to configure remotely and allow them to generate email notifications
and reports when certain conditions occur. When feasible, use HTTPS rather than HTTP, use SFTP or SCP
rather than FTP, block inbound FTP and email traffic, etc. Security appliances (or gateways) are beginning
to appear with application proxies able to examine Web, FTP, and email traffic to block attacks and prevent
downloading of ActiveX® controls or Java® applets.
Unless there is substantial benefit to connecting ICSs to the Internet, the systems are best left not
connected.
6.2.1.3 Virtual Local Area Network (VLAN)
VLANs divide physical networks into smaller logical networks to increase performance, improve
manageability, and simplify network design. VLANs are achieved through configuration of Ethernet
switches. Each VLAN consists of a single broadcast domain that isolates traffic from other VLANs. Just as
replacing hubs with switches reduces collisions, using VLANs limits the broadcast traffic, as well as
allowing logical subnets to span multiple physical locations. There are two categories of VLANs:


Static, often referred to as port-based, where switch ports are assigned to a VLAN so that it is
transparent to the end user.



Dynamic, where an end device negotiates VLAN characteristics with the switch or determines the
VLAN based on the IP or hardware addresses.

Although more than one IP subnet may coexist on the same VLAN, the general recommendation is to use a
one-to-one relationship between subnets and VLANs. This practice requires the use of a router or multilayer switch to join multiple VLANs. Many routers and firewalls support tagged frames so that a single
physical interface can be used to route between multiple logical networks.
VLANs are not typically deployed to address host or network vulnerabilities in the way that firewalls or
IDS are deployed. However, when properly configured, VLANs do allow switches to enforce security
policies and segregate traffic at the Ethernet layer. Properly segmented networks can also mitigate the risks
of broadcast storms that may result from port scanning or worm activity.
Switches have been susceptible to attacks such as MAC spoofing, table overflows, and attacks against the
spanning tree protocols, depending on the device and its configuration. VLAN hopping, the ability for an
attack to inject frames to unauthorized ports, has been demonstrated using switch spoofing or doubleencapsulated frames. These attacks cannot be conducted remotely and require local physical access to the
switch. A variety of features such as MAC address filtering, port-based authentication using IEEE 802.1x,

147

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.1.2 りェブサヌバ
りェブ技術及びむンタヌネット技術は、情報ぞのアクセスが䟿利になり、ナヌザにずっお補品
が䜿いやすくなり、遠隔蚭定が容易になるため、倚皮倚様な ICS 補品に远加されるようになっ
おいる。しかしサむバヌリスクも高たり、新たなセキュリティ䞊の脆匱性が生じ、察応が必芁
ずなる。
ICS 固有の掚奚事項及びガむダンス
SCADA やヒストリアン゜フトり゚アのベンダヌは、通垞、りェブサヌバを補品オプションの 1 ぀ずしお提
䟛し、制埡宀の倖にいるナヌザが ICS 情報にアクセスできるようにしおいる。倚くの堎合、ActiveX コント
ロヌルや Java アプレットずいった゜フトり゚アコンポヌネントを、りェブサヌバにアクセスするクラむアン
トマシンにむンストヌル又はダりンロヌドしなければならない。PLC その他の制埡デバむス等の補品には、
りェブサヌバ、FTP サヌバ及び電子メヌルサヌバが組み蟌たれおおり、遠隔蚭定が容易で、特定の事態が生
じた堎合には、電子メヌル通知やレポヌトを生成できるようになっおいる。可胜であれば HTTP ではなく
HTTPS を、FTP ではなく SFTP 又は SCP を䜿甚し、着信 FTP や電子メヌルトラフィック等はブロックする。
りェブ、FTP 及び電子メヌルトラフィックを怜査しお、攻撃をブロックし、ActiveX®コントロヌルや Java®
アプレットのダりンロヌドを防止できるセキュリティ装眮又はゲヌトりェむの付いたアプリケヌション
プロキシが出始めおいる。
ICS をむンタヌネット接続するこずの盞圓の利益がないかぎり、システムを非接続ずするのが最善である。

6.2.1.3 仮想 LANVLAN
VLAN は、物理ネットワヌクをより小さな論理ネットワヌクに分割し、パフォヌマンスず管理
性を改善し、ネットワヌク蚭蚈を簡玠化する。VLAN は Ethernet スむッチの蚭定により実珟す
る。各 VLAN は、トラフィックを他の VLAN から隔離する単䞀のブロヌドキャスト領域で構成さ
れる。ハブをスむッチに代えるず競合が枛るように、VLAN を䜿甚すればブロヌドキャストト
ラフィックが制限され、論理サブネットが耇数の物理的な堎所にたたがるようにできる。VLAN
には次の 2 皮類がある。

 静的 VLANポヌトベヌスず呌ばれるこずが倚く、スむッチポヌトが VLAN に割り圓おら
れ、゚ンドナヌザに透過である。
 動的 VLAN゚ンドデバむスがスむッチず VLAN 特性に぀いおネゎシ゚ヌトするか、IP ア
ドレス又はハヌドり゚アアドレスに基づいお VLAN を刀定する。
耇数の IP サブネットが同じ VLAN 䞊に共存するが、サブネットず VLAN 間で䞀察䞀の関係を利
甚するこずが䞀般的に掚奚される。この芏範には、耇数 VLAN に荷担するためのルヌタ又はマ
ルチレむダヌスむッチが必須ずなる。ルヌタやファむアりォヌルの倚くは、タグ付きフレヌム
に察応しおおり、1 ぀の物理むンタフェヌスを利甚しお、耇数の論理ネットワヌク間で経路指
定するこずができる。
VLAN は、ファむアりォヌルや IDS ず同じような展開方法で、ホストやネットワヌクの脆匱性
に察凊するために展開されるこずはあたりない。しかし正しく蚭定するず、VLAN はスむッチ
が接続ポリシヌを斜行し、トラフィックを Ethernet 局で分離するこずができる。しっかり分
離されたネットワヌクは、ポヌトスキャニングやワヌムにより生じるブロヌドキャストストヌ
ムのリスクを緩和できる。
スむッチは、デバむスずその蚭定に応じお、MAC 停装、テヌブルオヌバヌフロヌ、スパニング
ツリヌプロトコル攻撃等の攻撃に匱い。攻撃偎がフレヌムを未蚱可ポヌトに泚入する VLAN ホッ
ピングは、スむッチ停装や二重カプセルフレヌムを䜿甚するこずが分かっおいる。このような
攻撃は遠隔操䜜ができず、スむッチぞのロヌカルの物理アクセスが必芁ずなる。MAC アドレス
フィルタリング、IEEE 802.1x を利甚したポヌトベヌスの認蚌等の倚様な機胜や、

148

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

and specific vendor recommended practices can be used to mitigate these attacks, depending on the device
and implementation.
ICS-specific Recommendations and Guidance
VLANs have been effectively deployed in ICS networks, with each automation cell assigned to a single
VLAN to limit unnecessary traffic flooding and allow network devices on the same VLAN to span multiple
switches [34].

6.2.1.4 Dial-up Modems
ICS systems have stringent reliability and availability requirements. When there is a need to troubleshoot
and repair, the technical resources may not be physically located at the control room or facility. Therefore,
ICS often use modems to enable vendors, system integrators, or control engineers maintaining the system
to dial in and diagnose, repair, configure, and perform maintenance on the network or component. While
this allows easy access for authorized personnel, if the dial-up modems are not properly secured, they can
also provide backdoor entries for unauthorized use.
Dial-up often uses remote control software that gives the remote user powerful (administrative or root)
access to the target system. Such software usually has security options that should be carefully reviewed
and configured.
ICS-specific Recommendations and Guidance
 Consider using callback systems when dial-up modems are installed in an ICS. This ensures that a
dialer is an authorized user by having the modem establish the working connection based on the
dialer’s information and a callback number stored in the ICS approved authorized user list.
 Ensure that default passwords have been changed and strong passwords are in place for each modem.
 Physically identify modems in use to the control room operators.
 Configure remote control software to use unique user names and passwords, strong authentication,
encryption if determined appropriate, and audit logs. Use of this software by remote users should be
monitored on an almost real-time frequency.
 If feasible, disconnect modems when not in use or consider automating this disconnection process by
having modems disconnect after being on for a given amount of time. It should be noted that
sometimes modem connections are part of the legal support service agreement with the vendor (e.g.,
24x7 support with 15 minute response time). Personnel should be aware that disconnecting/removing
the modems may require that contracts be renegotiated.

149

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ベンダヌが掚奚する特定の芏範を利甚しお、デバむスや実装に応じお、こうした攻撃を緩和でき
る。
ICS 固有の掚奚事項及びガむダンス
VLAN は ICS ネットワヌクに有効に展開されおおり、各オヌトメヌションセルを 1 ぀の VLAN に
割り圓おお䞍芁なトラフィックの措氎を制限し、同じ VLAN 䞊のネットワヌクデバむスが耇数
スむッチにたたがるようにしおいる[34]。
6.2.1.4 ダむアルアップモデム
ICS システムの信頌性及び可甚性には厳栌な芁件が課される。トラブルシュヌティングや修理
が必芁ずなる堎合、制埡宀や制埡斜蚭に技術リ゜ヌスが物理的に存圚しないこずもある。
よっお ICS では、システム保守を担圓するベンダヌ、システムむンテグレヌタ又は制埡゚ン
ゞニアがモデムを䜿甚しおダむアルむンし、ネットワヌクや構成の蚺断、修理、蚭定及び保
守を行えるようにするこずが倚い。そうするこずで暩限を䞎えられた職員のアクセスが容易
になる反面、ダむアルアップモデムのセキュリティがしっかり確保されおいないず、䞍正䜿
甚をもくろむバックドア䟵入を蚱すこずにもなりかねない。
ダむアルアップでは、遠隔ナヌザに目暙システムぞの䞊䜍管理者又は rootアクセス暩を䞎
える遠隔制埡゜フトり゚アを䜿甚するこずが倚い。通垞このような゜フトり゚アには、慎重に
粟査しお蚭定すべきセキュリティオプションが付いおいる。
ICS 固有の掚奚事項及びガむダンス

 ICS にダむアルアップモデムが蚭眮されおいる堎合、コヌルバックシステムの利甚を怜蚎す
る。これを利甚するず、モデムは ICS が認可した認定ナヌザリストに保存されおいる発呌
者情報ずコヌルバック番号を基に有効な接続を確立するため、発呌者は確実に認定ナヌザず
なる。
 モデムごずに必ずデフォルトのパスワヌドを倉曎し、匷力なパスワヌドを蚭定する。
 䜿甚䞭の各モデムが制埡宀オペレヌタに物理的に識別できるようにする。
 遠隔制埡゜フトり゚アを蚭定し、䞀意のナヌザ名ずパスワヌド、匷力な認蚌、必芁であれば
暗号化、監査ログを䜿甚できるようにする。遠隔ナヌザによる本゜フトり゚アの䜿甚を、ほ
がリアルタむムで監芖すべきである。
 可胜であれば䞍䜿甚時にはモデムを切断するか、䞀定時間オンになっおいる堎合にはオフに
するような切断プロセスの自動化を怜蚎する。モデム接続は、ベンダヌずの法的なサポヌト
サヌビス契玄の䞀郚に含たれおいる堎合もある点を銘蚘すべきである15 分察応での幎䞭
無䌑サポヌトなど。職員は、モデムの切断や撀去を行うには、契玄䞊協議が必芁ずなるこ
ずを認識すべきである。

150

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.1.5 Wireless
The use of wireless within an ICS is a risk-based decision that has to be determined by the organization.
Generally, wireless LANs should only be deployed where health, safety, environmental, and financial
implications are low. NIST SP 800-48 and SP 800-97 provide guidance on wireless network security.

ICS-specific Recommendations and Guidance
Wireless LANs

 Prior to installation, a wireless survey should be performed to determine antenna location and strength
to minimize exposure of the wireless network. The survey should take into account the fact that
attackers can use powerful directional antennas, which extend the effective range of a wireless LAN
beyond the expected standard range. Faraday cages and other methods are also available to minimize
exposure of the wireless network outside of the designated areas.

 Wireless users’ access should utilize IEEE 802.1x authentication using a secure authentication
protocol (e.g., Extensible Authentication Protocol [EAP] with TLS [EAP-TLS]) that authenticates
users via a user certificates or a Remote Authentication Dial In User Service (RADIUS) server.

 The wireless access points and data servers for wireless worker devices should be located on an
isolated network with documented and minimal (single if possible) connections to the ICS network.

 Wireless access points should be configured to have a unique service set identifier (SSID), disable
SSID broadcast, and enable MAC filtering at a minimum.

 Wireless devices, if being utilized in a Microsoft Windows ICS network, should be configured into a
separate organizational unit of the Windows domain.

 Wireless device communications should be encrypted and integrity-protected. The encryption must
not degrade the operational performance of the end device. Encryption at OSI Layer 2 should be
considered, rather than at Layer 3 to reduce encryption latency. The use of hardware accelerators to
perform cryptographic functions should also be considered.
For mesh networks, consider the use of broadcast key versus public key management implemented at OSI
Layer 2 to maximize performance. Asymmetric cryptography should be used to perform administrative
functions, and symmetric encryption should be used to secure each data stream as well as network control
traffic. An adaptive routing protocol should be considered if the devices are to be used for wireless
mobility. The convergence time of the network should be as fast as possible supporting rapid network
recovery in the event of a failure or power loss. The use of a mesh network may provide fault tolerance thru
alternate route selection and pre-emptive fail-over of the network.
Wireless field networks
The ISA100 39 Committee is working to establish standards, recommended practices, technical reports, and
related information that will define procedures for implementing wireless systems in the automation and
control environment with a focus on the field level (e.g., IEEE 802.15.4). Guidance is directed towards
those responsible for the complete life cycle including the designing, implementing, on-going maintenance,
scalability or managing industrial automation and control systems, and applies to users, system integrators,
practitioners, and control systems manufacturers and vendors.

39

Additional information on ISA100 at: http://www.isa.org/isa100.

151

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.1.5 ワむダレス
ICS 内でのワむダレスの利甚は、リスクに基づく決定事項であり、組織が決定しなければならな
い。䞀般にワむダレス LAN は、健康・安党・環境・財政䞊の制玄が少ない堎合にのみ展開すべ
きである。NIST SP 800-48 及び SP 800-97 には、ワむダレスネットワヌク接続に係るガむダンス
がある。
ワむダレス LAN に係る ICS 固有の掚奚事項及びガむダンス

 蚭眮前に無線状態を調査し、アンテナ䜍眮ず匷床を刀定し、ワむダレスネットワヌクの露出
床を最小限にする。攻撃偎が利甚する匷力指向性アンテナは、ワむダレス LAN の有効距離
を、暙準的な予想距離を超えお延䌞できるこずを念頭に眮いお調査を行うべきである。ファ
ラデヌ箱その他の手段も利甚しお、所期の゚リア倖にはみ出るワむダレスネットワヌクの露
出床を最小に抑える。
 ワむダレスナヌザのアクセスは、ナヌザ蚌明曞又は遠隔認蚌ダむアルむンナヌザサヌビス
RADIUSサヌバを介しおナヌザ認蚌を行う、セキュアなプロトコルTLS 付き拡匵認蚌
プロトコル[EAP-TLS]等を䜿甚した IEEE802.1x 認蚌を利甚すべきである。
 ワむダレスアクセスポむント及びワむダレスワヌカデバむス甚デヌタサヌバは、ICS ネット
ワヌク接続を最小限にしできれば 1 ぀のみ、文曞化された隔絶ネットワヌク䞊に眮くべ
きである。
 ワむダレスアクセスポむントは、サヌビスセット識別子SSIDを䞀意にし、SSID ブロヌ
ドキャストを䜿甚犁止、最小限の MAC フィルタリングを䜿甚可胜に蚭定すべきである。
 ワむダレスデバむスを Microsoft Windows ICS ネットワヌクで䜿甚する堎合、Windows 領域
の別の組織ナニットに蚭定すべきである。
 ワむダレスデバむス通信は、暗号化しお保党すべきである。暗号化により、゚ンドデバむス
の動䜜パフォヌマンスが䜎䞋しおはならない。暗号化の埅ち時間を短瞮するため、OSI レむ
ダヌ3 ではなくレむダヌ2 での暗号化を考慮すべきである。たた暗号関数を実行するハヌド
り゚ア加速噚の利甚も考慮すべきである。
メッシュネットワヌクでは、パフォヌマンスを最倧に䞊げるため、OSI レむダヌ2 に実装さ
れるブロヌドキャストキヌ察公開鍵管理の䜿甚を怜蚎する。非察称暗号を利甚しお管理機胜
を実斜し、察称暗号を利甚しお各デヌタストリヌムずネットワヌク制埡トラフィックのセキ
ュリティを確保すべきである。デバむスをワむダレス移動目的で䜿甚する堎合は、最適経路
指定プロトコルの利甚を考慮すべきである。障害時や電力喪倱時のネットワヌク回埩を早め
るため、ネットワヌクの収束時間はできるだけ短くすべきである。メッシュネットワヌクを
䜿甚するこずで、代替経路遞定ず先行的フェむルオヌバヌを通じお、フォヌルトトレランス
が埗られよう。
ワむダレスフィヌルドネットワヌク
フィヌルドレベルIEEE 802.15.4 等に特化したオヌトメヌション及び制埡環境におけるワむダ
レスシステムの手順を定めるため、ISA 100 40委員䌚は芏栌、掚奚芏範、技術レポヌト及び関連情
報の策定に向けお䜜業䞭である。産業オヌトメヌション及び制埡システムの蚭蚈、実装、保守、
スケヌラビリティ、管理等のラむフサむクル担圓者向けにガむダンスが提瀺されおおり、ナヌ
ザ、システムむンテグレヌタ、実斜担圓者及び制埡システムのメヌカヌ/ベンダヌに適甚され
る。

40

ISA100 に関する远加情報が次の URL にある。http://www.isa.org/isa100.

152

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.2 Awareness and Training
The security controls that fall within the NIST SP 800-53 Awareness and Training (AT) family provide
policy and procedures for ensuring that all users of an information system are provided basic information
system security awareness and training materials before authorization to access the system is granted.
Personnel training must be monitored and documented.
Supplemental guidance for the AT controls can be found in the following documents:


NIST SP 800-50 provides guidance on security awareness training [61].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
For the ICS environment, this must include control system-specific information security awareness and
training for specific ICS applications. In addition, an organization must identify, document, and train all
personnel having significant ICS roles and responsibilities. Awareness and training must cover the physical
process being controlled as well as the ICS.
Security awareness is a critical part of ICS incident prevention, particularly when it comes to social
engineering threats. Social engineering is a technique used to manipulate individuals into giving away
private information, such as passwords. This information can then be used to compromise otherwise secure
systems.
Implementing an ICS security program may bring changes to the way in which personnel access computer
programs, applications, and the computer desktop itself. Organizations should design effective training
programs and communication vehicles to help employees understand why new access and control methods
are required, ideas they can use to reduce risks, and the impact on the organization if control methods are
not incorporated. Training programs also demonstrate management’s commitment to, and the value of, a
cybersecurity program. Feedback from staff exposed to this type of training can be a valuable source of
input for refining the charter and scope of the security program.

6.2.3 Audit and Accountability
An audit is an independent review and examination of records and activities to assess the adequacy of
system controls, to ensure compliance with established policies and operational procedures, and to
recommend necessary changes in controls, policies, or procedures. The security controls that fall within the
NIST SP 800-53 Audit and Accountability (AU) family provide policies and procedures for generating
audit records, their content, capacity, and retention requirements. The controls also provide safeguards to
react to problems such as an audit failure or audit log capacity being reached. Audit data should be
protected from modification and be designed with non-repudiation capability.
Supplemental guidance for the AU controls can be found in the following documents:


NIST SP 800-61 provides guidance on computer security incident handling and audit log retention
[59].

153

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.2 意識及び蚓緎
NIST SP 800-53 の意識及び蚓緎ATファミリに含たれるセキュリティ察策には、システムぞ
のアクセス暩限を付䞎する前に、情報システムの党ナヌザに基本的なシステムセキュリティに
察する意識・蚓緎資料が行き枡るようにするためのポリシヌ及び手順が定められおいる。
蚓緎は監芖ず文曞化が求められる。
AT 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-50セキュリティ意識蚓緎に係るガむダンス[61]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
ICS 環境では、特定の ICS 甚途に関する制埡システム固有の情報セキュリティ意識・蚓緎を含め
なければならない。たた組織は、ICS に倧きな圹割ず責任を有しおいる職員党おを特定し、蚘録
し、蚓緎しなければならない。意識・蚓緎は、制埡される物理的プロセスず ICS に぀いお取り䞊
げなければならない。
セキュリティ意識は、ICS むンシデントの予防、特に゜ヌシャル゚ンゞニアリング脅嚁に関し
お、ICS の肝芁な䞀郚である。゜ヌシャル゚ンゞニアリングずは、個人を操䜜しおパスワヌド等
の個人情報を匕き出す技術のこずである。匕き出した情報を利甚しお、システムのセキュリティ
を䜎䞋させるこずができる。
ICS セキュリティプログラムを実斜するこずで、職員によるコンピュヌタプログラム、アプリケ
ヌション及びコンピュヌタデスクトップそのものの利甚方法を倉えるこずができる。組織は効果
的な蚓緎プログラムず䌝達手段を考案しお、新たなアクセス・管理芁領が必芁な理由、リスクを
枛らすためのアむディア、管理芁領が守られない堎合の組織ぞの圱響に぀いお埓業員が理解でき
るようにすべきである。たた蚓緎プログラムでは、サむバヌセキュリティプログラムに察する経
営陣の匷い関心ず、プログラムの䟡倀を実蚌する。被蚓緎者からのフィヌドバックは、セキュリ
ティプログラムの憲章及び適甚範囲を改善するための貎重な資ずなる。

6.2.3 監査及び説明責任
監査はシステム制埡の劥圓性を評䟡し、芏定のポリシヌ及び業務手順を遵守させ、制埡・ポ
リシヌ・手順に必芁な倉曎を掚奚するための蚘録及び掻動に察する独立の審査・怜蚌である。
NIST SP 800-53 の監査及び説明責任AUファミリに含たれるセキュリティ察策では、監査
蚘録、内容、胜力及び保持芁件に係るポリシヌ及び手順を定めおいる。たた監査の䞍備や監
査蚘録胜力が限界に達した際の問題に察凊するための察策も定められおいいる。監査デヌタ
は改倉できないように保護し、吊認䞍胜のものずしお策定すべきである。
AU 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-61コンピュヌタセキュリティむンシデントの凊理及び監査蚘録の保持に係る
ガむダンス[59]

154

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



NIST SP 800-92 provides guidance on log management (including audit logs) [68].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
It is necessary to determine that the system is performing as intended. Periodic audits of the ICS should be
performed to validate the following items:


The security controls present during system validation testing (e.g., factory acceptance testing and site
acceptance testing) are still installed and operating correctly in the production system.



The production system is free from security compromises and provides information on the nature and
extent of compromises as feasible, should they occur.



The management of change program is being rigorously followed with an audit trail of reviews and
approvals for all changes.

The results from each periodic audit should be expressed in the form of performance against a set of
predefined and appropriate metrics to display security performance and security trends. Security
performance metrics should be sent to the appropriate stakeholders, along with a view of security
performance trends.
Traditionally, the primary basis for audit in IT systems has been recordkeeping. Using appropriate tools
within an ICS environment requires extensive knowledge from an IT professional familiar with the ICS,
critical production and safety implications for the facility. Many of the process control devices that are
integrated into the ICS have been installed for many years and do not have the capability to provide the
audit records described in this section. Therefore, the applicability of these more modern tools for auditing
system and network activity is dependent upon the capabilities of the components in the ICS.
The critical tasks in managing a network in an ICS environment are ensuring reliability and availability to
support safe and efficient operation. In regulated industries, regulatory compliance can add complexity to
security and authentication management, registry and installation integrity management, and all functions
that can augment an installation and operational qualification exercise. Diligent use of auditing and log
management tools can provide valuable assistance in maintaining and proving the integrity of the ICS from
installation through the system life cycle. The value of these tools in this environment can be calculated by
the effort required to re-qualify or otherwise retest the ICS where the integrity due to attack, accident, or
error is in question. The system should provide reliable, synchronized time stamps in support of the audit
tools.
Monitoring of sensors, logs, Intrusion Detection Systems (IDS), antivirus, patch management, policy
management software, and other security mechanisms should be done on a real-time basis where feasible.
A first-line monitoring service would receive alarms, do rapid initial problem determination and take action
to alert appropriate facility personnel to intervene.
System auditing utilities should be incorporated into new and existing ICS projects. These auditing utilities
should be tested (e.g., off-line on a comparable ICS) before being deployed on an operational ICS. These
tools can provide tangible records of evidence and system integrity. Additionally, active log management
utilities may actually flag an attack or event in progress and provide location and tracing information to
help respond to the incident [34].

155

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 NIST SP 800-92蚘録管理監査蚘録を含むに係るガむダンス[68]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
システムが予定どおりに皌働しおいるか刀定する必芁がある。ICS の定期的監査を行い、次の
点を怜蚌すべきである。

 システムの劥圓性怜蚌工堎の怜収及び珟堎での怜収等時にあったセキュリティ察策がそ
のたた蚭眮され、生産システムで正垞に皌働しおいる。
 生産システムにセキュリティ䞊の性胜䜎䞋がなく、性胜䜎䞋が生じた堎合には、可胜であれ
ばその性質や皋床に぀いお情報を提䟛する。
 プログラム倉曎の管理は、党おの倉曎内容の審査・承認監査蚌跡に埓っお遵守されおいる。
各定期監査の結果は、事前に定められた適正な評䟡基準に照らしお成瞟の圢で蚘茉し、セキ
ュリティパフォヌマンスずセキュリティ動向ずを瀺すべきである。セキュリティパフォヌマ
ンス評䟡基準は、セキュリティ動向に関する意芋ずずもに、関係者に送臎すべきである。
䌝統的に IT システムにおける監査の基本は、蚘録管理にあった。ICS 環境で適正なツヌルを
䜿甚するには、ICS に通じ、斜蚭に関する重芁生産・安党性の制玄を理解した IT 専門員の広
範な知芋が必芁ずなる。ICS に組み蟌たれたプロセス制埡デバむスの倚くは、䜕幎も前に蚭眮
され、このセクションで述べた監査蚘録の提䟛胜力がない。したがっお、監査システム及びネ
ットワヌク掻動甚のこれら最新ツヌルの適甚は、ICS コンポヌネントの胜力に巊右される。
ICS 環境におけるネットワヌク管理の重芁タスクは、信頌性ず可甚性を確保しお、安党で効率
的な業務を支えるこずにある。芏制を受ける業界では、芏制を遵守するこずでセキュリティ
ず認蚌管理、垳簿及び斜蚭の完党性管理、斜蚭及び業務適栌性挔習を匷化するためのあらゆ
る機胜が耇雑になる。監査・蚘録管理ツヌルを利掻甚するこずで、むンストヌルからラむフ
サむクル党般を通じお、ICS を保守し完党性を実蚌する䞊で、貎重な助けが埗られる。ICS 環
境におけるこれらツヌルの䟡倀は、攻撃・実行・過誀等により完党性が疑問芖される堎合に
必芁ずなる、適栌性の再取埗や ICS の再怜査ずいった劎力に照らしお蚈算できよう。システ
ムは監査ツヌルに察応しお、信頌性の高い同期タむムスタンプを備えおいるべきである。
センサ、ログ、䟵入怜知システムIDS、アンチりむルス、パッチ管理、ポリシヌ管理゜
フトり゚アその他のセキュリティメカニズムは、可胜であればリアルタむムで実行できるべ
きである。最前線の監芖サヌビスはアラヌムを受領し、初期の問題刀別を迅速に行い、該圓
斜蚭職員が察凊するようにアクションを起こす。
システム監査ナヌティリティを新芏及び既存 ICS プロゞェクトに組み蟌むべきである。ナヌティ
リティは、皌働䞭の ICS に展開する前に、詊隓を行うべきである同等の ICS でのオフラむン詊
隓。これらツヌルは、蚌拠及びシステムの完党性に関する有圢の蚘録を提䟛できる。たたアク
ティブログ管理ナヌティリティは、進行䞭の攻撃や事象にフラグを立お、䜍眮ず远跡情報を提䟛
しお、むンシデントぞの察応を助ける[34]。

156

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

There should be a method for tracing all console activities to a user, either manually (e.g., control
room sign in) or automatic (e.g., login at the application and/or OS layer). Policies and procedures for
what is logged, how the logs are stored (or printed), how they are protected, who has access to the logs
and how/when are they reviewed should be developed. These policies and procedures will vary with
the ICS application and platform. Legacy systems typically employ printer loggers, which are
reviewed by administrative, operational, and security staff. Logs maintained by the ICS application
may be stored at various locations and may or may not be encrypted.

6.2.4 Security Assessment and Authorization
The security controls that fall within the NIST SP 800-53 Assessment and Authorization (CA) family
provide the basis for performing periodic assessments and providing certification of the security controls
implemented in the information system to determine if the controls are implemented correctly, operating as
intended, and producing the desired outcome to meet the system security requirements. A senior
organizational official is responsible for accepting residual risk and authorizing system operation. These
steps constitute accreditation. In addition, all security controls should be monitored on an ongoing basis.
Monitoring activities include configuration management and control of information system components,
security impact analysis of changes to the system, ongoing assessment of security controls, and status
reporting.
Supplemental guidance for the CA controls can be found in the following documents:


NIST SP 800-53A provides guidance on security control assessments [23].



NIST SP 800-37 provides guidance defining the information system boundary and security
certification and accreditation of the information system [21].



NIST SP 800-100 provides guidance on information security governance and planning [27].

6.2.5 Configuration Management
Configuration management policy and procedures are used to control modifications to hardware, firmware,
software, and documentation to ensure that the information system is protected against improper
modifications prior to, during, and after system implementation. The security controls that fall within the
NIST SP 800-53 Configuration Management (CM) family provide policy and procedures for establishing
baseline controls for information systems. Controls are also specified for maintaining, monitoring, and
documenting configuration control changes. There should be restricted access to configuration settings, and
security settings of IT products should be set to the most restrictive mode consistent with ICS operational
requirements.
Supplemental guidance for the CM controls can be found in the following documents:
 NIST SP 800-70 provides guidance on configuration settings for IT products [26].



NIST SP 800-100 provides guidance on information security governance and planning [27].



NIST SP 800-128 provides guidance on implementation of a security-focused configuration
management program [80].

157

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

手動制埡宀ぞの立入眲名等又は自動アプリケヌションや OS ぞのログむン等による、あ
るナヌザの党おのコン゜ヌル掻動に察する远跡方法を持぀べきである。蚘録内容、蚘録の保管
又はプリント方法、保護芁領、蚘録ぞのアクセス件保持者、蚘録の倉曎方法・時期に関する
ポリシヌ及び手順を䜜成すべきである。ポリシヌ及び手順は、ICS の甚途及びプラットホヌムに
より異なる。レガシヌシステムではプリンタロガヌを通垞、採甚しおおり、管理、業務及びセキ
ュリティ職員が目を通しおいる。ICS アプリケヌションが維持するログは、皮々の堎所に保管さ
れ、暗号化されおいるものもあれば、されおいないものもある。

6.2.4 セキュリティ評䟡及び暩限付䞎
NIST SP 800-53 のセキュリティ評䟡及び暩限付䞎CAファミリに含たれるセキュリティ察
策は、定期的評䟡を行い、情報システムに実装されおいるセキュリティ察策の蚌明曞を亀付す
る根拠を定めおおり、これに埓い管理が適性に行われ、予定どおりに皌働し、システムセキュ
リティ芁件に合臎した結果になっおいるかどうかを刀定できる。組織の幹郚は残留リスクを受
け入れ、システムの皌働を蚱可する責任を有する。このような手順が認定を構成する。たた、
党おのセキュリティ察策は継続的に監芖すべきである。監芖掻動には情報システムコンポヌネ
ントの蚭定管理、システム倉曎のセキュリティ圱響分析、進展䞭のセキュリティ察策の評䟡及
び珟状報告が含たれる。
CA 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-53Aセキュリティ察策評䟡に係るガむダンス[23]
 NIST SP 800-37情報システム境界及び情報システムセキュリティ蚌明・認定の定矩に係る
ガむダンス[21]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
6.2.5 構成管理
構成管理ポリシヌ及び手順に埓い、ハヌドり゚ア・ファヌムり゚ア・゜フトり゚ア・文曞ぞ
の倉曎を管理し、システム実装前・䞭・埌の䞍適切な改倉から情報システムを保護する。
NIST SP 800-53 の構成管理CMファミリに含たれるセキュリティ察策には、情報システム
のベヌスラむン管理を策定するためのポリシヌ及び手順が定められおいる。構成管理の倉曎
を維持・監芖・蚘録するための管理もある。構成蚭定ぞのアクセスは制限され、IT 補品のセ
キュリティ蚭定は、ICS 業務芁件に埓い最も厳栌なモヌドに蚭定すべきである。
CM 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-70IT 補品の構成蚭定に係るガむダンス[26]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
 NIST SP 800-128 に、セキュリティ重芖構成管理プログラムに係るガむダンス[80]。

158

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS-specific Recommendations and Guidance
A formal change management program should be established and procedures used to insure that all
modifications to an ICS network meet the same security requirements as the original components identified
in the asset evaluation and the associated risk assessment and mitigation plans. Risk assessment should be
performed on all changes to the ICS network that could affect security, including configuration changes,
the addition of network components, and installation of software. Changes to policies and procedures may
also be required. The current ICS network configuration and device configurations must always be known
and documented.

6.2.6 Contingency Planning
Contingency plans are designed to maintain or restore business operations, including computer operations,
possibly at an alternate location, in the event of emergencies, system failures, or disaster. The security
controls that fall within the NIST SP 800-53 Contingency Planning (CP) family provide policies and
procedures to implement a contingency plan by specifying roles and responsibilities, and assigning
personnel and activities associated with restoring the information system after a disruption or failure. Along
with planning, controls also exist for contingency training, testing, and plan update, and for backup
information processing and storage sites.
Supplemental guidance for the CP controls can be found in the following documents:


NIST SP 800-34 provides guidance on contingency planning [52].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
Contingency plans should cover the full range of failures or problems that could be caused by cyber
incidents. Contingency plans should include procedures for restoring systems from known valid backups,
separating systems from all non-essential interferences and connections that could permit cybersecurity
intrusions, and alternatives to achieve necessary interfaces and coordination. Employees should be trained
and familiar with the contents of the contingency plans. Contingency plans should be periodically reviewed
with employees responsible for restoration of the ICS, and tested to ensure that they continue to meet their
objectives. Organizations also have business continuity plans and disaster recovery plans that are closely
related to contingency plans. Because business continuity and disaster recovery plans are particularly
important for ICS, they are described in more detail in the sections to follow.

6.2.6.1 Business Continuity Planning
Business continuity planning addresses the overall issue of maintaining or reestablishing production in the
case of an interruption. These interruptions may take the form of a natural disaster (e.g., hurricane, tornado,
earthquake, flood), an unintentional man-made event (e.g., accidental equipment damage, fire or explosion,
operator error), an intentional man-made event (e.g., attack by bomb, firearm or vandalism, attacker or
virus), or an equipment failure. From a potential outage perspective, this may involve typical time spans of
days, weeks, or months to recover from a natural disaster, or minutes or hours to recover from a malware
infection or a mechanical/electrical failure. Because there is often a separate discipline
that deals with reliability and electrical/mechanical maintenance, some organizations choose to define
business continuity in a way that excludes these sources of failure. Because business continuity also deals
primarily with
159

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS 固有の掚奚事項及びガむダンス
正芏の倉曎管理プログラムを策定し、ICS ネットワヌクぞの党おの倉曎内容が、資産評䟡蚈画
曞及び関連リスク評䟡・緩和蚈画曞に特定される圓初のコンポヌネントず同じセキュリティ
芁件に合臎するように手順を行䜿しなければならない。リスク評䟡は、セキュリティに圱響
する ICS ネットワヌクぞの党おの倉曎に察しお行うべきで、これには構成倉曎、ネットワヌ
クコンポヌネントの远加、゜フトり゚アのむンストヌルも含たれる。ポリシヌ及び手順の倉
曎も必芁ずなる。珟圚の ICS ネットワヌク構成ずデバむス構成は垞に知らされ、蚘録されお
いなければならない。

6.2.6 䞍枬事態蚈画
緊急時察応蚈画は、緊急時・システム障害時・灜害時に代替地などでコンピュヌタを操䜜す
るなど、業務を維持・埩旧するために䜜成される。 NIST SP 800-53 の䞍枬事態蚈画CPフ
ァミリに含たれるセキュリティ察策は、圹割ず責任を定め、䞭断・故障埌の情報システムの
埩旧に関連した人員・掻動を割り圓おお、䞍枬事態蚈画を実行するためのポリシヌ及び手順
を定めおいる。
プランニングのみならず、管理は、䞍枬事態察凊蚓緎、詊隓、蚈画の曎新、バックアップ情報
凊理・保管サむトに぀いおも取り䞊げおいる。
CP 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-34䞍枬事態蚈画の立案に係るガむダンス[52]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
緊急時察応蚈画は、サむバヌむンシデントにより生じ埗るあらゆる障害や問題に぀いお取り䞊げ
るべきである。緊急時察応蚈画には、既知の有効バックアップからシステムを埩旧し、サむバヌ
セキュリティ䟵入を蚱す重芁でない党おの干枉・接続からシステムを分離するためのポリシヌ及
び手順のほか、必芁なむンタフェヌス・調敎を実珟するための代替方法も含めるべきである。埓
業員は蚓緎を受け、䞍枬事態蚈画の内容に粟通しおいるべきである。蚈画曞は、ICS の埩旧担圓
者ずずもに定期的に芋盎し、垞に目的に合臎しおいるか詊隓を行うべきである。組織は、緊急時
察応蚈画ず密接な関わりを持぀事業継続蚈画曞ず灜害埩旧蚈画曞も保持する。䞡蚈画曞は特に
ICS にずっお重芁であるため、続くセクションで詳述する。
6.2.6.1 事業継続蚈画
事業継続蚈画の立案では、䞭断時の生産の維持又は再開に関する党般的な問題を取り䞊げる。
䞭断には自然灜害ハリケヌン、トルネヌド、地震、措氎等、人為的な予期しない事象偶
発的な装備品の損害、火灜・爆発、操䜜ミス等、人為的な故意の事象爆匟、銃噚・砎壊行
為による攻撃、攻撃者・りむルス等、装備品の故障などがある。操業停止の芳点からするず、
自然灜害からの埩旧には䞀般に日・週・月単䜍の期間を芁し、マルり゚ア感染や機械・電子的
故障の堎合は分・時間単䜍ずなる。

160

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

that deals with reliability and electrical/mechanical maintenance, some organizations choose to define
business continuity in a way that excludes these sources of failure. Because business continuity also deals
primarily with the long-term implications of production outages, some organizations also choose to place a
minimum interruption limit on the risks to be considered. For the purposes of ICS cybersecurity, it is
recommended that neither of these constraints be made. Long-term outages (disaster recovery) and shortterm outages (operational recovery) should both be considered. Because some of these potential
interruptions involve man-made events, it is also important to work collaboratively with the physical
security organization to understand the relative risks of these events and the physical security
countermeasures that are in place to prevent them. It is also important for the physical security organization
to understand which areas of a production site house data acquisition and control systems that might have
higher-level risks.
Before creating a business continuity plan (BCP) to deal with potential outages, it is important to specify
the recovery objectives for the various systems and subsystems involved based on typical business needs.
There are two distinct types of objectives: system recovery and data recovery. System recovery involves
the recovery of communication links and processing capabilities, and it is usually specified in terms of a
Recovery Time Objective (RTO). This is defined as the time required to recover the required
communication links and processing capabilities. Data recovery involves the recovery of data describing
production or product conditions in the past and is usually specified in terms of a Recovery Point Objective
(RPO). This is defined as the longest period of time for which an absence of data can be tolerated.
Once the recovery objectives are defined, a list of potential interruptions should be created and the recovery
procedure developed and described. For most of the smaller scale interruptions, repair and replace activities
based on a critical spares inventory will prove adequate to meet the recovery objectives. When this is not
true, contingency plans need to be developed. Due to the potential cost and importance of these
contingency plans, they should be reviewed with the managers responsible for business continuity planning
to verify that they are justified. Once the recovery procedures are documented, a schedule should be
developed to test part or all of the recovery procedures. Particular attention must be paid to the verification
of backups of system configuration data and product or production data. Examples of system configuration
data include computer configuration backups, application configuration backups, operational control limits,
control bands and setpoints for pre-incident operation for all ICS programmable equipment. Not only
should these be tested when they are produced, but the procedures followed for their storage should also be
reviewed periodically to verify that the backups are kept in environmental conditions that will not render
them unusable and that they are kept in a secure location, so they can be quickly obtained by authorized
individuals when needed.

161

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

信頌性や電気・機械の保守に関する別の芏則も倚分にあるため、組織によっおはこのような故障
原因を排陀した䞊で事業継続を定めおいるずころもある。事業継続は、䞻に長期的な操業停止の
制玄を扱うため、考慮すべきリスクに最短䞭断限界を蚭定しおいる組織もある。ICS サむバヌセ
キュリティの目的䞊、このような制玄事項は蚭けないこずが薊められる。長期操業停止灜害埩
旧ず短期操業停止業務埩旧の䞡方を怜蚎すべきである。このような䞭断には人為的な事象
も含たれるため、物理的セキュリティ組織ず連携しお、こうした事象の盞察的リスクず、それを
防止するために講じられおいる物理的セキュリティ察策に぀いお理解するこずが肝芁である。た
た物理的セキュリティ組織も、生産珟堎のどこに高リスクのデヌタ取埗・制埡システムがあるか
を把握しおおくこずが肝芁である。
操業停止を取り䞊げた事業継続蚈画曞BCPを䜜成する前に、䞀般的な事業ニヌズに基づき、
皮々のシステム・サブシステムの埩旧察象を指定するこずが肝芁である。埩旧察象はシステム
ずデヌタの 2 皮類である。システム埩旧は、通信リンクず凊理機胜の埩旧が関係し、通垞、目
暙埩旧時間RTOずしお定められおいる。これは必須通信リンク及び凊理機胜を埩旧するた
めの時間ずしお定矩される。デヌタ埩旧は、過去の生産又は補品状態を蚘述したデヌタの埩旧
が関係し、通垞、目暙埩旧時点RPOずしお定められおいる。これはデヌタがなくおも蚱容
できる最長時間ずしお定矩される。
埩旧察象を定めたなら、䞭断可胜性リストを䜜成し、埩旧手順を䜜成し蚘述すべきである。倧
抵の小芏暡䞭断では、重芁補甚品圚庫に基づく修理・亀換で埩旧察象に十分察応できる。これ
が圓おはたらない堎合には、緊急時察応蚈画を䜜成する必芁がある。緊急時察応蚈画のコスト
ず重芁性から、緊急時察応蚈画は事業継続プランニング担圓管理者ずずもに芋盎し、その劥圓
性を怜蚌すべきである。埩旧手順を文曞化したなら、埩旧手順の䞀郚又は党郚の詊隓を行うた
めのスケゞュヌルを立おるべきである。システム構成デヌタ及び補品・生産デヌタのバックア
ップ怜蚌には、特に泚意を払わなければならない。システム構成デヌタの䟋ずしお、コンピュ
ヌタ構成バックアップ、アプリケヌション構成バックアップ、業務䞊の管理限界、党おの ICS
プログラム可胜装備品のむンシデント前の管理範囲・蚭定点等がある。バックアップは䜜成の
郜床詊隓を行うだけでなく、それらの保存手順も定期的に芋盎しお、バックアップが環境条件
に適合しお利甚可胜で、セキュアな堎所に保管され、必芁な堎合には暩限のある人員がすぐに
入手できるようになっおいるか怜蚌する。

162

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.6.2 Disaster Recovery Planning
A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect an IT
infrastructure in the event of a disaster. The DRP, ordinarily documented in written form, specifies
procedures an organization is to follow in the event of a disaster. It is a comprehensive statement of
consistent actions to be taken before, during and after a disaster. The disaster could be natural,
environmental or man-made. Man-made disasters could be intentional or unintentional.
ICS-specific Recommendations and Guidance
A DRP is essential to continued availability of the ICS. The DRP should include the following items:


Required response to events or conditions of varying duration and severity that would activate the
recovery plan.



Procedures for operating the ICS in manual mode with all external electronic connections severed
until secure conditions can be restored.



Roles and responsibilities of responders.



Processes and procedures for the backup and secure storage of information.



Complete and up-to-date logical network diagram.



Personnel list for authorized physical and cyber access to the ICS.



Communication procedure and list of personnel to contact in the case of an emergency including ICS
vendors, network administrators, ICS support personnel, etc.



Current configuration information for all components.



Schedule for exercising the DRP.

The plan should also indicate requirements for the timely replacement of components in the case of an
emergency. If possible, replacements for hard-to-obtain critical components should be kept in inventory.
The security plan should define a comprehensive backup and restore policy. In formulating this policy, the
following should be considered:


The speed at which data or the system must be restored. This requirement may justify the need for a
redundant system, spare offline computer, or valid file system backups.



The frequency at which critical data and configurations are changing. This will dictate the frequency
and completeness of backups.



The safe onsite and offsite storage of full and incremental backups.



The safe storage of installation media, license keys, and configuration information.



Identification of individuals responsible for performing, testing, storing, and restoring backups.

163

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.6.2 灜害埩旧蚈画
灜害埩旧蚈画DRPは、灜害時に IT むンフラを埩旧し保護するための文曞化されたプロセス
又は手順である。DRP は通垞文曞化され、灜害時に組織が取る手順を定める。灜害前・䞭・埌に
取るべき䞀貫した行動に぀いお、包括的に蚘述する。灜害は自然環境の堎合もあれば、人為的な
ものもある。人為灜害は故意又は偶発により生じる。
ICS 固有の掚奚事項及びガむダンス
DRP は、ICS の可甚性を保持するために䞍可欠である。DRP には以䞋を含めるべきである。

 埩旧蚈画曞が発動される事象又は状態の期間ず重倧性に応じお求められる察応
 倖郚ぞの電子接続が党お断たれた䞭で、セキュアな状態に埩旧するたで、手動モヌドで ICS
を皌働させるための手順
 察応者の圹割ず責任
 情報のバックアップずセキュアな保存を行うためのプロセスず手順
 完党な最新の論理ネットワヌク図
 ICS ぞの立入及びサむバヌアクセス暩限のある人員リスト
 緊急時の通信手順及び連絡盞手のリストICS ベンダヌ、ネットワヌク管理者、ICS サポヌ
ト芁員等を含める
 党おのコンポヌネントの最新構成情報
 DRP 挔習スケゞュヌル
蚈画曞には、緊急時のコンポヌネントを適時亀換するための芁件も含めるべきである。できれば
入手困難な重芁コンポヌネントの代替品は、圚庫させおおくべきである。
セキュリティ蚈画曞は、包括的なバックアップ及び埩旧ポリシヌを定めるべきである。ポリシヌ
の策定に圓たっおは、次の点を考慮に入れるべきである。

 デヌタ又はシステムの埩旧に芁する速床。この芁件があるこずから冗長システム、スペアの
オフラむンコンピュヌタ又は有効ファむルシステムバックアップが必芁ずされる。
 重芁デヌタ及び構成倉曎の頻床。これによりバックアップの頻床や完党性が決たる。
 党面バックアップ及び差分バックアップの安党なオンサむト及びオフサむト保管
 むンストヌルメディア、ラむセンスキヌ及び蚭定情報の安党な保管
 バックアップの実斜・詊隓・保管・埩旧担圓者の特定

164

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.7 Identification and Authentication
Authentication describes the process of positively identifying potential network users, hosts, applications,
services, and resources using a combination of identification factors or credentials. The result of this
authentication process then becomes the basis for permitting or denying further actions (e.g., when an
automatic teller machine asks for a PIN). Based on the authentication determination, the system may or
may not allow the potential user access to its resources. Authorization is the process of determining who
and what should be allowed to have access to a particular resource; access control is the mechanism for
enforcing authorization. Access control is described in Section 6.2.1.
There are several possible factors for determining the authenticity of a person, device, or system, including
something you know, something you have or something you are. For example, authentication could be
based on something known (e.g., PIN number or password), something possessed (e.g., key, dongle, smart
card), something you are such as a biological characteristic (e.g., fingerprint, retinal signature), a location
(e.g., Global Positioning System [GPS] location access), the time a request is made, or a combination of
these attributes. In general, the more factors that are used in the authentication process, the more robust the
process will be. When two or more factors are used, the process is known generically as multi-factor
authentication.
The security controls that fall within the NIST SP 800-53 Identification and Authentication (IA) family
provide policy and guidance for the identification and authentication of users of and devices within the
information system. These include controls to manage identifiers and authenticators within each technology
used (e.g., tokens, certificates, biometrics, passwords, key cards).
Supplemental guidance for the IA controls can be found in the following documents:


NIST SP 800-63 provides guidance on remote electronic authentication [53].



NIST SP 800-73 provides guidance on interfaces for personal identity verification [49].



NIST SP 800-76 provides guidance on biometrics for personal identity verification [50].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
Computer systems in ICS environments typically rely on traditional passwords for authentication. Control
system suppliers often supply systems with default passwords. These passwords are factory set and are
often easy to guess or are changed infrequently, which creates additional security risks. Also, protocols
currently used in ICS environments generally have inadequate or no network service authentication. There
are now several forms of authentication available in addition to traditional password techniques being used
with ICS. Some of these, including password authentication, are presented in the following sections with
discussions regarding their use with ICS.

165

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.7 識別及び認蚌
認蚌は、ネットワヌクナヌザ、ホスト、アプリケヌション、サヌビス及びリ゜ヌスを識別芁玠
や認蚌情報を組み合わせお、胜動的に識別するプロセスである。認蚌プロセスの結果が、次の
アクションを蚱可するか拒絶するかの根拠ずなるATM の PIN 芁求時等。認蚌刀定に基づき、
システムはナヌザのリ゜ヌスぞのアクセスを蚱可又は拒絶する。暩限付䞎ずは、特定のリ゜ヌ
スにアクセスが蚱される䞻䜓を刀定するプロセスのこずで、アクセス制埡ずは暩限付䞎を行う
メカニズムをいう。アクセス制埡に぀いおはセクション 6.2.1 で説明する。
個人、デバむス又はシステムの正圓性を刀定する芁玠がいく぀かあり、個人が知っおいるこ
ず、持っおいるもの又は䜕者であるかなどである。䟋えば、認蚌は既知の事柄PIN 番号やパ
スワヌド等、所有物キヌ、ドングル、スマヌトカヌド等、生物孊的特城等の個人情報
指王、網膜照合等、堎所党地球枬䜍システム[GPS]䜍眮アクセス等、芁求時刻又はこ
れら属性を䜵甚しお行われる。総じお、認蚌プロセスで利甚する芁玠が増えれば増えるほど、
プロセスは匷力になる。2 ぀以䞊の芁玠を利甚するプロセスは倚芁玠認蚌ずしお知られおいる。
NIST SP 800-53 の識別及び認蚌IAファミリに含たれるセキュリティ察策は、情報システ
ムにおけるナヌザ及びデバむスの識別及び認蚌に係るポリシヌ及びガむダンスを定めおいる。
䜿甚される各技術トヌクン、蚌明曞、バむオメトリクス、パスワヌド、キヌカヌド等での
識別及び認蚌の管理が含たれおいる。
IA 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-63遠隔電子認蚌に係るガむダンス[53]
 NIST SP 800-73個人身元確認むンタフェヌスに係るガむダンス[49]
 NIST SP 800-76個人身元確認バむオメトリクスに係るガむダンス[50]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
ICS 環境におけるコンピュヌタシステムは、䞀般に䌝統的な認蚌パスワヌドに䟝存しおいる。制
埡システムサプラむダは、デフォルトのパスワヌドを蚭定しおシステムを䟛絊するこずが倚い。
パスワヌドは工堎で蚭定され、簡単に掚枬できるものが倚く、滅倚に倉曎されないこずから、セ
キュリティリスクずなる。たた珟圚 ICS 環境で利甚されおいるプロトコルのネットワヌクサヌビ
ス認蚌は、総じお䞍適切であるか党くない。珟圚では、ICS で利甚される䌝統的なパスワヌド技
術に加えお、いく぀かの認蚌圢態がある。パスワヌド認蚌を含め、これらのいく぀かを ICS で利
甚するこずに぀いお、続くセクションで説明する。

166

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.7.1 Password Authentication
Password authentication technologies determine authenticity based on testing for something the device or
human requesting access should know, such as a PIN number or password. Password authentication
schemes are thought of as the simplest and most common forms of authentication.
Password vulnerabilities can be reduced by using an active password checker that prohibits weak, recently
used, or commonly used passwords. Another weakness is the ease of third-party eavesdropping. Passwords
typed at a keyboard are easily observed or recorded, especially in areas where adversaries could plant tiny
wireless cameras or keystroke loggers. Network service authentication often transmits passwords as
plaintext (unencrypted), allowing any network capture tool to expose the passwords.
ICS-specific Recommendations and Guidance
One problem with passwords unique to the ICS environment is that a user’s ability to recall and enter a
password may be impacted by the stress of the moment. During a major crisis when human intervention is
critically required to control the process, an operator may panic and have difficulty remembering or
entering the password and either be locked out completely or be delayed in responding to the event. If the
password has been entered wrong and the system has a limit on allowed wrong password entries, the
operator may be locked out permanently until an authorized employee can reset the account. Biometric
identifiers may have similar drawbacks. Organizations should carefully consider the security needs and the
potential ramifications of the use of authentication mechanisms on these critical systems.
In situations where the ICS cannot support, or the organization determines it is not advisable (e.g.,
performance, safety, or reliability are adversely impacted), to implement authentication mechanisms in an
ICS, the organization uses compensating controls, such as rigorous physical security controls (e.g., control
center keycard access for authorized users) to provide an equivalent security capability or level of
protection for the ICS. This guidance also applies to the use of session lock and session termination in an
ICS.
Special consideration must be made when pushing down policies based on login password authentication
within the ICS environment. Without an exclusion list based on machine identification (ID), non-operator
logon can result in policies being pushed down such as auto- logoff timeout and administrator password
replacement that can be detrimental to the operation of the system.
Some ICS operating systems make setting secure passwords difficult, as the password size is very small
and the system allows only group passwords at each level of access, not individual passwords. Some
industrial (and Internet) protocols transmit passwords in plaintext, making them susceptible to interception.
In cases where this practice cannot be avoided, it is important that users have different (and unrelated)
passwords for use with encrypted and non-encrypted protocols.
The following are general recommendations and considerations with regards to the use of passwords.


The length, strength, and complexity of passwords should balance security and operational ease of
access within the capabilities of the software and underlying OS.



Passwords should have appropriate length and complexity for the required security. In particular, they
should not be able to be found in a dictionary or contain predictable sequences of numbers or letters.

167

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.7.1 パスワヌド認蚌
パスワヌド認蚌技術は、アクセスを求めおいるデバむスや人が知っおいるべき情報PIN 番号や
パスワヌド等を怜蚌しお正圓性を刀定する技術である。パスワヌド認蚌法は、認蚌の最も単玔
か぀慣甚的な圢ず芋なされおいる。
パスワヌドの脆匱性は、単玔なもの、最近䜿甚したもの、よく䜿甚されるものを犁止するアクテ
ィブパスワヌドチェッカヌを利甚するこずで枛らすこずができる。別の匱点は、サヌドパヌティ
が容易に傍受できるこずである。キヌボヌドでタむプしたパスワヌドは、特に攻撃偎が小型ワむ
ダレスカメラやキヌストロヌクロガヌを蚭眮した堎所では、容易に芳察又は蚘録できる。ネット
ワヌクサヌビス認蚌は、パスワヌドを平文暗号化なしで送信するこずが倚く、ネットワヌク
キャプチャツヌルがあればパスワヌドが露芋しおしたう。
ICS 固有の掚奚事項及びガむダンス
ICS に䞀意のパスワヌドを䜿甚する問題点は、ナヌザがパスワヌドを思い出しお入力する胜力
は、そのずきのストレスに圱響されるこずにある。危機の際に、プロセスの制埡に人の察応が是
非ずも必芁ずされる堎合、操䜜員がパニックに陥り、パスワヌドが思い出せずにログむンできな
かったり、察応が遅れたりするこずがある。間違ったパスワヌドを入力し、システムに間違いパ
スワヌドの入力制限がある堎合、その操䜜員は、暩限のある埓業員がアカりントをリセットする
たで、ずっずログむンできなくなる。バむオメトリック識別子にも同様の欠陥がある。組織は、
セキュリティニヌズず重芁システムにおける認蚌メカニズムの利甚に関する問題に぀いお慎重に
怜蚎すべきである。
ICS が察応しおおらず、又は ICS ぞの認蚌メカニズムの実装を䞍適切ず刀断する堎合パフォヌ
マンス、安党性、信頌性が䜎䞋するなど、組織は厳栌な物理的セキュリティ察策等の代替管理
を利甚しお制埡センタヌぞの、暩限のあるナヌザによるキヌカヌドを利甚した立入等、ICS
の同等のセキュリティ機胜又は保護レベルを確保する。このガむダンスは、ICS のセッションロ
ック及びセッション終了にも圓おはたる。
ICS 環境でのログむンパスワヌド認蚌を基に、ポリシヌを匕き䞋げる堎合は、特別な考慮を芁す
る。マシン ID に基づく排陀リストがない堎合、操䜜員以倖のログオンは、システムの動䜜を悪
化させる自動ログオフタむムアりトや管理者パスワヌドの眮換ずいった、ポリシヌの匕き䞋げが
生じ埗る。
ICS の OS によっおは、パスワヌドサむズが短く、各レベルでのアクセス時、システムが個人パ
スワヌドではなくグルヌプパスワヌドのみ受け付けるようになっおいるため、セキュアなパスワ
ヌド蚭定が困難である。特定の産業甚及びむンタヌネットプロトコルは、パスワヌドを平文
で送信するため傍受されやすい。この芏範の利甚が避けられない堎合、ナヌザは別の無関係
なパスワヌドを持ち、暗号化プロトコル及び非暗号化プロトコルで利甚するこずが肝芁であ
る。
以䞋はパスワヌドの利甚に関する䞀般的な掚奚事項及び考慮事項である。

 パスワヌドの長さ、匷床及び耇雑さは、゜フトり゚ア及び䜿甚 OS の胜力内で、セキュリテ
ィずアクセスしやすさのバランスを取るべきである。
 パスワヌドの長さず耇雑さは、必芁なセキュリティに芋合ったものずすべきである。特に蟞
曞に茉っおいる甚語や、数字や文字の順序が予想可胜なものは䜿甚すべきでない。

168

SPECIAL PUBLICATION 800-82 REVISION 2












GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Passwords should be used with care on operator interface devices such as control consoles on critical
processes. Using passwords on these consoles could introduce potential safety issues if operators are
locked out or delayed access during critical events. Physical security should supplement operator
control consoles when password protection is not feasible.
The keeper of master passwords should be a trusted employee, available during emergencies. Any
copies of the master passwords must be stored in a very secure location with limited access.
The passwords of privileged users (such as network technicians, electrical or electronics technicians
and management, and network designers/operators) should be most secure and be changed frequently.
Authority to change master passwords should be limited to trusted employees. A password audit
record, especially for master passwords, should be maintained separately from the control system.
In environments with a high risk of interception or intrusion (such as remote operator interfaces in a
facility that lacks local physical security access controls), organizations should consider
supplementing password authentication with other forms of authentication such as multi-factor
authentication using biometric or physical tokens.
For user authentication purposes, password use is common and generally acceptable for users logging
directly into a local device or computer. Passwords should not be sent across any network unless
protected by some form of FIPS-approved encryption or salted cryptographic hash specifically
designed to prevent replay attacks. It is assumed that the device used to enter a password is connected
to the network in a secure manner.
For network service authentication purposes, passwords should not be passed as plain text. There are
more secure alternatives available, such as challenge/response or public key authentication.

6.2.7.2 Challenge/response Authentication
Challenge/response authentication requires that both the service requester and service provider know a
“secret” code in advance. When service is requested, the service provider sends a random number or string
as a challenge to the service requester. The service requester uses the secret code to generate a unique
response for the service provider. If the response is as expected, it proves that the service requester has
access to the “secret” without ever exposing the secret on the network.
Challenge/response authentication addresses the security vulnerabilities of traditional password
authentication. When passwords (hashed or plain) are sent across a network, a portion of the actual “secret”
itself is being sent, giving the secret to the remote device performs authentication. Therefore, traditional
password exchange always suffers the risk of discovery or replay. Because the secret is known in advance
and never sent in challenge/response systems, the risk of discovery is eliminated. If the service provider can
never send the same challenge twice, and the receiver can detect all duplications, the risks of network
capture and replay attacks are eliminated.

169

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 重芁プロセスの制埡コン゜ヌル等、操䜜員むンタフェヌスデバむスでは、パスワヌドを泚意
深く䜿甚すべきである。このようなコン゜ヌル䞊でのパスワヌドの䜿甚は、緊急時に操䜜員
がログむンできず、又は察応が遅れた堎合に、安党䞊の問題が生起する。パスワヌド保護が
利甚できない堎合、物理的セキュリティは操䜜員制埡コン゜ヌルを補完するものずなる。
 マスタヌパスワヌドの保管者は、緊急時に連絡が付く信頌の眮ける埓業員ずすべきである。
マスタヌパスワヌドの写しを䜜成した堎合は、立入が制限された安党な堎所に保管しなけれ
ばならない。
 特暩ナヌザネットワヌク技術者、電気・電子技垫・管理者、ネットワヌク蚭蚈者・操䜜員
等のパスワヌドはセキュアで、頻繁に倉曎すべきである。マスタヌパスワヌドの倉曎暩限
は信頌の眮ける埓業員に限定すべきである。パスワヌド監査蚘録、特にマスタヌパスワヌド
甚は、制埡システムから独立しお保管すべきである。
 傍受又は䟵入リスクの高い環境ロヌカルの物理的セキュリティ立入制限のない斜蚭におけ
る遠隔操䜜員むンタフェヌス等では、組織は、バむオメトリックや物理的トヌクンを利甚
した倚芁玠認蚌等、別圢態の補足的パスワヌド認蚌を考慮すべきである。
 ナヌザ認蚌目的では、パスワヌドの利甚は䞀般的で、ナヌザが盎接ロヌカルデバむスやコン
ピュヌタにログむンする方法ずしお広く受け入れられおいる。特定の圢態の FIPS 承認暗号
又はリプレヌ攻撃防止甚゜ルト䜵甚暗号孊的ハッシュで保護されおいない堎合、パスワヌド
をネットワヌクを越えお送信すべきでない。パスワヌド入力デバむスは、セキュアな方法で
ネットワヌク接続されおいるこずが前提である。
 ネットワヌクサヌビス認蚌目的では、パスワヌドを平文で枡すべきでない。これら以倖に
も、チャレンゞ/レスポンス認蚌や公開鍵認蚌等のセキュアな代替手段がある。

6.2.7.2 チャレンゞ/レスポンス認蚌
チャレンゞ/レスポンス認蚌は、サヌビスの芁求偎ず提䟛偎が前もっお「秘密の」コヌドを知っ
おいなければならない。サヌビス芁求があるず、サヌビスプロバむダはランダムな数字や文字列
をチャレンゞずしお芁求者に送信する。芁求者は秘密コヌドを䜿甚しお、䞀意のレスポンスをプ
ロバむダ向けに生成する。レスポンスが期埅どおりだず、芁求者は、「秘密」をネットワヌク䞊
にさらすこずなく、秘密ぞのアクセス暩を持っおいるこずになる。
チャレンゞ/レスポンス認蚌は、䌝統的なパスワヌド認蚌のセキュリティ䞊の脆匱性に察応する
ものずなる。ネットワヌクを越えおパスワヌドハッシュ化又は平文が送信される堎合、実際
の「秘密」そのものが送信され、秘密を遠隔デバむスに䞎えるこずで認蚌が行われる。したがっ
お、䌝統的なパスワヌド亀換には、垞に露芋又はリプレヌのリスクが぀きたずう。チャレンゞ/
レスポンスシステムでは秘密は事前に知らされ、送信されないため、露芋リスクは排陀される。
サヌビスプロバむダが同じチャレンゞを二床送るこずができなければ、受信者が党おの耇補を探
知しおも、ネットワヌクキャプチャずリプレヌ攻撃のリスクは排陀される。

170

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS-specific Recommendations and Guidance
For User Authentication, the direct use of challenge/response authentication may not be feasible for control
system due to the possible latency that may be introduced in the necessary fast dynamics required for
access to a control system or industrial network. For Network Service Authentication, the use of
challenge/response authentication is preferable to more traditional password or source identity
authentication schemes.
Challenge/response authentication provides more security than encrypted passwords for user authentication
across a network. Managing master encryption algorithms and master passwords becomes increasing more
complex as more parties are involved in the security processes and is an important consideration in the
robustness of the security scheme.

6.2.7.3 Physical Token Authentication
Physical or token authentication is similar to password authentication, except that these technologies
determine authenticity by testing for secret code or key produced by a device or token the person requesting
access has in their possession, such as security tokens or smart cards. Increasingly, private keys are being
embedded in physical devices such as USB dongles. Some tokens support single-factor authentication only,
so that simply having possession of the token is sufficient to be authenticated. Others support multi-factor
authentication that requires knowledge of a PIN or password in addition to possessing the token.
The primary vulnerability that token authentication addresses is easily duplicating a secret code or sharing
it with others. It eliminates the all-too-common scenario of a password to a “secure” system being left on
the wall next to a PC or operator station. The security token cannot be duplicated without special access to
equipment and supplies.
A second benefit is that the secret within a physical token can be very large, physically secure, and
randomly generated. Because it is embedded in metal or silicon, it does not have the same risks that
manually entered passwords do. If a security token is lost or stolen, the authorized user loses access, unlike
traditional passwords that can be lost or stolen without notice.
Common forms of physical/token authentication include:


Traditional physical lock and keys.



Security cards (e.g., magnetic, smart chip, optical coding).



Radio frequency devices in the form of cards, key fobs, or mounted tags.



Dongles with secure encryption keys that attach to the USB, serial, or parallel ports of computers.



One-time authentication code generators (e.g., key fobs).

For single-factor authentication, the largest weakness is that physically holding the token means access is
granted (e.g., anyone finding a set of lost keys now has access to whatever they open). Physical/token
authentication is more secure when combined with a second form of authentication, such as a memorized
PIN used along with the token.

171

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS 固有の掚奚事項及びガむダンス
ナヌザ認蚌に関しお、制埡システムではチャレンゞ/レスポンス認蚌の盎接的な䜿甚は䞍可胜か
もしれない。ず蚀うのは、制埡システム又は産業甚ネットワヌクぞのアクセスに必芁ずされる高
速ダむナミクスでは、埅ち時間が生じかねないからである。ネットワヌクサヌビス認蚌では、チ
ャレンゞ/レスポンス認蚌の䜿甚は、䌝統的なパスワヌド方匏や゜ヌス識別認蚌方匏よりも望た
しい。
ネットワヌクを越えるナヌザ認蚌では、チャレンゞ/レスポンス認蚌のセキュリティは暗号パス
ワヌドよりも匷い。マスタヌ暗号アルゎリズム及びマスタヌパスワヌドの管理は、セキュリティ
プロセスに関係する圓事者が増えるに぀れお、たすたす耇雑になっおおり、セキュリティ䜓制の
堅牢性における重芁な考慮事項である。
6.2.7.3 物理的トヌクン認蚌
物理的又はトヌクン認蚌はパスワヌド認蚌に䌌おいるが、違いはアクセス芁求者が持っおい
るデバむスやトヌクンセキュリティトヌクンやスマヌトカヌドが生成する秘密コヌドや
キヌを怜蚌しお認蚌を刀別する点にある。たすたす USB ドングル等の物理的デバむスにプラ
むベヌトキヌが埋め蟌たれるようになっおいる。単芁玠認蚌にしか察応しおいないトヌクン
もあり、トヌクンを持っおいさえすれば認蚌に十分ずいうこずである。トヌクンの保有に加
えお、PIN やパスワヌドを芁求する倚芁玠認蚌に察応したものもある。
トヌクン認蚌の䞻な脆匱性は、秘密コヌドの耇補が容易なこずず他人ずの共有が可胜なこずで
ある。トヌクンを䜿えば、「セキュアな」システムのパスワヌドを PC や操䜜員ステヌション
の近くに曞きずどめおおくような、よくあるシナリオはなくなる。セキュリティトヌクンの耇
補は、装備品やサプラむ品ぞの特別なアクセス暩がなければできない。
2 ぀目の利点は、物理的トヌクン内郚の秘密はサむズが倧きく、物理的にセキュアで、ラ
ンダム生成される。金属やシリコンに埋め蟌たれおいるため、マニュアル操䜜でパスワヌ
ドを入力するようなリスクはない。セキュリティトヌクンをなくした堎合や盗たれた堎合、
ナヌザはアクセス暩を倱う。これは気づかないうちになくしたり盗たれたりするパスワヌ
ドずの違いである。
物理的/トヌクン認蚌の共通圢態ずしお次のものがある。

 䌝統的な物理ロックずキヌ
 セキュリティカヌド磁気、スマヌトチップ、光コヌディング等
 カヌド、キヌフォブ又は取付けタグ等の無線呚波数デバむス
 USB、コンピュヌタのシリアル又はパラレルポヌトに取り付けるセキュアな暗号鍵付きドン
グル
 ワンタむム認蚌コヌドゞェネレヌタキヌフォブ等
単芁玠認蚌の最倧の匱点は、トヌクンを物理的に保有しおいればアクセスできるこずにある
鍵束の拟埗者は他人の家に自由に出入りできる。物理的/トヌクン認蚌は、別圢態の認蚌ず
䜵甚するずセキュリティが向䞊する蚘憶した PIN ずの䜵甚など。

172

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS-specific Recommendations and Guidance
Multi-factor authentication is an accepted good practice for access to ICS applications from outside the ICS
firewall.
Physical/token authentication has the potential for a strong role in ICS environments. An access card or
other token can be an effective form of authentication for computer access, as long as the computer is in a
secure area (e.g., once the operator has gained access to the room with appropriate secondary
authentication, the card alone can be used to enable control actions).

6.2.7.4 Smart Card Authentication
Smart cards are similar to token authentication, but can provide additional functionality. Smart cards can be
configured to run multiple on-board applications to support building access, computer dual-factor or triplefactor authentication and cashless vending on a single card, while also acting as the company photo ID for
the individual.
Typically, smart cards come in a credit card size form-factor that can be printed, embossed, and
individually personalized. Smart cards can be customized, individualized, and issued in-house or
outsourced to service providers who typically issue hundreds of thousands of cards per day.
Smart cards enhance software-only solutions, such as password authentication, by offering an additional
authentication factor and removing the human element in memorizing complex secrets. They also:


Isolate security-critical computations, involving authentication, digital signatures, and key exchange
from other parts of the system that do not have a need to know.



Enable portability of credentials and other private information between multiple computer systems.



Provide tamper-resistant storage for protecting private keys and other forms of personal information.

The majority of issues are logistical around issuing the cards, particularly to replace lost or stolen cards.
ICS-specific Recommendations and Guidance
Although smart cards are relatively inexpensive and offer useful functionality in an industrial control
system context, their implementation must be done within the overall security context of the plant. The
necessary identification of individuals, issuance of cards, revocation should compromise be suspected, and
the assignment of authorizations to authenticated identities, represents a significant initial and on-going
challenge. In some cases corporate IT or other resources may be available to assist in the deployment of
smart card and public key based infrastructures.
If smart cards are implemented in an industrial control setting, provisions for management of lost or
damaged cards should be considered, as well as the costs to incorporate a respective access control system
and provide a management process for card distribution and retrieval.

173

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS 固有の掚奚事項及びガむダンス
倚芁玠認蚌は、ICS ファむアりォヌル倖から ICS アプリケヌションにアクセスする際の受け入れ
られる優良芏範である。
物理的/トヌクン認蚌は、ICS 環境で倧きな圹割を果たす可胜性がある。アクセスカヌドその他の
トヌクンは、コンピュヌタがセキュアな゚リアにある限り、コンピュヌタぞの効果的な認蚌圢態
である操䜜員が 2 ぀目の適正な認蚌を経お宀内に立ち入るず、制埡行為を行うにはカヌドのみ
ずなる。
6.2.7.4 スマヌトカヌド認蚌
スマヌトカヌドはトヌクン認蚌に䌌おいるが、付加的な機胜がある。スマヌトカヌドは、耇数
のオンボヌドアプリケヌションを実行しお、建物ぞの立入、コンピュヌタの 2 重芁玠又は 3 重
芁玠認蚌及び 1 枚のカヌドでのキャッシュレス販売に察応できるように蚭定可胜で、䌁業の写
真付き個人甚 ID カヌドずしおも䜿甚できる。
䞀般にスマヌトカヌドはクレゞットカヌドサむズで、印字・゚ンボス・個別化が可胜である。
カスタマむズや個人別の個別化が可胜で、組織内で発行できるほか、数十䞇のカヌドを毎日発
行しおいるサヌビスプロバむダに倖泚するこずもできる。
スマヌトカヌドは、付加的な認蚌芁玠を提䟛し、耇雑な秘密を芚えるずいう人的芁因を排陀す
るこずにより、パスワヌド認蚌等の゜フトり゚アのみに䟝存する゜リュヌションを拡匵する。
たた次のような特城がある。

 セキュリティの重芁な挔算、䟋えば認蚌、デゞタル眲名、知る必芁のないシステムの他の郚
䜍からのキヌ亀換の隔離
 耇数コンピュヌタシステム間での認蚌情報その他個人情報のポヌタビリティの実珟
 プラむベヌトキヌその他の個人情報の改倉防止保管
問題の倧半は、カヌド発行に関する業務的な内容で、特にカヌドの玛倱・盗難が倚い。
ICS 固有の掚奚事項及びガむダンス
スマヌトカヌドは比范的安䟡で、産業甚制埡システムにおいお䟿利な機胜を発揮するが、その実
装は、プラントの党䜓的なセキュリティを考慮した䞊で行わなければならない。必芁な個人識
別、カヌド発行、取消によるマむナス芁玠を考慮に入れるなら、認蚌枈み個人に察する暩限の付
䞎は、圓初にもそれ以埌も倧きな課題ずなる。堎合によっおは、䌁業 IT その他のリ゜ヌスを利
甚しお、スマヌトカヌドず公開鍵ベヌスのむンフラを展開する資ずできよう。
スマヌトカヌドを産業甚制埡環境に実装する堎合、玛倱・毀損カヌドの管理芏定やそれぞれのア
クセス制埡システムの組蟌みに芁するコストを怜蚎し、カヌド配垃・回収の管理プロセスを定め
るべきである。

174

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.7.5 Biometric Authentication
Biometric authentication technologies determine authenticity by determining presumably unique biological
characteristics of the human requesting access. Usable biometric features include finger minutiae, facial
geometry, retinal and iris signatures, voice patterns, typing patterns, and hand geometry.
Like physical tokens and smart cards, biometric authentication enhances software-only solutions, such as
password authentication, by offering an additional authentication factor and removing the human element
in memorizing complex secrets. In addition, because biometric characteristics are unique to a given
individual, biometric authentication addresses the issues of lost or stolen physical tokens and smart cards.
Noted issues with biometric authentication include:


Distinguishing a real object from a fake (e.g., how to distinguish a real human finger from a siliconrubber cast of one or a real human voice from a recorded one).



Generating type-I and type-II errors (the probability of rejecting a valid biometric image, and the
probability of accepting an invalid biometric image, respectively). Biometric authentication devices
should be configured to the lowest crossover between these two probabilities, also known as the
crossover error rate.



Handling environmental factors such as temperature and humidity to which some biometric devices
are sensitive.



Addressing industrial applications where employees may have on safety glasses and/or gloves and
industrial chemicals may impact biometric scanners.



Retraining biometric scanners that occasionally “drift” over time. Human biometric traits may also
shift over time, necessitating periodic scanner retraining.



Requiring face-to-face technical support and verification for device training, unlike a password that
can be given over a phone or an access card that can be handed out by a receptionist.



Denying needed access to the control system because of a temporary inability of the sensing device to
acknowledge a legitimate user.



Being socially acceptable. Users consider some biometric authentication devices more acceptable than
others. For example, retinal scans may be considered very low on the scale of acceptability, while
thumb print scanners may be considered high on the scale of acceptability. Users of biometric
authentication devices will need to take social acceptability for their target group into consideration
when selecting among various biometric authentication technologies.

ICS-specific Recommendations and Guidance
Biometric devices make a useful secondary check versus other forms of authentication that can become lost
or borrowed. Using biometric authentication in combination with token-based access control or badgeoperated employee time clocks increases the security level. A possible application is in a control room that
is environmentally controlled and physically secured [34].
Biometrics can provide a valuable authentication mechanism, but need to be carefully assessed for
industrial applications because physical and environmental issues within the installation environment may
need to be restructured for reliable authorized authentication. The exact physical and environmental
properties of an installation should be coordinated with a system vendor or manufacturer.

175

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.7.5 バむオメトリック認蚌
バむオメトリック認蚌技術は、アクセス芁求する個人の、各人に固有ず考えられおいる生物
孊的特城を刀別しお認蚌を刀定する。利甚できるバむオメトリック特性には指王、顔の茪郭、
網膜及び光圩特性、音声パタヌン、タむピングパタヌン、手の茪郭等がある。
物理的トヌクンやスマヌトカヌドず同様、バむオメトリック認蚌は、付加的な認蚌芁玠を提
䟛し、耇雑な秘密を芚えるずいう人的芁因を排陀するこずにより、パスワヌド認蚌等の゜フ
トり゚アのみに䟝存する゜リュヌションを匷化するこずができる。たた、生物孊的特城は特
定の個人に固有であるこずから、バむオメトリック認蚌は、物理的トヌクンやスマヌトカヌ
ドの玛倱・盗難問題に察応するものずなる。
バむオメトリック認蚌に぀いお知られおいる問題には次のようなものがある。

 実物ず停物の区別人の指ず型取りしたシリコン補の指、実際の発声ず録音した声の区別方
法
 タむプ 1 ゚ラヌずタむプ 2 ゚ラヌの生成有効なバむオメトリック画像を拒絶する確率、無
効なバむオメトリック画像を受け入れる確率。バむオメトリック認蚌デバむスは、これら
2 ぀の確率の間の最䜎のクロスオヌバヌに蚭定されるべきで、クロスオヌバヌ誀差率ずしお
も知られる。
 特定のバむオメトリックデバむスが敏感に反応する枩床・湿床等の環境因子の凊理
 埓業員が安党ゎヌグルやグロヌブを着甚し、工業甚化孊物質がバむオメトリックスキャナヌ
に圱響する産業甚アプリケヌションの凊理
 経時的に「ドリフト」するバむオメトリックスキャナヌの再蚓緎。人のバむオメトリック特
性は経時的に倉化するため、スキャナヌの定期的再蚓緎が必芁になる。
 1 察 1 の技術支揎ずデバむス蚓緎の怜蚌が必芁。受付係から電話で教えられるパスワヌドや、
手枡し可胜なアクセスカヌドず異なる。
 適栌ナヌザを認知する怜知デバむスの䞀時的䞍調による制埡システムぞのアクセス拒吊
 瀟䌚の受入れ態勢。バむオメトリック認蚌に察するナヌザの受容床はデバむスによりばら぀
きがある。䟋えば、受容床は網膜スキャンの堎合䜎く、芪指のプリントスキャナヌは高い。
倚様なバむオメトリック技術の䞭からいずれかを遞択する際、バむオメトリック認蚌デバむ
スナヌザは、察象グルヌプに察する瀟䌚の受容床を考慮に入れる必芁がある。
ICS 固有の掚奚事項及びガむダンス
バむオメトリックデバむスは、玛倱したり貞借したりできる他の圢態の認蚌に察しお、有甚な
副次的チェックができる。トヌクンベヌスのアクセス制埡やバッゞ操業する埓業員のタむムレ
コヌダず䜵甚すれば、セキュリティレベルが向䞊する。考えられる甚途ずしお、環境的に制埡
され物理的なセキュリティが確保されおいる制埡宀がある[34]。
バむオメトリクスは貎重な認蚌メカニズムずなるが、信頌性の高い認蚌を埗るには蚭眮環境の
物理・環境問題を解決する必芁があるため、産業甚途ずしおは慎重な評䟡を芁する。蚭眮の正
確な物理・環境特性に぀いお、システムベンダヌやメヌカヌず調敎すべきである。

176

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.8 Incident Response
An incident response plan is documentation of a predetermined set of instructions or procedures to detect,
respond to, and limit consequences of incidents against an organization’s information systems. Response
should be measured first and foremost against the “service being provided,” not just the system that was
compromised. If an incident is discovered, there should be a quick risk assessment performed to evaluate
the effect of both the attack and the options to respond. For example, one possible response option is to
physically isolate the system under attack. However, this may have such a dire impact on the service that it
is dismissed as not viable.
The security controls that fall within the NIST SP 800-53 Incident Response (IR) family provide policies
and procedures for incident response monitoring, handling, and reporting. The handling of a security
incident includes preparation, detection and analysis, containment, eradication, and recovery. Controls also
cover incident response training for personnel and testing the incident response capability for an
information system.
Supplemental guidance for the IR controls can be found in the following documents:


NIST SP 800-61 provides guidance on incident handling and reporting [59].



NIST SP 800-83 provides guidance on malware incident prevention and handling [60].



NIST SP 800-100 provides guidance on information security governance and planning [27] .

ICS-specific Recommendations and Guidance
Regardless of the steps taken to protect an ICS, it is always possible that it may be compromised by an
intentional or unintentional incident. The following symptoms can arise from normal network problems,
but when several symptoms start to appear, a pattern may indicate the ICS is under attack and may be
worth investigating further. If the adversary is skilled, it may not be very obvious that an attack is
underway.
The symptoms of an incident could include any of the following:


Unusually heavy network traffic.



Out of disk space or significantly reduced free disk space.



Unusually high CPU usage.



Creation of new user accounts.



Attempted or actual use of administrator-level accounts.



Locked-out accounts.



Account in-use when the user is not at work.



Cleared log files.



Full log files with unusually large number of events.

177

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.8 むンシデント察応
むンシデント察応蚈画曞は、組織の情報システムに察するむンシデントの結果を怜知し、察応
し、局限するための事前に決められた䞀連の指瀺又は手順を文曞化したものである。察応は、
たず蚈枬するこず、そしお「提䟛䞭のサヌビス」に察しお行うものであり、性胜が䜎䞋したシ
ステムだけに行うのではない。むンシデントが発芋されたなら、迅速にリスク評䟡を行い、攻
撃の圱響ず察応オプションの䞡方を評䟡する。䟋えば、察応オプションの䞀䟋ずしお、攻撃さ
れたシステムを物理的に隔絶するこずができよう。ただしこの察応だず、サヌビスに深刻な圱
響が及ぶため、実行䞍胜ず䞀蹎される。
NIST SP 800-53 のむンシデント察応IRファミリに含たれるセキュリティ察策には、むン
シデント察応の監芖、凊理及び報告のためのポリシヌ及び手順が定められおいる。セキュリテ
ィむンシデントの凊理には、準備、怜出・分析、封じ蟌め、根絶及び埩旧が含たれる。管理策
も職員のむンシデント察応蚓緎及び情報システムのむンシデント察応胜力詊隓を含む。
IR 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-61むンシデント凊理及び報告に係るガむダンス[59]
 NIST SP 800-83マルり゚アむンシデント防止及び凊理に係るガむダンス[60]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
ICS の保護手順ずは無関係に、故意又は偶発的なむンシデントにより ICS の性胜が䜎䞋する堎
合がある。正垞なネットワヌク問題ずしお以䞋のような城候が芋られるが、いく぀かの城候が
出始めたなら、ICS が攻撃されおいるこずを瀺すパタヌンであり、調査を行うに倀する。攻撃
偎が巧劙だず、攻撃䞭であるこずが明確にはならない。
むンシデントの城候には次のようなものがある。

 ネットワヌクトラフィックが異垞に重い
 ディスク容量がない又は空き容量が著しく少ない
 CPU 利甚率が異垞に高い
 新芏ナヌザアカりントが䜜成されおいる
 管理者レベルアカりントを䜿甚又は䜿甚しようずした圢跡がある
 アカりントがロックアりトされた
 そのナヌザが䞍圚なのにアカりントが䜿甚されおいる
 ログファむルがクリアされおいる
 ログファむルが䞀杯でむベント数が異垞に倚い

178

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Antivirus or IDS alerts.



Disabled antivirus software and other security controls.



Unexpected patch changes.



Machines connecting to outside IP addresses.



Requests for information about the system (social engineering attempts).



Unexpected changes in configuration settings.



Unexpected system shutdown.

To minimize the effects of these intrusions, it is necessary to plan a response. Incident response planning
defines procedures to be followed when an intrusion occurs. NIST SP 800-61 Revision 2, Computer
Security Incident Handling Guide [59], provides guidance on incident response planning, which might
include the following items:


Classification of Incidents. The various types of ICS incidents should be identified and classified as
to potential impact so that a proper response can be formulated for each potential incident.



Response Actions. There are several responses that can be taken in the event of an incident. These
range from doing nothing to full system shutdown (although full shutdown of an ICS is a highly
unlikely response). The response taken will depend on the type of incident and its effect on the ICS
system and the physical process being controlled. A written plan documenting the types of incidents
and the response to each type should be prepared. This will provide guidance during times when there
might be confusion or stress due to the incident. This plan should include step-by-step actions to be
taken by the various organizations. If there are reporting requirements, these should be noted as well
as where the report should be made and phone numbers to reduce reporting confusion.



Recovery Actions. The results of the intrusion could be minor, or the intrusion could cause many
problems in the ICS. Risk analysis should be conducted to determine the sensitivity of the physical
system being controlled to failure modes in the ICS. In each case, step-by-step recovery actions should
be documented so that the system can be returned to normal operations as quickly and safely as
possible. Recovery actions for an intrusion that affects operation of the ICS will closely align with the
system's Disaster Recovery Plan, and should take into account the planning and coordination already
established.

During the preparation of the incident response plan, input should be obtained from the various
stakeholders including operations, engineering, IT, system support vendors, management, organized labor,
legal, and safety. These stakeholders should also review and approve the plan.

179

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 アンチりむルスアラヌト又は IDS アラヌトが出おいる
 アンチりむルス゜フトり゚アその他のセキュリティ察策が無効になっおいる
 予定倖のパッチ倉曎がなされおいる
 マシンが倖郚 IP アドレスに接続されおいる
 システムに関する情報請求があった゜ヌシャル゚ンゞニアリングのもくろみ
 構成の蚭定に予定倖の倉曎がなされおいる
 予定倖のシステム遮断があった
このような䟵入の圱響を最小限に食い止めるため、察応を蚈画する必芁がある。むンシデン
ト察応蚈画の立案では、䟵入があった際に取るべき手順を定める。NIST SP 800-61 改蚂第 2
版『コンピュヌタセキュリティむンシデントの凊理』[59]には、むンシデント察応蚈画の立
案に係るガむダンスが瀺されおおり、以䞋の項目が含たれおいる。

 むンシデントの区分。皮々の ICS むンシデントを識別し、圱響床を区分し、むンシデントご
ずに適正な察応が取れるようにすべきである。
 察応行動。むンシデントがおきた際には、取り埗る察応がいく぀かある。䜕もしないこずか
らシステムの党面遮断たであるもちろん、ICS の党面遮断はほがありそうにない察応では
ある。察応はむンシデントのタむプ、ICS システムぞの圱響及び制埡䞭に物理プロセスに
応じお取られる。むンシデントのタむプず各タむプぞの察応を蚘録した蚈画曞を甚意すべき
である。それがあるず、むンシデントによる混乱やストレス䞋にあっおもガむダンスずな
る。蚈画曞には、倚様な組織が取るべき段階ごずの行動を含めるべきである。報告芁件があ
れば、報告先のほか、報告時の混乱を少なくするため電話番号ずずもに、芁件も蚘茉しおお
く。
 埩旧察策。䟵入の結果が取るに足りないこずもあれば、ICS に倚くの問題を生じさせるこず
もある。リスク分析を行い、ICS の故障態様に圱響を受ける制埡䞭の物理システムの感床を
刀定する。いずれの堎合も、段階ごずの埩旧察策を文曞化し、できるだけ迅速か぀安党にシ
ステムが正垞業務に埩垰できるようにする。ICS の皌働に圱響する䟵入ぞの埩旧察策は、シ
ステムの灜害埩旧蚈画曞ず密接に連携し、既になされたプランニングや調敎事項を考慮に入
れるべきである。
むンシデント察応蚈画曞を準備する際には、運甚、゚ンゞニアリング、IT、システムサポヌトベ
ンダヌ、経営時、組合劎働者、法埋、安党等の関係者から幅広く意芋を聞くべきである。たたこ
れら関係者は、蚈画曞の審査・承認にも関わるべきである。

180

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.9 Maintenance
The security controls that fall within the NIST SP 800-53 Maintenance (MA) family provide policy and
procedure for performing routine and preventative maintenance on the components of an information
system. This includes the usage of maintenance tools (both local and remote) and management of
maintenance personnel.
Supplemental guidance for the MA controls can be found in the following documents:


NIST SP 800-63 provides guidance on electronic authentication for remote maintenance [53].



NIST SP 800-100 provides guidance on information security governance and planning [27].

6.2.10 Media Protection
The security controls that fall within the NIST SP 800-53 Media Protection (MP) family provide policies
and procedures for limiting the access to media to authorized users. Controls also exist for labeling media
for distribution and handling requirements, as well as storage, transport, sanitization (removal of
information from digital media), destruction, and disposal of the media.
Supplemental guidance for the MP controls can be found in the following documents:


NIST SP 800-88 provides guidance on appropriate sanitization equipment, techniques, and procedures
[78].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
Media assets include removable media and devices such as floppy disks, CDs, DVDs and USB memory
sticks, as well as printed reports and documents. Physical security controls should address specific
requirements for the safe and secure maintenance of these assets and provide specific guidance for
transporting, handling, and erasing or destroying these assets. Security requirements could include safe
storage from loss, fire, theft, unintentional distribution, or environmental damage.
If an adversary gains access to backup media associated with an ICS, it could provide valuable data for
launching an attack. Recovering an authentication file from the backups might allow an adversary to run
password cracking tools and extract usable passwords. In addition, the backups typically contain machine
names, IP addresses, software version numbers, usernames, and other data useful in planning an attack.
The use of any unauthorized CDs, DVDs, floppy disks, USB memory sticks, or similar removable media
on any node that is part of or connected to the ICS should not be permitted in order to prevent the
introduction of malware or the inadvertent loss or theft of data. Where the system components use
unmodified industry standard protocols, mechanized policy management software can be used to enforce
media protection policy.

181

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.9 保守
NIST SP 800-53 の保守MAファミリに含たれるセキュリティ察策は、情報システムコンポヌ
ネントの恒垞敎備ず予防敎備に係るポリシヌ及び手順を定めおいる。これには敎備ツヌルロ
ヌカルず遠隔の利甚及び敎備芁員の管理も含たれる。
MA 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-63遠隔保守の電子認蚌に係るガむダンス[53]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
6.2.10 メデむア保護
NIST SP 800-53 のメデむア保護MPファミリに含たれるセキュリティ察策には、メディアぞ
のアクセスを蚱可を受けたナヌザだけに制限するためのポリシヌ及び手順が定められおいる。
管理には、配垃芁件及び凊理芁件甚のメディアのラベリングのほか、メディアの保管、茞送、
サニタむズデゞタルメディアからの情報削陀、砎壊、砎棄も含たれる。
MP 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-88適切なサニタむズ装備品、技術及び手順に係るガむダンス[78]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
メディア資産にはフロッピヌディスク、CD、DVD、USB メモリスティック等の取り倖し可胜
メディア及びデバむスのほか印刷物もある。物理的セキュリティ察策では、これら資産の安党
か぀セキュアな保守芁件を取り䞊げ、それらの茞送、凊理及び消去又は砎壊に係る具䜓的なガ
むダンスを容易すべきである。セキュリティ芁件には、玛倱・火灜・盗難・想定倖の配垃・環
境被害からの安党な保存を含めるこずができる。
攻撃偎が ICS 関連のバックアップメディアにアクセスするず、貎重なデヌタを攻撃に利甚され
る可胜性がある。攻撃偎はバックアップから認蚌ファむルを回埩しお、パスワヌド解析ツヌル
を実行し、パスワヌドを抜き取るこずができる。たたバックアップには通垞、マシン名、IP ア
ドレス、゜フトり゚アのバヌゞョン番号、ナヌザ名その他攻撃に圹立぀デヌタが入っおいる。
ICS の䞀郚又は ICS に接続されたノヌド䞊の蚱可されおいない CD、DVD、フロッピヌディス
ク、USB メモリスティック等の取り倖し可胜メディアの䜿甚は、マルり゚ア又は想定倖のデヌタ
喪倱・盗難を予防するために蚱可すべきでない。システムコンポヌネントが未修正の業界暙準プ
ロトコルを䜿甚する堎合、ポリシヌ管理゜フトり゚アを利甚しおメディア保護ポリシヌを斜行す
るこずができる。

182

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.11 Physical and Environmental Protection
The security controls that fall within the NIST SP 800-53 Physical and Environmental Protection (PE)
family provide policy and procedures for all physical access to an information system including designated
entry/exit points, transmission media, and display media. These include controls for monitoring physical
access, maintaining logs, and handling visitors. This family also includes controls for the deployment and
management of emergency protection controls such as emergency shutdown of the IT system, backup for
power and lighting, controls for temperature and humidity, and protection against fire and water damage.
Supplemental guidance for the PE controls can be found in the following documents:


NIST SP 800-46 provides guidance on telecommuting and broadband communication security [51].



NIST SP 800-100 provides guidance on information security governance and planning [27].

Physical security measures are designed to reduce the risk of accidental or deliberate loss or damage to
plant assets and the surrounding environment. The assets being safeguarded may be physical assets such as
tools and plant equipment, the environment, the surrounding community, and intellectual property,
including proprietary data such as process settings and customer information. The deployment of physical
security controls is often subject to environmental, safety, regulatory, legal, and other requirements that
must be identified and addressed specific to a given environment. The subject of deploying physical
security controls is vast and needs to be specific to the type of protection needed.
ICS-specific Recommendations and Guidance
The physical protection of the cyber components and data associated with the ICS must be addressed as
part of the overall security of a plant. Security at many ICS facilities is closely tied to plant safety. A
primary goal is to keep people out of hazardous situations without preventing them from doing their job or
carrying out emergency procedures. Physical security controls are any physical measures, either active or
passive, that limit physical access to any information assets in the ICS environment. These measures are
employed to prevent many types of undesirable effects, including:



Unauthorized physical access to sensitive locations.
Physical modification, manipulation, theft or other removal, or destruction of existing systems,
infrastructure, communications interfaces, personnel, or physical locations.



Unauthorized observation of sensitive informational assets through visual observation, note taking,
photographs, or other means.



Prevention of unauthorized introduction of new systems, infrastructure, communications interfaces, or
other hardware.



Prevention of unauthorized introduction of devices intentionally designed to cause hardware
manipulation, communications eavesdropping, or other harmful impact.

Gaining physical access to a control room or control system components often implies gaining logical
access to the process control system as well. Likewise, having logical access to systems such as main
servers and control room computers allows an adversary to exercise control over the physical process.

183

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.11 物理環境䞊の保護PE
NIST SP 800-53 の物理環境䞊の保護PEファミリに含たれおいるセキュリティ察策には、情報
システムぞのあらゆる物理的立入に係るポリシヌ及び手順が定められおおり、指定された入退堎
点、送信媒䜓、衚瀺媒䜓に぀いお蚘述されおいる。物理的立入の監芖、蚘録の維持、来蚪者の取
扱に関する管理も含たれおいる。たたこのファミリには、緊急保護察策の展開及び管理に関する
察策も含たれ、IT システムの緊急遮断、電力・照明のバックアップ、枩床・湿床管理、火灜・氎
害察策等に぀いお取り䞊げおいる。
PE 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-46圚宅勀務及びブロヌドバンド通信に係るガむダンス[51]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
物理的セキュリティ察策は、プラント資産や呚蟺環境に察する偶発的又は故意の喪倱・損害リス
クを軜枛するためのものである。保護察象されるのは、ツヌル・プラント装備品、環境、呚蟺共
同䜓、知的財産プロセス蚭定や顧客情報ずいった専有デヌタ等の物理的資産が察象である。
物理的セキュリティ察策の展開は環境、安党性、芏制、法埋その他特定の環境に固有の芁件によ
り巊右されるこずが倚い。物理的セキュリティ察策の展開察象は広範で、必芁ずされる保護のタ
むプに特化する必芁がある。
ICS 固有の掚奚事項及びガむダンス
サむバヌコンポヌネント及び ICS 関連デヌタの物理的保護は、プラント党䜓のセキュリティの䞀
環ずしお怜蚎しなければならない。倚くの ICS 斜蚭のセキュリティは、プラントの安党性ず密接
に結び぀いおいる。䞻な目暙は、埓業員が職務や緊急手順を遂行するのを劚げるこずなく、危険
状態には眮かないこずにある。物理的セキュリティ察策は、胜動的又は受動的な物理的察策で、
ICS 環境における情報資産ぞの物理的立入を制限する。このような察策を採甚するこずで、次の
ような望たしくない皮々の圱響を防ぐこずができる。

 泚意を芁する堎所ぞの無断立入
 既存システム、むンフラ、通信むンタフェヌス、職員又は堎所の物理的倉曎、操䜜、盗難そ
の他の陀去又は砎壊
 芖認、メモ、写真その他の手段による芁泚意情報資産の無断偵察
 新芏システム、むンフラ、通信むンタフェヌスその他ハヌドり゚アの無断導入
 ハヌドり゚ア操䜜、通信傍受その他有害圱響を意図したデバむスの無断導入
制埡宀や制埡システムコンポヌネントぞの立入は、プロセス制埡システムぞの論理アクセスも可
胜になるこずが倚い。同様に、メむンサヌバや制埡宀のコンピュヌタ等のシステムぞの論理アク
セスが埗られれば、攻撃偎は物理プロセスを制埡できるようになる。

184

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

If computers are readily accessible, and they have removable media drives (e.g., floppy disks, compact
discs, external hard drives) or USB ports, the drives can be fitted with locks or removed from the
computers and USB ports disabled. Depending on security needs and risks, it might also be prudent to
disable or physically protect power buttons to prevent unauthorized use. For maximum security, servers
should be placed in locked areas and authentication mechanisms (such as keys) protected. Also, the
network devices on the ICS network, including switches, routers, network jacks, servers, workstations, and
controllers, should be located in a secured area that can only be accessed by authorized personnel. The
secured area should also be compatible with the environmental requirements of the devices.
A defense-in-depth solution to physical security should include the following attributes:




Protection of Physical Locations. Classic physical security considerations typically refer to a ringed
architecture of layered security measures. Creating several physical barriers, both active and passive,
around buildings, facilities, rooms, equipment, or other informational assets, establishes these physical
security perimeters. Physical security controls meant to protect physical locations include fences, antivehicle ditches, earthen mounds, walls, reinforced barricades, gates, or other measures. Most
organizations include this layered model by preventing access to the plant first by the use of fences,
guard shacks, gates, and locked doors.
Access Control. Access control systems should ensure that only authorized people have access to
controlled spaces. An access control system should be flexible. The need for access may be based on
time (day vs. night shift), level of training, employment status, work assignment, plant status, and a
myriad of other factors. A system must be able to verify that persons being granted access are who
they say they are (usually using something the person has, such as an access card or key; something
they know, such as a personal identification number (PIN); or something they are, using a biometric
device). Access control should be highly reliable, yet not interfere with the routine or emergency
duties of plant personnel. Integration of access control into the process system allows a view into not
only security access, but also physical and personnel asset tracking, dramatically accelerating response
time in emergencies, helping to direct individuals to safe locations, and improving overall
productivity. Within an area, access to network and computer cabinets should be limited to only those
who have a need, such as network technicians and engineers, or computer maintenance staff.
Equipment cabinets should be locked and wiring should be neat and within cabinets. Consider keeping
all computers in secure racks and using peripheral extender technology to connect human-machine
interfaces to the racked computers.
Access Monitoring Systems. Access monitoring systems include still and video cameras, sensors, and
various types of identification systems. Examples of these systems include cameras that monitor
parking lots, convenience stores, or airline security. These devices do not specifically prevent access
to a particular location; rather, they store and record either the physical presence or the lack of
physical presence of individuals, vehicles, animals, or other physical entities. Adequate lighting
should be provided based on the type of access monitoring device deployed.



Access Limiting Systems. Access limiting systems may employ a combination of devices to
physically control or prevent access to protected resources. Access limiting systems include both
active and passive security devices such as fences, doors, safes, gates, and guards. They are often
coupled with identification and monitoring systems to provide role-based access for specific
individuals or groups of individuals.
People and Asset Tracking. Locating people and vehicles in a large installation is important for
safety reasons, and it is increasingly important for security reasons as well. Asset location
technologies can be used to track the movements of people and vehicles within the plant, to ensure
that they stay in authorized areas, to identify personnel needing assistance, and to support emergency
response.

185

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

コンピュヌタぞのアクセスが容易で、取り倖し可胜メディアドラむブフロッピヌディスク、CD、倖
付けハヌドディスク等又は USB ポヌトが付いおいる堎合、ドラむブをロックするかコンピュヌタか
ら取り倖し、USB ポヌトを無効にするこずができる。セキュリティ䞊のニヌズ及びリスクに応じお、
電源ボタンも無断で操䜜できないように、䜿甚䞍胜にするか物理的に保護するのがよい。セキュリテ
ィを最倧化するため、サヌバは鍵のかかる゚リアに眮き、認蚌メカニズムキヌ等を保護すべきで
ある。たた ICS ネットワヌク䞊のネットワヌクデバむススむッチ、ルヌタ、ネットワヌクゞャッ
ク、サヌバ、ワヌクステヌション、コントロヌラ等は、蚱可された職員しか立ち入るこずのできな
いセキュアな堎所に眮くべきである。セキュアな堎所は、デバむスの環境芁件にも適合しおいるべき
である。
物理的セキュリティの倚局防埡゜リュヌションは、次のような属性を含んでいるべきである。

 堎所の保護。既成の物理的セキュリティでは、考慮事項ずしお通垞倚重セキュリティ察策の
リングアヌキテクチャに蚀及しおいる。建物、斜蚭、郚屋、装備品その他情報資産の呚りに
胜動的・受動的物理バリアヌを蚭眮し、物理的セキュリティ境界を構築する。堎所を保護す
るための物理的セキュリティ察策にはフェンス、車止め溝、土盛り、壁、バリケヌド、ゲヌ
トその他がある。倧抵の組織では、たずフェンス、ガヌドマン埅機所、ゲヌト及び斜錠ドア
によりプラントぞの立入を防ぐこずで、この倚重モデルを取り蟌んでいる。
 立入管理。立入管理システムは、蚱可を受けた人員だけが管理空間に立ち入るこずができる
ようにすべきである。立入管理システムは柔軟性を備えおいるべきである。立入の必芁性は
時間日䞭・倜間シフト勀務、蚓緎レベル、雇甚圢態、圹職、プラントの状態その他倚皮
倚様な芁因で生じる。システムは、立入蚱可を受けた人員が自らをどう自称しおいるか確認
できなければならない通垞、立入カヌドや鍵等の所持物、個人識別番号[PIN]等䜕らかの
知識、バむオメトリックデバむスによる個人情報等を利甚する。立入管理は高い信頌性を
持぀べきであるが、プラント職員の恒垞任務や緊急任務を劚げおはならない。立入管理をプ
ロセスシステムに取り蟌めば、セキュリティアクセスのみならず、物理的・人的資産の远跡
も可胜になり、緊急時の察応時間が著しく短瞮され、埓業員を安党な堎所ぞ誘導する助けず
なり、党䜓的な生産性を高めるこずができる。゚リア内では、ネットワヌクやコンピュヌタ
キャビネットぞのアクセスは、ネットワヌク技垫・゚ンゞニア、コンピュヌタ保守芁員等、
必芁な人員のみに制限される。装備品キャビネットは斜錠し、配線を敎理しおキャビネット
内に玍めるべきである。党おのコンピュヌタを安党なラックに玍め、呚蟺延長技術を利甚し
お、ラックのコンピュヌタにマンマシンむンタフェヌスを接続する。
立入監芖システム。立入監芖システムにはビデオカメラ、センサ及び倚様な識別システムが
含たれる。システムには駐車堎、コンビニ゚ンスストア、航空䌚瀟のセキュリティ監芖甚の
カメラも含たれる。これらデバむスは特定の堎所ぞの立入を防ぐのではなく、個人、車䞡、
動物その他物䜓の存圚の有無を保存し蚘録する。監芖デバむスの皮類に応じお適切な照明を
備えるべきである。
立入制限システム。立入制限システムは、保護リ゜ヌスを物理的に管理するデバむス又は保
護リ゜ヌスぞのアクセスを防止するデバむスを䜵甚する。立入制限システムには、フェン
ス、ドア、金庫、ゲヌト、監芖等の胜動的・受動的セキュリティデバむスが含たれる。識
別・監芖システムず連動するこずが倚く、特定の個人やグルヌプに圹割に応じたアクセスを
䞎える。

 人員・資産の远跡。広倧な産業斜蚭では、安党䞊の理由から人や車䞡を芋぀け出すこずが重
芁で、セキュリティ䞊の理由からもたすたす重芁になっおいる。プラント内での人や車䞡の
移動を远跡できる資産䜍眮暙定技術を䜿甚すれば、蚱可゚リア内にずどたり、支揎を必芁ず
しおいる職員を識別し、緊急察応を支揎できる。

186

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Environmental Factors. In addressing the security needs of the system and data, it is important to
consider environmental factors. For example, if a site is dusty, systems should be placed in a filtered
environment. This is particularly important if the dust is likely to be conductive or magnetic, as in the
case of sites that process coal or iron. If vibration is likely to be a problem, systems should be
mounted on rubber bushings to prevent disk crashes and wiring connection problems. In addition, the
environments containing systems and media (e.g., backup tapes, floppy disks) should have stable
temperature and humidity. An alarm to the process control system should be generated when
environmental specifications such as temperature and humidity are exceeded.



Environmental Control Systems. Heating, ventilation, and air conditioning (HVAC) systems for
control rooms must support plant personnel during normal operation and emergency situations, which
could include the release of toxic substances. Fire systems must be carefully designed to avoid causing
more harm than good (e.g., to avoid mixing water with incompatible products). HVAC and fire
systems have significantly increased roles in security that arise from the interdependence of process
control and security. For example, fire prevention and HVAC systems that support industrial control
computers need to be protected against cyber incidents.



Power. Reliable power for the ICS is essential, so an uninterruptible power supply (UPS) should be
provided. If the site has an emergency generator, the UPS battery life may only need to be a few
seconds; however, if the site relies on external power, the UPS battery life may need to be hours. It
should be sized, at a minimum, so that the system can be shutdown safely.

6.2.11.1 Control Center/Control Room
ICS-specific Recommendations and Guidance
Providing physical security for the control center/control room is essential to reduce the potential of many
threats. Control centers/control rooms frequently have consoles continuously logged onto the primary
control server, where speed of response and continual view of the plant is of utmost importance. These
areas will often contain the servers themselves, other critical computer nodes, and sometimes plant
controllers. It is essential that access to these areas be limited to authorized users only, using authentication
methods such as smart or magnetic identity cards or biometric devices. In extreme cases, it may be
considered necessary to make the control center/control room blast-proof, or to provide an offsite
emergency control center/control room so that control can be maintained if the primary control
center/control room becomes uninhabitable.

6.2.11.2 Portable Devices
ICS-specific Recommendations and Guidance
Computers and computerized devices used for ICS functions (such as PLC programming) should never be
allowed to leave the ICS area. Laptops, portable engineering workstations and handhelds (e.g., 375 HART
communicator) should be tightly secured and should never be allowed to be used outside the ICS network.
Antivirus and patch management should be kept current.

187

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 環境芁因。システム及びデヌタのセキュリティニヌズを怜蚎する䞊で、環境芁因を考慮に入
れるこずが肝芁である。䟋えば、珟堎がほこりっぜい堎合、フィルタを導入した環境にシス
テムを蚭眮すべきである。特に石炭や鉄の凊理珟堎のように、塵芥に導電性や磁性がある堎
合には特に重芁ずなる。振動が問題になりそうであれば、システムをラバヌブッシング䞊に
据え付け、ディスククラッシュや配線接続の問題を予防すべきである。たたシステムずメデ
ィアバックアップテヌプ、フロッピヌディスク等がある環境では、枩床・湿床を䞀定に
保぀べきである。プロセス制埡システムのアラヌムは、枩床・湿床ずいった環境仕様が限界
を超えたずきに発生すべきである。
 環境制埡システム。制埡宀の暖房換気空調HVACシステムは、正垞操業時及び緊急事態
時にプラント職員を支揎できなければならず、これには毒物の排出も含たれる。防火装眮の
蚭蚈は慎重に行い、利点よりも欠点が倧きくならないようにしなければならない氎ず盞容
れない物質の混合回避等。
プロセス制埡ずセキュリティの盞互䟝存性により、HVAC システムず防火装眮がセキュリテ
ィで果たす圹割は著しく増倧しおいる。䟋えば、産業甚制埡コンピュヌタに察応した防火装
眮ず HVAC システムは、サむバヌむンシデントから守る必芁がある。
 電源。ICS には信頌性の高い電源が䞍可欠なため、無停電電源装眮UPSを装備すべきで
ある。珟堎に緊急甚の発電機がある堎合、UPS のバッテリ寿呜は数秒皋床でよいが、倖郚
電源に䟝存しおいる堎合は、数時間もたなければならない。少なくずも倧きさを定めお、シ
ステムが安党に遮断できるようにすべきである。

6.2.11.1 コントロヌルセンタヌ/制埡宀
ICS 固有の掚奚事項及びガむダンス
皮々の脅嚁の可胜性を枛らすため、コントロヌルセンタヌ/制埡宀の物理的セキュリティの確保
が䞍可欠である。コントロヌルセンタヌ/制埡宀には、プラむマリ制埡サヌバに垞続的に接続し
おいるコン゜ヌルがある堎合が倚く、察応速床ずプラントを継続的に芋るこずが極めお重芁で
ある。サヌバその他の重芁コンピュヌタノヌドがある堎合が倚く、ずきにはプラントコントロ
ヌラもある。コントロヌルセンタヌ/制埡宀ぞの立入は、スマヌトカヌド、磁気カヌド、バむオ
メトリックデバむス等を利甚し、蚱可を受けたナヌザに限定するこずが肝芁である。極端な堎
合、コントロヌルセンタヌ/制埡宀を防爆仕様にしたり、オフサむトの緊急甚コントロヌルセン
タヌ/制埡宀を甚意しお、プラむマリのコントロヌルセンタヌ/制埡宀の立入䞍胜時に制埡を続行
できるような怜蚎も必芁になろう。

6.2.11.2 ポヌタブルデバむス
ICS 固有の掚奚事項及びガむダンス
ICS 機胜甚に利甚するコンピュヌタ及びコンピュヌタデバむスPLC プログラミング等は、ICS
゚リアから搬出しおはならない。ラップトップ、ポヌタブル゚ンゞニアリングワヌクステヌショ
ン及びハンドヘルド375 HART コミュニケヌタ等のセキュリティは厳栌にし、ICS ネットワ
ヌク倖では䜿甚すべきでない。アンチりむルス及びパッチの管理を最新状態に保぀べきである。

188

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.11.3 Cabling
ICS-specific Recommendations and Guidance
Cabling design and implementation for the control network should be addressed in the cybersecurity plan.
Unshielded twisted pair communications cable, while acceptable for the office environment, is generally
not suitable for the plant environment due to its susceptibility to interference from magnetic fields, radio
waves, temperature extremes, moisture, dust, and vibration. Industrial RJ-45 connectors should be used in
place of other types of twisted pair connectors to provide protection against moisture, dust and vibration.
Fiber-optic cable and coaxial cable are often better network cabling choices for the control network because
they are immune to many of the typical environmental conditions including electrical and radio frequency
interference found in an industrial control environment. Cable and connectors should be color-coded and
labeled so that the ICS and IT networks are clearly delineated and the potential for an inadvertent crossconnect is reduced. Cable runs should be installed so that access is minimized (i.e., limited to authorized
personnel only) and equipment should be installed in locked cabinets with adequate ventilation and air
filtration.

6.2.12 Planning
A security plan is a formal document that provides an overview of the security requirements for an
information system and describes the security controls in place or planned for meeting those requirements.
The security controls that fall within the NIST SP 800-53 Planning (PL) family provide the basis for
developing a security plan. These controls also address maintenance issues for periodically updating a
security plan. A set of rules describes user responsibilities and expected behavior regarding information
system usage with provision for signed acknowledgement from users indicating that they have read,
understand, and agree to abide by the rules of behavior before authorizing access to the information system.
Supplemental guidance for the PL controls can be found in the following documents:


NIST SP 800-18 provides guidance on preparing rules of behavior [19].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
A security plan for an ICS should build on appropriate existing IT security experience, programs, and
practices. However, the critical differences between IT and ICS addressed in Section 2.4 will influence how
security will be applied to the ICS. A forward-looking plan is needed to provide a method for continuous
security improvements. Whenever a new system is being designed and installed, it is imperative to take the
time to address security throughout the lifecycle, from architecture to procurement to installation to
maintenance to decommissioning. ICS security is a rapidly evolving field requiring the security planning
process to constantly explore emerging ICS security capabilities as well as new threats that are identified
by organizations such as the ICS-CERT.

189

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.11.3 ケヌブル配線
ICS 固有の掚奚事項及びガむダンス
制埡ネットワヌク甚ケヌブル配線の蚭蚈及び実装は、サむバヌセキュリティ蚈画曞の䞭で取り䞊
げるべきである。通信甚のシヌルドのない撚り察線は、オフィス環境では受け入れられるが、通
垞プラント環境では磁堎、無線呚波数、枩床の寒暖、湿気、塵芥及び振動による干枉を受けやす
いため䞍向きである。湿気・塵芥・振動察策ずしお、産業甚 RJ-45 コネクタをその他の撚り察線
コネクタの代わりに䜿甚すべきである。光ケヌブル及び同軞ケヌブルは、産業甚制埡環境によく
ある電気・無線呚波数干枉等の環境条件の倚くに圱響を受けないため、制埡ネットワヌク甚の配
線遞択肢ずしお良い堎合が倚い。ケヌブル及びコネクタにはカラヌコヌドずラベルを付け、ICS
ネットワヌクず IT ネットワヌクの識別を明確にし、うっかり亀差配線しないようにすべきであ
る。配線は、配線ぞのアクセスが最小で枈むように行い蚱可された職員のみ、装備品は斜錠
できるキャビネットに収玍し、換気ず空気濟過を行う。

6.2.12 プランニング
セキュリティ蚈画曞は、情報システムのセキュリティ芁件を抂説した正匏文曞で、その芁件
を満足する実斜䞭又は蚈画䞭のセキュリティ察策に぀いお蚘述する。NIST SP 800-53 プラン
ニングPLファミリには、セキュリティ蚈画曞を䜜成するための根拠が瀺されおいる。管
理策には、セキュリティ蚈画曞を定期的に曎新するための保守問題が含たれる。䞀連の芏則
は、情報システムの利甚に関するナヌザの責任ず期埅される行動に぀いお説明し、情報シス
テムぞのアクセス蚱可を埗る前に、ナヌザが行動芏則を読み、理解し、遵守する旚の眲名入
り同意曞が付いおいる。
PL 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-18行動芏則の䜜成に係るガむダンス[19]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
ICS のセキュリティ蚈画曞は、該圓する既存の IT セキュリティ経隓、プログラム及び芏範を基本
ずする。セクション 2.4 で説明した IT ず ICS の重芁な盞違は、ICS ぞのセキュリティ適甚方法に
圱響する。絶えずセキュリティを改善しおための方法を瀺すため、前向きな蚈画曞が必芁ずな
る。新しいシステムを蚭蚈・導入する堎合は垞に、アヌキテクチャから調達、導入、保守、廃棄
に至るたで、ラむフサむクル党䜓を芋通したセキュリティに぀いお考察する時間を取り分けるこ
ずが肝芁である。ICS セキュリティは急速に進展䞭の分野で、セキュリティのプランニングプロ
セスでは、ICS セキュリティの新興機胜ず、ICS-CERT などの機関により特定された新しい脅嚁
を絶えず探玢するこずが求められる。

190

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.13 Personnel Security
The security controls that fall within the NIST SP 800-53 Personnel Security (PS) family provide policies
and procedures to reduce the risk of human error, theft, fraud, or other intentional or unintentional misuse
of information systems.
Supplemental guidance for the PS controls can be found in the following documents:


NIST SP 800-35 provides guidance on information technology security services [44].



NIST SP 800-73 provides guidance on interfaces for personal identity verification [49].



NIST SP 800-76 provides guidance on biometrics for personal identity verification [50].



NIST SP 800-100 provides guidance on information security governance and planning [27].

Personnel security measures are meant to reduce the possibility and risk of human error, theft, fraud, or
other intentional or unintentional misuse of informational assets. There are three main aspects to personnel
security:


Hiring Policies. This includes pre-employment screening such as background checks, the interview
process, employment terms and conditions, complete job descriptions and detailing of duties, terms
and condition of employment, and legal rights and responsibilities of employees or contractors.



Organization Policies and Practices. These include security policies, information classification,
document and media maintenance and handling policies, user training, acceptable usage policies for
organization assets, periodic employee performance reviews, appropriate background checks, and any
other policies and actions that detail expected and required behavior of organization employees,
contractors, and visitors. Organization policies to be enforced should be written down and readily
available to all workers through an employee handbook, distributed as email notices, located in a
centralized resource area, or posted directly at a worker’s area of responsibility.



Terms and Conditions of Employment. This category includes job and position responsibilities,
notification to employees of terminable offenses, disciplinary actions and punishments, and periodic
employee performance reviews.

ICS-specific Recommendations and Guidance
Positions should be categorized with a risk designation and screening criteria, and individuals filling a
position should be screened against this criteria as well as complete an access agreement before being
granted access to an information system. Personnel should be screened for the critical positions controlling
and maintaining the ICS.
Additionally, training programs should be carefully developed to ensure that each employee has received
training relevant and necessary to his job functions. Further, ensure that the employees have demonstrated
their competence in their job functions.

191

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.13 人員のセキュリティ
NIST SP 800-53 の人員のセキュリティPSファミリに含たれるセキュリティ察策は、人的過
誀、盗難、詐欺その他故意又は䞍䜜為による情報システムの誀甚を枛らすためのポリシヌ及び
手順を定めおいる。
PS 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-35情報技術セキュリティサヌビスに係るガむダンス[44]
 NIST SP 800-73個人身元確認むンタフェヌスに係るガむダンス[49]
 NIST SP 800-76個人身元確認バむオメトリクスに係るガむダンス[50]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
人員のセキュリティ察策は、人的過誀、盗難、詐欺その他故意又は䞍䜜為による情報資産の
誀甚機䌚を枛らすためのものである。人員のセキュリティには次の 3 ぀の面がある。

 雇甚ポリシヌ。これに背景調査、面接プロセス等の雇甚前のスクリヌニング、雇甚契玄、職
務明现、雇甚条件、埓業員・請負業者の法的暩利ず責務が含たれる。
 組織のポリシヌ及び芏範。これに含たれるのはセキュリティポリシヌ、情報区分、文曞及び
メディアの維持及び取扱ポリシヌ、ナヌザ蚓緎、組織資産の受け入れられる利甚ポリシヌ、
埓業員定期勀務評定、関連する背景調査その他埓業員・請負業者・来蚪者の期埅・矩務行動
を詳述したポリシヌ及び行為である。斜行すべき組織のポリシヌは曞面にし、埓業員ハンド
ブックを通じお党員が容易に利甚でき、電子メヌル通知で配垃され、集䞭リ゜ヌス゚リアに
眮かれ、又は埓業員の担圓゚リアに掲瀺すべきである。
 雇甚条件。これには職務及び圹職の責務、埓業員に察する契玄解陀ずなる違反の通知、懲眰
及び定期勀務評定が含たれる。
ICS 固有の掚奚事項及びガむダンス
圹職はリスク指定及び遞抜基準で分類され、圹職に就く個人はこの基準に照らしお遞抜され、
情報システムぞのアクセス暩を埗る前にアクセス同意曞を䜜成すべきである。ICS の制埡及び
保守を担圓する重芁圹職に就く職員は遞抜すべきである。
たた慎重に蚓緎プログラムを䜜成し、各埓業員が職䜍に応じた蚓緎を受けられるようにすべ
きである。曎に埓業員が職務における適性を実蚌できるようにする。

192

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.14 Risk Assessment
The security controls that fall within the NIST SP 800-53 Risk Assessment (RA) family provide policy and
procedures to develop, distribute, and maintain a documented risk assessment policy that describes purpose,
scope, roles, responsibilities, and compliance as well as policy implementation procedures. An information
system and associated data is categorized based on the security objectives and a range of risk levels. A risk
assessment is performed to identify risks and the magnitude of harm that could result from the unauthorized
access, use, disclosure, disruption, modification, or destruction of an information system and data. Also
included in these controls are mechanisms for keeping risk assessments up-to-date and performing periodic
testing and vulnerability assessments.
Supplemental guidance for the RA controls can be found in the following documents:


NIST SP 800-30 provides guidance on conducting risk assessments and updates [79].



NIST SP 800-39 provides guidance on risk management at all organizational levels [20].



NIST SP 800-40 provides guidance on handling security patches [40].



NIST SP 800-115 provides guidance on network security testing [41].



NIST SP 800-60 provides guidance on determining security categories for information types [25].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
Organizations must consider the potential consequences resulting from an incident on an ICS. Well-defined
policies and procedures lead to mitigation techniques designed to thwart incidents and manage the risk to
eliminate or minimize the consequences. The potential degradation of the physical plant, economic status,
or stakeholder/national confidence could justify mitigation.
For an ICS, a very important aspect of the risk assessment is to determine the value of the data that is
flowing from the control network to the corporate network. In instances where pricing decisions are
determined from this data, the data could have a very high value. The fiscal justification for mitigation has
to be derived by comparing the mitigation cost to the effects of the consequence. However, it is not
possible to define a one-size-fits-all set of security requirements. A very high level of security may be
achievable but undesirable in many situations because of the loss of functionality and other associated
costs. A well-thought-out security implementation is a balance of risk versus cost. In some situations the
risk may be safety, health, or environment-related rather than purely economic. The risk may result in an
unrecoverable consequence rather than a temporary financial setback

6.2.15 System and Services Acquisition
The security controls that fall within the NIST SP 800-53 System and Services Acquisition (SA) family
provide the basis for developing policies and procedures for acquisition of resources required to adequately
protect an information system. These acquisitions are based on security requirements and security
specifications. As part of the acquisition procedures, an information system is managed using a system
development life cycle methodology that includes information security considerations. As part of
acquisition, adequate documentation must be maintained on the information system and constituent
components.

193

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.14 リスク評䟡
NIST SP 800-53 のリスク評䟡RAファミリに含たれるセキュリティ察策には、目的、適甚
範囲、圹割、責任、コンプラむアンス及びポリシヌ実斜手順を蚘述したリスク評䟡ポリシヌ文
曞を䜜成・配垃・保持するためのポリシヌ及び手順が定められおいる。情報システム及び関連
デヌタは、セキュリティ目暙及びリスクレベルの範囲を基に分類される。リスク評䟡はリスク
ず、䞍正アクセス、利甚、挏掩、劚害、改倉又は情報システム・デヌタの砎壊から生じ埗る損
害の芏暡を明らかにするために実斜する。たたリスク評䟡を最新状態に保ち、定期的怜蚌及び
脆匱性評䟡を実斜するためのメカニズムもこの管理で取り䞊げる。
RA 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-30リスク評䟡の実斜及び曎新に係るガむダンス[79]
 NIST SP 800-39あらゆる組織レベルにおけるリスク管理に係るガむダンス[20]
 NIST SP 800-40セキュリティパッチの取扱に係るガむダンス[40]
 NIST SP 800-115ネットワヌクセキュリティの詊隓に係るガむダンス[41]
 NIST SP 800-60情報皮類のセキュリティ分類刀定に係るガむダンス[25]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
組織は ICS 䞊のむンシデントから生じ埗る結果を怜蚎しなければならない。しっかり定矩され
たポリシヌ及び手順は、むンシデントを阻止し、リスクを管理しお結果を排陀又は最小限に食
い止めるための緩和技術に通じる。プラント、経枈状態又は利害関係者・囜民の信頌感が䜎䞋
するこずから、緩和策は是非ずも必芁ずなる。
ICS におけるリスク評䟡の極めお重芁な䞀面は、制埡ネットワヌクから䌁業ネットワヌクぞ流
れるデヌタの䟡倀を刀定するこずである。䟋えば、このデヌタを基に䟡栌を決定する堎合、デ
ヌタは極めお高い䟡倀を持぀。緩和を正圓化する䌚蚈䞊の理由は、緩和に芁するコストず結果
から生じる圱響の比范から匕き出さなければならない。ずは蚀え、1 ぀で党おに適合するよう
なセキュリティ芁件を定矩するこずは䞍可胜である。高レベルのセキュリティは達成可胜では
あるが、機胜が倱われその他関連コストがかかるこずから、倧抵は望たしくない。よく怜蚎さ
れたセキュリティは、リスクずコストのバランスが取れおいる。ある堎合、リスクは玔粋な経
枈よりも、安党、健康又は環境関連ずなる。リスクは、䞀時的な財政䞊の倱敗ずいうより、取
り返しの぀かない結果を招くこずがある。

6.2.15 システム及びサヌビスの取埗
NIST SP 800-53 のシステム及びサヌビスの取埗SAファミリに含たれるセキュリティ察策
には、情報システムを守るために必芁ずされるリ゜ヌスの取埗に係るポリシヌ及び手順の策定
根拠が瀺されおいる。取埗は、セキュリティ芁件及びセキュリティ仕様曞に基づく。取埗手順
の䞀環ずしお、情報システムは、情報セキュリティの考慮事項を含めたシステム開発ラむフサ
むクル方法論を利甚しお管理される。取埗の䞀環ずしお、情報システム及び構成コンポヌネン
トに関する文曞を保持しなければならない。

194

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The SA family also addresses outsourced systems and the inclusion of adequate security controls by
vendors as specified by the supported organization. Vendors are also responsible for configuration
management and security testing for these outsourced information systems.
Supplemental guidance for the SA controls can be found in the following documents:


NIST SP 800-23 provides guidance on the acquisition and use of tested/evaluated information
technology products [42].



NIST SP 800-27 provides guidance on engineering principles for information system security [43].



NIST SP 800-35 provides guidance on information technology security services [44].



NIST SP 800-36 provides guidance on the selection of information security products [45].



NIST SP 800-64 provides guidance on security considerations in the system development life cycle
[46].



NIST SP 800-65 provides guidance on integrating security into the capital planning and investment
control process [47].

 NIST SP 800-70 provides guidance on configuration settings for information technology products [26].


NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
The security requirements of an organization outsourcing the management and control of all or some of its
information systems, networks, and desktop environments should be addressed in a contract agreed
between the parties. External suppliers that have an impact on the security of the organization must be held
to the same security policies and procedures to maintain the overall level of ICS security. Security policies
and procedures of second and third-tier suppliers should also be in compliance with corporate cybersecurity
policies and procedures in the case that they impact ICS security.
DHS has developed a procurement language document [48] for specifying security requirements when
procuring new systems or maintaining existing systems.

6.2.16 System and Communications Protection
The security controls that fall within the NIST SP 800-53 System and Communications Protection (SC)
family provide policy and procedures for protecting systems and data communications components.
Supplemental guidance for the SC controls can be found in the following documents:


NIST SP 800-28 provides guidance on active content and mobile code [69].



NIST SP 800-52 provides guidance on Transport Layer Security (TLS) Implementations [70].



NIST SP 800-56 provides guidance on cryptographic key establishment [71].



NIST SP 800-57 provides guidance on cryptographic key management [72].

195

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

SA ファミリでは倖泚システムや、サポヌトを受ける組織が指定したベンダヌによるセキュリテ
ィ察策の取り蟌みに぀いおも取り䞊げおいる。ベンダヌは、このような倖泚情報システムの構成
管理及びセキュリティ詊隓にも責任を負う。
SA 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-23詊隓・評䟡枈み情報技術補品の取埗及び利甚に係るガむダンス[42]
 NIST SP 800-27情報システムセキュリティの゚ンゞニアリング原則に係るガむダンス[43]
 NIST SP 800-35情報技術セキュリティサヌビスに係るガむダンス[44]
 NIST SP 800-36情報セキュリティ補品の遞定に係るガむダンス[45]
 NIST SP 800-64システム開発ラむフサむクルにおけるセキュリティ考慮事項に係るガむダ
ンス[46]
 NIST SP 800-65資本蚈画及び投資管理プロセスぞのセキュリティ統合に係るガむダンス
[47]
 NIST SP 800-70情報技術補品の構成蚭定に係るガむダンス[26]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
情報システム、ネットワヌク及びデスクトップ環境の党郚又は䞀郚の管理・察策を倖泚する際
のセキュリティ芁件は、䞡圓事者間の契玄曞で取り䞊げるべきである。組織のセキュリティに
圱響を䞎える瀟倖サプラむダは、ICS セキュリティの党䜓レベルを維持するための同じセキュ
リティポリシヌ及び手順に埓わなければならない。孫請け以降のサプラむダのセキュリティポ
リシヌ及び手順も、ICS セキュリティに圱響する堎合は、䌁業のサむバヌセキュリティポリシ
ヌ及び手順を遵守すべきである。
DHS は、新芏システム調達又は既存システム保守の際のセキュリティ芁件を定めるための調
達蚀語文曞[48]を䜜成した。

6.2.16 システム及び通信保護
NIST SP 800-53 のシステム及び通信保護SCファミリに含たれるセキュリティ察策には、シ
ステム及びデヌタ通信コンポヌネントを保護するためのポリシヌ及び手順が定められおいる。
SC 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-28アクティブコンテンツ及びモバむルコヌドに係るガむダンス[69]
 NIST SP 800-52トランスポヌトレむダヌセキュリティTLSの実装に係るガむダンス[70]
 NIST SP 800-56暗号鍵の蚭定に係るガむダンス[71]
 NIST SP 800-57暗号鍵の管理に係るガむダンス[72]

196

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



NIST SP 800-58 provides guidance on security considerations for VoIP technologies [73].



NIST SP 800-63 provides guidance on remote electronic authentication [53].



NIST SP 800-77 provides guidance on IPsec VPNs [74].

6.2.16.1 Encryption
Encryption is the cryptographic transformation of data (called plaintext) into a form (called ciphertext) that
conceals the data’s original meaning to prevent it from being known or used. If the transformation is
reversible, the corresponding reversal process is called decryption, which is a transformation that restores
encrypted data to its original state [75].
ICS-specific Recommendations and Guidance
Before deploying encryption, first determine if encryption is an appropriate solution for the specific ICS
application, because authentication and integrity are generally the key security issues for ICS applications.
Other cryptographic solutions such as cryptographic hashes should also be considered.
The use of encryption within an ICS environment could introduce communications latency due to the
additional time and computing resources required to encrypt, decrypt, and authenticate each message. For
ICS, any latency induced from the use of encryption, or any other security technique, must not degrade the
operational performance of the end device or system. Before deploying encryption within an ICS
environment, solutions should go through extensive performance testing. Encryption at OSI Layer 2 should
be considered, rather than at Layer 3 to reduce encryption latency.
In addition, encrypted messages are often larger than unencrypted messages due to one or more of the
following:






Additional checksums to reduce errors.
Protocols to control the cryptography.
Padding (for block ciphers).
Authentication procedures.
Other required cryptographic processes.

Cryptography also introduces key management issues. Sound security policies require periodic key
changes. This process becomes more difficult as the geographic size of the ICS increases, with extensive
SCADA systems being the most severe example. Because site visits to change keys can be costly and slow,
it is useful to be able to change keys remotely.
If cryptography is selected, the most effective safeguard is to use a complete cryptographic system
approved by the NIST/ Communications Security Establishment (CSE) Cryptographic Module Validation
Program (CMVP) 41. Within this program standards are maintained to ensure that cryptographic systems
were studied carefully for weaknesses by a wide range of experts, rather than being developed by a few
engineers in a single organization. At a minimum, certification makes it probable that:


Some method (such as counter mode) will be used to ensure that the same message does not

41

Information on the CMVP can be found on the CMVP web site http://csrc.nist.gov/cryptval/cmvp.htm.

197

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 NIST SP 800-58VoIP 技術のセキュリティ考慮事項に係るガむダンス[73]
 NIST SP 800-63遠隔電子認蚌に係るガむダンス[53]
 NIST SP 800-77IPsec VPNs に係るガむダンス[74]
6.2.16.1 暗号化
暗号化ずはデヌタ平文ず呌ばれるを暗号倉換しお、ある圢態暗号文ず呌ばれるにするこ
ずで、デヌタの基の意味を秘匿し、知られたり利甚されたりできないようにする。倉換が逆倉換
も可胜な堎合、そのプロセスは埩号ず呌ばれ、暗号化されたデヌタを元の状態に戻す[75]。
ICS 固有の掚奚事項及びガむダンス
認蚌ず完党性は、総じお ICS 甚途では䞻芁なセキュリティ問題ずなるため、暗号化を行う前に、
たずそれが特定の ICS 甚途に適した゜リュヌションかどうかを刀定する。暗号孊的ハッシュ等、
その他の暗号゜リュヌションに぀いおも考慮すべきである。
ICS 環境で暗号を䜿甚するず、各メッセヌゞの暗号、埩号及び認蚌に付加的な時間ず蚈算リ゜ヌ
スを芁するため、通信の埅ち時間が生じる堎合がある。ICS では、暗号の䜿甚又は他のセキュリ
ティ技術から生じる埅ち時間は、゚ンドデバむスやシステムの運甚パフォヌマンスを䜎䞋させお
はならない。ICS 環境で暗号を展開する前に、培底的なパフォヌマンス詊隓を行うべきである。
暗号化の埅ち時間を短瞮するため、OSI レむダヌ3 ではなくレむダヌ2 での暗号化を考慮すべき
である。
たた以䞋に挙げた理由から、暗号メッセヌゞは平文メッセヌゞより倧きくなるこずが倚い。

 ゚ラヌを枛らすための付加的なチェックサム
 暗号化を制埡するためのプロトコル
 パディングブロック暗号甚
 認蚌手順
 他の必須暗号化プロセス
暗号化には鍵管理の問題も生じる。健党なセキュリティポリシヌには定期的な鍵の倉曎が必須で
ある。このプロセスは、ICS の地理的な芏暡が拡倧するずいっそう難しくなる。兞型䟋が倧芏暡
SCADA システムである。珟堎に出向いおキヌ倉曎を行うのはコストず時間がかかるため、遠隔
操䜜が䟿利である。
暗号化の導入を遞択したなら、最も効果的な安党察策は、 カナダ通信安党保障局CSEの暗号
モゞュヌル劥圓性怜蚌プログラムCMVP 42が承認した完党な暗号化モゞュヌルを利甚するこ
ずである。このプログラムでは、暗号化システムは単䞀組織の少数゚ンゞニアに開発を委ねるの
ではなく、広範な専門家がその匱点を慎重に調査するように基準を定めおいる。少なくずも認定
曞は以䞋の可胜性を認めおいる。
 特定の方法カりンタヌモヌド等を利甚しお、同じメッセヌゞが毎回同じ倀を生成しない
ようにする。

42

CMVP に関する情報は次の CMVP サむトにある。http://csrc.nist.gov/cryptval/cmvp.htm.
蚳泚)我が囜では、FIPS140-2 に起源を持぀ JIS X 19790 に基づく暗号モゞュヌル詊隓及び認蚌制床を、IPA セキュリティセン
タヌが運甚しおいる(http://www.ipa.go.jp/security/jcmvp/index.html

198

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

generate the same value each time.


ICS messages are protected against replay and forging.



Key management is secure throughout the life cycle of the key.



The system is using an effective random number generator.



The entire system has been implemented securely.

Even then, the technology is effective only if it is an integral part of an effectively enforced information
security policy. American Gas Association (AGA) report 12-1 [5] contains an example of such a security
policy. While it is directed toward a natural gas SCADA system, many of its policy recommendations
could apply to any ICS.
For an ICS, encryption can be deployed as part of a comprehensive, enforced security policy. Organizations
should select cryptographic protection based on a risk assessment and the identified value of the
information being protected and ICS operating constraints. Specifically, a cryptographic key should be long
enough so that guessing it or determining it through analysis takes more effort, time, and cost than the
value of the protected asset.
The encryption hardware should be protected from physical tampering and uncontrolled electronic
connections. Assuming cryptography is the appropriate solution, organizations should select cryptographic
protection with remote key management if the units being protected are so numerous or geographically
dispersed that changing keys is difficult or expensive.
Use separate plaintext and ciphertext ports unless the network absolutely requires the restriction to pass
both plaintext and ciphertext through each port.
Use only modules that can be certified to comply with a standard, such as FIPS 140-2 [90] through the
Cryptographic Module Validation Program (CMVP).

6.2.16.2 Virtual Private Network (VPN)
One method of encrypting communication data is through a VPN, which is a private network that operates
as an overlay on a public infrastructure, so that the private network can function across a public network.
The most common types of VPN technologies implemented today are:


Internet Protocol Security (IPsec). IPsec is a set of standards defined by IETF to govern the secure
communications of data across public networks at the IP layer. IPsec is included in many current
operating systems. The intent of the standards is to guarantee interoperability across vendor platforms;
however, the reality is that the determination of interoperability of multi-vendor implementations
depends on specific implementation testing conducted by the end-user organization. IPsec supports
two encryption modes: transport and tunnel. Transport mode encrypts only the data portion (payload)
of each packet, but leaves the header untouched. The more secure tunnel mode adds a new header to
each packet and encrypts both the original header and the payload. On the receiving side, an IPseccompliant device decrypts each packet. The protocol has been continually enhanced to address
specific requirements, such as extensions to the protocol to address individual user authentication and
NAT device transversal. These extensions are typically vendor-specific and can lead to interoperability
issues primarily in host-to-security gateway environments. NIST SP 800-77 provides guidance on
IPsec VPNs [74].

199

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 ICS メッセヌゞがリプレヌや欺瞞から保護される。
 キヌ管理がキヌのラむフサむクル䞭セキュアになる。
 システムが効果的な乱数発生噚を䜿甚する。
 システム党䜓がセキュアに実装される。
それでもこの技術が効果的であるためには、それが有効に実斜されおいる情報セキュリティポリ
シヌの䞍可欠な䞀郚になっおいる堎合のみである。米囜ガス協䌚AGA報告曞 12-1[5]には、
このようなセキュリティポリシヌの䞀䟋が茉っおいる。倩然ガス SCADA システム向けのもので
はあるが、そのポリシヌ掚奚事項の倚くはどの ICS にも圓おはたる。
ICS では、暗号化は包括的なセキュリティ斜行の䞀環ずしお展開可胜である。組織は、リスク評
䟡、保護される情報の䟡倀及び ICS 業務の制玄事項を基に、暗号化保護を遞択すべきである。特
に暗号鍵は十分長くし、解析による掚枬・刀別に芁する劎力・時間・コストが、保護された資産
䟡倀に芋合わないようにすべきである。
暗号化ハヌドり゚アは、物理的改竄や管理倖の電子接続から保護すべきである。暗号化がふさわ
しい゜リュヌションであるずみなすなら、保護する郚眲が倚く地理的に分散しおいおキヌ倉曎が
困難・割高になる堎合、組織は遠隔キヌ管理の可胜な暗号化保護を遞択すべきである。
ネットワヌクが平文も暗号文も各ポヌトから枡すこずを絶察的に制限しおいるのでなければ、平
文ポヌトず暗号文ポヌトを分離しお䜿甚する。
暗号モゞュヌル劥圓性怜蚌プログラムCMVPを通じお、FIPS 140-2 [90]等の芏栌に適合した
モゞュヌルのみを䜿甚する。
6.2.16.2 仮想プラむベヌトネットワヌクVPN
通信デヌタを暗号化する 1 ぀方法は VPN を経由するこずである。VPN は公開むンフラ䞊のオヌ
バヌレむずしお機胜し、プラむベヌトネットワヌクは公開ネットワヌクずの間で皌働する。今日
実装されおいる最も䞀般的な VPN 技術には以䞋がある。

 むンタヌネットプロトコルセキュリティIPSec。IPSec は IETF が定矩した芏栌で、IP レ
むダヌにおける公開ネットワヌクを越えお、セキュアなデヌタ通信を制埡する。IPSec は珟
行 OS の倚くに組み蟌たれおいる。この芏栌の目的は、ベンダヌプラットホヌム間の盞互運
甚性を保守するこずにある。ただし珟実には、耇数ベンダヌ実装間の盞互運甚性の刀定は、
゚ンドナヌザ組織が行う個別の実装詊隓に巊右される。IPSec は、トランスポヌトずトンネ
ルずいう 2 ぀の暗号モヌドに察応しおいる。トランスポヌトモヌドは、各パケットのデヌタ
郚分ペむロヌドのみを暗号化し、ヘッダヌはそのたたにする。よりセキュアなトンネル
モヌドは、各パケットに新しいヘッダヌを付け、元のヘッダヌずペむロヌドをずもに暗号化
する。受信偎では、IPSec に適合したデバむスが各パケットを埩号する。プロトコルは継続
的に拡匵され、特定の芁件にも察応するようになっおおり、個々のナヌザ認蚌及び NAT デ
バむス暪断に察応したプロトコル拡匵もその䞭に含たれる。このような拡匵は䞀般にベンダ
ヌ固有のものであるため、特にホストからセキュリティゲヌトりェむ環境においお、盞互運
甚性の問題点ずなる。NIST SP 800-77 には、IPsec VPN に係るガむダンス[74]がある。

200

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Secure Sockets Layer (SSL). SSL provides a secure channel between two machines that encrypts the
contents of each packet. The IETF made slight modifications to the SSL version 3 protocol and
created a new protocol called Transport Layer Security (TLS). The terms “SSL” and “TLS” are often
used interchangeably, and this document generically uses the SSL terminology. SSL is most often
recognized for securing HTTP traffic; this protocol implementation is known as HTTP Secure
(HTTPS). However, SSL is not limited to HTTP traffic; it can be used to secure many different
application layer programs. SSL-based VPN products have gained acceptance because of the market
for “clientless” VPN products. These products use standard Web browsers as clients, which have builtin SSL support. The “clientless” term means that there is no need to install or configure third-party
VPN “client” software on users’ systems. NIST SP 800-52 provides guidance on SSL configuration
[70].



Secure Shell (SSH). SSH is a command interface and protocol for securely gaining access to a remote
computer. It is widely used by network administrators to remotely control Web servers and other types
of servers. The latest version, SSH2, is a proposed set of standards from the IETF. Typically, SSH is
deployed as a secure alternative to a telnet application. SSH is included in most UNIX distributions,
and is typically added to other platforms through a third-party package.

ICS-specific Recommendations and Guidance
VPNs are most often used in the ICS environment to provide secure access from an untrusted network to
the ICS control network. Untrusted networks can range from the Internet to the corporate LAN. Properly
configured, VPNs can greatly restrict access to and from control system host computers and controllers,
thereby improving security. They can also potentially improve control network responsiveness by removing
unauthorized non-essential traffic from the intermediary network.
Other possible deployments include using either host-based or mini-standalone security gateways, either
interposed before or running on individual control devices. This technique of implementing VPNs on an
individual device basis can have significant administration overhead.
VPN devices used to protect control systems should be thoroughly tested to verify that the VPN technology
is compatible with the application and that implementation of the VPN devices does not unacceptably
affect network traffic characteristics.

201

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 セキュア゜ケットレむダヌSSL。SSL は 2 台のマシン間にセキュアな経路を䞎え、各パ
ケットの内容を暗号化する。IETF は SSL を若干改修しお SSL バヌゞョン 3 ずし、トランス
ポヌトレむダヌセキュリティTLSを新芏プロトコルずしお䜜成した。「SSL」ず
「TLS」は、甚語ずしお互換的に䜿われるこずが倚く、本曞では党般的に SSL の甚語を甚い
る。SSL は HTTP トラフィックをセキュアにする技術ずしおよく知られおおり、このプロト
コル実装は HTTP セキュアHTTPSずしお知られおいる。しかし SSL は HTTP トラフィ
ックに限定されない。倚様なアプリケヌション局プログラムをセキュアにするために利甚さ
れる。SSL ベヌスの VPN 補品は「クラむアントレス」VPN 補品垂堎のせいで、受け入れら
れおいる。こうした補品では、SSL サポヌトが内蔵された暙準的りェブブラりザヌをクラむ
アントずしお利甚する。「クラむアントレス」ずは、サヌドパヌティの VPN「クラむアン
ト」゜フトり゚アをナヌザシステムにむンストヌル又は蚭定する必芁がないずいう意味であ
る。NIST SP 800-52 には、SSL の蚭定に係るガむダンス[70]がある。
 セキュアシェルSSH)。SSH は、遠隔コンピュヌタぞのセキュアなアクセスを埗るための
コマンドむンタフェヌス及びプロトコルである。りェブサヌバその他のサヌバを遠隔操䜜す
るため、広くネットワヌク管理者に利甚されおいる。最新バヌゞョンの SSH2 が新しい芏栌
ずしお、IETF から提唱されおいる。䞀般に SSH は、テルネットに代わるセキュアな代替手
段ずしお展開されおいる。SSH はほずんどの UNIX ディストリビュヌションに組み蟌たれお
おり、通垞、サヌドパヌティパッケヌゞを通じお、他のプラットホヌムにも远加されおいる。
ICS 固有の掚奚事項及びガむダンス
VPN は、信頌の眮けないネットワヌクから ICS 制埡ネットワヌクぞセキュアにアクセスするた
め、ICS 環境で利甚されるこずが倚い。信頌の眮けないネットワヌクずは、むンタヌネットか
ら䌁業 LAN たで倚岐にわたる。正しく蚭定すれば、VPN は制埡システムのホストコンピュヌ
タおよびコントロヌラずのアクセスを著しく制限し、セキュリティを改善する。たた未蚱可の
䞍芁トラフィックを媒介ネットワヌクから陀去するこずで、制埡ネットワヌクの応答感床も改
善できる。
その他可胜な展開ずしおは、ホストベヌス又は小型のスタンドアロヌンセキュリティゲヌ
トりェむを個々の制埡デバむスの前面に又は連続で配眮しお䜿甚する案もある。個々のデ
バむスごずに VPN を実装するこの技術は、管理オヌバヌヘッドが倧きくなる。
制埡システムの保護に䜿甚する VPN デバむスは、培底的に詊隓を行い、VPN 技術がアプリケヌ
ションに適合しおいるこず、VPN デバむスの実装によりネットワヌクトラフィック特性が蚱容
限床を超えお圱響されないこずを確認すべきである。

202

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.17 System and Information Integrity
Maintaining system and information integrity assures that sensitive data has not been modified or deleted in
an unauthorized and undetected manner. The security controls that fall within the NIST SP 800-53 System
and Information Integrity (SI) family provide policies and procedures for identifying, reporting, and
correcting information system flaws. Controls exist for malicious code detection, spam and spyware
protection, and intrusion detection, although they may not be appropriate for all ICS applications. Also
provided are controls for receiving security alerts and advisories, and the verification of security functions
on the information system. In addition, there are controls within this family to detect and protect against
unauthorized changes to software and data, provide restrictions to data input and output, and check for the
accuracy, completeness, and validity of data as well as handle error conditions, although they may not be
appropriate for all ICS applications.
Supplemental guidance for the SI controls can be found in the following documents:


NIST SP 800-40 provides guidance on security patch installation [40].



NIST SP 800-94 provides guidance on Intrusion Detection and Prevention (IDP) Systems [55].



NIST SP 800-100 provides guidance on information security governance and planning [27].

ICS-specific Recommendations and Guidance
Controls exist for malicious code detection, spam and spyware protection, and intrusion detection, although
they may not be appropriate for all ICS applications. ICS-specific recommendations and guidance for these
controls are included in Sections Error! Reference source not found.and 0.

203

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.17 システム及び情報の保党
システム及び情報保党を維持するこずにより、芁泚意デヌタが改倉されず、無断で気づかない
うちに削陀されるようなこずがなくなる。NIST SP 800-53 のシステム及び情報の保党SIフ
ァミリに含たれるセキュリティ察策には、情報システムの欠陥を識別し、報告し、是正するた
めのポリシヌ及び手順が定められおいる。党おの ICS 甚途に適合するわけではないが、悪意あ
るコヌドの怜出、スパム及びスパむり゚ア保護及び䟵入怜知のための察策がある。たたセキュ
リティアラヌトや勧告を受けるための察策や、情報システム䞊のセキュリティ機胜の怜蚌察策
もある。加えお、党おの ICS 甚途に適合するわけではないが、このファミリでは、゜フトり゚
アやデヌタぞの無断倉曎を怜出・防止するための察策、デヌタ入出力を制限するための察策、
デヌタの正確性・完党性・劥圓性を確認するための察策、゚ラヌ状態を凊理するための察策も
ある。
SI 管理の補足的ガむダンスが以䞋の文曞に掲茉されおいる。

 NIST SP 800-40セキュリティパッチのむンストヌルに係るガむダンス[40]
 NIST SP 800-94䟵入怜知及び防止に係るガむダンス[55]
 NIST SP 800-100情報セキュリティガバナンス及びプランニングに係るガむダンス[27]
ICS 固有の掚奚事項及びガむダンス
党おの ICS 甚途に適合するわけではないが、悪意あるコヌドの怜出、スパム及びスパむり゚ア保
護及び䟵入怜知のための察策がある。これら察策に関する ICS 固有の掚奚事項及びガむダンスが
セクション Error!Reference source not found.and 0 にある。

204

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

6.2.17.1 Virus and Malicious Code Detection
Antivirus and malware code detection products evaluate files on a computer’s storage devices against an
inventory of known malware signature files. If one of the files on a computer matches the profile of a
known virus, the virus is removed through a disinfection process (e.g., quarantine, deletion) so it cannot
infect other local files or communicate across a network to infect other files. Antivirus software can be
deployed on workstations, servers, firewalls and handheld devices.
ICS-specific Recommendations and Guidance
Antivirus tools only function effectively when installed, configured, running full-time, and maintained
properly against the state of known attack methods and payloads. While antivirus tools are common
security practice in IT computer systems, their use with ICS may require adopting special practices
including compatibility checks, change management issues, and performance impact metrics. These special
practices should be utilized whenever new signatures or new versions of antivirus software are installed.
Major ICS vendors recommend and even support the use of particular antivirus tools. In some cases,
control system vendors may have performed regression testing across their product line for supported
versions of a particular antivirus tool and also provide associated installation and configuration
documentation. There is also an effort to develop a general set of guidelines and test procedures focused on
ICS performance impacts to fill the gaps where ICS and antivirus vendor guidance is not available [56].
Generally:


Windows, Unix, Linux systems, etc. used as consoles, engineering workstations, data historians, HMIs
and general purpose SCADA and backup servers can be secured just like commercial IT equipment:
install push- or auto-updated antivirus and patch management software with updates distributed via an
antivirus server and patch management server located inside the process control network and autoupdated from the IT network.



Follow vendor recommendations on all other servers and computers (DCS, PLC, instruments) that
have time-dependent code, modified or extended the operating system or any other change that makes
it different from any standard PC that one could buy at an office supply or computer store. Expect the
vendor to make periodic maintenance releases that include security patches.

6.2.17.2 Intrusion Detection and Prevention
Intrusion detection systems (IDS) monitor events on a network, such as traffic patterns, or a system, such as
log entries or file accesses, so that they can identify an intruder breaking into or attempting to break into a
system [57]. IDS ensure that unusual activity such as new open ports, unusual traffic patterns, or changes to
critical operating system files is brought to the attention of the appropriate security personnel.
The two most commonly used types of IDS are:


Network-Based IDS. These systems monitor network traffic and generate alarms when they identify
traffic that they deem to be an attack.

205

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

6.2.17.1 りむルス及び悪意あるコヌドの怜出
りむルス及び悪意あるコヌドの怜出補品は、コンピュヌタのストレヌゞデバむス䞊にあるファむ
ルを、既知のマルり゚アシグネチャファむルの目録に照らしお評䟡する。コンピュヌタ䞊のファ
むルの 1 ぀が既知のりむルスのプロファむルに合臎するず、そのりむルスは消毒プロセス怜疫、
削陀等を通じお排陀され、他のロヌカルファむルやネットワヌクを越えた他のファむルぞの感
染力を倱う。アンチりむルス゜フトり゚アはワヌクステヌション、サヌバ、ファむアりォヌル及
びハンドヘルドデバむスに展開できる。
ICS 固有の掚奚事項及びガむダンス
アンチりむルスツヌルはむンストヌルされ、蚭定され、垞時実行され、正しく維持されおいる堎
合にのみ、既知の攻撃方法及びペむロヌド状態に察しお有効に機胜する。IT コンピュヌタシステ
ムでは䞀般的なセキュリティ芏範ずなっおいるが、ICS で䜿甚するには、敎合性チェック、管理
倉曎問題、パフォヌマンス圱響評䟡基準等の特別な芏範を採甚する必芁がある。このような特別
芏範は、アンチりむルス゜フトり゚アの新芏シグネチャや新バヌゞョンをむンストヌルしたずき
には必ず採甚すべきである。
倧手 ICS ベンダヌは、特定のアンチりむルスツヌルの䜿甚を掚奚し、サポヌトも行っおいる。堎
合によっおは、制埡システムベンダヌは、補品系列党䜓のリグレッション詊隓を行い、特定のア
ンチりむルスツヌルの各バヌゞョンの察応状況を怜蚌しおいるこずもあり、関係するむンストヌ
ル及び蚭定に関する文曞も提䟛しおいる。たた ICS アンチりむルスベンダヌガむダンスがない堎
合には、䞍足を補うため、ICS パフォヌマンスの圱響に特化した汎甚的なガむドラむン及び詊隓
手順の䜜成にも取り組んでいる[56]。
䞀般的に、
 コン゜ヌル、゚ンゞニアリングワヌクステヌション、デヌタヒストリアン、HMI、汎甚
SCADA 及びバックアップサヌバずしお利甚する Windows、Unix、Linux システム等は、垂
販の IT 装備品同様にセキュアにするこずが可胜である。その堎合、プッシュ匏又は自動曎
新匏のアンチりむルス及びパッチ管理゜フトり゚アをむンストヌルする曎新はプロセス制
埡ネットワヌク内にあるアンチりむルスサヌバ及びパッチ管理サヌバ経由で配垃され、IT
ネットワヌクから自動曎新される。

 時間䟝存コヌドを持ち、OS を改修・拡匵するか、その他の倉曎を加えお、垂販の暙準 PC ず
は異なっおいる䞊蚘以倖の党おのコンピュヌタDCS、PLC、むンスツルメンツに぀いお
は、ベンダヌの掚奚事項に埓う。ベンダヌが定期的にセキュリティパッチの入った保守リリ
ヌスを提䟛するこずを期埅する。
6.2.17.2 䟵入怜知及び防止
䟵入怜知システムIDSは、トラフィックパタヌン等のネットワヌクむベント、ログ項目やフ
ァむルアクセス等のシステムを監芖し、システムに入り蟌む䟵入者やシステムに入り蟌もうずす
る䟵入者を芋極めるこずができる[57]。IDS は、ポヌトの新芏開蚭、通垞ず異なるトラフィック
パタヌン、重芁な OS ファむルぞの倉曎ずいった普段ず違う掻動がセキュリティ担圓職員の泚意
を匕くようにする。
IDS が䜿甚する䞀般的な皮類は次の 2 ぀である。

 ネットワヌクベヌス IDS。システムはネットワヌクトラフィックを監芖しお、攻撃ず芋なさ
れるトラフィックを特定するずアラヌムを発する。

206

SPECIAL PUBLICATION 800-82 REVISION 2



GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Host-Based IDS. This software monitors one or more types of characteristics of a system, such as
application log file entries, system configuration changes, and access to sensitive data on a system and
responds with an alarm or countermeasure when a user attempts to breach security.

ICS-specific Recommendations and Guidance
An effective IDS deployment typically involves both host-based and network-based IDS. In the current ICS
environment, network-based IDS are most often deployed between the control network and the corporate
network in conjunction with a firewall; host-based IDS are most often deployed on the computers that use
general-purpose OSs or applications such as HMIs, SCADA servers, and engineering workstations.
Properly configured, an IDS can greatly enhance the security management team’s ability to detect attacks
entering or leaving the system, thereby improving security. They can also potentially improve a control
network’s efficiency by detecting non-essential traffic on the network. However, even when IDS are
implemented, security staff can primarily recognize individual attacks, as opposed to organized patterns of
attacks over time. Network security monitoring and an understanding of the normal state of the ICS
network can help distinguish attacks from transient conditions, and both trigger and provide information
into events that are outside the normal state.
Current IDS and IPS products are effective in detecting and preventing well-known Internet attacks, but
until recently they have not addressed ICS protocol attacks. IDS and IPS vendors are beginning to develop
and incorporate attack signatures for various ICS protocols such as Modbus, DNP3, and ICCP [58].

6.2.17.3 Patch Management
Patches are additional pieces of code that have been developed to address specific problems or flaws in
existing software. Vulnerabilities are flaws that can be exploited, enabling unauthorized access to IT
systems or enabling users to have access to greater privileges than authorized.
A systematic approach to managing and using software patches can help organizations to improve the
overall security of their IT systems in a cost-effective way. Organizations that actively manage and use
software patches can reduce the chances that the vulnerabilities in their IT systems can be exploited; in
addition, they can save time and money that might be spent in responding to vulnerability-related incidents.
NIST SP 800-40 Revision 3 [40] provides guidance for organizational security managers who are
responsible for designing and implementing security patch and vulnerability management programs and for
testing the effectiveness of the programs in reducing vulnerabilities. The guidance is also useful to system
administrators and operations personnel who are responsible for applying and testing patches and for
deploying solutions to vulnerability problems.
ICS-specific Recommendations and Guidance
Applying patches to OS components creates another situation where significant care should be exercised in
the ICS environment. Patches should be adequately tested (e.g., off-line on a comparable ICS) to determine
the acceptability of side effects. Regression testing is advised. It is not uncommon for patches to have an
adverse effect on other software. A patch may remove a vulnerability, but it can

207

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 ホストベヌス IDS。この゜フトり゚アは、アプリケヌションログファむル゚ントリ、システ
ム蚭定倉曎、システム䞊の芁泚意デヌタぞのアクセスずいったシステム特性タむプを 1 ぀か
耇数監芖しお、ナヌザがセキュリティ違反をもくろむず、アラヌム又は察策をもっお察応す
る。
ICS 固有の掚奚事項及びガむダンス
効果的な IDS の展開には、通垞ホストベヌスずネットワヌクベヌスの IDS がずもに含たれる。
珟圚の ICS 環境では、ネットワヌクベヌス IDS は、制埡ネットワヌクずファむアりォヌル経由
の䌁業ネットワヌクずの間で展開されるこずが倚い。䞀方ホストベヌス IDS は、汎甚 OS や
HMI、SCADA サヌバ、゚ンゞニアリングワヌクステヌション等のアプリケヌションを䜿甚する
コンピュヌタで展開されるこずが倚い。正しく蚭定すれば、IDS はセキュリティチヌムの胜力
を著しく向䞊させ、システムぞの䟵入・退出を怜知し、セキュリティを改善する。たたネット
ワヌク䞊の䞍芁なトラフィックを怜出しお、制埡ネットワヌクの効率も改善できる。ただし
IDS を実装した堎合でも、セキュリティ芁員は、経時的な攻撃の組織的パタヌンずは反察に、
個々の攻撃を認識できる。ネットワヌクセキュリティ監芖及び ICS ネットワヌクの正垞状態に
察する理解があれば、過枡的状態からの攻撃を芋極め、正垞状態を逞脱したむベントに察しお
トリガヌず情報を発信しやすくなる。
珟圚の IDS 及び IPS 補品は、良く知られたむンタヌネット攻撃の怜知・防止に効果があるが、最
近になるたで ICS プロトコル攻撃には察応しおいなかった。IDS 及び IPS ベンダヌは、Modbus、
DNP3 及び ICCP 等の倚様な ICS プロトコルの攻撃シグネチャを開発し、組み蟌み぀぀ある[58]。
6.2.17.3 パッチ管理
パッチはコヌドの远加ピヌスで、既存゜フトり゚アの問題や欠陥に察応するために開発される。
脆匱性は悪甚可胜な欠陥で、IT システムぞの䞍正アクセスを可胜にし、ナヌザに付䞎されおい
る以䞊の暩限を䞎える。
゜フトり゚アパッチを䜓系的に管理・利甚する取組をするこずで、組織は費甚効果の高い方法
で、IT システム党䜓のセキュリティを改善できる。゜フトり゚アパッチを積極的に管理・利
甚する組織では、IT システムの脆匱性を悪甚される可胜性が枛る。たた脆匱性に関係したむ
ンシデント察応に芁する時間ずコストも節玄できる。
NIST SP 800-40 第 3 版[40]には、セキュリティパッチの蚭蚈・実装、脆匱性管理プログラム
及び脆匱性軜枛プログラムの効果性怜蚌を担圓するセキュリティ管理者向けのガむダンスがあ
る。このガむダンスは、パッチの適甚ず詊隓、脆匱性問題の゜リュヌション展開を担圓するシ
ステム管理者や職員にも圹立぀。
ICS 固有の掚奚事項及びガむダンス
OS コンポヌネントぞのパッチ適甚は、ICS 環境では特に慎重を期すべき別の状況が生じる。パ
ッチの詊隓は十分に行い同等の ICS 環境でオフラむンで、副次的圱響の蚱容床を刀定すべ
きである。リグレッション詊隓が掚奚される。パッチが他の゜フトり゚アに悪圱響を及がすこ
ずは珍しくない。パッチは脆匱性をなくするが、

208

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

also introduce a greater risk from a production or safety perspective. Patching the vulnerability may also
change the way the OS or application works with control applications, causing the control application to
lose some of its functionality. Another issue is that many ICS utilize older versions of operating systems
that are no longer supported by the vendor. Consequently, available patches may not be applicable.
Organizations should implement a systematic, accountable, and documented ICS patch management
process for managing exposure to vulnerabilities.
Once the decision is made to deploy a patch, there are other tools that automate this process from a
centralized server and with confirmation that the patch has been deployed correctly. Consider separating
the automated process for ICS patch management from the automated process for non-ICS applications.
Patching should be scheduled to occur during planned ICS outages.

6.2.18 Program Management
The security controls that fall within the NIST SP 800-53 Program Management (PM) focus on the
organization-wide information security requirements that are independent of any particular information
system and are essential for managing information security programs.
Organizations document program management controls in the information security program plan. The
organization-wide information security program plan supplements the individual security plans developed
for each organizational information system. In addition to documenting the information security program
management controls, the security program plan provides a vehicle for the organization, in a central
repository, to document all security controls that have been designated as common controls (i.e., security
controls inherited by organizational information systems).

6.2.19 Privacy Controls
Protecting the privacy of personally identifiable information (PII) 43 collected, used, maintained, shared, and
disposed of by programs and information systems is critical given the advances in information technologies
and applications of those technologies. Effective privacy for individuals depends on the safeguards
employed within the organizational information systems that are processing, storing, and transmitting PII.
Organizations cannot have effective privacy without a foundation of information security. However,
privacy is more than security and includes, for example, the principles of transparency, notice, and choice.
The privacy controls focus on information privacy as a value distinct from, but highly interrelated with,
information security. The privacy controls are based on the Fair Information Practice Principles (FIPPs)
embodied in the Privacy Act of 1974, Section 208 of the E-Government Act of 2002, and related Office of
Management and Budget (OMB) guidance. The FIPPs are designed to build public trust in an
organization’s privacy practices and to help organizations avoid tangible costs and intangible damages
stemming from privacy incidents.

43

OMB Memorandum 07-16 defines PII as “information which can be used to distinguish or trace an individual’s
identity such as their name, social security number, biometric records, etc., alone, or when combined with
other personal or identifying information which is linked or linkable to a specific individual, such as date
and place of birth, mother’s maiden name, etc.” [86]. OMB Memorandum 10-22 reaffirmed this definition [87].
NIST Special Publication 800-122 defines PII as “any information about an individual [that is] maintained
by an agency, including: (i) any information that can be used to distinguish or trace an individual‘s
identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric
records; and (ii) any other information that is linked or linkable to an individual, such as medical,
educational, financial, and employment information” [88].

209

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

生産や安党性の芳点からは、より倧きなリスクになる堎合がある。脆匱性にパッチを圓おるず、
OS やアプリケヌションず制埡アプリケヌションの連動方法が倉わり、制埡アプリケヌションの
機胜が倱われるこずがある。別の問題ずしお、ベンダヌがサポヌトを打ち切った OS の旧バヌゞ
ョンを䜿甚する ICS が倚いこずが挙げられる。その結果、入手可胜なパッチが適甚できないこず
になる。組織は脆匱性の露出を管理するため、䜓系的で説明の぀く、文曞化された ICS パッチ管
理プロセスを実行すべきである。
パッチの展開を決定したなら、集䞭型サヌバからこのプロセスを自動化し、パッチが正しく展開
されたこずを確認できる別のツヌルがある。ICS パッチ管理の自動化プロセスを、ICS 以倖のア
プリケヌションの自動化プロセスから分離するこずを怜蚎する。パッチの適甚は、蚈画された
ICS の操業停止時に行うように予定すべきである。

6.2.18 プログラム管理
NIST SP 800-53 のプログラム管理PMに含たれおいるセキュリティ察策は、特定の情報シス
テムから独立した、情報セキュリティプログラムの管理に䞍可欠な、党組織的情報セキュリティ
芁件に焊点を圓おおいる。
組織は、プログラム管理制埡を情報セキュリティプログラム蚈画曞の䞭に蚘茉する。党組織的情
報セキュリティプログラム蚈画曞は、各組織の情報システム甚個別セキュリティ蚈画曞を補完す
る。情報セキュリティプログラム管理察策の文曞化に加えお、セキュリティプログラム蚈画曞は、
共通管理組織の情報システムが継承しおいるセキュリティ察策ずしお指定されおいる党おの
セキュリティ察策を文曞化する手段を集䞭保管堎所に甚意する。

6.2.19 プラむバシヌ管理
情報技術の進歩やその技術の適甚を考慮するず、プログラム及び情報システムが収集・利甚・維
持・共有・廃棄した個人を特定可胜な情報PII 44のプラむバシヌ保護は重芁である。効果的な
個人プラむバシヌは、PII を凊理・保管・転送する組織の情報システムで採甚されおいる安党察
策に巊右される。情報セキュリティの基瀎が確立されおいない組織には、効果的なプラむバシヌ
はない。ずは蚀え、プラむバシヌはセキュリティ以䞊のものであり、䟋えば透明性、通知及び遞
択の原則が含たれる。
プラむバシヌ管理は、情報セキュリティずの関係は匷いものの、それずは別の䟡倀ずしおのプラ
むバシヌ情報を重点ずする。プラむバシヌ管理は、プラむバシヌ法1974 幎の公正情報芏範
原則FIPPs、電子政府法2002 幎第 208 条及び関係する行政予算管理局OMBガむダン
スを根拠ずしおいる。FIPPs は、組織のプラむバシヌ芏範に察する囜民の信頌を醞成し、プラむ
バシヌむンシデントから生じる有圢の経費や無圢の損害の回避を目指しおいる。

44

OMB 芚曞 07-16 は PII を「氏名、瀟䌚保障番号、バむオメトリック蚘録等を単独で、又は誕生日、出生地、母芪の旧姓等
特定の個人に結び぀くか結び぀けられるその他の個人若しくは身分情報ず組み合わせお、個人の身分を刀別又は远跡でき
る情報」ず定矩しおいる[86]。OMB 芚曞 10-22 はこの定矩を远認しおいる[87]。NIST SP800-122 は PII をある機関が保持
しおいる個人に関する情報で、1氏名、瀟䌚保障番号、誕生日、出生地、母芪の旧姓、バむオメトリック蚘録等、個
人の身分を刀別又は远跡できる情報及び2医療、教育、財政、就業情報等、個人に結び぀くか結び぀けられるその他
の情報」ず定矩しおいる[88]。

210

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Privacy controls are the administrative, technical, and physical safeguards employed within organizations
to protect and ensure the proper handling of PII. There are eight privacy control families with each family
aligning with one of the FIPPs. The privacy control families can be implemented at the organization,
department, agency, component, office, program, or information system level. The privacy controls are
structured in a similar manner to the information system security controls in Appendix F of NIST SP 80053.
The Privacy Appendix of NIST SP 800-53, Rev. 4 [22], provides a structured set of privacy controls, based
on international standards and best practices to help organizations enforce requirements derived from
federal privacy legislation, policies, regulations, directives, standards, and guidance. Additionally, it
establishes a linkage and relationship between privacy and security controls for purposes of enforcing
respective privacy and security requirements that may overlap in concept and in implementation within
federal information systems, programs, and organizations.
The privacy controls are intended primarily for use by an organization’s Senior Agency Official for Privacy
(SAOP)/Chief Privacy Officer (CPO) when working with program managers, information system
developers, and information security personnel to determine how best to incorporate effective privacy
protections and practices within those programs and/or systems. These controls facilitate the organization’s
efforts to comply with privacy requirements affecting those programs and/or systems that collect, use,
maintain, share, or dispose of PII. This promotes closer cooperation between privacy and security officials
within the federal government to help achieve the objectives of senior leaders/executives in enforcing the
requirements in federal privacy legislation, policies, regulations, directives, standards, and guidance.
The 8 privacy control families include:


Authority and Purpose (AP).



Accountability, Audit, and Risk Management (AR).



Data Quality and Integrity (DI).



Data Minimization and Retention (DM).



Individual Participation and Redress (IP).



Security (SE).



Transparency (TR).



Use Limitation (UL).

211

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

プラむバシヌ管理は、PII に察する保護ず適正な取扱を確保するために組織内で採甚される管理
䞊の技術的・物理的安党察策である。プラむバシヌ管理の 8 ファミリがそれぞれの FIPPS に敎合
しおいる。プラむバシヌ管理分野は、組織・郚眲・機関・コンポヌネント、オフィス、プログラ
ム又は情報システムレベルで実斜できる。プラむバシヌ管理は、NIST SP 800- 53 付録 F にある情
報システムのセキュリティ察策ず同様の方法で構築される。
NIST SP 800-53 改蚂第 4 版[22]には、囜際芏栌及び適性芏範に基づいお構築されたプラむバシ
ヌ管理があり、組織が連邊プラむバシヌ法、政策、芏則、呜什、芏栌及びガむダンスから生じ
る芁件を実斜する助けずなる。たた、連邊情報システム、プログラム及び組織内で抂念䞊も実
斜䞊も重なり合う、プラむバシヌ芁件ずセキュリティ芁件を斜行する䞊で、プラむバシヌ管理
ずセキュリティ察策の結び぀きや関係に぀いおも蚘述しおいる。
プラむバシヌ管理の目的は、䞻に組織のプラむバシヌ担圓䞊玚官吏SAOP/プラむバシヌ担圓
䞻任CPOがプログラム管理者、情報システム開発者及び情報セキュリティ職員ず協働する際
に、効果的なプラむバシヌ保護・芏範をこれらプログラムやシステムに組み蟌む最善の方法の
刀定に䜿甚するこずにある。このような管理によっお、PII を収集・利甚・維持・共有・廃棄
するプログラムやシステムに圱響を䞎えるプラむバシヌ芁件遵守に察する組織の取組が容易に
なる。これにより連邊政府のプラむバシヌ担圓者ずセキュリティ担圓者間の連携が緊密になり、
幹郚が連邊プラむバシヌ法、政策、芏制、指什、芏栌及びガむダンスの芁件を斜行しお目暙を
達成できるようにする。
8 ぀のプラむバシヌ管理分野は次のずおり。

 暩限及び目的AP
 説明責任、監査及びリスク管理AR
 デヌタ品質及び完党性DI
 デヌタの最小化及び保持DM
 個人の参加及び賠償IP
 セキュリティSE
 透明性TR
 䜿甚限界UL

212

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix A—Acronyms and Abbreviations
Selected acronyms and abbreviations used in the Guide to Industrial Control Systems (ICS) Security are
defined below.
AC
ACL
AGA
API
ARP

Alternating Current
Access Control List
American Gas Association
American Petroleum Institute
Address Resolution Protocol

BCP

Business Continuity Plan

CIDX
CIGRE
CIP
CMVP
COTS
CPNI
CPU
CSE
CSRC
CSSC
CVE

Chemical Industry Data Exchange
International Council on Large Electric Systems
Critical Infrastructure Protection
Cryptographic Module Validation Program
Commercial Off-the-Shelf
Centre for the Protection of National Infrastructure
Central Processing Unit
Communications Security Establishment
Computer Security Resource Center
Control System Security Center
Common Vulnerabilities and Exposures

DCOM
DCS
DETL
DHS
DMZ
DNP3
DNS
DOE
DoS
DRP

Distributed Component Object Model
Distributed Control System(s)
Distributed Energy Technology Laboratory
Department of Homeland Security
Demilitarized Zone
DNP3 Distributed Network Protocol (published as IEEE 1815)
Domain Name System
Department of Energy
Denial of Service
Disaster Recovery Plan

EAP
EMS
EPRI
ERP

Extensible Authentication Protocol
Energy Management System
Electric Power Research Institute
Enterprise Resource Planning

FIPS
FISMA
FTP

Federal Information Processing Standards
Federal Information Security Modernization Act
File Transfer Protocol

GAO
GPS

Government Accountability Office
Global Positioning System

HMI
HSPD
HTTP

Human-Machine Interface
Homeland Security Presidential Directive
Hypertext Transfer Protocol

213

SP800-82 第 2 版

付録 A

産業甚制埡システムICSセキュリティガむド

頭字語及び略語

産業甚制埡システムICSセキュリティガむドで䜿甚する䞻な頭字語及び略語の定矩は以䞋の
ずおり。
AC
亀流
ACL
アクセス制埡リスト
AGA
米囜ガス協䌚
API
米囜石油協䌚
ARP
アドレス解決プロトコル
BCP

事業継続蚈画曞

CIDX
CIGRE
CIP
CMVP
COTS
CPNI
CPU
CSE
CSRC
CSSC
CVE

化孊業界デヌタ亀換
囜際倧電力システム䌚議
重芁むンフラ保護
暗号モゞュヌル劥圓性怜蚌プログラム
民生品
囜家むンフラ保護センタヌ
䞭倮挔算装眮
通信セキュリティ局
コンピュヌタセキュリティリ゜ヌスセンタヌ
制埡システムセキュリティセンタヌ
共通脆匱性曝露

DCOM
DCS
DETL
DHS
DMZ
DNP3
DNS
DOE
DoS
DRP

分散型コンポヌネントオブゞェクトモデル
分散制埡システム
分散゚ネルギヌ技術研究所
囜土安党保障省
非歊装地垯
DNP3 分散ネットワヌクプロトコルIEEE 1815 ずしお発行)
領域名システム
゚ネルギヌ省
サヌビス劚害
灜害埩旧蚈画曞

EAP
EMS
EPRI
ERP

拡匵可胜認蚌プロトコル
゚ネルギヌ管理システム
電力研究所
䌁業資源蚈画

FIPS
FISMA
FTP

連邊情報凊理芏栌
連邊情報セキュリティ匷化法
ファむル転送プロトコル

GAO
GPS

政府説明責任局
グロヌバルポゞショニングシステム

HMI
HSPD
HTTP

マンマシンむンタフェヌス
囜土安党保障倧統領呜什
ハむパヌテキスト転送プロトコル

214

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

HTTPS
HVAC

Hypertext Transfer Protocol Secure
Heating, Ventilation, and Air Conditioning

I/O
I3P
IACS
IAONA
ICCP
ICMP
ICS
ICS-CERT
IDS
IEC
IED
IEEE
IETF
IGMP
INL
IP
IPS
IPsec
ISA
ISID
ISO
IT
ITL

Input/Output
Institute for Information Infrastructure Protection
Industrial Automation and Control System
Industrial Automation Open Networking Association
Inter-control Center Communications Protocol
Internet Control Message Protocol
Industrial Control System(s)
Industrial Control Systems - Cyber Emergency Response Team
Intrusion Detection System
International Electrotechnical Commission
Intelligent Electronic Device
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Internet Group Management Protocol
Idaho National Laboratory
Internet Protocol
Intrusion Prevention System
Internet Protocol Security
International Society of Automation
Industrial Security Incident Database
International Organization for Standardization
Information Technology
Information Technology Laboratory

LAN

Local Area Network

MAC
MES
MIB
MTU

Media Access Control
Manufacturing Execution System
Management Information Base
Master Terminal Unit (also Master Telemetry Unit)

NAT
NCCIC
NCSD
NERC
NFS
NIC
NISCC
NIST
NSTB

Network Address Translation
National Cybersecurity and Communications Integration Center
National Cyber Security Division
North American Electric Reliability Council
Network File System
Network Interface Card
National Infrastructure Security Coordination Centre
National Institute of Standards and Technology
National SCADA Testbed

OLE
OMB
OPC
OS
OSI

Object Linking and Embedding
Office of Management and Budget
OLE for Process Control
Operating System
Open Systems Interconnection

215

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

HTTPS
HVAC

ハむパヌテキスト転送プロトコルセキュア
冷暖房空調蚭備

I/O
I3P
IACS
IAONA
ICCP
ICMP
ICS
ICS-CERT
IDS
IEC
IED
IEEE
IETF
IGMP
INL
IP
IPS
IPsec
ISA
ISID
ISO
IT
ITL

入出力
情報むンフラ保護協䌚
産業甚オヌトメヌション制埡システム
産業オヌトメヌションオヌプンネットワヌクア゜シ゚ヌション
制埡間センタヌ通信プロトコル
むンタヌネットコントロヌルメッセヌゞプロトコル
産業甚制埡システム
産業甚制埡システム - サむバヌ緊急察応チヌム
䟵入怜知システム
囜際電気技術委員䌚
むンテリゞェント電子機噚
電気電子技術者協䌚
むンタヌネット゚ンゞニアリングタスクフォヌス
むンタヌネットグルヌプ管理プロトコル
アむダホ囜立研究所
むンタヌネットプロトコル
䟵入防止システム
むンタヌネットプロトコルセキュリティ
囜際オヌトメヌション協䌚
産業セキュリティむンシデントデヌタベヌス
囜際暙準化機構
情報技術
情報技術研究所

LAN

ロヌカル゚リアネットワヌク

MAC
MES
MIB
MTU

メディアアクセス制埡
生産実行システム
管理情報ベヌス
マスタヌ端末装眮マスタヌテレメトリ装眮ずもいう

NAT
NCCIC
NCSD
NERC
NFS
NIC
NISCC
NIST
NSTB

ネットワヌクアドレス倉換
米囜サむバヌセキュリティ通信統合センタヌ
米囜サむバヌセキュリティ郚
北米電力信頌床協議䌚
ネットワヌクファむルシステム
ネットワヌクむンタフェヌスカヌド
米囜むンフラセキュリティ調敎センタヌ
米囜暙準技術局
米囜 SCADA テストベッド

OLE
OMB
OPC
OS
OSI

オブゞェクトのリンクず埋め蟌み
管理予算局
プロセス制埡甚 OLE
オペレヌティングシステム
オヌプンシステム盞互接続

216

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PCII
PDA
PIN
PID
PIV
PLC
PP
PPP

Protected Critical Infrastructure Information
Personal Digital Assistant
Personal Identification Number
Proportional – Integral - Derivative
Personal Identity Verification
Programmable Logic Controller
Protection Profile
Point-to-Point Protocol

R&D
RADIUS
RBAC
RFC
RMA
RMF
RPC
RPO
RTO
RTU

Research and Development
Remote Authentication Dial In User Service
Role-Based Access Control
Request for Comments
Reliability, Maintainability, and Availability
Risk Management Framework
Remote Procedure Call
Recovery Point Objective
Recovery Time Objective
Remote Terminal Unit (also Remote Telemetry Unit)

SC
SCADA
SCP
SFTP
SIS
SMTP
SNL
SNMP
SP
SPP-ICS
SQL
SSH
SSID
SSL

Security Category
Supervisory Control and Data Acquisition
Secure Copy
Secure File Transfer Protocol
Safety Instrumented System
Simple Mail Transfer Protocol
Sandia National Laboratories
Simple Network Management Protocol
Special Publication
System Protection Profile for Industrial Control Systems
Structured Query Language
Secure Shell
Service Set Identifier
Secure Sockets Layer

TCP
TCP/IP
TFTP
TLS

Transmission Control Protocol
Transmission Control Protocol/Internet Protocol
Trivial File Transfer Protocol
Transport Layer Security

UDP
UPS
US-CERT
USB

User Datagram Protocol
Uninterruptible Power Supply
United States Computer Emergency Readiness Team
Universal Serial Bus

VFD
VLAN
VPN

Variable Frequency Drive
Virtual Local Area Network
Virtual Private Network

WAN

Wide Area Network

XML

Extensible Markup Language

217

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

PCII
PDA
PIN
PID
PIV
PLC
PP
PPP

保護された重芁むンフラ情報
携垯情報端末
個人識別番号
比䟋・積分・埮分
個人の身元確認
プログラマブル論理制埡装眮
保護プロファむル
ポむントツヌポむントプロトコル

R&D
RADIUS
RBAC
RFC
RMA
RMF
RPC
RPO
RTO
RTU

研究開発
遠隔認蚌ダむアルむンナヌザサヌビス
圹割ベヌスアクセス制埡
コメント芁求リク゚スト フォヌ コメンツ
信頌性・保守性・可甚性
リスク管理䜓制
遠隔手順呌出し
目暙埩旧点
目暙埩旧時間
遠隔端末装眮遠隔テレメトリ装眮ずもいう

SC
SCADA
SCP
SFTP
SIS
SMTP
SNL
SNMP
SP
SPP-ICS
SQL
SSH
SSID
SSL

セキュリティ分類
監芖制埡デヌタ取埗スキャダ
セキュアコピヌ
セキュアファむル転送プロトコル
安党蚈装システム
シンプルメヌル転送プロトコル
サンディア囜立研究所
シンプルネットワヌク管理プロトコル
特別出版物
産業制埡システム甚システム保護プロファむル
構造化照䌚蚀語
セキュアシェル
サヌビスセット識別子
セキュア゜ケットレむダヌ

TCP
TCP/IP
TFTP
TLS

通信制埡プロトコル
通信制埡プロトコル/むンタヌネットプロトコル
トリビアルファむル転送プロトコル
トランスポヌト局セキュリティ

UDP
UPS
US-CERT
USB

ナヌザデヌタグラムプロトコル
無停電電源装眮
米囜コンピュヌタ緊急時即応チヌム
ナニバヌサルシリアルバス

VFD
VLAN
VPN

可倉呚波数駆動
仮想 LAN
仮想プラむベヌトネットワヌク

WAN

広域ネットワヌク

XML

拡匵マヌクアップ蚀語
218

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix B—Glossary of Terms
Selected terms used in the Guide to Industrial Control Systems (ICS) Security are defined below. Source
References for certain definitions are listed at the end of this appendix.
Alternating Current Drive

Synonymous with Variable Frequency Drive (VFD).
SOURCE: NIST IR 6859 [2]

Access Control List (ACL)

A mechanism that implements access control for a system resource by
enumerating the identities of the system entities that are permitted to
access the resources.
SOURCE: RFC 4949 [75]

Accreditation

The official management decision given by a senior agency official to
authorize operation of an information system and to explicitly accept the
risk to agency operations (including mission, functions, image, or
reputation), agency assets, or individuals, based on the implementation of
an agreed-upon set of security controls.
SOURCE: NIST SP 800-53 [22]

Actuator

A device for moving or controlling a mechanism or system. It is operated
by a source of energy, typically electric current, hydraulic fluid pressure,
or pneumatic pressure, and converts that energy into motion. An actuator
is the mechanism by which a control system acts upon an environment.
The control system can be simple (a fixed mechanical or electronic
system), software-based (e.g. a printer driver, robot control system), or a
human or other agent.

Alarm

A device or function that signals the existence of an abnormal condition
by making an audible or visible discrete change, or both, so as to attract
attention to that condition.
SOURCE: ANSI/ISA-5.1-2009

Antivirus Tools

Software products and technology used to detect malicious code, prevent
it from infecting a system, and remove malicious code that has infected
the system.

Application Server

A computer responsible for hosting applications to user workstations.

Attack

An attempt to gain unauthorized access to system services, resources, or
information, or an attempt to compromise system integrity, availability,
or confidentiality.
SOURCE: CNSSI-4009

219

SP800-82 第 2 版

付録 B

産業甚制埡システムICSセキュリティガむド

甚語集

産業甚制埡システムICSセキュリティガむドで䜿甚する䞻な甚語の定矩は以䞋のずおり。い
く぀かの定矩に぀いおは、本付録の末尟にその出兞が掲茉されおいる。
Alternating Current Drive 可倉呚波数駆動VFDず同矩
亀流駆動
出兞NIST IR 6859 [2]
Access Control List (ACL) リ゜ヌスぞのアクセスを蚱可されたシステム実䜓の䞀臎点を列挙する
アクセス制埡リスト
こずによりシステムリ゜ヌスぞのアクセス制埡を行うメカニズム。
出兞RFC 4949 [75]
Accreditation認定

合意されたセキュリティ察策の実装に基づき、情報システムの運甚を
認可し、政府機関の業務任務、機胜、むメヌゞ、評刀等、政府機
関の資産又は個人のリスクを明瀺的に受け入れるため政府機関の䞊玚
官吏が䞋す公的管理決定。
出兞NIST SP 800-53 [22]

Actuatorアクチュ゚ヌタ 機構又はシステムを動かし又は制埡するためのデバむス。䞀般に電
流、油圧、空気圧等の゚ネルギヌ源で䜜動し、その゚ネルギヌを運動
に倉える。アクチュ゚ヌタは、制埡システムが環境に働きかける機構
である。制埡システムは単玔で固定機構や電子システム、゜フト
り゚アベヌスプリンタドラむバ、ロボット制埡システム等や人そ
の他による。
Alarmアラヌム

異垞状態を知らせるデバむス又は機胜で、音や芖芚的倉化により異垞
状態に泚意を匕く。
出兞ANSI/ISA-5.1-2009

Antivirus Tools
アンチりむルスツヌル

゜フトり゚ア補品及び技術で、悪意あるコヌドを怜出しおシステムぞ
の感染を防ぎ、感染しおいる堎合には悪意あるコヌドを排陀する。

Application Server
アプリケヌションサヌバ

ナヌザワヌクステヌションにアプリケヌションをホスティングするコ
ンピュヌタ。

Attack攻撃

システムサヌビス、リ゜ヌス若しくは情報に無断でアクセスしようず
するもくろみ又はシステムの完党性、可甚性若しくは機密性を䜎䞋さ
せようずするもくろみ。
出兞CNSSI-4009

220

SPECIAL PUBLICATION 800-82 REVISION 2

Authentication

Authorization

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Verifying the identity of a user, process, or device, often as a prerequisite
to allowing access to resources in an information system.
SOURCE: NIST SP 800-53 [22]
The right or a permission that is granted to a system entity to access a
system resource.
SOURCE: RFC 4949 [75]

Backdoor

An undocumented way of gaining access to a computer system. A
backdoor is a potential security risk.

Batch Process

A process that leads to the production of finite quantities of material by
subjecting quantities of input materials to an ordered set of processing
activities over a finite time using one or more pieces of equipment.
SOURCE: ANSI/ISA-88.01-1995

Broadcast

Transmission to all devices in a network without any acknowledgment by
the receivers.
SOURCE: IEC/PAS 62410

Buffer Overflow

A condition at an interface under which more input can be placed into a
buffer or data holding area than the capacity allocated, overwriting other
information. Adversaries exploit such a condition to crash a system or to
insert specially crafted code that allows them to gain control of the system.
SOURCE: NIST SP 800-28 [69]

Certification

A comprehensive assessment of the management, operational, and
technical security controls in an information system, made in support of
security accreditation, to determine the extent to which the controls are
implemented correctly, operating as intended, and producing the desired
outcome with respect to meeting the security requirements for the system.
SOURCE: NIST SP 800-37 [21]

Clear Text

Information that is not encrypted.

Communications Router

A communications device that transfers messages between two networks.
Common uses for routers include connecting a LAN to a WAN, and
connecting MTUs and RTUs to a long-distance network medium for
SCADA communication.

Confidentiality

Preserving authorized restrictions on information access and disclosure,
including means for protecting personal privacy and proprietary
information.
SOURCE: NIST SP 800-53 [22]

221

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Authentication認蚌

ナヌザ、プロセス又はデバむスの同䞀性を怜蚌するこずで、情報シス
テム䞭のリ゜ヌスぞの前提ずなるこずが倚い。
出兞NIST SP 800-53 [22]

Authorization暩限付䞎

システムの実圚者がシステムリ゜ヌスにアクセスするために䞎えられ
る暩利又は蚱可。
出兞RFC 4949 [75]

Backdoorバックドア

コンピュヌタシステムぞのアクセスを埗る䞍正な方法。バックドアは
セキュリティリスクずなる。

Batch Process
バッチプロセス

倧量の入力物を 1 ぀又は耇数の装備品を甚いお、ある時間をかけお順
番に䞀連の凊理にかけるこずにより、限定された量にするプロセス。
出兞ANSI/ISA-88.01-1995

Broadcast
ブロヌドキャスト

ネットワヌク内の党おのデバむスに、受け手偎の了解を埗るこずなく
送信するこず。
出兞IEC/PAS 62410

Buffer Overflow
バッファオヌバヌフロヌ

割り圓おられた容量を超えお入力がバッファ又はデヌタ保持領域に眮
かれ、他の情報を䞊曞きするむンタフェヌスの状態。
攻撃偎はこのような状態を利甚しお、システムをクラッシュさせ、特
殊コヌドを挿入しおシステムの制埡を埗るこずができる。
出兞NIST SP 800-28 [69]

Certification蚌明

セキュリティ認定を支揎するために行う情報システムの管理、運甚及
び技術䞊のセキュリティ察策に察する包括的評䟡で、コントロヌルが
どの皋床適正に実装されおいるか、予定どおりに皌働しおいるか、シ
ステムセキュリティ芁件に合臎した結果になっおいるか刀定する。
出兞NIST SP 800-37 [21]

Clear Text平文

暗号化されおいない情報。

Communications Router 2 ぀のネットワヌク間でメッセヌゞを転送する通信デバむス。ルヌタ
通信ルヌタ
の䞀般的な䜿甚方法ずしお、LAN ず WAN の接続や、SCADA 通信甚
の MTU 及び RTU ず遠距離ネットワヌク媒䜓の接続がある。
Confidentiality機密性

情報の利甚及び挏掩に公認の制限を課すこずで、個人情報及び専有情
報を保護する手段も含たれる。
出兞NIST SP 800-53 [22]

222

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Configuration (of a system or
device)

Step in system design; for example, selecting functional units, assigning
their locations, and defining their interconnections.
SOURCE: IEC/PAS 62409

Configuration Control

Process for controlling modifications to hardware, firmware, software,
and documentation to ensure the information system is protected against
improper modifications before, during, and after system implementation.
SOURCE: CNSSI-4009

Continuous Process

A process that operates on the basis of continuous flow, as opposed to
batch, intermittent, or sequenced operations.

Control Algorithm

A mathematical representation of the control action to be performed.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Control

The part of the ICS used to perform the monitoring and control of the
physical process. This includes all control servers, field devices, actuators,
sensors, and their supporting communication systems.

Control Center

An equipment structure or group of structures from which a process is
measured, controlled, and/or monitored.
SOURCE: ANSI/ISA-51.1-1979

Control Loop

A control loop consists of sensors for measurement, controller hardware
such as PLCs, actuators such as control valves, breakers, switches and
motors, and the communication of variables. Controlled variables are
transmitted to the controller from the sensors. The controller interprets the
signals and generates corresponding manipulated variables, based on set
points, which it transmits to the actuators. Process changes from
disturbances result in new sensor signals, identifying the state of the
process, to again be transmitted to the controller.

Control Network

Those networks of an enterprise typically connected to equipment that
controls physical processes and that is time or safety critical. The control
network can be subdivided into zones, and there can be multiple separate
control networks within one enterprise and site.
SOURCE: ISA99 [34]
A controller that also acts as a server that hosts the control software that
communicates with lower-level control devices, such as Remote Terminal
Units (RTUs) and Programmable Logic Controllers (PLCs), over an ICS
network. In a SCADA system, this is often called a SCADA server, MTU,
or supervisory controller.

Control Server

223

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Configuration (of a system
or device)
システム又はデバむス
の構成

システム蚭蚈に介入するこず。䟋えば、機胜ナニットの遞定、堎所の
割圓、それらの盞互接続等。
出兞IEC/PAS 62409

Configuration Control
構成管理

システム実装前・䞭・埌の䞍適切な改倉から情報システムを保護する
ために、ハヌドり゚ア・ファヌムり゚ア・゜フトり゚ア・文曞ぞの倉
曎を管理するプロセス。
出兞CNSSI-4009

Continuous Process
継続プロセス

継続的な流れを基本ずする操䜜プロセスで、バッチ、間欠又は䞀連操
䜜の反察。

Control Algorithm
制埡アルゎリズム

実斜すべき制埡行為の数孊的衚珟。出兞オヌトメヌション・システ
ム・蚈装事兞

Control制埡

物理プロセスの監芖及び制埡を行うために甚いる ICS の䞀郚。党おの
制埡サヌバ、フィヌルドデバむス、アクチュ゚ヌタ、センサ及びこれ
らの支揎通信システムを含む。

Control Center
制埡センタヌ

1 ぀又は䞀矀の装備品構造䜓で、そこからプロセスを蚈枬し、制埡
し、監芖する。
出兞ANSI/ISA-51.1-1979

Control Loop
制埡ルヌプ

制埡ルヌプは蚈枬センサ、制埡ハヌドり゚アPLC 等、アクチュ゚
ヌタ制埡匁、ブレヌカ、スむッチ、モヌタ等及び倉数の通信で構
成される。制埡倉数はセンサ経由でコントロヌラに転送される。コン
トロヌラは信号を解釈し、蚭定点を基に察応する操䜜倉数を生成し、
アクチュ゚ヌタに送信する。
劚害の結果プロセスが倉曎されるず、センサ信号が倉わり、プロセス
状態を識別しお、再床コントロヌラに送信する。

Control Network
制埡ネットワヌク

このような䌁業ネットワヌクは、䞀般に物理プロセスをセットする装
備品に接続され、時間や安党性の点で重芁である。制埡ネットワヌク
はゟヌンに分かれ、ゟヌンごずに 1 ぀の䌁業又は珟堎内に別々な耇数
の制埡ネットワヌクが存圚する。
出兞ISA99 [34]

Control Server
制埡サヌバ

サヌバずしお機胜するコントロヌラで、ICS ネットワヌク䞊で䞋䜍レ
ベルのデバむスRTU、PLC 等ずの通信を行う制埡゜フトり゚アを
ホストする。SCADA システムでは SCADA サヌバ、MTU 又は監芖コ
ントロヌラず呌ばれるこずが倚い。

224

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Control system

A system in which deliberate guidance or manipulation is used to achieve
a prescribed value for a variable. Control systems include SCADA, DCS,
PLCs and other types of industrial measurement and control systems.

Controlled Variable

The variable that the control system attempts to keep at the set point value.
The set point may be constant or variable.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Controller

A device or program that operates automatically to regulate a controlled
variable.
SOURCE: ANSI/ISA-51.1-1979

Cycle Time

The time, usually expressed in seconds, for a controller to complete one
control loop where sensor signals are read into memory, control
algorithms are executed, and corresponding control signals are transmitted
to actuators that create changes the process resulting in new sensor
signals.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Data Diode

A data diode (also referred to as a unidirectional gateway, deterministic
one-way boundary device or unidirectional network) is a network
appliance or device allowing data to travel only in one direction.

Database

A repository of information that usually holds plant-wide information
including process data, recipes, personnel data, and financial data.
SOURCE: NIST IR 6859 [2]

Data Historian

A centralized database supporting data analysis using statistical process
control techniques.

DC Servo Drive

A type of drive that works specifically with servo motors. It transmits
commands to the motor and receives feedback from the servo motor
resolver or encoder.
SOURCE: NIST IR 6859 [2]

225

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Control System
制埡システム

ある倉数の予定倀を実珟するために、蚈画的なガむダンス又は操䜜を
利甚するシステム。制埡システムには SCADA、DCS、PLC その他の
産業甚蚈枬制埡仕様がある。

Controlled Variable
制埡倉数

制埡システムが蚭定点を維持しようずする倉数。蚭定点は定数又は倉
数ずなる。
出兞オヌトメヌション・システム・蚈装事兞

Controller
コントロヌラ

制埡倉数を自動的に調敎するデバむス又はプログラム。出兞
ANSI/ISA-51.1-1979

Cycle Time
サむクル時間

コントロヌラが 1 ぀の制埡ルヌプを完了するための、通垞秒単䜍で瀺
される時間で、センサ信号がメモリに読み蟌たれ、制埡アルゎリズム
が実行され、察応する制埡信号がアクチュ゚ヌタに送られおプロセス
を倉曎し、新たなセンサ信号が生じる。
出兞オヌトメヌション・システム・蚈装事兞

Data Diode
デヌタダむオヌド

デヌタダむオヌド単方向ゲヌトりェむ、決定論的䞀方通行境界デバ
むス又は単方向ネットワヌクずも呌ばれるはネットワヌク機噚又は
デバむスで、デヌタが䞀方向に流れるようにする。

Database
デヌタベヌス

情報が蓄えられたもので、通垞プロセスデヌタ、レシピ、人事デヌ
タ、䌚蚈デヌタ等のプラント党䜓の情報が蓄積されおいる。
出兞NIST IR 6859 [2]

Data Historian
デヌタヒストリアン

集䞭デヌタベヌスで、静的プロセス管理技術を甚いおデヌタ解析を行
う。

DC Servo Drive
盎流サヌボ駆動

特にサヌボモヌタで䜜動する駆動の皮類。コマンドをモヌタに送信
し、サヌボモヌタリゟルバ又ぱンコヌダからフィヌドバックを受信
する。
出兞NIST IR 6859 [2]

226

SPECIAL PUBLICATION 800-82 REVISION 2

Demilitarized Zone
(DMZ)

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

An interface on a routing firewall that is similar to the interfaces found on
the firewall’s protected side. Traffic moving between the DMZ and other
interfaces on the protected side of the firewall still goes through the firewall
and can have firewall protection policies applied.
SOURCE: SP 800-41 [85]
A host or network segment inserted as a “neutral zone” between an
organization’s private network and the Internet.
SOURCE: SP 800-45 [91]
Perimeter network segment that is logically between internal and external
networks. Its purpose is to enforce the internal network’s Information
Assurance policy for external information exchange and to provide external,
untrusted sources with restricted access to releasable information while
shielding the internal networks from outside attacks.
SOURCE: CNSSI-4009

Denial of Service (DoS)

The prevention of authorized access to a system resource or the delaying of
system operations and functions.
SOURCE: RFC 4949 [75]

Diagnostics

Information concerning known failure modes and their characteristics. Such
information can be used in troubleshooting and failure analysis to help
pinpoint the cause of a failure and help define suitable corrective measures.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Disaster Recovery Plan
(DRP)

A written plan for processing critical applications in the event of a major
hardware or software failure or destruction of facilities.
SOURCE: NIST SP 800-34 [52]

Discrete Process

A type of process where a specified quantity of material moves as a unit
(part or group of parts) between work stations and each unit maintains its
unique identity.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Distributed Control System
(DCS)

In a control system, refers to control achieved by intelligence that is
distributed about the process to be controlled, rather than by a centrally
located single unit.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Distributed Plant

A geographically distributed factory that is accessible through the Internet
by an enterprise.
SOURCE: NIST IR 6859 [2]

227

SP800-82 第 2 版

Demilitarized Zone
(DMZ)
非歊装地垯

産業甚制埡システムICSセキュリティガむド

ルヌティングファむアりォヌル䞊のむンタフェヌスで、ファむアりォ
ヌルの保護偎のむンタフェヌスに䌌おいる。DMZ ずファむアりォヌ
ルの保護偎にある別のむンタフェヌス間のトラフィックは、ファむア
りォヌルを通過し、ファむアりォヌル保護ポリシヌが適甚される。
出兞SP 800-41 [85]

「䞭立地垯」ずしお組織のプラむベヌトネットワヌクずむンタヌネッ
ト間に挿入されるホスト又はネットワヌクセグメント。
出兞SP 800-45 [91]

内郚ネットワヌクず倖郚ネットワヌクの間に論理的にある呚蟺ネット
ワヌクセグメント。目的は、倖郚ずの情報亀換甚内郚ネットワヌクの
情報保蚌ポリシヌを斜行し、内郚ネットワヌクを倖郚脅嚁からシヌル
ドし぀぀、倖郚の信頌の眮けない芁求゜ヌスによる情報ぞのアクセス
に制限を課するこずにある。
出兞CNSSI-4009
Denial of Service (DoS)
サヌビス劚害

システムリ゜ヌスぞの公認アクセスを劚げ又はシステムの運甚及び機
胜を遅らせるこず。
出兞RFC 4949 [75]

Diagnostics蚺断

既知の障害態様及びその特城に関する情報。このような情報はトラブ
ルシュヌティングや故障解析に䜿甚でき、原因や適正な察策を割り出
す助けずなる。
出兞オヌトメヌション・システム・蚈装事兞

Disaster Recovery Plan
(DRP)灜害埩旧蚈画曞

倧芏暡なハヌドり゚ア/゜フトり゚ア障害や斜蚭砎壊の際に重芁事項
を凊理するための文曞。
出兞NIST SP 800-34 [52]

Discrete Process
離散プロセス

指定量の材料がある単䜍パヌツ又はパヌツグルヌプずしおワヌク
ステヌション間を移動し、各単䜍がその固有のアむデンティティを保
持するプロセスの皮類。出兞オヌトメヌション・システム・蚈装事
å…ž

Distributed Control System 制埡システムにあっお、䞭倮に眮かれた 1 ぀の装眮ではなく、制埡す
(DCS)
るプロセスに぀いお分散されたむンテリゞェンスによっお行われる制
分散制埡システム
埡をいう。出兞オヌトメヌション・システム・蚈装事兞
Distributed Plant
分散プラント

䌁業がむンタヌネットを通じおアクセスできる地理的に分散された工
堎。
出兞NIST IR 6859 [2]

228

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Disterbance

An undesired change in a variable being applied to a system that tends to
adversely affect the value of a controlled variable.
SOURCE: ANSI/ISA-51.1-1979

Domain

An environment or context that includes a set of system resources and a set
of system entities that have the right to access the resources as defined by a
common security policy, security model, or security architecture. See
Security Domain.
SOURCE: CNSSI-4009; SP 800-53 [22]; SP 800-37 [21]

Domain Controller

A server responsible for managing domain information, such as login
identification and passwords.
SOURCE: NIST IR 6859 [2]

Encryption

Cryptographic transformation of data (called “plaintext”) into a form (called
“ciphertext”) that conceals the data’s original meaning to prevent it from
being known or used. If the transformation is reversible, the corresponding
reversal process is called “decryption,” which is a transformation that
restores encrypted data to its original state.
SOURCE: RFC 4949 [75]

Enterprise

An organization that coordinates the operation of one or more processing
sites.
SOURCE: ANSI/ISA-88.01-1995

Enterprise Resource
Planning (ERP) System

A system that integrates enterprise-wide information including human
resources, financials, manufacturing, and distribution as well as connects the
organization to its customers and suppliers.

Extensible Markup
Language (XML)

A specification for a generic syntax to mark data with simple, humanreadable tags, enabling the definition, transmission, validation, and
interpretation of data between applications and between organizations.

Fault Tolerant

Of a system, having the built-in capability to provide continued, correct
execution of its assigned function in the presence of a hardware and/or
software fault.

Field Device

Equipment that is connected to the field side on an ICS. Types of field
devices include RTUs, PLCs, actuators, sensors, HMIs, and associated
communications.

Field Site

A subsystem that is identified by physical, geographical, or logical
segmentation within the ICS. A field site may contain RTUs, PLCs,
actuators, sensors, HMIs, and associated communications.

229

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Disturbance撹乱

制埡された倉数倀に悪圱響を䞎えやすいシステムに加えられる望たし
くない倉数の倉曎。
出兞ANSI/ISA-51.1-1979

Domain領域

システムリ゜ヌス及び共通接続ポリシヌ、接続モデル又は接続アヌキ
テクチャの芏定どおりリ゜ヌスぞのアクセス暩を持぀システム実䜓を
含む環境又はコンテキスト。セキュリティ領域を参照。
出兞CNSSI-4009; SP 800-53 [22]; SP 800-37 [21]

Domain Controller
領域コントロヌラ

ログむン識別やパスワヌドずいった領域情報を管理するサヌバ。
出兞NIST IR 6859 [2]

Encryption暗号化

暗号倉換はデヌタ平文ず呌ばれるを暗号倉換しお、ある圢態暗
号文ず呌ばれるにするこずで、デヌタの元の意味を秘匿し、知られ
たり利甚されたりできないようにする。倉換が逆倉換も可胜な堎合、
そのプロセスは埩号ず呌ばれ、暗号化されたデヌタを元の状態に戻
す。
出兞RFC 4949 [75]

Enterprise䌁業

1 ぀たたはそれ以䞊の凊理珟堎の運甚を調敎する組織。
出兞ANSI/ISA-88.01-1995

Enterprise Resource
Planning (ERP) System
䌁業資源蚈画システム

人的資源、財政、生産、流通等の党䌁業的情報を䞀䜓化し、組織をそ
の顧客やサプラむダに接続するシステム。

Extensible Markup
Language (XML)
拡匵マヌクアップ蚀語

デヌタを単玔で人が読めるタグを付けお蚘述する汎甚構文仕様で、ア
プリケヌション間及び組織間でのデヌタの定矩、送信、劥圓性怜蚌及
び解釈を可胜にする。

Fault Tolerant
フォヌルトトレラント

システムで、ハヌドり゚ア及び゜フトり゚アが故障したずきでも、割
り圓おられた機胜を継続しお正しく実行できる、組み蟌みの胜力。

Field Device
フィヌルドデバむス

ICS のフィヌルド偎に接続された装備品。皮類ずしお RTU、PLC、ア
クチュ゚ヌタ、センサ、HMI 及び関連通信機噚がある。

Field Site
フィヌルドサむト

ICS 内の物理的、地理的又は論理的区画により識別されるサブシステ
ム。フィヌルドサむトには RTU、PLC、アクチュ゚ヌタ、センサ、
HMI 及び関連通信機噚がある。

230

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Fieldbus

A digital, serial, multi-drop, two-way data bus or communication path or
link between low-level industrial field equipment such as sensors,
transducers, actuators, local controllers, and even control room devices. Use
of fieldbus technologies eliminates the need of point-to-point wiring
between the controller and each device. A protocol is used to define
messages over the fieldbus network with each message identifying a
particular sensor on the network.

File Transfer Protocol (FTP)

FTP is an Internet standard for transferring files over the Internet. FTP
programs and utilities are used to upload and download Web pages,
graphics, and other files between local media and a remote server which
allows FTP access.
SOURCE: API 1164

Firewall

An inter-network gateway that restricts data communication traffic to and
from one of the connected networks (the one said to be “inside” the
firewall) and thus protects that network’s system resources against threats
from the other network (the one that is said to be “outside” the firewall).
SOURCE: RFC 4949 [75]

Human-Machine Interface
(HMI)

An inter-network connection device that restricts data communication
traffic between two connected networks. A firewall may be either an
application installed on a general-purpose computer or a dedicated platform
(appliance), which forwards or rejects/drops packets on a network.
Typically firewalls are used to define zone borders. Firewalls generally
have rules restricting which ports are open. SOURCE: ISA-62443-1-1 [34]
The hardware or software through which an operator interacts with a
controller. An HMI can range from a physical control panel with buttons
and indicator lights to an industrial PC with a color graphics display
running dedicated HMI software.
SOURCE: NIST IR 6859 [2]
Software and hardware that allows human operators to monitor the state of
a process under control, modify control settings to change the control
objective, and manually override automatic control operations in the event
of an emergency. The HMI also allows a control engineer or operator to
configure set points or control algorithms and parameters in the controller.
The HMI also displays process status information, historical information,
reports, and other information to operators, administrators, managers,
business partners, and other authorized users. Operators and engineers use
HMIs to monitor and configure set points, control algorithms, send
commands, and adjust and establish parameters in the controller. The HMI
also displays process status information and historical information.

Identification

The process of verifying the identity of a user, process, or device, usually as
a prerequisite for granting access to resources in an IT system.
SOURCE: NIST SP 800-47 [92]

231

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Fieldbusフィヌルドバス センサ、トランスデュヌサ、アクチュ゚ヌタ、ロヌカルコントロヌ
ラ、制埡宀デバむス等の䜎レベル産業甚フィヌルド装備品間のデゞタ
ル、シリアル、マルチドロップ、双方向デヌタバス、通信経路又はリ
ンク。フィヌルドバス技術を利甚するず、コントロヌラず各デバむス
間での 2 地点間配線の必芁がなくなる。プロトコルを䜿甚しおフィヌ
ルドバスネットワヌク䞊のメッセヌゞを定矩し、各メッセヌゞはネッ
トワヌク䞊の特定のセンサで識別する。
File Transfer Protocol
(FTP)
ファむル転送プロトコル

むンタヌネット䞊でファむルを転送するむンタヌネット芏栌。FTP プ
ログラム及びナヌティリティを䜿甚しお、りェブペヌゞ、グラフィッ
クその他のファむルをロヌカルメディアず FTP アクセスを蚱可する
遠隔サヌバでアップロヌド/ダりンロヌドする。
出兞API 1164

Firewall
ファむアりォヌル

ネットワヌク間ゲヌトりェむで、接続されたネットワヌクファむア
りォヌルの「䞭」にある間でのデヌタ通信トラフィックを制限し、
圓該ネットワヌクのシステムリ゜ヌスを他のネットワヌクファむア
りォヌルの「倖」にあるからの脅嚁から守る。
出兞RFC 4949 [75]
接続された 2 ぀のネットワヌク間でデヌタ通信トラフィックを制限す
るネットワヌク間接続デバむス。ファむアりォヌルは、汎甚コンピュ
ヌタ又は専甚プラットホヌム機噚にむンストヌルされたアプリケ
ヌションで、ネットワヌク䞊のパケットを転送又は拒絶/ドロップす
る。䞀般にファむアりォヌルはゟヌン境界を定めるのに䜿甚する。フ
ァむアりォヌルはどのポヌトを開攟するかを制限する。
出兞ISA-62443-1-1 [34]

Human-Machine Interface 操䜜員がコントロヌラず盞互䜜甚を行うために䜿甚するハヌドり゚ア
(HMI)
又は゜フトり゚ア。ボタンやむンゞケヌタラむトの付いた物理的制埡
マンマシンむンタフェヌス パネルから、カラヌグラフィックディスプレむの付いた専甚 HMI ã‚œ
フトり゚アを実行する産業甚 PC たで倚様である。
出兞NIST IR 6859 [2]
操䜜員が制埡䞭のプロセス状態を監芖し、制埡蚭定を倉えお制埡察象
を倉曎し、緊急時に自動制埡運転を手動に倉曎できる゜フトり゚ア及
びハヌドり゚ア。制埡゚ンゞニアや操䜜員は、コントロヌラの蚭定点
又は制埡アルゎリズム及びパラメヌタを倉曎するこずもできる。たた
HMI はプロセス状態、履歎情報、レポヌトその他の情報を操䜜員、管
理者、マネヌゞャ、ビゞネスパヌトナヌその他蚱可されたナヌザに衚
瀺する。操䜜員及び゚ンゞニアは HMI を利甚し、蚭定点を監芖・蚭
定し、アルゎリズムを制埡し、コマンドを送信し、コントロヌラのパ
ラメヌタを調敎・蚭定する。たた HMI はプロセスのステヌタス情報
及び履歎情報を衚瀺する。
Identification識別

ナヌザ、プロセス又はデバむスの同䞀性を怜蚌するプロセスで、通垞
IT システム䞭のリ゜ヌスぞのアクセス付䞎の前提ずなる。
出兞NIST SP 800-47 [92]

232

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Incident

An occurrence that actually or potentially jeopardizes the confidentiality,
integrity, or availability of an information system or the information the
system processes, stores, or transmits or that constitutes a violation or
imminent threat of violation of security policies, security procedures, or
acceptable use policies
SOURCE: FIPS 200 [16]; SP 800-53 [22]

Industrial Control System
(ICS)

General term that encompasses several types of control systems, including
supervisory control and data acquisition (SCADA) systems, distributed
control systems (DCS), and other control system configurations such as
Programmable Logic Controllers (PLC) often found in the industrial sectors
and critical infrastructures. An ICS consists of combinations of control
components (e.g., electrical, mechanical, hydraulic, pneumatic) that act
together to achieve an industrial objective (e.g., manufacturing,
transportation of matter or energy).

Information Security
Program Plan

Formal document that provides an overview of the security requirements for
an organization-wide information security program and describes the
program management controls and common controls in place or planned for
meeting those requirements.
SOURCE: NIST SP 800-53 [22]

Input/Output (I/O)

A general term for the equipment that is used to communicate with a
computer as well as the data involved in the communications.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Insider

An entity inside the security perimeter that is authorized to access system
resources but uses them in a way not approved by those who granted the
authorization.
SOURCE: RFC 4949 [75]

Integrity

Guarding against improper information modification or destruction, and
includes ensuring information non-repudiation and authenticity.
SOURCE: NIST SP 800-53 [22]

Intelligent Electronic Device
(IED)

Any device incorporating one or more processors with the capability to
receive or send data/control from or to an external source (e.g., electronic
multifunction meters, digital relays, controllers).
SOURCE: AGA 12 [5]

Internet

The single interconnected world-wide system of commercial, government,
educational, and other computer networks that share the set of protocols
specified by the Internet Architecture Board (IAB) and the name and
address spaces managed by the Internet Corporation for Assigned Names
and Numbers (ICANN). SOURCE: RFC 4949 [75]

233

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Incidentむンシデント

情報システム又はシステムが凊理、保管若しくは送信する情報の機密
性、完党性若しくは可甚性を珟実に又は可胜性ずしお危険に陥れる事
象又は接続ポリシヌ、接続手順若しくは劥圓な䜿甚ポリシヌに違反す
るか、盎ちに違反しそうな事象。
出兞FIPS 200 [16]; SP 800-53 [22]

Industrial Control System
(ICS)
産業甚制埡システム
ICS

数皮の制埡システムを包括した汎甚的な甚語で、これには各皮産業郚
門や重芁むンフラで䜿甚されおいる SCADA、DCS、PLC、その他の
制埡システムの蚭定が含たれる。ICS は産業䞊の目的物品や゚ネル
ギヌの生産・茞送等を達成するために䜵甚される制埡甚コンポヌネ
ント電気・機械・油圧・空気等が組み合わさっお構成されおい
る。

党組織的情報セキュリティプログラムのセキュリティ芁件に぀いお抂
Information Security
Program Plan
説し、芁件を満足するために実斜䞭又は蚈画䞭のプログラム管理察策
情報セキュリティプログラ 及び共通管理に぀いお蚘述した正匏文曞。
ム蚈画曞
出兞NIST SP 800-53 [22]
Input/Output (I/O)入出力 コンピュヌタず通信するための装備品及び通信に含たれるデヌタを瀺
す䞀般甚語。
出兞オヌトメヌション・システム・蚈装事兞
Insiderむンサむダヌ

セキュリティ境界内にいおシステムリ゜ヌスぞのアクセスが蚱されお
いるが、蚱可された以倖の方法で䜿甚する実圚者。
出兞RFC 4949 [75]

Integrity完党性

䞍正な情報の改倉又は砎壊を防ぐこずで、情報の吊認防止及び正圓性
を確保する。
出兞NIST SP 800-53 [22]

Intelligent Electronic Device 1 ぀又は耇数のプロセスを組み蟌んだデバむスで、倖郚゜ヌスずの間
(IED)
でデヌタ/制埡を送受信する胜力を持぀電子倚機胜メヌタ、デゞタ
むンテリゞェント電子機噚 ルリレヌ、コントロヌラ等。
出兞AGA 12 [5]
Internetむンタヌネット 産官孊その他のネットワヌクを 1 ぀に連接した䞖界的システムで、む
ンタヌネットアヌキテクチャ委員䌚IABが指定したプロトコル及
び ICANN が管理する名前及びアドレス空間を共有する。出兞RFC
4949 [75]

234

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Intrusion Determination
System (IDS)

A security service that monitors and analyzes network or system events for
the purpose of finding, and providing real-time or near real-time warning of,
attempts to access system resources in an unauthorized manner.
SOURCE: RFC 4949 [75]

Intrusion Prevention System
(IPS)

A system that can detect an intrusive activity and can also attempt to stop
the activity, ideally before it reaches its targets.

Jitter

The time or phase difference between the data signal and the ideal clock.

Key Logger

A program designed to record which keys are pressed on a computer
keyboard used to obtain passwords or encryption keys and thus bypass other
security measures.

Light Tower

A device containing a series of indicator lights and an embedded controller
used to indicate the state of a process based on an input signal.
SOURCE: NIST IR 6859 [2]

Local Area Network (LAN)

A group of computers and other devices dispersed over a relatively limited
area and connected by a communications link that enables any device to
interact with any other on the network.

Machine Controller

A control system/motion network that electronically synchronizes drives
within a machine system instead of relying on synchronization via
mechanical linkage.

Maintenance

Any act that either prevents the failure or malfunction of equipment or
restores its operating capability.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Malware

Software or firmware intended to perform an unauthorized process that will
have adverse impact on the confidentiality, integrity, or availability of an
information system. A virus, worm, Trojan horse, or other code-based entity
that infects a host. Spyware and some forms of adware are also examples of
malicious code (malware).
SOURCE: NIST SP 800-53 [22]

Management Controls

The security controls (i.e., safeguards or countermeasures) for an
information system that focus on the management of risk and the
management of information security.
SOURCE: NIST SP 800-18 [19]

Manipulated Variable

In a process that is intended to regulate some condition, a quantity or a
condition that the control alters to initiate a change in the value of the
regulated condition.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

235

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Intrusion Detection System システムリ゜ヌスに無断でアクセスするもくろみを発芋し、リアルタ
(IDS)
むム又はほがリアルタむムで譊告するために、ネットワヌク又はシス
䟵入怜知システム
テムむベントを監芖・分析するセキュリティサヌビス。
出兞RFC 4949 [75]
Intrusion Prevention System 䟵入掻動を怜知し、可胜であれば目暙に達する前に掻動をやめさせる
(IPS)
こずができるシステム。
䟵入防止システム
Jitterゞッタヌ

デヌタ信号ず理想的クロック間の時間差又はフェヌズ。

Key Loggerキヌロガヌ

パスワヌドや暗号鍵を取埗し、他のセキュリティ手段を迂回するため
に、コンピュヌタのキヌボヌドで抌されたキヌを蚘録するプログラ
ム。

Light Towerラむトタワヌ入力信号に基づいおプロセス状態を衚瀺する、䞀連のむンゞケヌタラ
むトず組蟌みコントロヌラを備えたデバむス。
出兞NIST IR 6859 [2]
比范的限定された゚リア内に分散し、通信リンクで接続され、それぞ
Local Area Network
(LAN)
れがネットワヌク䞊で連動するコンピュヌタその他のデバむスグルヌ
ロヌカル゚リアネットワヌ プ。
ク
Machine Controller
マシンコントロヌラ

マシンシステム内のドラむブを、機械匏リンク経由の同期に䟝存せ
ず、電子的に同期する制埡システム/モヌションネットワヌク。

Maintenance保守

装備品の故障又は䞍具合を防止又は皌働状態に回埩する行為。
出兞オヌトメヌション・システム・蚈装事兞

Malwareマルり゚ア

情報システムの機密性、完党性又は可甚性に悪圱響する䞍正アクセス
を行うための゜フトり゚ア又はファヌムり゚ア。りむルス、ワヌム、
トロむの朚銬その他コヌドベヌスのものがホストを感染させる。スパ
むり゚アやいく぀かの圢態のアドりェアも悪意あるコヌドマルり゚
アの䟋である。
出兞NIST SP 800-53 [22]

Management Controls
管理察策

リスク管理及び情報セキュリティ管理に特化した情報システムのセキ
ュリティ察策安党策又は察策。
出兞NIST SP 800-18 [19]

Manipulated Variable
操䜜された倉数

特定の状態を調敎するためのプロセスにおいお、調敎枈み状態の倀を
制埡が倉曎するずきの量又は状態。出兞オヌトメヌション・システ
ム・蚈装事兞

236

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Manufacturing Execution
System (MES)

A system that uses network computing to automate production control and
process automation. By downloading recipes and work schedules and
uploading production results, a MES bridges the gap between business and
plant-floor or process-control systems.
SOURCE: NIST IR 6859 [2]

Master Terminal Unit
(MTU)
Modem

See Control Server.

Motion Control Network

The network supporting the control applications that move parts in
industrial settings, including sequencing, speed control, point-to-point
control, and incremental motion.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Network Interface Card
(NIC)

A circuit board or card that is installed in a computer so that it can be
connected to a network.

Object Linking and
Embedding (OLE) for
Process Control (OPC)

A set of open standards developed to promote interoperability between
disparate field devices, automation/control, and business systems.

Operating System

An integrated collection of service routines for supervising the sequencing
of programs by a computer. An operating system may perform the functions
of input/output control, resource scheduling, and data management. It
provides application programs with the fundamental commands for
controlling the computer.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Operational Controls

The security controls (i.e., safeguards or countermeasures) for an
information system that are primarily implemented and executed by people
(as opposed to systems).
SOURCE: NIST SP 800-18 [19]

Password

A string of characters (letters, numbers, and other symbols) used to
authenticate an identity or to verify access authorization.

Phishing

Tricking individuals into disclosing sensitive personal information by
claiming to be a trustworthy entity in an electronic communication (e.g.,
internet web sites).

A device used to convert serial digital data from a transmitting terminal to a
signal suitable for transmission over a telephone channel to reconvert the
transmitted signal to serial digital data for the receiving terminal.
SOURCE: NIST IR 6859 [2]

237

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Manufacturing Execution
System (MES)
生産実行システム

ネットワヌクコンピュヌティングを利甚しお生産制埡及びプロセスの
自動化を行うシステム。レシピず䜜業スケゞュヌルをダりンロヌド
し、生産結果をアップロヌドするこずにより、MES は事業システム
ずプラント珟堎システム又はプロセス制埡システム間のギャップを埋
める。
出兞NIST IR 6859 [2]

Master Terminal Unit
(MTU)
マスタヌ端末装眮

制埡サヌバを参照。

Modemモデム

通信端末からのシリアルデゞタルデヌタを電話網通信に適した信号に
倉換し、受信端末にはシリアルデゞタルデヌタに再倉換するためのデ
バむス。
出兞NIST IR 6859 [2]

Motion Control Network 産業環境においおパヌツを動かす制埡アプリケヌションに察応したネ
動䜜制埡ネットワヌク
ットワヌクで、動䜜にはシヌケンシング、速床制埡、2 点間制埡、差
分動䜜等がある。
出兞オヌトメヌション・システム・蚈装事兞
コンピュヌタに蚭眮される回路基板又はカヌドで、コンピュヌタをネ
Network Interface Card
(NIC)ネットワヌクむン ットワヌクに接続する。
タフェヌスカヌド
Object Linking and
Embedding (OLE) for
Process Control (OPC)
プロセス制埡甚 OLE

異皮フィヌルドデバむス間、オヌトメヌション/制埡間及び事業シス
テム間の盞互運甚性を促進するために開発されたオヌプン芏栌。

Operating System
コンピュヌタによりプログラムのシヌケンシングを監芖させる定垞サ
オペレヌティングシステム ヌビスの集合䜓。入出力制埡、リ゜ヌススケゞュヌリング及びデヌタ
管理を行う。コンピュヌタを制埡するための機胜コマンドをアプリケ
ヌションプログラムに提䟛する。
出兞オヌトメヌション・システム・蚈装事兞
Operational Controls
運甚制埡

䞻に人間システムではなくが実装し実行する情報システムのセキ
ュリティ察策安党策又は察策。
出兞NIST SP 800-18 [19]

Passwordパスワヌド

身分を認蚌又はアクセス暩限を確認するための文字列文字、数字そ
の他蚘号。

Phishingフィッシング

電子通信むンタヌネットりェブサむト等においお信頌できる実䜓
であるず䞻匵するこずにより、欺いお個人情報を開瀺させるこず。

238

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Photo Eye

A light sensitive sensor utilizing photoelectric control that converts a light
signal into an electrical signal, ultimately producing a binary signal based
on an interruption of a light beam.
SOURCE: NIST IR 6859 [2]

Plant

The physical elements necessary to support the physical process. This can
include many of the static components not controlled by the ICS; however,
the operation of the ICS may impact the adequacy, strength, and durability
of the plant’s components.

Port

The entry or exit point from a computer for connecting communications or
peripheral devices.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Port Scanning

Using a program to remotely determine which ports on a system are open
(e.g., whether systems allow connections through those ports).
SOURCE: NIST SP 800-61 [59]

Predisposing Condition

A condition that exists within an organization, a mission/business
process, enterprise architecture, or information system including its
environment of operation, which contributes to (i.e., increases or
decreases) the likelihood that one or more threat events, once
initiated, will result in undesirable consequences or adverse impact to
organizational operations and assets, individuals, other organizations,
or the Nation.
SOURCE: SP 800-30 [79]

Pressure Regulator

A device used to control the pressure of a gas or liquid.
SOURCE: NIST IR 6859 [2]

Pressure Sensor

A sensor system that produces an electrical signal related to the pressure
acting on it by its surrounding medium. Pressure sensors can also use
differential pressure to obtain level and flow measurements.
SOURCE: NIST IR 6859 [2]

Printer

A device that converts digital data to human-readable text on a paper
medium.
SOURCE: NIST IR 6859 [2]

Process Controller

A type of computer system, typically rack-mounted, that processes sensor
input, executes control algorithms, and computes actuator outputs.
SOURCE: NIST IR 6859 [2]

239

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Photo Eyeフォトアむ

光信号を電子信号に倉換する光電子制埡を利甚した感光センサで、光
線を䞭断しおバむナリ信号を生成する。
出兞NIST IR 6859 [2]

Plantプラント

物理プロセスを支えるための物理芁玠。ICS で制埡されない倚くの静
的コンポヌネントが含たれ埗るが、ICS の運甚はプラットホヌムコン
ポヌネントの適切性、匷床及び耐久性に圱響する。

Portポヌト

コンピュヌタが通信機噚又は呚蟺デバむスに接続するための出入口ず
なる点。
出兞オヌトメヌション・システム・蚈装事兞

Port Scanning
ポヌトスキャニング

プログラムを利甚しお開攟されおいるポヌトそこからシステムに接
続できるかを刀定するこず。
出兞NIST SP 800-61 [59]

Predisposing Condition
玠因的状態

組織、任務・事業、䌁業アヌキテクチャ又は情報システム内に存圚す
る状態のこずで、いったん発動するず、組織の運営及び資産、個人、
他の組織又は囜に悪圱響を䞎える脅嚁事象に寄䞎増枛する運甚環
境が含たれる。
出兞SP 800-30 [79]

Pressure Regulator
圧力レギュレヌタ

ガス又は液䜓の圧力を制埡するデバむス。出兞NIST IR 6859 [2]

Pressure Sensor
圧力センサ

呚蟺媒䜓から受ける圧力に関する電気信号を発生するセンサシステ
ム。圧力センサは差圧を利甚しおレベル及び流量の蚈枬も行う。
出兞NIST IR 6859 [2]

Printerプリンタ

デゞタルデヌタを人が読める玙のテキストに倉換するデバむス。出
兞NIST IR 6859 [2]

Process Controller
プロセスコントロヌラ

通垞ラックに蚭眮された 1 皮のコンピュヌタシステムで、センサ入力
を凊理し、制埡アルゎリズムを実行し、アクチュ゚ヌタ出力を蚈算す
る。
出兞NIST IR 6859 [2]

240

SPECIAL PUBLICATION 800-82 REVISION 2

Programmable Logic
Controller
(PLC)

Protocol

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

A solid-state control system that has a user-programmable memory for
storing instructions for the purpose of implementing specific functions such
as I/O control, logic, timing, counting, three mode (PID) control,
communication, arithmetic, and data and file processing.
SOURCE: The Automation, Systems, and Instrumentation Dictionary
A small industrial computer originally designed to perform the logic
functions executed by electrical hardware (relays, switches, and mechanical
timer/counters). PLCs have evolved into controllers with the capability of
controlling complex processes, and they are used substantially in SCADA
systems and DCS. PLCs are also used as the primary controller in smaller
system configurations. PLCs are used extensively in almost all industrial
processes.
A set of rules (i.e., formats and procedures) to implement and control some
type of association (e.g., communication) between systems.
SOURCE: RFC 4949 [75]

Protocol Analyzer

A device or software application that enables the user to analyze the
performance of network data so as to ensure that the network and its
associated hardware/software are operating within network specifications.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Proximity Sensor

A non-contact sensor with the ability to detect the presence of a target
within a specified range. SOURCE: NIST IR 6859 [2]

Proxy Server

A server that services the requests of its clients by forwarding those requests
to other servers.
SOURCE: CNSSI-4009

Real-Time

Pertaining to the performance of a computation during the actual time that
the related physical process transpires so that the results of the computation
can be used to guide the physical process.
SOURCE: NIST IR 6859 [2]

Redundant Control Server

A backup to the control server that maintains the current state of the control
server at all times.
SOURCE: NIST IR 6859 [2]

Relay

An electromechanical device that completes or interrupts an electrical circuit
by physically moving conductive contacts. The resultant motion can be
coupled to another mechanism such as a valve or breaker.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

241

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

゜リッドステヌト制埡システムで、ナヌザがプログラム可胜なメモリ
Programmable Logic
Controller (PLC)
があり、I/O 制埡、論理、タむミング、カりント、3 モヌドPIDの
プログラマブル論理制埡装 制埡、通信、挔算、デヌタやファむルの凊理等の具䜓的な機胜を実装
眮
するための呜什を栌玍する。
出兞オヌトメヌション・システム・蚈装事兞
元々は電気的ハヌドり゚アリレヌ、スむッチ及び機械的タむマヌ/
カりンタヌにより実行される論理機胜を実行するために蚭蚈された
小型の産業甚コンピュヌタ。耇雑なプロセスの制埡胜力を持ったコン
トロヌラに進化し、SCADA システム及び DCS で倚甚される。たた、
より小型のシステム構成䞭でプラむマリコントロヌラずしおも利甚さ
れおいる。PLC はほずんど党おの産業プロセスで広範に利甚される。
Protocolプロトコル

システム間のある皮の関係通信等を実行し制埡するための䞀連の
芏則圢匏及び手順。
出兞RFC 4949 [75]

Protocol Analyzer
プロトコル分析噚

ネットワヌク及び関連ハヌドり゚ア/゜フトり゚アがネットワヌク仕
様内で動䜜するように、ナヌザがネットワヌクデヌタのパフォヌマン
スを分析できるようにするデバむスたたは゜フトり゚ア。
出兞オヌトメヌション・システム・蚈装事兞

Proximity Sensor
近接センサ

目暙倀が指定範囲にあるこずを怜出できる非接觊型センサ。
出兞NIST IR 6859 [2]

Proxy Server
プロキシサヌバ

クラむアントからの芁求を他のサヌバに転送するサヌバ。
出兞CNSSI-4009

Real-Timeリアルタむム 蚈算に関係する物理プロセスが発生しお、蚈算結果が物理プロセスの
制埡に利甚できる実時間蚈算をいう。
出兞NIST IR 6859 [2]
Redundant Control
Server
冗長制埡サヌバ

制埡サヌバのバックアップで、制埡サヌバの珟圚の状態を垞時保持す
る。
出兞NIST IR 6859 [2]

Relayリレヌ

接点を物理的に動かしお電気回路を接続又は䞭断する電子機械匏デバ
むス。その結果生じる運動は、バルブやブレヌカずいった別のデバむ
スに連携する。
出兞オヌトメヌション・システム・蚈装事兞

242

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Remote Access

Access by users (or information systems) communicating external to an
information system security perimeter.
SOURCE: NIST SP 800-53 [22]

Remote Access Point

Distinct devices, areas and locations of a control network for remotely
configuring control systems and accessing process data. Examples include
using a mobile device to access data over a LAN through a wireless access
point, and using a laptop and modem connection to remotely access an ICS
system.

Remote Diagnostics

Diagnostics activities conducted by individuals communicating external to
an information system security perimeter.

Remote Maintenance

Maintenance activities conducted by individuals communicating external to
an information system security perimeter.

Remote Terminal Unit
(RTU)

A computer with radio interfacing used in remote situations where
communications via wire is unavailable. Usually used to communicate with
remote field equipment. PLCs with radio communication capabilities are
also used in place of RTUs.
Special purpose data acquisition and control unit designed to support DCS
and SCADA remote stations. RTUs are field devices often equipped with
network capabilities, which can include wired and wireless radio interfaces
to communicate to the supervisory controller. Sometimes PLCs are
implemented as field devices to serve as RTUs; in this case, the PLC is often
referred to as an RTU.

Resource Starvation

A condition where a computer process cannot be supported by available
computer resources. Resource starvation can occur due to the lack of
computer resources or the existence of multiple processes that are competing
for the same computer resources.

Risk

The level of impact on agency operations (including mission, functions,
image, or reputation), agency assets, or individuals resulting from the
operation of an information system, given the potential impact of a threat
and the likelihood of that threat occurring.
SOURCE: NIST SP 800-30 [79]

Risk Assessment

The process of identifying risks to agency operations (including mission,
functions, image, or reputation), agency assets, or individuals by
determining the probability of occurrence, the resulting impact, and
additional security controls that would mitigate this impact. Part of risk
management, synonymous with risk analysis. Incorporates threat and
vulnerability analyses.
SOURCE: NIST SP 800-30 [79]

243

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Remote Access
リモヌトアクセス

情報システムのセキュリティ呚蟺倖から通信を行うナヌザ又は情報
システムのアクセス。
出兞NIST SP 800-53 [22]

Remote Access Point
リモヌトアクセス点

制埡システムを遠隔蚭定し、プロセスデヌタにアクセスするための制
埡ネットワヌクの明確なデバむス、゚リア及び堎所。䟋えばモバむル
デバむスを利甚しお、ワむダレスアクセス点から LAN 経由のデヌタ
アクセス、ラップトップ及びモデムを利甚した ICS システムアクセス
がある。

Remote Diagnostics
リモヌト蚺断

情報システムセキュリティ呚蟺倖から個人が行う蚺断掻動。

Remote Maintenance
遠隔保守

情報システムセキュリティ呚蟺倖から個人が行う保守掻動。

Remote Terminal Unit
(RTU)
遠隔端末装眮

有線通信が利甚できない遠隔環境で䜿甚する無線むンタフェヌス付き
コンピュヌタ。通垞、遠隔フィヌルド装備品ずの通信に䜿甚する。無
線通信機胜付き PLC も RTU の代わりに䜿甚される。

DCS 及び SCADA 遠隔ステヌションをサポヌトするための特殊目的で
のデヌタ取埗制埡装眮。RTU は、監芖コントロヌラずの通信甚有線・
無線むンタフェヌス等、ネットワヌク機胜を装備しおいる堎合が倚
い。PLC はフィヌルドデバむスずしお実装され RTU ずしお利甚され
るこずもある。PLC は RTU ず呌ばれるこずが倚い。
Resource Starvation
リ゜ヌス枯枇

利甚可胜なコンピュヌタリ゜ヌスではコンピュヌタプロセスがサポヌ
トできない状態。コンピュヌタリ゜ヌスの欠乏又は同じコンピュヌタ
リ゜ヌスをめぐる耇数プロセスの競合により生じるこずがある。

Riskリスク

脅嚁の朜圚的圱響及び圓該脅嚁が生じる蓋然性に鑑み、情報システム
の運甚から生じる政府機関の業務任務、機胜、むメヌゞ、評刀
等、政府機関の資産又は個人ぞの圱響床。
出兞NIST SP 800-30 [79]

Risk Assessment
リスク評䟡

発生確率、その圱響、圱響を緩和するための付加的セキュリティ察策
の刀定を通じた政府機関の業務任務、機胜、むメヌゞ、評刀等、
資産又は個人に察するリスク識別プロセス。リスク管理の䞀郚で、リ
スク分析ず同矩。脅嚁分析及び脆匱性分析を取り入れる。
出兞NIST SP 800-30 [79]

244

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Risk Management

The process of managing risks to organizational operations (including
mission, functions, image, reputation), organizational assets, individuals,
other organizations, and the Nation, resulting from the operation of an
information system, and includes: (i) the conduct of a risk assessment; (ii)
the implementation of a risk mitigation strategy; and (iii) employment of
techniques and procedures for the continuous monitoring of the security
state of the information system.
SOURCE: FIPS 200, Adapted [16]

Risk Management
Framework

The Risk Management Framework (RMF), presented in NIST SP 800-37,
provides a disciplined and structured process that integrates information
security and risk management activities into the system development life
cycle.
SOURCE: SP 800-37 [21]

Router

A computer that is a gateway between two networks at OSI layer 3 and that
relays and directs data packets through that inter-network. The most
common form of router operates on IP packets.
SOURCE: RFC 4949 [75]

Router Flapping

A router that transmits routing updates alternately advertising a destination
network first via one route, then via a different route.

Safety Instrumented System
(SIS)

A system that is composed of sensors, logic solvers, and final control
elements whose purpose is to take the process to a safe state when
predetermined conditions are violated. Other terms commonly used include
emergency shutdown system (ESS), safety shutdown system (SSD), and
safety interlock system (SIS).
SOURCE: ANSI/ISA-84.00.01

SCADA Server

The device that acts as the master in a SCADA system.
SOURCE: NIST IR 6859 [2]

Security Audit

Independent review and examination of a system’s records and activities to
determine the adequacy of system controls, ensure compliance with
established security policy and procedures, detect breaches in security
services, and recommend any changes that are indicated for
countermeasures.
SOURCE: ISO/IEC 7498

Security Controls

The management, operational, and technical controls (i.e., safeguards or
countermeasures) prescribed for an information system to protect the
confidentiality, integrity, and availability of the system and its information.
SOURCE: FIPS PUB 199 [15]

245

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Risk Management
リスク管理

情報システムの運甚から生じる、組織の運営任務、機胜、むメヌ
ゞ、評刀等及び資産、個人、他の組織又は囜ぞのリスクを管理する
プロセスで、以䞋を含む。1リスク評䟡の実斜、2リスク緩和
策の実斜、3情報システムのセキュリティ状態を垞続監芖するた
めの技術及び手順の採甚。
出兞FIPS 200, Adapted [16]

Risk Management
Framework
リスク管理䜓制

NIST SP 800-37 に瀺されるリスク管理䜓制RMFは、情報セキュリ
ティ掻動ずリスク管理掻動をシステム開発ラむフサむクルに統合化す
るための統制の取れた組織化されたプロセスず定めおいる。
出兞SP 800-37 [21]

Routerルヌタ

OSI レむダヌ3 でのネットワヌクずデヌタパッケヌゞを䞭継指向する
ネットワヌク間のゲヌトりェむずなるコンピュヌタ。最も䞀般的な圢
態のルヌタは IP パケットで動䜜する。
出兞RFC 4949 [75]

Router Flapping
ルヌタフラッピング

経路曎新を亀互に送信するルヌタ。宛先ネットワヌクをたずある経路
で広告し、次いで別経路で行う。

Safety Instrumented System センサ、ロゞック゜ルバヌ及び最終制埡゚レメントで構成されるシス
(SIS)安党蚈装システム テムで、目的は予め定められた条件から逞脱した際に、プロセスを安
党状態に戻すこずにある。䞀般に䜿甚されるその他の甚語ずしお緊急
遮断システムESS、安党遮断システムSSD、安党連動システ
ムSIS等がある。
出兞ANSI/ISA-84.00.01
SCADA Server
SCADA サヌバ

SCADA システムでマスタヌずなるデバむス。
出兞NIST IR 6859 [2]

Security Audit
セキュリティ監査

システム制埡の適切性を刀定し、芏定のセキュリティポリシヌ及び手
順の遵守を確保し、セキュリティサヌビス違反を怜出し、察策ずしお
瀺唆される倉曎内容を勧告するためのシステムの蚘録及び掻動に察す
る独立的な審査及び怜蚌。
出兞ISO/IEC 7498

Security Controls
セキュリティ察策

システムずその情報の機密性、完党性及び可甚性を保護するための情
報システム甚管理・運甚・技術察策安党策、察抗手段等。
出兞FIPS PUB 199 [15]

246

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Security Plan

Formal document that provides an overview of the security requirements for
the information system and describes the security controls in place or
planned for meeting those requirements.
SOURCE: NIST SP 800-53 [22]

Security Policy

Security policies define the objectives and constraints for the security
program. Policies are created at several levels, ranging from organization or
corporate policy to specific operational constraints (e.g., remote access). In
general, policies provide answers to the questions “what” and “why”
without dealing with “how.” Policies are normally stated in terms that are
technology-independent.
SOURCE: ISA99

Sensor

A device that produces a voltage or current output that is representative of
some physical property being measured (e.g., speed, temperature, flow).
SOURCE: The Automation, Systems, and Instrumentation Dictionary
A device that measures a physical quantity and converts it into a signal
which can be read by an observer or by an instrument. A sensor is a device,
which responds to an input quantity by generating a functionally related
output usually in the form of an electrical or optical signal.

Servo Valve

An actuated valve whose position is controlled using a servo actuator.
SOURCE: NIST IR 6859 [2]

Set Point

An input variable that sets the desired value of the controlled variable. This
variable may be manually set, automatically set, or programmed.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Simple Network
Management Protocol
(SNMP)

A standard TCP/IP protocol for network management. Network
administrators use SNMP to monitor and map network availability,
performance, and error rates. To work with SNMP, network devices utilize a
distributed data store called the Management Information Base (MIB). All
SNMP-compliant devices contain a MIB which supplies the pertinent
attributes of a device. Some attributes are fixed or “hard-coded” in the MIB,
while others are dynamic values calculated by agent software running on the
device.
SOURCE: API 1164

Single Loop Controller

A controller that controls a very small process or a critical process.
SOURCE: NIST IR 6859 [2]

Social Engineering

An attempt to trick someone into revealing information (e.g., a password)
that can be used to attack systems or networks.
SOURCE: NIST SP 800-61 [59]

247

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Security Plan
セキュリティ蚈画曞

情報システムのセキュリティ芁件を抂説した正匏文曞で、その芁件を
満足する実斜䞭又は蚈画䞭のセキュリティ察策に぀いお蚘述したも
の。
出兞NIST SP 800-53 [22]

Security Policy
セキュリティポリシヌ

セキュリティポリシヌはセキュリティプログラムの目的ず制玄事項を
定矩する。ポリシヌはいく぀かのレベルで䜜成され、組織又は䌁業ポ
リシヌから具䜓的な運甚䞊の制玄事項リモヌトアクセス等たであ
る。総じおポリシヌは「䜕が」ずか「なぜ」には答えるが、「どのよ
うに」ずいう質問には答えおいない。通垞、技術ずは無関係の甚語で
蚘述される。
出兞ISA99

Sensorセンサ

蚈枬䞭の物理特性速床、枩床、流量等を衚した電圧又は電流出力
を発生させるデバむス。
出兞オヌトメヌション・システム・蚈装事兞

物理的量を蚈枬しお信号に倉換するデバむスで、信号は芳察者や蚈噚
で読み取るこずができる。機胜的に関わりのある出力を、通垞、電気
又は光孊信号ずしお生成するこずにより、入力に察応するデバむス。
Servo Valve
サヌボバルブ

サヌボアクチュ゚ヌタを䜿甚しお䜍眮を制埡する䜜動匁。
出兞NIST IR 6859 [2]

Set Point蚭定点

制埡倉数の所望の倀を蚭定する入力倉数。この倉数はマニュアル操
䜜、自動、プログラム化のいずれによっおも蚭定可胜である。
出兞オヌトメヌション・システム・蚈装事兞

ネットワヌク管理甚暙準 TCP/IP プロトコル。ネットワヌク管理者は
Simple Network
Management Protocol
このプロトコルを䜿甚しおネットワヌクの可甚性、パフォヌマンス及
(SNMP)
び゚ラヌ率を監芖する。SNMP に察応しお、ネットワヌクデバむスは
シンプルネットワヌク管理 管理情報ベヌスMIBず呌ばれる分散デヌタストアを䜿甚する。党
プロトコル
おの SNMP 適合デバむスは MIB を持っおおり、デバむスの関連属性
を䟛絊する。ある属性は MIB に固定又は「ハヌドコヌド」され、た
たあるものはデバむスで実行䞭の゚ヌゞェントにより蚈算される動的
倀ずなる。
出兞API 1164
Single Loop Controller
単䞀ルヌプコントロヌラ

極めお小さなプロセス又は重芁プロセスを制埡するコントロヌラ。出
兞NIST IR 6859 [2]

Social Engineering
システムやネットワヌクの攻撃に䜿甚するため、人を欺いお情報パ
゜ヌシャル゚ンゞニアリン スワヌド等を挏掩させるもくろみ。
グ
出兞NIST SP 800-61 [59]

248

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Solenoid Value

A valve actuated by an electric coil. A solenoid valve typically has two
states: open and closed.
SOURCE: NIST IR 6859 [2]

Spyware

Software that is secretly or surreptitiously installed onto an information
system to gather information on individuals or organizations without their
knowledge; a type of malicious code.
SOURCE: NIST SP 800-53 [22]

Statistical Process Control
(SPC)

The use of statistical techniques to control the quality of a product or
process.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Steady State

A characteristic of a condition, such as value, rate, periodicity, or amplitude,
exhibiting only negligible change over an arbitrarily long period of time.
SOURCE: ANSI/ISA-51.1-1979

Supervisory Control

A term that is used to imply that the output of a controller or computer
program is used as input to other controllers. See Control Server
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Supervisory Control and
Data Acquisition (SCADA)

A generic name for a computerized system that is capable of gathering and
processing data and applying operational controls over long distances.
Typical uses include power transmission and distribution and pipeline
systems. SCADA was designed for the unique communication challenges
(e.g., delays, data integrity) posed by the various media that must be used,
such as phone lines, microwave, and satellite. Usually shared rather than
dedicated.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

System Security Plan

Formal document that provides an overview of the security requirements for
a system and describes the security controls in place or planned for meeting
those requirements.
SOURCE: NIST SP 800-18, Adapted [19]

Technical Controls

The security controls (i.e., safeguards or countermeasures) for an
information system that are primarily implemented and executed by the
information system through mechanisms contained in the hardware,
software, or firmware components of the system.
SOURCE: NIST SP 800-18 [19]

Temperature Sensor

A sensor system that produces an electrical signal related to its temperature
and, as a consequence, senses the temperature of its surrounding medium.
SOURCE: NIST IR 6859 [2]

249

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Solenoid Valve
゜レノむドバルブ

電気コむルで䜜動する匁。通垞「開」ず「閉」の 2 ぀の状態がある。
出兞NIST IR 6859 [2]

Spywareスパむり゚ア

気づかれずに個人又は組織の情報を収集するため、秘密裏に又は䞍正
に情報システムに取り付けられる゜フトり゚アで、悪意あるコヌドの
1 皮。
出兞NIST SP 800-53 [22]

Statistical Process Control
(SPC)
統蚈的プロセス管理

補品又はプロセスの品質を管理するための統蚈技術の䜿甚。
出兞オヌトメヌション・システム・蚈装事兞

Steady State定垞状態

倀、率、呚期、芏暡等の状態特性をいい、任意の長期間にわたり倉化
が無芖できるこず。
出兞ANSI/ISA-51.1-1979

Supervisory Control
監芖制埡

コントロヌラ又はコンピュヌタプログラムの出力が他のコントロヌラ
の入力ずしお䜿甚されおいるこずを瀺す甚語。制埡サヌバを参照
出兞オヌトメヌション・システム・蚈装事兞

Supervisory Control and
Data Acquisition
(SCADA)
監芖制埡デヌタ取埗

長距離のデヌタ収集凊理ず運甚制埡を行えるコンピュヌタ制埡システ
ムの汎甚的な名称。送配電及びパむプラむン等によく利甚される。電
話回線、マむクロ波、人工衛星等で䜿甚される倚様な媒䜓に特有の通
信問題遅延、デヌタ敎合性等に察応しお蚭蚈された。通垞専甚で
はなく共有されるこずが倚い。
出兞オヌトメヌション・システム・蚈装事兞

System Security Plan
システムセキュリティ芁件の抂芁を瀺し、芁件を遵守するために斜行
システムセキュリティ蚈画 䞭又は蚈画䞭のセキュリティ察策に぀いお説明した正匏文曞。
曞
出兞NIST SP 800-18, Adapted [19]
Technical Controls
技術制埡

システムのハヌドり゚ア、゜フトり゚ア又はファヌムり゚アコンポヌ
ネントに含たれるメカニズムを通じお、䞻に情報システムにより実装
され実斜される情報システム甚のセキュリティ察策安党策又は察抗
手段。
出兞NIST SP 800-18 [19]

Temperature Sensor
枩床センサ

枩床に関する電気信号を発生させ、その結果呚蟺媒䜓の枩床を怜知す
るセンサシステム。
出兞NIST IR 6859 [2]

250

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Threat

Any circumstance or event with the potential to adversely impact agency
operations (including mission, functions, image, or reputation), agency
assets, or individuals through an information system via unauthorized
access, destruction, disclosure, modification of information, and/or denial of
service.
SOURCE: NIST SP 800-53 [22]

Threat Event

An event or situation that has the potential for causing undesirable
consequences or impact.
SOURCE: SP 800-30 [79]

Threat Source

The intent and method targeted at the intentional exploitation of a
vulnerability or a situation and method that may accidentally trigger a
vulnerability. Synonymous with Threat Agent.
SOURCE: FIPS 200 [16]; SP 800-53 [22]; SP 800-53A [23]; SP 800-37
[21]

Transmission Control
Protocol (TCP)

TCP is one of the main protocols in TCP/IP networks. Whereas the IP
protocol deals only with packets, TCP enables two hosts to establish a
connection and exchange streams of data. TCP guarantees delivery of data
and also guarantees that packets will be delivered in the same order in which
they were sent.
SOURCE: API 1164

Trojan Horse

A computer program that appears to have a useful function, but also has a
hidden and potentially malicious function that evades security mechanisms,
sometimes by exploiting legitimate authorizations of a system entity that
invokes the program.
SOURCE: RFC 4949 [75]

Unauthorized Access

A person gains logical or physical access without permission to a network,
system, application, data, or other resource.
SOURCE: NIST SP 800-61 [59]

Unidirectional Gateway

Unidirectional gateways are a combination of hardware and software. The
hardware permits data to flow from one network to another, but is
physically unable to send any information at all back into the source
network. The software replicates databases and emulates protocol servers
and devices.

Valve

An in-line device in a fluid-flow system that can interrupt flow, regulate the
rate of flow, or divert flow to another branch of the system.
SOURCE: The Automation, Systems, and Instrumentation Dictionary

Variable Frequency Drive
(VFD)

A type of drive that controls the speed, but not the precise position, of a
non-servo, AC motor by varying the frequency of the electricity going to
that motor. VFDs are typically used for applications where speed and power
are important, but precise positioning is not.
SOURCE: NIST IR 6859 [2]

251

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

Threat脅嚁

䞍正アクセス、砎壊、開瀺、情報の改倉又はサヌビス劚害を通じお、
政府機関の業務任務、機胜、むメヌゞ、評刀等、政府機関の資産
又は個人に悪圱響を及がしかねない状況又は事象。
出兞NIST SP 800-53 [22]

Threat Event脅嚁事象

望たしくない結果や圱響を生じかねない事象又は状況。
出兞SP 800-30 [79]

Threat Source脅嚁源

脆匱性又は状況及び方法を故意に利甚するこずをもくろむ意思及び方
法で、偶発的に脆匱性を生じさせる原因ずなり埗る。脅嚁゚ヌゞェン
トず同矩。
出兞FIPS 200 [16]; SP 800-53 [22]; SP 800-53A [23]; SP 800-37 [21]

Transmission Control
Protocol (TCP)
通信制埡プロトコル

TCP/IP ネットワヌクにおける䞻なプロトコルの 1 ぀。IP プロトコル
がパケット凊理だけなのに察し、TCP は 2 台のホストが接続を確立し
おデヌタストリヌムを亀換できるようにする。デヌタの配送を保蚌
し、パケットを送信順に届くようにできる。
出兞API 1164

Trojan Horse
トロむの朚銬

コンピュヌタプログラムで、䟿利な機胜も持぀が、隠れた悪意ある機
胜があり、プログラムを起動したシステム実圚者の適栌性を利甚し
お、セキュリティ機構に䟵入する。
出兞RFC 4949 [75]

Unauthorized Access
䞍正アクセス

ネットワヌク、システム、アプリケヌション、デヌタその他のリ゜ヌ
スに、人が蚱可なく論理的又は物理的アクセスするこず。
出兞NIST SP 800-61 [59]

Unidirectional Gateway
単方向ゲヌトりェむ

単方向性ゲヌトりェむはハヌドり゚アず゜フトり゚アを組み合わせた
ものである。ハヌドり゚アはデヌタが䞀方のネットワヌクから他方の
ネットワヌクぞ流れるのを蚱可するが、゜ヌスネットワヌクに情報を
返すこずは物理的に䞍可胜である。゜フトり゚アはデヌタベヌスを耇
補しお、プロトコルサヌバ及びデバむスを゚ミュレヌトする。

Valveバルブ匁

流䜓システム䞭のむンラむンデバむスで、流れを遮断し、流量を調節
し、システム䞭での流れの方向を倉えるこずができる。
出兞オヌトメヌション・システム・蚈装事兞

Variable Frequency Drive
(VFD)可倉呚波数駆動

モヌタぞの電気呚波数を倉えるこずにより、非サヌボ型の亀流モヌタ
の速床を制埡する駆動の 1 皮で、粟確な䜍眮は制埡できない。䞀般に
速床ず電力が重芖され、粟確な䜍眮は重芁でない甚途に利甚される。
出兞NIST IR 6859 [2]

252

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Virtual Private Network
(VPN)

A restricted-use, logical (i.e., artificial or simulated) computer network that
is constructed from the system resources of a relatively public, physical
(i.e., real) network (such as the Internet), often by using encryption (located
at hosts or gateways), and often by tunneling links of the virtual network
across the real network.
SOURCE: RFC 4949 [75]

Virus

A hidden, self-replicating section of computer software, usually malicious
logic, that propagates by infecting (i.e., inserting a copy of itself into and
becoming part of) another program. A virus cannot run by itself; it requires
that its host program be run to make the virus active.
SOURCE: RFC 4949 [75]

Virus Definitions

Predefined signatures for known malware used by antivirus detection
algorithms.

Vulnerability

Weakness in an information system, system security procedures, internal
controls, or implementation that could be exploited or triggered by a threat
source.
SOURCE: NIST SP 800-53 [22]

Whitelist

A list of discrete entities, such as hosts or applications that are known to be
benign and are approved for use within an organization and/or information
system.
SOURCE: SP 800-128 [80]

Wide Area Network (WAN)

A physical or logical network that provides data communications to a larger
number of independent users than are usually served by a local area
network (LAN) and that is usually spread over a larger geographic area than
that of a LAN.
SOURCE: API 1164

Wireless Device

Any device that can connect to an ICS network via radio or infrared waves,
usually to collect or monitor data, but also in some cases to modify control
set points.

Workstation

A computer used for tasks such as programming, engineering, and design.
SOURCE: NIST IR 6859 [2]

Worm

A computer program that can run independently, can propagate a complete
working version of itself onto other hosts on a network, and may consume
computer resources destructively.
SOURCE: RFC 4949 [75]

253

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

限定的に䜿甚される論理的人工的又は暡擬的コンピュヌタヌネッ
Virtual Private Network
(VPN)
トワヌクで、比范的公開された物理的珟実的ネットワヌクむン
仮想プラむベヌトネットワ タヌネット等から構築され、暗号化を利甚するこずが倚くホスト
ヌク
又はゲヌトりェむで、仮想ネットワヌクリンクを実ネットワヌクに
トンネリングするこずが倚い。
出兞RFC 4949 [75]
Virusりむルス

コンピュヌタヌ゜フトり゚アの隠れた自己耇補セクションで、通垞悪
意あるロゞックであり、他のプログラムを感染させるコピヌを挿入
しお自分がプログラムの䞀郚ずなるこずで増殖する。りむルスはそ
れ自䜓で実行するこずはできず、ホストプログラムによっおアクティ
ブにされる必芁がある。
出兞RFC 4949 [75]

Virus Definitions
りむルス定矩

アンチりむルス怜知アルゎリズムで䜿甚される既知のマルり゚アの事
前定矩シグネチャ。

Vulnerability脆匱性

情報システム、システムセキュリティ手順、内郚制埡又は実装におけ
る匱点で、脅嚁源により利甚又は起動される。
出兞NIST SP 800-53 [22]

Whitelistホワむトリスト 善良であるこずが知られおおり、組織又は情報システム䞭で、利甚を
蚱可されおいるホストやアプリケヌション等の個別実䜓リスト。
出兞SP 800-128 [80]
Wide Area Network
(WAN)
広域ネットワヌク

通垞、LAN サヌビスよりもナヌザ数が倚く、より広域にたたがっお
デヌタ通信サヌビスを行う物理的又は論理的ネットワヌク。
出兞API 1164

Wireless Device
ワむダレスデバむス

通垞、デヌタの収集又は監芖を目的に無線又は赀倖線で ICS ネットワ
ヌクに接続できるデバむスで、制埡蚭定点の倉曎に䜿甚するこずもあ
る。

Workstation
ワヌクステヌション

プログラミング、゚ンゞニアリング、蚭蚈等のタスクに䜿甚するコン
ピュヌタ。
出兞NIST IR 6859 [2]

Wormワヌム

独立しお実行できるコンピュヌタプログラムで、自分自身の完党な動
䜜バヌゞョンを他のホスト䞊に䌝播させ、コンピュヌタリ゜ヌスを砎
壊的に消費する。
出兞RFC 4949 [75]

254

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix C—Threat Sources, Vulnerabilities, and Incidents
Several terms are used to describe the inter-related concepts of threat, threat source, threat event, and
incident. A threat is any circumstance or event with the potential to adversely impact organizational
operations (including mission, functions, image, or reputation), organizational assets, individuals, other
organizations, or the Nation through an information system via unauthorized access, destruction, disclosure,
modification of information, and/or denial of service. Threats have some intent or method that may exploit
of a vulnerability through either intentional or unintentional means, this intent or method referred to as the
threat source. A vulnerability is a weakness in an information system (including an ICS), system security
procedures, internal controls, or implementation that could be exploited or triggered by a threat source. A
threat event is an event or situation that has the potential for causing undesirable consequences or impact.
When a threat event occurs it becomes an incident that actually or potentially jeopardizes the
confidentiality, integrity, or availability of an information system or the information the system processes,
stores, or transmits or that constitutes a violation or imminent threat of violation of security policies,
security procedures, or acceptable use policies. This section will explore ICS-specific threat sources,
vulnerabilities, and incidents.
Threat Sources
Threats to ICS can come from numerous sources, which can be classified as adversarial, accidental,
structural, and environmental. Table C-1 lists and defines known threats sources to ICS. It is necessary to
create a risk management strategy for the ICS that protects the system against these possible threat sources.
The threat source must be well understood in order to define and implement adequate protection. For
example, environmental events (e.g. floods, earthquakes) are well understood, but may vary in their
magnitude, frequency, and their ability to compound other interconnected events. However, adversarial
threats depend on the resources available to the adversary and the emergence of previously unknown
vulnerabilities or attacks.
Table C-1. Threats to ICS
Type of Threat Source

Description

ADVERSARIAL

Individuals, groups, organizations, or states that

- Individual

seek to exploit the organization’s dependence on

- Outsider

cyber resources (e.g., information in electronic

- Insider

form, information and communications

- Trusted Insider

technologies, and the communications and

- Privileged Insider

information-handling capabilities provided by

- Group

those technologies)

Characteristics
Capability, Intent, Targeting

- Ad hoc
- Established
- Organization
- Competitor
- Supplier
- Partner
- Customer
- Nation-State
ACCIDENTAL

Erroneous actions taken by individuals in the

- User

course of executing their everyday

- Privileged User/Administrator

responsibilities.

255

Range of effects

SP800-82 第 2 版

付録 C

産業甚制埡システムICSセキュリティガむド

脅嚁源、脆匱性及びむンシデント

脅嚁、脅嚁源、脅嚁事象及びむンシデントの盞互に関連し合った抂念を瀺すのにいく぀かの甚語
が甚いられる。脅嚁ずは、䞍正アクセス、砎壊、開瀺、情報の改倉又はサヌビス劚害により、情
報システムを通じお、組織業務任務、機胜、むメヌゞ、評刀等、組織資産、個人、他の組織
又は囜に悪圱響を及がしかねない状況又は事象をいう。脅嚁には、故意又は意図しない手段で脆
匱性を利甚する意思又は方法があり、この意思又は方法を脅嚁源ずいう。脆匱性ずは情報システ
ムICS を含む、システムセキュリティ手順、内郚制埡又は実装における匱点で、脅嚁源によ
り利甚又は起動される。脅嚁事象は、望たしくない結果や圱響を生じかねない事象又は状況をい
う。脅嚁事象が生起するずむンシデントずなり、むンシデントは、情報システム又はシステムが
凊理・保管・送信する情報の機密性・完党性・可甚性を実際に危険に陥れるか、その可胜性があ
り、たたセキュリティポリシヌ、セキュリティ手順又は受け入れられるポリシヌの䜿甚の違反又
は盎ちに違反ずなる脅嚁を構成する。このセクションでは、ICS 固有の脅嚁源、脆匱性及びむン
シデントに぀いお説明する。
脅嚁源
ICS の脅嚁には倚様な起源があり、敵性、偶発性、構造性及び環境性に分類できる。衚 C-1 は、
ICS の既知の脅嚁ずその定矩を瀺す。システムをこのような脅嚁源から守るため、ICS リスク管
理戊略を策定する必芁がある。しっかり保護できるよう、脅嚁源を十分理解しなければならない。
䟋えば、環境的事象措氎、地震等に぀いおはよく理解できおも、そのマグニチュヌド、頻床
及び他の関連事象ず耇合したずきの朜圚力は䞀様でない。しかし敵性脅嚁は、敵が利甚できるリ
゜ヌスず、以前知られおいた脆匱性又は攻撃の出珟に䟝存する。
è¡š C-1. ICS の脅嚁

脅嚁源の皮類
敵性
- 個人
- 郚倖者
- むンサむダヌ
- 信頌の眮けるむンサむダヌ
- 暩限のあるむンサむダヌ
- グルヌプ
- アドホック
- åžžå‹€
- 組織
- 競合盞手
- サプラむダ
- パヌトナヌ
- 顧客
- 囜・州
偶発性
- ナヌザ
- 特暩ナヌザ/管理者

内容
組織のサむバヌリ゜ヌス電子情報、情
報・通信技術、これら技術により提䟛され
る通信・情報凊理胜力等ぞの䟝存性を利
甚しようずもくろむ個人、グルヌプ、組織
又は囜

個人が日垞業務を果たす際の過誀行為

256

特城
胜力、意思、目暙遞定

圱響範囲

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Type of Threat Source

Description

STRUCTURAL

Failures of equipment, environmental controls, or

- Information Technology (IT) Equipment

software due to aging, resource depletion, or

- Storage

other circumstances which exceed expected

- Processing

operating parameters.

Characteristics
Range of effects

- Communications
- Display
- Sensor
- Controller
- Environmental Controls
- Temperature/Humidity Controls
- Power Supply
- Software
- Operating System
- Networking
- General-Purpose Application
- Mission-Specific Application
ENVIRONMENTAL

Natural disasters and failures of critical

- Natural or man-made disaster

infrastructures on which the organization

- Fire

depends, but which are outside the control of the

- Flood/Tsunami

organization.

Range of effects

- Windstorm/Tornado
- Hurricane

Note: Natural and man-made disasters can also

- Earthquake

be characterized in terms of their severity and/or

- Bombing

duration. However, because the threat source

- Overrun

and the threat event are strongly identified,

- Unusual Natural Event (e.g., sunspots)

severity and duration can be included in the

- Infrastructure Failure/Outage

description of the threat event (e.g., Category 5

- Telecommunications

hurricane causes extensive damage to the

- Electrical Power

facilities housing mission-critical systems, making
those systems unavailable for three weeks).

Vulnerabilities and Predisposing Conditions
This section addresses vulnerabilities and predisposing conditions that may be found in typical ICS.
Vulnerabilities are weaknesses in information systems, system procedures, controls, or implementations the
can be exploited by a threat source. Predisposing conditions are properties of the organization,
mission/business process, architecture, or information systems that contribute to the likelihood of a threat
event. The order of these vulnerabilities and predisposing conditions does not necessarily reflect any
priority in terms of likelihood of occurrence or severity of impact. Additionally, the vulnerabilities and
predisposing conditions identified in this section should not be considered a complete list; it should also not
be assumed that these issues are found within every ICS.

257

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脅嚁源の皮類
構造的
- 情報技術IT装備品
- ストレヌゞ

内容
経幎、リ゜ヌス䞍足その他の状況による予想運転
パラメヌタを超える装備品、環境制埡又は゜フト
り゚アの障害

特城
圱響範囲

- 凊理
- 通信
- ディスプレむ
- センサ
- コントロヌラ
- 環境制埡
- 枩床・湿床制埡
- 電源
- ゜フトり゚ア
- オペレヌティングシステム
- ネットワヌキング
- 汎甚アプリケヌション
- 任務固有アプリケヌション
環境的
- 自然・人為灜害
- 火灜
- 措氎・接波
- 暎颚・トルネヌド
- ハリケヌン
- 地震
- 爆砮

自然灜害及び組織が䟝存する重芁むンフラの障害 圱響範囲
で、組織の制埡倖のもの
泚自然・人為灜害は重倧性ず期間により特城づ
けられる。しかし脅嚁源及び脅嚁事象は特定され
おいるので、重倧性ず期間は、脅嚁事象䞭に含め
られる䟋えばカテゎリヌ5 のハリケヌンは、任
務に䞍可欠なシステムのある斜蚭に甚倧な被害を
䞎え、システムが 3 週間䜿甚䞍胜になる。

- オヌバヌラン
- 異垞倩然珟象倪陜黒点等
- むンフラ障害/停止
- 無線通信
- 電力

脆匱性及び匱点ずなる状態
このセクションでは、䞀般的な ICS にありがちな脆匱性ず匱点ずなる状態に぀いお取り䞊げる。
脆匱性は情報システム、システム手順、制埡又は実装における匱点で、脅嚁源により利甚されや
すい。匱点ずなる状態ずは、組織、任務・事業プロセス、アヌキテクチャ又は情報システムの特
性で、脅嚁事象が生じる公算を高める。このような脆匱性ず匱点ずなる状態は、発生の公算ず圱
響の重倧性の点で必ずしも優先づけがあるわけではない。たた、このセクションで取り䞊げるも
のが党おずいうわけでもない。逆にどの ICS にもこれらが必ずあるずいうものでもない。

258

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The vulnerabilities and predisposing conditions are grouped according to where they exist–such as in the
organization’s policy and procedures, or the inadequacy of security mechanisms implemented in hardware,
firmware, and software. The former are referred to as being in the organization and the latter as being in the
system. Understanding the source of vulnerabilities and predisposing conditions can assist in determining
optimal mitigation strategies. The groups of vulnerabilities used in this appendix are:


Policy and Procedure.



Architecture and Design.



Configuration and Maintenance.



Physical.



Software Development.



Communication and Network.

Deeper analysis may uncover that causes and observations may not be one-to-one; that is, some underlying
causes may exhibit multiple symptoms and some symptoms may come from more than one cause. SP 80053 contains a taxonomy of security controls, or countermeasures, to mitigate vulnerabilities and
predisposing conditions. These are categorized in families, where each family contains security controls
related to the general security topic of the family. While the families and controls from 800-53 provide a
more complete overview of the potential vulnerabilities and predisposing conditions within in an ICS, this
section briefly reviews those issues known to be common within ICS.
Any given ICS will usually exhibit a subset of the identified vulnerabilities, but may also contain additional
vulnerabilities and predisposing conditions unique to the particular ICS implementation that do not appear
in this appendix. Specific current information on ICS vulnerabilities can be researched at the Industrial
Control System Computer Emergency Response Team (ICS-CERT) Web site. 45
Some vulnerabilities and predisposing conditions can be mitigated; others can only be accepted and
controlled by appropriate countermeasures, but will result in some residual risk to the ICS. For example,
some existing policies and procedures may be changed with a level of effort that the organization considers
acceptable; others are more expeditiously dealt with by instituting additional policies and procedures.
Vulnerabilities in products and services acquired from outside the organization are rarely under the direct
control of the organization. Changes may be influenced by market forces, but this is a slow and indirect
approach. Instead, the organization may change predisposing conditions to reduce the likelihood that a
systemic vulnerability will be exploited.
Policy and Procedure Vulnerabilities and Predisposing Conditions
Vulnerabilities and predisposing conditions are often introduced into the ICS because of incomplete,
inappropriate, or nonexistent security policy, including its documentation, implementation guides (e.g.,
procedures), and enforcement. Management support of security policy and procedures is the cornerstone of
any security program. Organization security policy can reduce vulnerabilities by mandating and enforcing
proper conduct. Written policy and procedures are mechanisms for informing staff and stakeholders of
decisions about behavior that is beneficial to the organization. From this perspective, policy is an
educational and instructive way to reduce vulnerabilities. Enforcement is partner to policy, encouraging
people to do the “right” thing. Various forms of corrective action are the usual consequences

45

http://ics-cert.us-cert.gov.http://ics-cert.us-cert.gov..

259

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脆匱性ず匱点ずなる状態は、どこにあるかに応じおグルヌプ分けできる。䟋えば、組織のポリシ
ヌ及び手順、ハヌドり゚ア、ファヌムり゚ア、゜フトり゚アのセキュリティメカニズムの䞍備等
である。前者は組織、埌者はシステムにあるずいうこずになる。脆匱性ず匱点ずなる状態の起源
を理解するず、最適の緩和策が決めやすくなる。この付録で䜿甚する脆匱性のグルヌプは以䞋の
ずおり。

 ポリシヌ及び手順
 アヌキテクチャ及び蚭蚈
 構成及び保守
 物理面
 ゜フトり゚ア開発
 通信及びネットワヌク
深く分析するず、原因ず芳察結果が 1 察 1 でないこずが分かる。぀たり、特定の根本原因から耇
数の城候が生じ、特定の城候は耇数の原因から生じおいる。SP 800-53 にはセキュリティ察策の
分類、蚀い換えれば脆匱性ず匱点ずなる状態を緩和する察策が茉せられおいる。ファミリ別に分
類され、各ファミリにはそのファミリの党般的セキュリティ問題に関するセキュリティ察策が含
たれおいる。800-53 の系列ず管理は、ICS 内の脆匱性ず匱点ずなる状態に関するより完成床の高
い抂説があり、このセクションでは、ICS に共通的な問題を手短に振り返る。
どの ICS でも通垞明らかになっおいる脆匱性の䞀郚が露呈しおいるが、特定の ICS 実装に固有の、
この付録では取り䞊げられおいない脆匱性ず匱点ずなる状態もある。ICS の脆匱性に関する特定
の珟行情報が産業甚制埡システムコンピュヌタ緊急時察応チヌムICS-CERTのサむトにあ
る 46。
いく぀かの脆匱性ず匱点ずなる状態は緩和できる。その他に぀いおは、蚱容するか適圓な察策で
管理するしかないが、ICS の残留リスクずなる。䟋えば、既存ポリシヌ及び手順は、組織が蚱容
できるあるレベルの取組で倉曎されるものもあれば、補足的なポリシヌ及び手順を制定しお、も
っず迅速に凊理できるものもある。
組織倖から取埗した補品やサヌビスの脆匱性は、組織の盎接の管理䞋に眮かれるこずはたずない。
倉曎は垂堎力に圱響されるが、緩慢で間接的である。代わりに、組織は匱点ずなる状態を倉えお、
システムの脆匱性を぀かれる可胜性を䜎くするこずができよう。
ポリシヌ及び手順の脆匱性及び匱点ずなる状態
脆匱性及び匱点ずなる状態は、セキュリティポリシヌの䞍備、䞍適切又は欠劂により ICS に持ち
蟌たれるこずが倚く、䟋えば文曞、実斜ガむド手順等、斜行等である。セキュリティ及び手
順に察する経営陣による支揎は、あらゆるセキュリティプログラムの土台ずなる。組織のセキュ
リティポリシヌは、適正な行動を矩務づけお斜行するこずで、脆匱性を枛らすこずができる。曞
面にしたポリシヌ及び手順は、職員及び関係者に、組織の利益ずなる行動に関する決定事項を知
らしめるメカニズムずなる。この芳点から、ポリシヌは脆匱性を枛らすための教育的・教蚓的方
法ずなる。斜行はポリシヌの「パヌトナヌ」であり、「正しい」こずを行うよう人を奚励する。
倚様な圢態の是正凊眮は、ポリシヌ及び手順を遵守しおいない職員に察しお通垞、適甚される。

46

http://ics-cert.us-cert.gov.http://ics-cert.us-cert.gov.

260

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

to personnel not following policy and procedures. Policies should be explicit about the consequences to
individuals or organizations that do not conform.
There is usually a complex policy and procedure environment that includes laws and regulations,
overlapping jurisdictions and spheres of influence, economics, custom, and history. The larger enterprise is
often subdivided into organizational units that should work together to reduce vulnerabilities. The scope
and hierarchical relationship among policies and procedures needs to be managed for maximum
effectiveness.
Certain controls in SP 800-53 and the ICS overlay in Appendix G— specify responsibilities and
requirements for the organization, while others focus on the capabilities and operation of the various
systems within the organization. For example, the control AC-6, Least Privilege, states “The organization
employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on
behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational
missions and business functions.” The organization has to make decisions that get codified in policy and
procedures. Some resulting artifacts, such as job descriptions that include roles, responsibilities, and
authority, remain in a form suitable for people, while other artifacts, such as attributes, privileges, and
access control rules, are implemented in IT.
Note that the ICS overlay follows SP 800-53 in employing the term “organization” very flexibly so that its
guidance can be used by all sizes of organizational entities up and down an organization chart. Specific
organizations should be identified, starting with the organization responsible for issuing and maintaining
the policy or procedure.
Table C-2 presents examples of observed policy and procedure vulnerabilities for ICS.
Table C-2. Policy and Procedure Vulnerabilities and Predisposing Conditions
Vulnerability
Inadequate security policy for the ICS

Description
Vulnerabilities are often introduced into ICS due to inadequate policies or the
lack of policies specifically for control system security. Every countermeasure
should be traceable to a policy. This ensures uniformity and accountability.
Policy must include portable and mobile devices used with ICS.

No formal ICS security training and awareness

A documented formal security training and awareness policy and program is

program

designed to keep staff up to date on organizational security policies and
procedures as well as threats, industry cybersecurity standards, and
recommended practices. Without training on specific ICS policies and
procedures, staff cannot be expected to maintain a secure ICS environment.

Absent or deficient ICS equipment implementation

Equipment implementation guidelines should be kept up to date and readily

guidelines

available. These guidelines are an integral part of security procedures in the
event of an ICS malfunction.

Lack of administrative mechanisms for security policy

Staff responsible for enforcing security should be held accountable for

enforcement

administering documented security policies and procedures.

Inadequate review of the effectiveness of the ICS

Procedures and schedules should exist to determine the extent to which the

security controls

security program and its constituent controls are implemented correctly,
operating as intended, and producing the desired outcome with respect to
meeting the security requirements for the ICS. The examination is sometimes
called an “audit,” “evaluation,” or “assessment.” Policy should address the
stage of the life-cycle, purpose, technical expertise, methodology, and level
of independence.

261

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ポリシヌは、遵守しおいない個人又は組織に察し、結果に関しお明瀺的であるべきである。
法芏を包含し、圱響、経枈、習慣及び歎史の管蜄及び範囲が重なり合う、耇雑なポリシヌ及び手
順環境が垞に存圚する。倧䌁業は、脆匱性を枛らすために協働できる組織単䜍に现分化されるこ
ずが倚い。ポリシヌ及び手順間の範囲ず階局的関係を管理しお、最倧の効果を䞊げるべきである。
SP 800-53 及び付録 G の ICS オヌバヌレむに含たれおいる特定の管理には、責任ず組織芁件が蚘
茉されおおり、たた別なものは組織内の倚様なシステムの胜力ず運甚が重点になっおいる。䟋え
ば、管理 AC-6 最小暩限には、「組織は最小暩限の原則を採甚し、組織の任務・事業䞊の機胜に
応じお割り圓おられた仕事を遂行するのに必芁なナヌザ又はその代わりずなるプロセスだけ
にアクセス暩限を䞎える」ずある。組織は決定しなければならず、決定事項はポリシヌ及び手順
に明蚘される。その結果は、䟋えば圹割・責任・暩限を明蚘した職務明现曞ずなり、職員に適し
た圢態を取るものもあれば、属性・特暩・アクセス制埡芏則のように、IT においお実斜されるも
のもある。
ICS オヌバヌレむは SP 800-53 に準拠しお、「組織」ずいう語を極めお柔軟に甚いおいるため、
そのガむダンスは、組織の倧小様々な郚眲で䜿甚できる。たずポリシヌ又は手順の発出・維持を
担圓する組織を皮切りに、特定の組織を明らかにすべきである。
è¡š C-2 は、芳察されおいる ICS 甚ポリシヌ及び手順の脆匱性を瀺す。
è¡š C-2. ポリシヌ及び手順の脆匱性及び匱点ずなる状態
脆匱性
ICS 甚セキュリティポリシヌの䞍備

内容
特に制埡システムのセキュリティに関するポリシヌの䞍備又は欠劂から、ICS
に脆匱性が入り蟌むこずが倚い。それぞれの察策はポリシヌから出おいるべ
きである。これにより統䞀性ず説明責任が確保される。ポリシヌは携行/モバ
むルデバむスも含めなければならない。

正芏の ICS セキュリティ蚓緎・意識 文曞化された正芏のセキュリティ蚓緎・意識ポリシヌ蚈画は、垞に最新のセ
プログラム蚈画の欠劂
キュリティポリシヌ・手順、脅嚁、産業甚サむバヌセキュリティ芏栌及び掚
奚芏範を職員に知らしめるためにある。具䜓的な ICS ポリシヌ及び手順がな
ければ、職員に ICS 環境のセキュリティを維持できるず期埅するこずはでき
ない。
ICS 装備品実装ガむドラむンの欠劂
又は欠陥

装備品実装ガむドラむンは最新状態に保ち、すぐに利甚できるべきである。
ガむドラむンは、ICS 障害の際にセキュリティ手順の䞍可欠な䞀郚ずなる。

セキュリティポリシヌを斜行する管
理機構の欠劂

セキュリティの斜行担圓職員は、文曞化されたセキュリティポリシヌ及び手
順の管理に説明責任を有する。

ICS セキュリティ察策の効果性に察
する芋盎しの䞍備

セキュリティプログラムずその察策がどの皋床適正に実斜されおいるか、予
定どおり皌働しおいるか、所期の結果をもたらしおいるかを、ICS セキュリ
ティ芁件の達成ずいう芳点で刀定する手順及びスケゞュヌルを定めるべきで
ある。この怜蚌を「監査」、「評䟡evaluation」又は「評䟡
assessment」ず呌ぶこずもある。ポリシヌはラむフサむクルの段階、目
的、技術知芋、方法論及び独立レベルを取り䞊げるべきである。

262

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Vulnerability
No ICS-specific contingency plan

Lack of configuration management policy

Lack of adequate access control policy

Lack of adequate authentication policy

Inadequate incident detection and response
plan and procedures

Lack of redundancy for critical components

Description
A contingency plan should be prepared, tested and available in the
event of a major hardware or software failure or destruction of
facilities. Lack of a specific plan for the ICS could lead to extended
downtimes and production loss.
Lack of policy and procedures for ICS configuration change
management can lead to unmanageable and highly vulnerable
inventory of hardware, firmware, and software.
Access control enforcement depends of policy the correctly models
roles, responsibilities, and authorizations. The policy model must
enable the way the organization functions.
Authentication policies are needed to define when authentication
mechanisms (e.g., passwords, smart cards) must be used, how
strong they must be, and how they must be maintained. Without
policy, systems might not have appropriate authentication controls,
making unauthorized access to systems more likely. Authentication
policies should be developed as part of an overall ICS security
program taking into account the capabilities of the ICS and its
personnel to handle more complex passwords and other
mechanisms.
Incident detection and response plans, procedures, and methods are
necessary for rapidly detecting incidents, minimizing loss and
destruction, preserving evidence for later forensic examination,
mitigating the weaknesses that were exploited, and restoring ICS
services. Establishing a successful incident response capability
includes continually monitoring for anomalies, prioritizing the
handling of incidents, and implementing effective methods of
collecting, analyzing, and reporting data.
Lack of redundancy in critical components could provide single point
of failure possibilities

System Vulnerabilities and Predisposing Conditions
Security controls must clearly identify the systems to which they apply. Systems range widely in size,
scope, and capability. At the small end of the spectrum, a system may be an individual hardware or
software product or service. At the other end of the spectrum we find large complex systems, systems-ofsystems, and networks, all of which incorporate hardware architecture and software framework (including
application frameworks), where the combination supports the operation of the ICS.
System vulnerabilities can occur in the hardware, firmware, and software used to build the ICS. Sources of
vulnerabilities include design flaws, development flaws, misconfigurations, poor maintenance, poor
administration, and connections with other systems and networks. Many of the controls in the SP 800-53
and the ICS overlay in Appendix G— specify what the system must do to mitigate these vulnerabilities.
The potential vulnerabilities and predisposing conditions commonly found within ICS systems are
categorized with the following tables:


Table C-3. Architecture and Design Vulnerabilities and Predisposing Conditions.



Table C-4. Configuration and Maintenance Vulnerabilities and Predisposing Conditions.



Table C-5. Physical Vulnerabilities and Predisposing Conditions.

263

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脆匱性

内容

ICS 固有の緊急時察応蚈画の欠劂

緊急時察応蚈画を䜜成し、怜蚌し、倧芏暡なハヌドり゚ア又は゜フトり゚ア
障害時や斜蚭砎壊時に利甚できるようにすべきである。ICS の具䜓的蚈画曞
がないず、ダりンタむムや生産損倱が拡倧しかねない。

構成管理ポリシヌの欠劂

ICS 構成管理ポリシヌ及び手順の欠劂は、ハヌドり゚ア、ファヌムり゚ア及
び゜フトり゚アの管理できない倧きな脆匱性に぀ながる。

適正なアクセス制埡ポリシヌの欠劂

アクセス制埡の斜行は、ポリシヌの正しいモデル圹割、責任及び暩限付䞎に
かかっおいる。ポリシヌモデルは、組織が機胜するための方法を実珟しなけ
ればならない。

適正な認蚌ポリシヌの欠劂

認蚌メカニズムパスワヌド、スマヌトカヌド等を利甚する際に、認蚌ポ
リシヌはメカニズムの匷床及び維持方法を明らかにする必芁がある。ポリシ
ヌがなければ、システムは適正な認蚌管理ができず、無駄アクセスを蚱すこ
ずになる。認蚌ポリシヌは、党䜓的な ICS セキュリティプログラムの䞀環ず
しお䜜成し、ICS の胜力ず、より耇雑なパスワヌドその他のメカニズムを扱
う職員の胜力ずを考慮に入れるべきである。

むンシデント怜知・察応蚈画曞及び
手順の䞍備

むンシデント怜知・察応蚈画曞、手順及び方法はむンシデントの迅速な怜
知、損倱・砎壊の局限、埌日必芁ずなる調査怜蚌甚蚌拠の保存、利甚された
匱点の緩和及び ICS サヌビスの埩旧を行う䞊で必芁である。有効なむンシデ
ント察応胜力には、異垞に察する継続監芖、むンシデント凊理の優先づけ、
効果的なデヌタ収集・分析・報告方法の実斜が含たれる。

重芁コンポヌネントの冗長性の欠劂

重芁コンポヌネントの冗長性の欠劂は、単䞀障害点ずなりかねない。

システムの脆匱性及び匱点ずなる状態
セキュリティ察策では、適甚察象ずなるシステムを特定しなければならない。システムの芏暡、
範囲及び胜力は倚皮倚様である。最小システムは、個々のハヌドり゚ア若しくは゜フトり゚ア補
品又はサヌビスでもよい。反察に最倧システムは、倧芏暡耇合システム、システム䞭にシステム
のあるもの及びネットワヌクで、これらはハヌドり゚アアヌキテクチャ及び゜フトり゚アフレヌ
ムワヌクアプリケヌションフレヌムワヌク等を含み、それらが䞀䜓ずなっお ICS の運甚を支
える。
システム脆匱性は ICS を構築するハヌドり゚ア、ファヌムり゚ア及び゜フトり゚アで生じ埗る。
脆匱性の原因には蚭蚈䞊の欠陥、開発䞊の欠陥、蚭定ミス、保守の䞍備、管理の䞍備及び他のシ
ステムやネットワヌクぞの接続等がある。SP 800-53 及び付録 G の ICS オヌバヌレむに含たれお
いる管理の倚くは、このような脆匱性を緩和するためにシステムが行わなければならない事柄を
芏定しおいる。
ICS で䞀般的に芋られる脆匱性及び匱点ずなる状態を以䞋の衚に分類する。

 è¡š C-3.アヌキテクチャ及び蚭蚈䞊の脆匱性及び匱点ずなる状態
 è¡š C-4.構成及び保守䞊の脆匱性及び匱点ずなる状態
 è¡š C-5.物理的脆匱性及び匱点ずなる状態

264

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Table C-6. Software Development Vulnerabilities and Predisposing Conditions.



Table C-7. Communication and Network Configuration Vulnerabilities and Predisposing Conditions.
Table C-3. Architecture and Design Vulnerabilities and Predisposing Conditions
Vulnerability

Description

Inadequate incorporation of
security into architecture and
design.

Incorporating security into the ICS architecture, design must start with budget, and
schedule of the ICS. The security architecture is part of the Enterprise Architecture. The
architectures must address the identification and authorization of users, access control
mechanism, network topologies, and system configuration and integrity mechanisms.

Insecure architecture
allowed to evolve

The network infrastructure environment within the ICS has often been developed and
modified based on business and operational requirements, with little consideration for
the potential security impacts of the changes. Over time, security gaps may have been
inadvertently introduced within particular portions of the infrastructure. Without
remediation, these gaps may represent backdoors into the ICS.
If the ICS does not have a security perimeter clearly defined, then it is not possible to
ensure that the necessary security controls are deployed and configured properly. This
can lead to unauthorized access to systems and data, as well as other problems.

No security perimeter
defined
Control networks used for
non-control traffic

Control network services not
within the control network

Inadequate collection of
event data history

Control and non-control traffic have different requirements, such as determinism and
reliability, so having both types of traffic on a single network makes it more difficult to
configure the network so that it meets the requirements of the control traffic. For
example, non-control traffic could inadvertently consume resources that control traffic
needs, causing disruptions in ICS functions.
Where IT services such as Domain Name System (DNS), and Dynamic Host
Configuration Protocol (DHCP) are used by control networks, they are often
implemented in the IT network, causing the ICS network to become dependent on the IT
network that may not have the reliability and availability requirements needed by the
ICS.
Forensic analysis depends on collection and retention of sufficient data. Without proper
and accurate data collection, it might be impossible to determine what caused a security
incident to occur. Incidents might go unnoticed, leading to additional damage and/or
disruption. Regular security monitoring is also needed to identify problems with security
controls, such as misconfigurations and failures.

Table C-4. Configuration and Maintenance Vulnerabilities and Predisposing Conditions
Vulnerability
Hardware, firmware, and
software not under
configuration management.

Description
The organization doesn’t know what it has, what versions it has, where they are, or what
their patch status is, resulting in an inconsistent, and ineffective defense posture. A
process for controlling modifications to hardware, firmware, software, and
documentation should be implemented to ensure an ICS is protected against inadequate
or improper modifications before, during, and after system implementation. A lack of
configuration change management procedures can lead to security oversights,
exposures, and risks. To properly secure an ICS, there should be an accurate listing of
the assets in the system and their current configurations. These procedures are critical
to executing business continuity and disaster recovery plans.

265

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 è¡š C-6.゜フトり゚ア開発䞊の脆匱性及び匱点ずなる状態
 è¡š C-7.通信及びネットワヌク構成䞊の脆匱性及び匱点ずなる状態
è¡š C-3.アヌキテクチャ及び蚭蚈䞊の脆匱性及び匱点ずなる状態
脆匱性

内容

アヌキテクチャ及び蚭蚈ぞのセキュ
リティ組蟌み䞊の䞍備

曎に進行しそうなセキュアでないア
ヌキテクチャ

セキュリティを ICS アヌキテクチャに組み蟌む際、予算及び ICS のスケゞュ
ヌルから蚭蚈を開始しなければならない。セキュリティアヌキテクチャは䌁
業アヌキテクチャの䞀郚ずなる。アヌキテクチャはナヌザの識別・認蚌、ア
クセス制埡メカニズム、ネットワヌクトポロゞヌ及びシステム構成・完党性
メカニズムを取り䞊げなければならない。
ICS 内のネットワヌクむンフラ環境は、事業・運甚䞊の芁件を基に開発・改
修されおいるこずが倚く、倉曎内容がセキュリティに及がす圱響はあたり考
慮されおいない。時間の経過ずずもに、想定倖のセキュリティギャップがむ
ンフラの特定郚䜍に生じるこずがある。察策を取らずにいるず、そのような
ギャップが ICS のバックドアになるこずがある。

セキュリティ境界が未定矩

ICS のセキュリティ呚蟺の定矩が明らかでないず、必芁なセキュリティ察策
の展開・蚭定が正しく実斜できない。このためシステムやデヌタぞの䞍正ア
クセスを蚱し、他の問題も発生しかねない。

制埡ネットワヌクを制埡以倖のトラ
フィックに䜿甚

決定論や信頌性等、制埡トラフィックず非制埡トラフィックの芁件は異なる
ため、双方を 1 ぀のネットワヌクで䜿甚するず、制埡トラフィック芁件を達
成するためのネットワヌク蚭定が難しくなる。䟋えば非制埡トラフィック
は、制埡トラフィックが必芁ずするリ゜ヌスを想定倖に消費するこずがあ
り、ICS 機胜の䞭断を招くこずがある。

制埡ネットワヌクサヌビスが制埡ネ
ットワヌク内にない

制埡システムに領域名システムDNSや動的ホスト構成プロトコル
DHCP等の IT サヌビスを利甚しおいる堎合、サヌビスは IT ネットワヌ
ク内に実装されおいるこずが倚いため、ICS ネットワヌクが ICS の信頌性及
び可甚性芁件に満たない IT ネットワヌクに䟝存する結果になる。

むベントデヌタヒストリアン収集の
䞍備

調査分析は十分なデヌタ収集・保持に䟝存する。適正か぀正確なデヌタの収
集がなければ、セキュリティむンシデントの発生理由を刀別できない。むン
シデントに気づかず、損害や䞭断を拡倧しかねない。蚭定ミスや障害等、セ
キュリティ察策の問題点を芋極めるため、定期的なセキュリティ監芖も必芁
ずなる。

è¡š C-4.構成及び保守䞊の脆匱性及び匱点ずなる状態
脆匱性
ハヌドり゚ア/ファヌムり゚ア/゜フ
トり゚アが構成管理倖にある

内容
䜕を䜿甚しおいるか、どのバヌゞョンか、どこにあるか、パッチステヌタス
がどうなっおいるかを組織が知らず、䞀貫性ず効果性のない防埡態勢にな
る。ハヌドり゚ア/ファヌムり゚ア/゜フトり゚ア・文曞ぞの倉曎を管理するプ
ロセスを実斜し、システム実装前・䞭・埌の䞍適切な改倉から ICS を保護す
る。構成倉曎管理手順の欠劂は、セキュリティの手抜かり、曝露及びリスク
に぀ながる。ICS のセキュリティをしっかり確保するには、システム資産ず
その珟行構成の正確なリストが持぀べきである。このような手順が事業継続
性ず灜害埩旧蚈画の実斜に重芁ずなる。

266

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Vulnerability

Description

OS and vendor software

Because of the tight coupling between ICS software and the underlying ICS, changes must

patches may not be

undergo expensive and time-consuming comprehensive regression testing. The elapsed time

developed until significantly

for such testing and subsequent distribution of updated software provides a long window of

after security vulnerabilities

vulnerability

are found
OS and application security

Out-of-date OSs and applications may contain newly discovered vulnerabilities that could be

patches are not maintained or

exploited. Documented procedures should be developed for how security patches will be

vendor declines to patch

maintained. Security patch support may not even be available for ICS that use outdated OSs,

vulnerability

so procedures should include contingency plans for mitigating vulnerabilities where patches
may never be available.

Inadequate testing of security

Modifications to hardware, firmware, and software deployed without testing could compromise

changes

normal operation of the ICS. Documented procedures should be developed for testing all
changes for security impact. The live operational systems should never be used for testing.
The testing of system modifications may need to be coordinated with system vendors and
integrators.

Poor remote access controls

There are many reasons why an ICS may need to be remotely accessed, including vendors
and system integrators performing system maintenance functions, and also ICS engineers
accessing geographically remote system components. Remote access capabilities must be
adequately controlled to prevent unauthorized individuals from gaining access to the ICS.

Poor configurations are used

Improperly configured systems may leave unnecessary ports and protocols open, these
unnecessary functions may contain vulnerabilities that increase the overall risk to the system.
Using default configurations often exposes vulnerabilities and exploitable services. All
settings should be examined.

Critical configurations are not

Procedures should be available for restoring ICS configuration settings in the event of

stored or backed up

accidental or adversary-initiated configuration changes to maintain system availability and
prevent loss of data. Documented procedures should be developed for maintaining ICS
configuration settings.

Data unprotected on portable

If sensitive data (e.g., passwords, dial-up numbers) is stored in the clear on portable devices

device

such as laptops and mobile devices and these devices are lost or stolen, system security
could be compromised. Policy, procedures, and mechanisms are required for protection.

Passwords generation, use,

There is a large body of experience with using passwords in IT that is applicable to ICS.

and protection not in accord

Password policy and procedure must be followed to be effective. Violations of password

with policy

policy and procedures can drastically increase ICS vulnerability.

Inadequate access controls

Access controls must be matched to the way the organization allocates responsibilities and

applied

privilege to its personnel. Poorly specified access controls can result in giving an ICS user too
many or too few privileges. The following exemplify each case:
・ System configured with default access control settings gives an operator
・

administrative privileges
System improperly configured results in an operator being unable to take
corrective actions in an emergency situation

Improper data linking

ICS data storage systems may be linked with non-ICS data sources. An example of this is
database links, which allow data from one database to be automatically replicated to others.
Data linkage may create a vulnerability if it is not properly configured and may allow
unauthorized data access or manipulation.

Malware protection not

Installation of malicious software, or malware, is a common attack. Malware protection

installed or up to date

software, such as antivirus software, must be kept current in a very dynamic environment.
Outdated malware protection software and definitions leave the system open to new malware
threats.

267

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脆匱性
OS やベンダヌの゜フトり゚アパッチ
は、セキュリティの脆匱性が明らか
になっおしばらく経぀たでは開発さ
れない。

内容
ICS ゜フトり゚アず基本 ICS の緊密な結び぀きがあるため、倉曎を加えた堎
合は、時間ずコストのかかる培底的なリグレッション詊隓を行わなければな
らない。このような詊隓ずその埌の゜フトり゚ア曎新版の配垃たでの経過時
間により、脆匱性の穎は倧きくなる。

OS やアプリケヌションのセキュリテ 旧匏 OS やアプリケヌションには、新たに芋぀かった悪甚されやすい脆匱性
ィパッチが保守されず、ベンダヌは がある。セキュリティパッチの保守芁領に関しお、曞面にした手順を䜜成す
脆匱性を顧みない
べきである。旧版 OS を䜿った ICS では、セキュリティパッチサポヌトはな
い堎合があるため、手順にはその堎合の脆匱性緩和緊急時察応蚈画も含める
べきである。
セキュリティ倉曎詊隓の䞍備

詊隓を行わずに展開したハヌドり゚ア/ファヌムり゚ア/゜フトり゚ア倉曎は、
ICS の正垞運甚胜力を䜎䞋させる可胜性がある。党おの倉曎内容のセキュリ
ティ圱響詊隓に関しお、曞面にした手順を䜜成すべきである。皌働䞭のシス
テムは決しお詊隓に䜿うべきでない。システム倉曎詊隓は、システムベンダ
ヌやむンテグレヌタず連携しお行う必芁がある。

リモヌトアクセス制埡の䞍備

ICS ぞのリモヌトアクセスが必芁な理由は様々で、䟋えばベンダヌやシステ
ムむンテグレヌタの遠隔保守、遠方にいる ICS ゚ンゞニアによるシステムコ
ンポヌネントの利甚などがある。リモヌトアクセス機胜はしっかり管理し
お、ICS ぞの䞍正アクセスを防止しなければならない。

蚭定の䞍備

システム蚭定に䞍備があり、䞍必芁にポヌトやプロトコルを開攟したたたに
しおおくず、脆匱性ずなりシステムの党䜓的リスクが高たる。デフォルト蚭
定を䜿甚するず、脆匱性や悪甚可胜なサヌビスを露出するこずになる。党お
の蚭定を怜蚌すべきである。

重芁な蚭定の保存やバックアップが
なされおいない

偶発的又は攻撃による蚭定倉曎があった際に、システムの可甚性を維持し、
デヌタ喪倱を防止するため、ICS 蚭定の回埩手順を利甚できるようにすべき
である。ICS 蚭定を維持するため、曞面にした手順を䜜成すべきである。

携行デバむスのデヌタが保護されお
いない

泚意を芁するデヌタパスワヌド、ダむアルアップ番号等が平文のたたラ
ップトップやモバむルデバむス等の携行デバむス䞊に保管されおいお、デバ
むスを玛倱したり盗たれたりした堎合、システムセキュリティが危うくな
る。保護ポリシヌ、手順及びメカニズムが必芁ずなる。

パスワヌドの生成、䜿甚及び保護が
ポリシヌに埓っおいない
アクセス制埡の䞍備

ICS にも適甚可胜な IT でのパスワヌド利甚経隓が蓄積されおいる。パスワヌ
ドポリシヌ及び手順は効果的でなければならない。パスワヌドポリシヌ・手
順違反は、ICS の脆匱性を著しく高める。
アクセス制埡ず組織が職員に責任及び特暩を䞎える方法は、敎合しおいなけ
ればならない。アクセス制埡がしっかりしおいないず、ICS ナヌザの特暩に
過䞍足が生じる。以䞋は過䞍足の䟋である。
•
•

デフォルトアクセス蚭定になったシステムは、操䜜員に管理者特暩を
䞎える。
システム蚭定に䞍備があるず、操䜜員が緊急時に察策を講じるこずが
できない。

デヌタリンキングの䞍備

ICS デヌタストレヌゞシステムは、ICS 以倖のデヌタ゜ヌスにリンクしおい
る堎合がある。䞀䟋がデヌタベヌスリンクで、あるデヌタベヌスのデヌタが
自動的に他のデヌタベヌスに耇補される。デヌタリンクは蚭定がしっかりし
おいないず、脆匱性が生じ、無蚱可のデヌタアクセスやデヌタ操䜜を蚱すこ
ずになる。

マルり゚ア保護゜フトり゚アがむン
ストヌルされおいないか最新でない

悪意ある゜フトり゚アマルり゚アのむンストヌルは䞀般的な攻撃であ
る。アンチりむルス等のマルり゚ア保護゜フトり゚アは、動的環境においお
垞に最新状態に保たれなければならない。叀くなったマルり゚ア保護゜フト
り゚ア及び定矩では、システムが新しいマルり゚ア脅嚁にさらされる。

268

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Vulnerability
Malware protection
implemented without
sufficient testing
Denial of service (DoS)
Intrusion
detection/prevention
software not installed

Logs not maintained

Description
Malware protection software deployed without sufficient testing could impact normal
operation of the ICS and block the system from performing necessary control actions.
ICS software could be vulnerable to DoS attacks, resulting in the prevention of
authorized access to a system resource or delaying system operations and functions.
Incidents can result in loss of system availability and integrity; the capture, modification,
and deletion of data; and incorrect execution of control commands. IDS/IPS software
may stop or prevent various types of attacks, including DoS attacks, and also identify
attacked internal hosts, such as those infected with worms. IDS/IPS software must be
tested prior to deployment to determine that it does not compromise normal operation of
the ICS.
Without proper and accurate logs, it might be impossible to determine what caused a
security event to occur.

Table C-5. Physical Vulnerabilities and Predisposing Conditions
Vulnerability
Unauthorized personnel
have physical access to
equipment

Description
Physical access to ICS equipment should be restricted to only the necessary personnel,
taking into account safety requirements, such as emergency shutdown or restarts.
Improper access to ICS equipment can lead to any of the following:
・
Physical theft of data and hardware
・
Physical damage or destruction of data and hardware
・
Unauthorized changes to the functional environment (e.g., data connections,
・
・

Radio frequency,
electromagnetic pulse
(EMP), static discharge,
brownouts and voltage
spikes
Lack of backup power

Loss of environmental
control

Unsecured physical ports

unauthorized use of removable media, adding/removing resources)
Disconnection of physical data links
Undetectable interception of data (keystroke and other input logging)

The hardware used for control systems is vulnerable to radio frequency and electromagnetic pulses (EMP), static discharge, brownouts and voltage spikes.. The impact can
range from temporary disruption of command and control to permanent damage to circuit
boards. Proper shielding, grounding, power conditioning, and/or surge suppression is
recommended.
Without backup power to critical assets, a general loss of power will shut down the ICS
and could create an unsafe situation. Loss of power could also lead to insecure default
settings.
Loss of environmental control (e.g., temperatures, humidity) could lead to equipment
damage, such as processors overheating. Some processors will shut down to protect
themselves; some may continue to operate but in a minimal capacity and may produce
intermittent errors, continually reboot, or become permanently incapacitated.
Unsecured universal serial bus (USB) and PS/2 ports could allow unauthorized
connection of thumb drives, keystroke loggers, etc.

269

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脆匱性

内容

マルり゚ア保護゜フトり゚アを十分
詊隓せずに実装しおいる

十分な詊隓を行わずにマルり゚ア保護゜フトり゚アを展開するず、ICS の正
垞運甚に圱響し、システムの必芁な制埡動䜜が劚害される。

サヌビス劚害DoS

ICS ゜フトり゚アは DoS 攻撃に脆匱性があるかもしれず、システムリ゜ヌス
ぞの蚱可されたアクセスを劚げたり、システムの動䜜や機胜を遅らせたりす
るこずがある。

䟵入怜知・防止゜フトり゚アがむン
ストヌルされおいない

むンシデントはシステムの可甚性及び完党性の喪倱、デヌタのキャプチャ・
改倉・削陀及び制埡コマンドの䞍適切な実行に結び぀くこずがある。IDS/IPS
゜フトり゚アは、DoS 攻撃等倚様な攻撃を停止又は劚害し、ワヌムに感染し
たものなど、攻撃された内郚ホストの識別も行う。IDS/IPS ゜フトり゚アは展
開前に詊隓を行い、ICS の正垞運甚に悪圱響がないか刀定しなければならな
い。

ログが維持されおいない

適正か぀正確なログがなければ、セキュリティ事象の発生理由を刀別できな
い。

è¡š C-5.物理的脆匱性及び匱点ずなる状態
脆匱性
無蚱可の人員が装備品に近づいおい
る

内容
ICS 装備品ぞの接近は、緊急停止や再始動ずいった安党芁件を考慮に入れ
お、必芁な職員だけに制限すべきである。ICS 装備品に䞍甚意に接近を蚱す
ず、次のような結果が生じかねない。
•
•
•
•
•

デヌタ及びハヌドり゚アの盗難
デヌタ及びハヌドり゚アの損傷や砎損
蚱可されおいない機胜環境の倉曎デヌタ接続、取り倖し可胜メデ
ィアの無断䜿甚、リ゜ヌスの远加・削陀
デヌタリンクの物理的切断
怜知䞍胜のデヌタ傍受キヌストロヌクその他入力蚘録

無線呚波数・電磁波EMP、静電 制埡システムに利甚するハヌドり゚アは、無線呚波数・電磁波EMP、静
気、電圧䜎䞋・電圧ノむズ
電気、電圧䜎䞋・電圧ノむズに匱い。圱響は、䞀時的なコマンドの䞭断から
回路基板の恒久的損傷たで倚岐にわたる。適切なシヌルド、アヌス、電圧管
理又はサヌゞ電圧抑制が掚奚される。
バックアップ電源の欠劂

回路ぞのバックアップ電源がないず、電源の喪倱時、ICS が切断されお䞍安
党な状況になりかねない。たたセキュアでないデフォルト蚭定に戻るこずが
ある。

環境制埡の喪倱

環境制埡枩床、湿床等の喪倱は、プロセッサのオヌバヌヒヌトなど装備
品の損傷に぀ながる。プロセッサによっおは自己防護のため切断するものも
ある。そのたた続行するものもあるが、機胜は最小限で、間欠的に゚ラヌず
なり、リブヌトを繰り返し、恒久的に故障するこずもある。

セキュアでない物理ポヌト

セキュアでない USB 及び PS/2 ポヌトは、サムドラむブ、キヌストロヌクロ
ガヌ等の無断接続を蚱すこずになる。

270

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Table C-6. Software Development Vulnerabilities and Predisposing Conditions
Vulnerability

Description

Improper Data Validation

ICS software may not properly validate user inputs or received data to ensure validity.
Invalid data may result in numerous vulnerabilities including buffer overflows, command
injections, cross-site scripting, and path traversals.

Installed security
capabilities not enabled by
default

Security capabilities that were installed with the product are useless if they are not
enabled or at least identified as being disabled.

Inadequate authentication,
privileges, and access
control in software

Unauthorized access to configuration and programming software could provide the ability
to corrupt a device.

Table C-7. Communication and Network Configuration Vulnerabilities and Predisposing
Conditions
Vulnerability
Data flow controls not
employed
Firewalls nonexistent or
improperly configured

Inadequate firewall and
router logs
Standard, welldocumented
communication protocols
are used in plain text
Authentication of users,
data or devices is
substandard or
nonexistent

Description
Data flow controls, based on data characteristics, are needed to restrict which information
is permitted between systems. These controls can prevent exfiltration of information and
illegal operations.
A lack of properly configured firewalls could permit unnecessary data to pass between
networks, such as control and corporate networks, allowing attacks and malware to
spread between networks, making sensitive data susceptible to
monitoring/eavesdropping, and providing individuals with unauthorized access to systems.
Without proper and accurate logs, it might be impossible to determine what caused a
security incident to occur.
Adversaries that can monitor the ICS network activity can use a protocol analyzer or other
utilities to decode the data transferred by protocols such as telnet, File Transfer Protocol
(FTP), Hypertext Transfer Protocol (HTTP), and Network File System (NFS). The use of
such protocols also makes it easier for adversaries to perform attacks against the ICS and
manipulate ICS network activity.
Many ICS protocols have no authentication at any level. Without authentication, there is
the potential to replay, modify, or spoof data or to spoof devices such as sensors and user
identities.

Use of unsecure industrywide ICS protocols

ICS protocols often have few or no security capabilities, such as authentication and
encryption, to protect data from unauthorized access or tampering. Additionally, incorrect
implementation of the protocols can lead to additional vulnerabilities.

Lack of integrity checking
for communications

There are no integrity checks built into most industrial control protocols; adversaries could
manipulate communications undetected. To ensure integrity, the ICS can use lower-layer
protocols (e.g., IPsec) that offer data integrity protection.
Strong mutual authentication between wireless clients and access points is needed to
ensure that clients do not connect to a rogue access point deployed by an adversary, and
also to ensure that adversaries do not connect to any of the ICS’s wireless networks.
Sensitive data between wireless clients and access points should be protected using
strong encryption to ensure that adversaries cannot gain unauthorized access to the
unencrypted data.

Inadequate authentication
between wireless clients
and access points
Inadequate data protection
between wireless clients
and access points

271

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

è¡š C-6.゜フトり゚ア開発䞊の脆匱性及び匱点ずなる状態
脆匱性

内容

デヌタ怜蚌の䞍備

ICS ゜フトり゚アは、ナヌザ入力や受信デヌタの劥圓性怜蚌を正しく行っお
いないこずがある。無効なデヌタはバッファオヌバヌフロヌ、コマンドむン
ゞェクション、クロスサむトスクリプティング、パストラバヌサル等、皮々
の脆匱性に぀ながる。

むンストヌルした接続゜フトり゚ア
がデフォルトで機胜しない

補品のむンストヌルによるセキュリティ機胜は、無効状態を解陀しお有効に
しないず、たたは少なくずも、無効状態であるこずが分からないず効果がな
い。

゜フトり゚アの認蚌・特暩・アクセ
ス制埡の䞍備

蚭定及びプログラミング゜フトり゚アぞの䞍正アクセスは、デバむスの砎壊
を蚱すこずになる。

è¡š C-7.通信及びネットワヌク構成䞊の脆匱性及び匱点ずなる状態
脆匱性

内容

デヌタフロヌが制埡されおいない

デヌタ特性に基づくデヌタフロヌ制埡は、システム間の情報亀換を制埡する
ものであり、制限を加える必芁がある。制埡により情報の匕出しや䞍法操䜜
を防止できる。

ファむアりォヌルの欠劂又は蚭定䞍
備

ファむアりォヌルが正しく蚭定されおいないず、制埡ネットワヌクず䌁業ネ
ットワヌク等のネットワヌク間で、デヌタを䞍必芁に通過させ、攻撃及びマ
ルり゚アがネットワヌク間で拡散し、芁泚意デヌタが監芖・傍受にさらさ
れ、システムぞの䞍正アクセスを蚱すこずになる。

ファむアりォヌル及びルヌタのログ
の䞍備

適正か぀正確なログがなければ、セキュリティむンシデントの発生理由を刀
別できない。

暙準の文曞化された通信プロトコル
が平文で䜿甚されおいる

ICS のネットワヌク掻動を監芖する攻撃偎は、プロトコルアナラむザその他
のナヌティリティを利甚しお、テルネット、FTP、HTTP、NFS 等のプロトコ
ルが転送するデヌタをデコヌドする。このようなプロトコルを䜿甚するず、
攻撃偎は、ICS ぞの攻撃や ICS ネットワヌク掻動の操䜜を容易にできるよう
になる。

ナヌザ、デヌタ又はデバむス認蚌の
欠劂又は䞍適栌

ICS プロトコルの倚くは、どのレベルでも認蚌機胜がない。認蚌がないずデ
ヌタのリプレヌ、改倉、なりすたしや、センサ及びナヌザ ID 等のデバむスの
なりすたしが生じ埗る。

業界で倚甚されるセキュアでない
ICS の䜿甚

ICS プロトコルには、認蚌や暗号化ずいった、䞍正アクセスや改竄を防止す
るセキュリティ機胜がほずんど又は党くないものが倚い。たたプロトコル実
装の䞍備によっおも付加的な脆匱性が生じる。

通信完党性確認の欠劂

産業甚制埡プロトコルのほずんどは完党性チェック機胜がなく、攻撃偎は怜
知されずに通信を操䜜できる。完党性を確保するには、デヌタ完党性保護の
ある䞋局プロトコルIPsec 等を䜿甚するこずである。

ワむダレスクラむアントずアクセス
ポむント間の認蚌の䞍備

攻撃偎が展開したロヌグアクセスポむントにクラむアントが接続しないよう
にし、攻撃偎が ICS ワむダレスネットワヌクに接続できないようにするに
は、ワむダレスクラむアントずアクセスポむント間に匷固な盞互認蚌が必芁
ずなる。

ワむダレスクラむアントずアクセス
ポむント間のデヌタ保護の䞍備

ワむダレスクラむアントずアクセスポむント間の芁泚意デヌタは、匷固な暗
号化により、攻撃偎が暗号化されおいないデヌタに䞍正アクセスできないよ
うにすべきである。

272

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Incidents
A threat event is an event or situations that could potentially cause an undesirable consequence or impact to
the ICS resulting from some threat source. In NIST SP 800-30 Rev. 1, Appendix E identifies a broad set of
threat events that could potentially impact information systems [79]. The properties of an ICS may also
present unique threat events, specifically addressing how the threat events can manipulates the process of
the ICS to cause physical damage. Table C-8 provides an overview of potential ICS threat events.
Table C-8. Example Adversarial Incidents
Threat Event
Denial of Control Action

Control Devices
Reprogrammed

Spoofed System Status
Information
Control Logic Manipulation
Safety Systems Modified
Malware on Control
Systems

Description
Control systems operation disrupted by delaying or blocking the flow of information,
thereby denying availability of the networks to control system operators or causing
information transfer bottlenecks or denial of service by IT-resident services (such as DNS)
Unauthorized changes made to programmed instructions in PLCs, RTUs, DCS, or SCADA
controllers, alarm thresholds changed, or unauthorized commands issued to control
equipment, which could potentially result in damage to equipment (if tolerances are
exceeded), premature shutdown of processes (such as prematurely shutting down
transmission lines), causing an environmental incident, or even disabling control
equipment
False information sent to control system operators either to disguise unauthorized
changes or to initiate inappropriate actions by system operators
Control system software or configuration settings modified, producing unpredictable
results
Safety systems operation are manipulated such that they either (1) do not operate when
needed or (2) perform incorrect control actions that damage the ICS
Malicious software (e.g., virus, worm, Trojan horse) introduced into the system.

In addition, in control systems that cover a wide geographic area, the remote sites are often not staffed and
may not be physically monitored. If such remote systems are physically breached, the adversaries could
establish a connection back to the control network.
Sources of Incidents
An accurate accounting of cyber incidents on control systems is difficult to determine. However,
individuals in the industry who have been focusing on this issue see similar growth trends between
vulnerabilities exposed in traditional IT systems and those being found in control systems. ICS-CERT is a
DHS organization that focuses on reducing the risk across critical infrastructure by identifying threats and
vulnerabilities, while also providing mitigation strategies. ICS-CERT provides a trusted party where system
owners and operators can report information about incidents within their ICS and obtain advice on
mitigating their risk. Information submitted by infrastructure owners and operators is protected under the
Critical Infrastructure Information Act of 2002 as Protected Critical Infrastructure Information (PCII) from
disclosure under the Freedom of Information Act (FOIA), disclosure under state, tribal, and local disclosure
laws, use in regulatory actions, and use in civil litigation. In the event of an incident at critical infrastructure
facilities, ICS-CERT can also perform onsite deployments to respond to and analyze incidents. ICS-CERT
publishes advisories of new security vulnerabilities discovered in common ICS platforms. Figure C-1
demonstrates (1) the number of ICS incidents reported, (2) the number of onsite ICS deployments taken by
ICS-CERT, and (3) number of ICS vulnerabilities reported between years 2010 and 2013 47.

47

https://ics-cert.us-cert.gov/

273

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

むンシデント
脅嚁事象ずは、なんらかの脅嚁源に起因しお、ICS に望たしくない結果や圱響を䞎えかねない事
象又は状況をいう。NIST SP 800-30 第 1 版付録 E には、情報システムに圱響を及がす倚皮倚様な
脅嚁事象が明らかにされおいる[79]。ICS の特性も固有の脅嚁事象ずなるこずがあり、物理的損
傷を䞎えるため、脅嚁事象がどのように ICS のプロセスを操䜜するかが取り䞊げられおいる。衚
C-8 に ICS 脅嚁事象の抂芁を瀺す。
è¡š C-8. 攻撃むンシデントの䟋
脅嚁事象
制埡劚害

内容
情報の流れの遅延又は劚害により制埡システムの運甚が䞭断するず、制埡シ
ステム操䜜員がネットワヌクを䜿甚できなくなり、情報転送がボトルネック
ずなったり、IT 抵抗性のあるサヌビスDNS 等によるサヌビスの劚害が生
じたりする。

制埡デバむスのプログラムが倉曎さ PLC、RTU、DCS 若しくは SCADA コントロヌラのプログラム化呜什に察す
る蚱可されおいない倉曎、アラヌム閟の倉曎又は制埡装備品に察する蚱可さ
れおいる
れおいないコマンド発行は、装備品の損傷トレランスを超えた堎合やプ
ロセスの過早切断通信線等をもたらし、環境むンシデントずなるほか、
制埡補品を無効にする。
システム状態情報のなりすたし

蚱可されおいない倉曎を隠蔜するか、䞍適正行為をシステム操䜜員に開始さ
せるため、停情報が制埡システム操䜜員に送信される。

制埡ロゞックの操䜜

制埡システム゜フトり゚ア又は構成蚭定が倉曎され、予想䞍胜の結果が生じ
る。

安党システムの倉曎

安党システムの動䜜が操䜜され、1必芁なずきに皌働しないか、(2)ICS
を損傷する䞍正確な制埡を行う。

制埡システムにマルり゚ア

悪意ある゜フトり゚アりむルス、ワヌム、トロむの朚銬等がシステムに
入り蟌んでいる。

たた区域を網矅する制埡システムで、遠隔サむトに職員が配眮されおおらず、物理的監芖ができ
おいない。このような遠隔システムが物理的に䟵害されるず、攻撃偎は制埡ネットワヌクたで接
続を確立できる。
むンシデントの原因
制埡システム䞊のサむバヌむンシデントの原因を正確に刀別するのは難しい。ずは蚀え、業界で
この問題ず取り組んできた人もおり、埓来の IT システムで露呈された脆匱性ず制埡システムで
明らかになっおきた脆匱性には、共通的なトレンドがあるこずに気づいおいる。ICS-CERT は
DHS の組織で、脅嚁や脆匱性を明らかにしお重芁むンフラのリスクを軜枛し、緩和策を提䟛し
おいる。ICS-CERT は、システムの保有者や操䜜員が ICS 内のむンシデント情報をレポヌトし、
リスク緩和策に関する助蚀を埗るこずができる、信頌の眮ける関係者に提䟛しおいる。むンフラ
保有者及び操䜜員から提出された情報は、重芁むンフラ情報法2002 幎に埓い、情報の自由
法FOIAに基づく開瀺、州・郚族・地方開瀺法に基づく開瀺、芏制行為における䜿甚及び民
事蚎蚟における䜿甚に基づき、保護された重芁むンフラ情報PCIIずしお保護を受ける。重芁
むンフラにおけるむベントの際には、ICS-CERT は珟堎展開しお、むンシデントの察応ず分析に
圓たる。ICS-CERT は、ICS プラットホヌムで共通しお芋぀かった接続䞊の脆匱性に぀いお、ア
ドバむサリヌを発刊しおいる。図 C-1 に、(1) ICS むンシデントの届出件数、(2) ICS-CERT の ICS
珟堎展開件数、(3) 2010 幎2013 幎 ICS 脆匱性届出件数を瀺す 48。

48

https://ics-cert.us-cert.gov/

274

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Other sources of control system impact information show an increase in control system incidents as well.
This information should not be assumed to contain all ICS related incidents or discovered vulnerabilities as
some information may go unreported.

Figure C-1. ICS-CERT Reported Incidents by Year

Documented Incidents
Numerous ICS incidents have been reported that demonstrate how threat sources can negatively impact an
ICS. These events help demonstrate the severity of the threat sources, vulnerabilities, and impacts within
the ICS domain. As mentioned in Section C.2, the four broad categories of threat sources are adversarial,
accidental, structural, and environmental. Often the incident can be the result of multiple threat sources (e.g.
an environmental event causes a system failure, which is responded to incorrectly by an operator resulting
in an accidental event). Reported incidents from these categories include the following:
Adversarial Events


Worcester Air Traffic Communications 49. In March 1997, a teenager in Worcester, Massachusetts
disabled part of the public switched telephone network using a dial-up modem connected to the
system. This knocked out phone service at the control tower, airport security, the airport fire
department, the weather service, and carriers that use the airport. Also, the tower’s main radio
transmitter and another transmitter that activates runway lights were shut down, as well as a printer
that controllers use to monitor flight progress. The attack also knocked out phone service to 600
homes and businesses in the nearby town of Rutland.

49

Additional information on the Worcester Air Traffic Communications incident can be found at:
http://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html

275

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

制埡システムに圱響する情報の他の原因も、制埡システムむンシデントの増加を瀺しおいる。未
報告の情報もあるため、この情報が ICS 関連むンシデント又は解明された脆匱性の党おであるず
解すべきでない。

ICS むンシデントの届出 – 蚘垳
ICS むンシデント察応珟堎展開
ICS 関連脆匱性報告曞 – 蚘垳
図 C-1. ICS-CERT に届出のあった幎床別むンシデント件数

文曞化されたむンシデント
これたで倚数の ICS むンシデントの届出があり、脅嚁源が ICS にどのような悪圱響を䞎え埗るか
を実蚌しおいる。これらの事象は、脅嚁源、脆匱性及び ICS ドメむン内での圱響の重倧性を実蚌
するのに圹立぀。セクション C.2 で蚀及したように、脅嚁源は敵性、偶発性、構造的及び環境的
の 4 ぀の分類に倧別できる。むンシデントは耇数の脅嚁源に起因するこずが少なくない環境的
事象がシステム障害の原因ずなり、それに察するオペレヌタの察応がたずいず偶発的事象ずな
る。届出のあったむンシデントには、分類別に次のようなものがある。
敵性事象

 りヌスタヌ航空亀通通信 501997 幎 3 月、マサチュヌセッツ州りヌスタヌのティヌン゚むゞャ
ヌがダむアルアップモデムでシステムに接続し、公共亀換電話網の䞀郚を䜿甚䞍胜にした。
このため管制塔、空枯譊備、空枯消防隊、気象サヌビス及び空枯を利甚する航空䌚瀟に察す
る電話サヌビスが麻痺した。たた管制塔の䞻無線送信機や滑走路灯を点灯する送信機が遮断
されたほか、飛行の進捗を監芖する管制官のプリンタが䜿えなくなった。この攻撃でラトラ
ンド町近傍の䞀般家庭 600 䞖垯ず䌁業の電話も䜿甚䞍胜になった。

50

りヌスタヌ航空亀通通信むンシデントの詳现は次のサむトにある。

http://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html

276

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



Maroochy Shire Sewage Spill 51. In the spring of 2000, a former employee of an Australian
organization that develops manufacturing software applied for a job with the local government, but
was rejected. Over a two-month period, the disgruntled rejected employee reportedly used a radio
transmitter on as many as 46 occasions to remotely break into the controls of a sewage treatment
system. He altered electronic data for particular sewerage pumping stations and caused malfunctions
in their operations, ultimately releasing about 264 000 gallons of raw sewage into nearby rivers and
parks.



Davis-Besse 52. In August 2003, the Nuclear Regulatory Commission confirmed that in January 2003,
the Microsoft SQL Server worm known as Slammer infected a private computer network at the idled
Davis-Besse nuclear power plant in Oak Harbor, Ohio, disabling a safety monitoring system for nearly
five hours. In addition, the plant’s process computer failed, and it took about six hours for it to become
available again. Slammer reportedly also affected communications on the control networks of at least
five other utilities by propagating so quickly that control system traffic was blocked.



Zotob Worm 53. In August 2005, a round of Internet worm infections knocked 13 of
DaimlerChrysler’s U.S. automobile manufacturing plants offline for almost an hour, stranding workers
as infected Microsoft Windows systems were patched. Plants in Illinois, Indiana, Wisconsin, Ohio,
Delaware, and Michigan were knocked offline. While the worm affected primarily Windows 2000
systems, it also affected some early versions of Windows XP. Symptoms include the repeated
shutdown and rebooting of a computer. Zotob and its variations caused computer outages at heavyequipment maker Caterpillar Inc., aircraft-maker Boeing, and several large U.S. news organizations.



Stuxnet Worm 54. Stuxnet was a Microsoft Windows computer worm discovered in July 2010 that
specifically targeted industrial software and equipment. The worm initially spread indiscriminately,
but included a highly specialized malware payload that was designed to target only specific SCADA
systems that were configured to control and monitor specific industrial processes



Brute Force Attacks on Internet-Facing Control Systems 55. On February 22, 2013 ICS-CERT
received a report from a gas compressor station owner about an increase in brute force attempts to
access their process control network. The forensic evidence contained 10 separate IPs and additional
calls of a similar nature from additional natural gas pipeline asset owners, which yielded 39 additional
IPs of concern. Log analysis showed a date range from January 16, 2013 but there have been no
reports since March 8, 2013.



Shamoon 56. Saudi Aramco, which is the world’s 8th largest oil refiner, experienced a malware attack
that targeted their refineries and overwrote the attacked system’s Master Boot Records (MBR),
partition tables and other random data files. This caused the systems to become unusable.

51

Additional information on the Maroochy Shire Sewage Spill incident can be found at:
http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-Study_report.pdf and
http://www.theregister.co.uk/2001/10/31/hacker_jailed_for_revenge_sewage/ [each accessed 4/16/15].
Additional information on the Davis-Besse incident can be found at:
http://www.securityfocus.com/news/6767 [accessed 4/16/15].
Additional information on the Zotob Worm incident can be found at: http://www.eweek.com/c/a/Security/ZotobPnP-Worms-Slam-13-DaimlerChrysler-Plants [accessed 4/16/15].
Additional information on the Stuxnet worm can be found at: http://en.wikipedia.org/wiki/Stuxnet [accessed
4/16/15].
Additional information on ICS-CERT reported incidents can be found at:
https://ics-cert.us-cert.gov/Information-Products [accessed 4/16/15].
Additional information on Shamoon can be found at:
http://ics-cert.us-cert.gov/sites/default/files/Monitors/ICS-CERT_Monitor_Sep2012.pdf [accessed 4/16/15].

52

53

54

55

56

277

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 マルヌチヌ垂の䞋氎流出 57 2000 幎春、豪州の元゜フトり゚ア開発䌚瀟瀟員が地方自治䜓職
員の募集に応募したが䞍採甚になった。䞍満を抱いた圓人は、2 か月間にわたり 46 回、無
線送信機で䞋氎凊理装眮に䟵入した。ある䞋氎ポンプステヌションの電子デヌタを改倉しお、
運転障害を発生させ、結局 26 侇 4,000 ガロンもの䞋氎を近隣の河川や公園に攟出させた。
 デむビス・ベス 58 2003 幎 8 月、原子力芏制委員䌚は同幎 1 月、スラマヌずしお知られるマ
むクロ゜フト SQL サヌバのワヌムが、オハむオ州オヌクハヌバヌにある非皌働䞭のデむビ
ス・ベス原子力発電所のプラむベヌトコンピュヌタネットワヌクに感染しおいるこずを確認
し、5 時間皋床安党監芖装眮が䜿甚できなかった。たた、発電所のプロセスコンピュヌタが
故障し、埩旧に玄 6 時間芁した。報告によればスラマヌは、少なくずも他の 5 ぀の公共事業
団䜓の制埡ネットワヌクの通信にも圱響を及がし、極めお迅速に䌝播しお制埡システムトラ
フィックを遮断した。
 Zotob ワヌム 59 2005 幎 8 月、むンタヌネットワヌムに感染したダむムラヌクラむスラヌの
米囜自動車生産プラント 13 箇所が玄 1 時間にわたりオフラむンになり、Windows システム
ぞのパッチ䜜業の間、䜜業員が立ち埀生した。むリノむ、むンディアナ、りィスコンシン、
オハむオ、デラりェア、ミシガンの各州ではプラントがオフラむンになった。感染したのは
䞻に Windows2000 だったが、Windows XP の初期バヌゞョンも感染した。感染の城候は、切
断ず再起動の繰り返しだった。Zotob 及びその掟生型は、倧型装備品メヌカヌの Caterpillar
Inc.、航空機メヌカヌの Boeing、その他倧手の報道機関のコンピュヌタが被害に遭った。
 Stuxnet ワヌム 60 Stuxnet は 2010 幎 7 月に芋぀かった Windows コンピュヌタのワヌムで、
産業甚゜フトり゚ア及び装備品を䞻な暙的ずしおいる。圓初このワヌムは察象を遞ばず拡散
したが、特殊なマルり゚アペむロヌドを組み蟌んで、特定の産業プロセスの制埡・監芖に特
化した SCADA システムだけを暙的ずするようになった。
 むンタヌネットに察面する制埡システムぞの匷力攻撃 61 2013 幎 2 月 22 日、ICS-CERT は
ガスコンプレッサステヌションの保有者から、制埡管理ネットワヌクぞのアクセスをもくろ
む匷倧な力の増加がある旚報告を受けた。調査の結果、別個の IP が 10 ず、同皮の補足的な
呌出しがほかの倩然ガスパむプラむン保有者からもあり、党郚で 39 の远加 IP 事案ずなった。
ログ解析の結果、2013 幎 1 月 16 日から始たっおいたが、同幎 3 月 8 日以降の届出はなかっ
た。
 シャムヌン 62 䞖界第 8 䜍の補油䌚瀟 Saudi Aramco は、同瀟の補油斜蚭を暙的ずしたマルり
゚ア攻撃に遭い、システムのマスタヌブヌトレコヌドMBR、パヌティションテヌブル
その他ランダムデヌタファむルが曞き換えられた。システムは䜿甚䞍胜になった。

57

58

59

60

61

62

マルヌチヌ垂の䞋氎流出むンシデントの詳现は次のサむトにある。

http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-Study_report.pdf
and http://www.theregister.co.uk/2001/10/31/hacker_jailed_for_revenge_sewage/ [each accessed
4/16/15].
デむビス・ベスむンシデントの詳现は次のサむトにある。http://www.securityfocus.com/news/6767 [accessed
4/16/15].
Zotob ワヌムむンシデントの詳现は次のサむトにある。http://www.eweek.com/c/a/Security/Zotob-PnP-WormsSlam-13-DaimlerChrysler-Plants [accessed 4/16/15].
Stuxnet ワヌムむンシデントの詳现は次のサむトにある。http://en.wikipedia.org/wiki/Stuxnet [accessed
4/16/15].
ICS-CERT 届出むンシデントの詳现は次のサむトにある。https://ics-cert.us-cert.gov/Information-Products
[accessed 4/16/15].
シャムヌンの詳现は次のサむトにある。http://ics-cert.us-cert.gov/sites/default/files/Monitors/ICSCERT_Monitor_Sep2012.pdf [accessed 4/16/15].

278

SPECIAL PUBLICATION 800-82 REVISION 2



GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

German Steel Mill Attack 63. In 2014, hackers manipulated and disrupted control systems to such a
degree that a blast furnace could not be properly shut down, resulting in “massive”—though
unspecified—damage.

Structural Events


CSX Train Signaling System 64. In August 2003, the Sobig computer virus was blamed for shutting
down train signaling systems throughout the east coast of the U.S. The virus infected the computer
system at CSX Corp.’s Jacksonville, Florida headquarters, shutting down signaling, dispatching, and
other systems. According to Amtrak spokesman Dan Stessel, ten Amtrak trains were affected in the
morning. Trains between Pittsburgh and Florence, South Carolina were halted because of dark signals,
and one regional Amtrak train from Richmond, Virginia to Washington and New York was delayed for
more than two hours. Long-distance trains were also delayed between four and six hours.



Northeast Power Blackout 65. In August 2003, failure of the alarm processor in First Energy’s
SCADA system prevented control room operators from having adequate situational awareness of
critical operational changes to the electrical grid. Additionally, effective reliability oversight was
prevented when the state estimator at the Midwest Independent System Operator failed due to
incomplete information on topology changes, preventing contingency analysis. Several key 345 kV
transmission lines in Northern Ohio tripped due to contact with trees. This eventually initiated
cascading overloads of additional 345 kV and 138 kV lines, leading to an uncontrolled cascading
failure of the grid. A total of 61 800 MW load was lost as 508 generating units at 265 power plants
tripped.



Taum Sauk Water Storage Dam Failure 66. In December 2005, the Taum Sauk Water Storage Dam
suffered a catastrophic failure releasing a billion gallons of water. The failure of the reservoir occurred
as the reservoir was being filled to capacity or may have possibly been overtopped. The current
working theory is that the reservoir's berm was overtopped when the routine nightly pump-back
operation failed to cease when the reservoir was filled. According to the utility, the gauges at the dam
read differently than the gauges at the Osage plant at the Lake of the Ozarks, which monitors and
operates the Taum Sauk plant remotely. The stations are linked together using a network of microwave
towers, and there are no operators on-site at Taum Sauk.



Bellingham, Washington Gasoline Pipeline Failure 67. In June 1999, 900 000 liters (237 000
gallons) of gasoline leaked from a 16 in. (40.64 cm) pipeline and ignited 1.5 hours later causing 3
deaths, 8 injuries, and extensive property damage. The pipeline failure was exacerbated by control
systems not able to perform control and monitoring functions. “Immediately prior to and during the
incident, the SCADA system exhibited poor performance that inhibited the pipeline controllers from
seeing and reacting to the development of an abnormal pipeline operation.” A key recommendation

63

Additional information on the German steel mill incident can be found at:

http://www.wired.com/2015/01/german-steel-mill-hack-destruction/
64

65

66

67

[accessed 4/16/15].
Additional information on the CSX Train Signaling System incident can be found at:
http://www.cbsnews.com/stories/2003/08/21/tech/main569418.shtml and
http://www.informationweek.com/story/showArticle.jhtml?articleID=13100807 [each accessed 4/16/15].
Additional information on the Northeast Power Blackout incident can be found at:
http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinalImplementationReport%282%29.pdf
[accessed 4/16/15].http://www.oe.energy.gov/DocumentsandMedia/BlackoutFinal-Web.pdf
Additional information on the Taum Sauk Water Storage Dam Failure incident can be found at:
http://www.ferc.gov/industries/hydropower/safety/projects/taum-sauk/ipoc-rpt/full-rpt.pdf [accessed 4/16/15].
Additional information on the Bellingham, Washington Gasoline Pipeline Failure incident can be found at
http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Bellingham_Case_Study_report%2020Sep071.pdf and
http://www.ntsb.gov/investigations/AccidentReports/Reports/PAR0202.pdf [each accessed 4/16/15].

279

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 ドむツ鉄工所攻撃 68 2014 幎にハッカヌは制埡システムを操䜜しお䞭断し、高炉が正垞に遮
断できなくなり、特定䞍胜の「倧芏暡」損害に至った。

構造的事象

 CSX 列車信号システム 69 2003 幎 8 月、Sobig コンピュヌタりむルスが原因ず蚀わる列車信
号システムの遮断が米囜東海岞䞀垯を襲った。りむルスは CSX Corp.のフロリダゞャク゜
ンビル本郚コンピュヌタシステムに感染し、信号、ディスパッチその他のシステムを遮断
した。Amtrak のスポヌクスマン Dan Stessel によれば、その朝列車 10 䞡に圱響が出た。サり
スカロラむナ州ピッツバヌグずフロヌレンス間で、暗信号のため列車が立ち埀生し、リッチ
モンド、バヌゞニア、ワシントン、ニュヌペヌク間でも 2 時間以䞊にわたりダむダに遅れが
生じた。長距離列車にも 46 時間の遅れが出た。
 北東郚の停電 70 2003 幎 8 月、First Energy の SCADA システムのアラヌムプロセッサが故障
し、配電網の重倧な運甚倉曎があったこずに、制埡宀操䜜員が気づかなかった。たた、
Midwest Independent System Operator の査定官が、トポロゞヌ倉曎に関する情報の䞍備から職
務を遂行できず、䞍枬事態分析が䞍胜で、信頌性に察する効果的な監督業務が阻害された。
オハむオ州北郚の䞻芁な 345kV 送電線が、暹朚ず接觊したために遮断された。このため連
鎖的な過負荷が別の 345kV 及び 138kV にかかり、送電網の制埡䞍胜な連鎖障害に至った。
結局 265 の発電所の発電装眮 508 基が遮断され、合蚈 61,800MW が倱われた。
 Taum Sauk 貯氎ダムの障害 71 2005 幎 12 月、Taum Sauk 貯氎ダムが壊滅的な被害に遭い、
数十億ガロンの氎が攟出された。障害は、貯氎池が満氎あるいはそれを越えたために生じた。
珟圚の䜜業理論では、貯氎池の満氎時に、毎倜行われるポンプバック操䜜が停止せず、貯氎
池の頂郚から溢れ出たずされおいる。事業者によれば、ダムのゲヌゞず、Taum Sauk 発電所
を遠隔監芖・運甚する Ozarks 湖にある Osage 発電所のゲヌゞの倀衚瀺が違っおいた。各ス
テヌションは、マむクロ波タワヌのネットワヌクを利甚しお結ばれおおり、Taum Sauk には
珟堎操䜜員がいない。
 ワシントン州ベリンガムのガ゜リンパむプラむン障害 72 1999 幎 6 月、ガ゜リン 90 䞇リッ
トル23 侇 7,000 ガロンが 16 むンチ40.64cmのパむプラむンから挏れ、1 時間半埌に
発火し、死者 3 人、負傷者 8 人のほか甚倧な物損が生じた。制埡システムの制埡・監芖機胜
が働かず、パむプラむン障害が悪化した。「むンシデントの盎前及び最䞭に、SCADA シス
テムのパフォヌマンスが劣り、パむプラむン操䜜員は、異垞なパむプラむン動䜜に察しお、
確認も察凊もできなかった。

68

ドむツの鉄工所むンシデントの詳现は次のサむトにある。http://www.wired.com/2015/01/german-steel-mill-

hack-destruction/ [accessed 4/16/15].
69

CSX 列車信号システムむンシデントの詳现は次のサむトにある。

http://www.cbsnews.com/stories/2003/08/21/tech/main569418.shtml and
http://www.informationweek.com/story/showArticle.jhtml?articleID=13100807 [each accessed 4/16/15].
70

北東郚の停電むンシデントの詳现は次のサむトにある。

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinalImplementationReport%282
%29.pdf [accessed 4/16/15].http://www.oe.energy.gov/DocumentsandMedia/BlackoutFinal-Web.pdf
71

Taum Sauk 貯氎ダム障害むンシデントの詳现は次のサむトにある。

http://www.ferc.gov/industries/hydropower/safety/projects/taum-sauk/ipoc-rpt/full-rpt.pdf
[accessed 4/16/15].
72

ワシントン州ベリンガムのガ゜リンパむプラむン障害むンシデントの詳现は次のサむトにある。

http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Bellingham_Case_Study_report%2020Sep071.pdf
and http://www.ntsb.gov/investigations/AccidentReports/Reports/PAR0202.pdf [each accessed
4/16/15].

280

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

from the NTSB report issued October 2002 was to utilize an off-line development and testing system
for implementing and testing changes to the SCADA database.


Browns Ferry-3 PLC Failure 73. In August 2006, TVA was forced to manually shut down one of their
plant's two reactors after unresponsive PLCs problems caused two water pumps to fail and threatened
the stability of the plant itself. Although there were dual redundant PLCs, they were connected to the
same Ethernet network. Later testing on the failed devices discovered that they would crash when they
encountered excessive network traffic.

Environmental Events


Fukushima Daiichi Nuclear Disaster 74. The Great East Japan Earthquake on 11 March 2011 struck
off the coast of Japan, sending a massive tsunami inland towards the nuclear plant. The tsunami
compromised the plants seawall, flooding much of the plant including the location housing the
emergency generators. This emergency power was critical to operate the control rooms and also to
provide coolant water for the reactors. The loss of coolant caused the reactor cores to overheat to the
point where the fuel's zirconium cladding reacted with water, releasing hydrogen gas and fueling large
explosions in three of the four reactor buildings. This resulted in large-scale radiation leakage that has
impacted plant employees, nearby citizens, and the local environment. Post event analysis found that
the plant’s emergency response center had insufficient secure communication lines to provide other
areas of the plant with information on key safety related instrumentation.

Accidental Events


Vulnerability Scanner Incidents 75. While a ping sweep was being performed on an active SCADA
network that controlled 3 meter (9 foot) robotic arms, it was noticed that one arm became active and
swung around 180 degrees. The controller for the arm was in standby mode before the ping sweep was
initiated. In a separate incident, a ping sweep was being performed on an ICS network to identify all
hosts that were attached to the network, for inventory purposes, and it caused a system controlling the
creation of integrated circuits in the fabrication plant to hang. This test resulted in the destruction of
$50,000 worth of wafers.



Penetration Testing Incident 76. A natural gas utility hired an IT security consulting organization to
conduct penetration testing on its corporate IT network. The consulting organization carelessly
ventured into a part of the network that was directly connected to the SCADA system. The penetration
test locked up the SCADA system and the utility was not able to send gas through its pipelines for four
hours. The outcome was the loss of service to its customer base for those four hours.

73

Additional information on the Browns Ferry -3 PLC Failure incident can be found at:
http://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2007/in200715.pdf [accessed 4/16/15].
Additional information can be found at: http://wwwpub.iaea.org/MTCD/meetings/PDFplus/2011/cn200/documentation/cn200_Final-Fukushima-Mission_Report.pdf and
http://pbadupws.nrc.gov/docs/ML1414/ML14140A185.pdf [each accessed 4/16/15].
Additional information on the vulnerability scanner incidents can be found at:
http://energy.sandia.gov/wp/wpcontent/gallery/uploads/sand_2005_2846p.pdfhttp://www.sandia.gov/scada/documents/sand_2005_2846p.pdf
[accessed 4/16/15].
Additional information on penetration testing incidents can be found at: http://energy.sandia.gov/wp/wpcontent/gallery/uploads/sand_2005_2846p.pdf [accessed 4/16/15].

74

75

76

281

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

2002 幎 10 月発行の NTSB 報告曞の䞻な掚奚事項は、SCADA デヌタベヌスぞの倉曎の実装
及び詊隓は、オフラむン開発詊隓システムを䜿甚するこずになっおいる。

 Browns Ferry-3 台の PLC 障害 77 2006 幎 8 月、PLC が反応しなくなり 2 基の氎ポンプが止
たり、発電所自䜓の安定性維持が危うくなったため、2 基の原子炉のうちの 1 基を手動で停
止した。2 重冗長性の PLC だったが、いずれも同じ Ethernet ネットワヌクに接続されおいた。
故障したデバむスを埌日詊隓した結果、ネットワヌクトラフィックが過倧になり、クラッシ
ュしおいたこずが分かった。
環境的事象

 犏島第 1 原子炉灜害 78 2011 幎 3 月 11 日、東日本倧地震が日本の沖合で発生し、倧型の接
波が発電所を襲った。接波は発電所の防波堀を突砎し、緊急甚発電機を収容した堎所も含め、
発電所の倧郚分が浞氎した。この緊急甚電力は、制埡宀の運甚ず原子炉甚冷华氎の絊氎に䞍
可欠だった。冷华氎が倱われたため炉心が過熱し、燃料のゞルコニりム被芆が氎ず反応しお
氎玠を攟出し、4 棟ある建屋の 3 棟で爆発が生じた。このため倧芏暡の攟射胜挏れが生じ、
発電所埓業員、近隣䜏人及び地元環境に圱響が及んだ。事埌解析の結果、重芁な安党関連蚈
装情報を発電所の他の゚リアに䌝えるための緊急時察応センタヌの通信線に䞍備があった。
偶発的事象

 脆匱性スキャナヌむンシデント 79 3m9 フィヌトのロボットアヌムを制埡するアクティ
ブ SCADA システムネットワヌクで、ピンスむヌプを行っおいたずころ、1 本のアヌムがア
クティブになりほが 180°振れた。ピンスむヌプの開始前、アヌム操䜜員はスタンバむモヌ
ドだった。別のむンシデントでは、ICS ネットワヌクでピンスむヌプを行い、圚庫管理目的
で、ネットワヌクに接続しおいる党おのホストを識別しおいたずころ、IC の䜜成を制埡し
おいる補造プラントのシステムをハングさせた。結果ずしお、5 䞇ドル分のりェハヌが砎損
した。
 ペネトレヌション・テスト・むンシデント 80 倩然ガス事業䜓は、自瀟 IT ネットワヌクの
ペネトレヌション・テスト実斜のため、IT 接続コンサルティング組織を雇甚した。コンサ
ルティング組織は、䞍泚意にも SCADA システムに盎接぀ながったネットワヌクの䞀郚に入
った。ペネトレヌション・テストのせいで SCADA システムがロックし、同事業䜓は 4 時間
にわたりガスを配送できなかった。結果は 4 時間にわたる顧客ぞのサヌビス提䟛の喪倱ずな
った。

77

78

79

80

Browns Ferry-3 台の PLC 障害むンシデントの詳现は次のサむトにある。http://www.nrc.gov/reading-rm/doccollections/gen-comm/info-notices/2007/in200715.pdf [accessed 4/16/15].
詳现は次のサむトにある。http://wwwpub.iaea.org/MTCD/meetings/PDFplus/2011/cn200/documentation/cn200_Final-FukushimaMission_Report.pdf and http://pbadupws.nrc.gov/docs/ML1414/ML14140A185.pdf [each accessed
4/16/15].
脆匱性スキャナヌむンシデントの詳现は次のサむトにある。http://energy.sandia.gov/wp/wpcontent/gallery/uploads/sand_2005_2846p.pdfhttp://www.sandia.gov/scada/documents/sand_2005_2846p.
pdf [accessed 4/16/15].
ペネトレヌション・テスト・むンシデントの詳现は次のサむトにある。http://energy.sandia.gov/wp/wpcontent/gallery/uploads/sand_2005_2846p.pdf [accessed 4/16/15].

282

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix D—Current Activities in Industrial Control System Security
This appendix contains abstracts of some of the many activities that are addressing ICS cybersecurity.
Please be aware that organization descriptions and related information provided in this appendix has been
drawn primarily from the listed organizations’ Web sites and from other reliable public sources, but has not
been verified. Readers are encouraged to contact the organizations directly for the most up-to-date and
complete information.
American Gas Association (AGA) Standard 12, “Cryptographic Protection of SCADA
Communications”
American Gas Association: http://www.aga.org/
The American Gas Association, representing 195 local energy utility organizations that deliver natural gas
to more than 56 million homes, businesses, and industries throughout the United States, advocates the
interests of its energy utility members and their customers, and provides information and services. The
AGA 12 series of documents recommends practices designed to protect SCADA communications against
cyber incidents. The recommended practices focus on ensuring the confidentiality of SCADA
communications.
The purpose of the AGA 12 series is to save SCADA system owners’ time and effort by recommending a
comprehensive system designed specifically to protect SCADA communications using cryptography. The
AGA 12 series may be applied to water, wastewater, and electric SCADA-based distribution systems
because of their similarities with natural gas systems, however timing requirements may be different.
Recommendations included in the series 12 documents may also apply to other ICS. Additional topics
planned for future addendums in this series include key management, protection of data at rest, and security
policies.
American Petroleum Institute (API) Standard 1164, “Pipeline SCADA Security”
American Petroleum Institute: http://www.api.org/
The American Petroleum Institute represents more than 400 members involved in all aspects of the oil and
natural gas industry. API 1164 provides guidance to the operators of oil and natural gas pipeline systems
for managing SCADA system integrity and security. The guideline is specifically designed to provide
operators with a description of industry practices in SCADA security, and to provide the framework needed
to develop sound security practices within the operator’s individual organizations. It stresses the
importance of operators understanding system vulnerability and risks when reviewing the SCADA system
for possible system improvements. API 1164 provides a means to improve the security of SCADA pipeline
operations by:


Listing the processes used to identify and analyze the SCADA system’s susceptibility to incidents.



Providing a comprehensive list of practices to harden the core architecture.



Providing examples of industry recommended practices.

The guideline targets small to medium pipeline operators with limited IT security resources. The guideline
is applicable to most SCADA systems, not just oil and natural gas SCADA systems. The appendices of the
document include a checklist for assessing a SCADA system and an example of a SCADA control system
security plan.

283

SP800-82 第 2 版

付録 D

産業甚制埡システムICSセキュリティガむド

産業甚制埡システムセキュリティにおける珟圚の掻動

この付録では、ICS サむバヌセキュリティを察象ずした諞掻動のいく぀かを取りたずめる。蚘茉
されおいる組織ず関連情報は、䞻に蚘茉されおいる組織のりェブサむトその他信頌できる公開の
出所から取ったもので、未怜蚌であるこずに留意されたい。盎接これら組織に問い合わせ、最新
情報を入手するように奚励する。
米囜ガス協䌚AGA芏栌 12「SCADA 通信の暗号化保護」
米囜ガス協䌚http://www.aga.org/
195 の地方゚ネルギヌ䟛絊事業䜓を代衚する米囜ガス協䌚は、党米の䞀般家庭 5,600 䞇䞖垯、䌁
業及び業界に倩然ガスを䟛絊し、事業者ず顧客双方の利益を擁護し、情報及びサヌビスを提䟛し
おいる。AGA12 シリヌズは、SCADA システムをサむバヌむンシデントから守るための芏範を掚
奚しおいる。掚奚芏範は、SCADA 通信の機密性の確保に重点を眮いおいる。
同シリヌズの目的は、暗号を利甚しお SCADA 通信を保護する包括的システムの掚奚により、
SCADA システム保有者の時間ず劎力を節玄するこずにある。同シリヌズは、倩然ガスシステム
ずの共通性が倚い氎道、䞋氎及び SCADA ベヌスの配電システムに適甚できるが、タむミングに
関する芁件は異なるこずがある。
掚奚事項は他の ICS にも適甚できる。補遺ずしお将来蚈画されおいるものには、重芁管理事項、
䌑眠䞭のデヌタ保護、セキュリティポリシヌ等がある。
米囜石油協䌚API芏栌 1164「パむプラむン SCADA セキュリティ」
米囜石油協䌚http://www.api.org/
米囜石油協䌚は、石油及び倩然ガス業界のあらゆる面に埓事する 400 以䞊のメンバヌを代衚しお
いる。API1164 は、SCADA システムの完党性及びセキュリティの管理に携わる、石油及び倩然
ガスパむプラむンシステム操䜜員向けガむダンスずなる。特に SCADA セキュリティの業界芏範
に぀いお説明し、操䜜員の組織における健党なセキュリティ芏範を策定するための基本構成を瀺
しおいる。SCADA システムを粟査しお改善を図る際に、操䜜員がシステムの脆匱性ずリスクを
理解する倧切さを匷調しおいる。API1164 は、SCADA パむプラむン運甚のセキュリティを向䞊
させる手段ずしお、以䞋を挙げおいる。

 SCADA システムのむンシデント感受性を識別・分析するためのプロセスの列挙
 コアアヌキテクチャを匷固にするための包括的芏範リストの䜜成
 業界掚奚芏範の䟋瀺
このガむドラむンは、IT セキュリティリ゜ヌスが限られた䞭小芏暡のパむプラむン事業者を察象
ずしおいる。石油及び倩然ガスのみならず、ほずんどの SCADA システムに適甚できる。ガむド
ラむンの付録には、SCADA システム評䟡のチェックリストや SCADA 制埡システムセキュリテ
ィ蚈画曞の䟋もある。

284

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Electric Power Research Institute (EPRI)
http://www.epri.com/Our-Work/Pages/Cyber-Security.aspx,
http://smartgrid.epri.com/NESCOR.aspx
The Electric Power Research Institute (EPRI) is a nonprofit center for public interest energy and
environmental research. EPRI brings together member organizations, the Institute's scientists and engineers,
and other leading experts to work collaboratively on solutions to the challenges of electric power. These
solutions span nearly every area of power generation, delivery, and use, including health, safety, and
environment. EPRI's members represent over 90% of the electricity generated in the United States.
Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)
https://ics-cert.us-cert.gov/About-Industrial-Control-Systems-Cyber-Emergency-Response-Team
The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) operates within the
National Cybersecurity and Integration Center (NCCIC), a division of the Department of Homeland
Security's Office of Cybersecurity and Communications (DHS CS&C). NCCIC/ICS-CERT is a key
component of the DHS Strategy for Securing Control Systems. The primary goal of the Strategy is to build
a long-term common vision where effective risk management of control systems security can be realized
through successful coordination efforts. ICS-CERT provides a control system security focus in
collaboration with US-CERT to:


Respond to and analyze control systems related incidents.



Conduct vulnerability and malware analysis.



Provide onsite support for incident response and forensic analysis.



Provide situational awareness in the form of actionable intelligence.



Coordinate the responsible disclosure of vulnerabilities/mitigations.



Share and coordinate vulnerability information and threat analysis through information products and
alerts.

ICS-CERT coordinates control systems-related security incidents and information sharing with Federal,
State, and local agencies and organizations, the intelligence community, and private sector constituents,
including vendors, owners and operators, and international and private sector CERTs. The focus on control
systems cybersecurity provides a direct path for coordination of activities among all members of the critical
infrastructure stakeholder community.
As a functional component of the NCCIC, ICS-CERT provides focused operational capabilities for defense
of control system environments against emerging cyber threats.
ICS-CERT provides efficient coordination of control-systems-related security incidents and information
sharing with federal, state, and local agencies and organizations, the Intelligence Community, private sector
constituents including vendors, owners, and operators, and international and private sector computer
security incident response teams (CSIRTs). The focus on control systems cybersecurity provides a direct
path for coordination of activities for all members of the stakeholder community.

285

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

米囜電力研究所EPRI
http://www.epri.com/Our-Work/Pages/Cyber-Security.aspx,
http://smartgrid.epri.com/NESCOR.aspx
米囜電力研究所EPRIは、公益゚ネルギヌ環境研究に関する非営利団䜓である。加盟団䜓、研
究所の科孊者・゚ンゞニアその他専門家を束ねお、電力問題の解決に取り組んでいる。解決策は
発電、配電、利甚などあらゆる分野にたたがり、健康、安党、環境等も含たれる。加盟メンバヌ
は、米囜発電量の 90%以䞊を生産しおいる。
産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)
https://ics-cert.us-cert.gov/About-Industrial-Control-Systems-Cyber-Emergency-Response-Team
産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)は、囜家サむバヌセキュリティ通信統合
センタヌ(NCCIC)内で、囜土安党保障省のサむバヌセキュリティ通信局DHS CS&Cの䞋にあ
る。NCCIC/ICS-CERT は、制埡サヌビスのセキュリティを確保する DHS 斜策の䞻芁な構成芁玠
である。この斜策の䞻な目的は、長期の共通的ビゞョンを打ち立お、盞互連携を通じお制埡シス
テムセキュリティの効果的リスク管理を実珟するこずにある。ICS-CERT は US-CERT ずの連携
を通じお、以䞋を重点ずする制埡システムセキュリティを掚進する。

 制埡システム関連むンシデントぞの察応ず分析
 脆匱性ずマルり゚アの分析
 珟堎でのむンシデント察応ず調査分析支揎
 実甚的な情報提䟛による意識の高揚
 脆匱性・緩和策の責任ある開瀺の調敎
 情報通知・アラヌトによる脆匱性情報ず脅嚁分析の共有ず調敎
ICS-CERT は制埡システム関連セキュリティむンシデントず情報を調敎し、囜・州・地方自治
䜓・組織・情報共同䜓・民間䌁業ベンダヌ・保有者・囜際民間䌁業 CERT 等ず共有する。制
埡システムのサむバヌセキュリティに泚力するこずで、党重芁むンフラ関係者間の掻動を盎接調
敎する道筋が開ける。
NCCIC の機胜芁玠ずしお ICS-CERT は、制埡システム環境を新興サむバヌ脅嚁から守るため、集
䞭的な運甚胜力を付䞎する。
ICS-CERT は制埡システム関連セキュリティむンシデントず情報を調敎し、囜・州・地方自治
䜓・組織・情報共同䜓・民間䌁業ベンダヌ・保有者・操䜜員・囜際/民間䌁業コンピュヌタセ
キュリティむンシデント察応チヌム[CSIRT]等ず共有する。制埡システムのサむバヌセキュリ
ティに泚力するこずで、党関係者に掻動を盎接調敎する道筋を開く。

286

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ICS-CERT Cyber Security Evaluation Tool (CSET®)
http://ics-cert.us-cert.gov/Assessments
The Cyber Security Evaluation Tool (CSET®) is a DHS product that assists organizations in protecting
their key national cyber assets. It was developed under the direction of the DHS ICS-CERT by
cybersecurity experts and with assistance from NIST. This tool provides users with a systematic and
repeatable approach for assessing the security posture of their cyber systems and networks. It includes both
high-level and detailed questions related to all industrial control and IT systems.
CSET is a desktop software tool that guides users through a step-by-step process to assess their control
system and information technology network security practices against recognized industry standards. The
output from CSET is a prioritized list of recommendations for improving the cybersecurity posture of the
organization's enterprise and industrial control cyber systems. The tool derives the recommendations from a
database of cybersecurity standards, guidelines, and practices. Each recommendation is linked to a set of
actions that can be applied to enhance cybersecurity controls.
CSET has been designed for easy installation and use on a stand-alone laptop or workstation. It
incorporates a variety of available standards from organizations such as NIST, NERC, Transportation
Security Administration (TSA), U.S. Department of Defense (DoD), and others. When the tool user selects
one or more of the standards, CSET will open a set of questions to be answered. The answers to these
questions will be compared against a selected security assurance level, and a detailed report will be
generated to show areas for potential improvement. CSET provides an excellent means to perform a selfassessment of the security posture of your control system environment.

ICS-CERT Recommended Practices
https://ics-cert.us-cert.gov/Introduction-Recommended-Practices
ICS-CERT works with the control systems community to ensure that recommended practices, which are
made available, have been vetted by subject-matter experts in industry before being made publicly
available in support of this program.
Recommended practices are developed to help users reduce their exposure and susceptibility to cyber
attacks. These recommendations are based on understanding the cyber threats, control systems
vulnerabilities and attack paths, and secure architecture design.
The recommended practices working group selects topics to be implemented in the recommended practices
section. Additional supporting documents detailing a wide variety of control systems topics associated
with cyber vulnerabilities and their mitigation have been developed and vetted by the working group for
accuracy. These documents will be updated and topics added to address additional content and emerging
issues.

287

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS-CERT サむバヌセキュリティ評䟡ツヌル(CSET®)
http://ics-cert.us-cert.gov/Assessments
ICS-CERT サむバヌセキュリティ評䟡ツヌル(CSET®)は、組織が囜の重芁サむバヌ資産を守るの
を支揎する DHS の補品である。DHS ICS-CERT の指導䞋で、NIST の支揎を埗おサむバヌセキュ
リティ専門家が開発した。サむバヌシステム及びネットワヌクのセキュリティ状態を評䟡する際
の䜓系的か぀反埩的な取組が可胜ずなる。あらゆる産業甚制埡及び IT システムに関係した高床
の詳现な疑問に答えおいる。
CSET はデスクトップ゜フトり゚アツヌルで、制埡システム及び情報技術ネットワヌクセキュリ
ティ芏範を、広く認められた業界基準に照らしお、段階的に評䟡するこずができる。CSET によ
り、組織の䌁業・産業甚制埡サむバヌシステムのサむバヌセキュリティ状態を改善するための優
先的掚奚事項リストを䜜成できる。このツヌルは、サむバヌセキュリティ基準、ガむドラむン及
び芏範デヌタベヌスから掚奚事項を導き出す。それぞれの掚奚事項は、サむバヌセキュリティ管
理の拡匵に適甚可胜な䞀連の行動に結び぀いおいる。
CSET は、スタンドアロヌンラップトップやワヌクステヌションに、簡単にむンストヌルしお利
甚できるようになっおいる。NIST、NERC、運茞保安局(TSA)、囜防総省その他の組織から入手
可胜な皮々の基準が取りたずめおられおいる。ツヌルのナヌザがこれら基準のいずれかを遞択す
るず、䞀連の質問が提瀺される。質問ぞの回答を、遞択されたセキュリティ保蚌レベルず照らし
合わせ、改善できる分野を瀺した詳现なレポヌトが䜜成されるようになっおいる。CSET は、制
埡システム環境のセキュリティ状態を自己評䟡できる優れた手段ずなる。

ICS-CERT 掚奚芏範
https://ics-cert.us-cert.gov/Introduction-Recommended-Practices
ICS-CERT は制埡システムの共同䜓ず連携し、入手可胜になった掚奚芏範を公開する前に、業界
の察象専門家に怜蚌を䟝頌する。
掚奚芏範は、サむバヌ攻撃に察する露出や感受性を枛らすために䜜成される。サむバヌ脅嚁、制
埡システムの脆匱性・攻撃経路及びセキュアなアヌキテクチャ蚭蚈に察する理解を基にしおいる。
掚奚芏範䜜業グルヌプは、掚奚芏範セクションで取り䞊げるべき論題を遞定する。サむバヌ脆匱
性ずその緩和策に関する倚様な制埡システム論題に぀いお詳述した補足文曞が䜜業グルヌプによ
り䜜成され、正確性が怜蚌されおいる。文曞は曎新され、補足的な内容や新しい問題を取り䞊げ
た論題が远加される。

288

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Institute of Electrical and Electronics Engineers, Inc. (IEEE)
http://www.ieee.org
IEEE 1686-2007 – Standard for Substation IED Cybersecurity Capabilities. The functions and features to
be provided in substation intelligent electronic devices (lEDs) to accommodate critical infrastructure
protection programs are defined in this standard. Security regarding the access, operation, configuration,
firmware revision, and data retrieval from an IED is addressed in this standard. Communications for the
purpose of power system protection (teleprotection) is not addressed. Encryption for the secure
transmission of data both within and external to the substation, including supervisory control and data
acquisition, is not part of this standard as this is addressed in other efforts."
IEEE P1711 - Standard for a Cryptographic Protocol for Cybersecurity of Substation Serial Links. This
standard defines a cryptographic protocol to provide integrity, and optional confidentiality, for
cybersecurity of serial links. It does not address specific applications or hardware implementations, and is
independent of the underlying communications protocol.
IEEE 1815-2012 - Standard for Electric Power System Communications-Distributed Network Protocol
(DNP3). This standard describes the DNP3 SCADA protocol, incorporating version five of the applicationlayer authentication procedure called DNP3 Secure Authentication (DNP3-SAv5). DNP3-SAv5 uses a
HMAC process to verify that data and commands are received (without tampering) from authorized
individual users or devices while limiting computational and communications overhead. SAv5 supports
remote update (add/change/revoke) of user credentials using either symmetric or PKI techniques. SAv5
authenticates but does not encrypt messages, hence it does not provide confidentiality. SAv5 can be used
together with encryption techniques such as TLS or IEEE 1711 where confidentiality is required.
Institute for Information Infrastructure Protection (I3P)
http://www.thei3p.org/
The I3P is a consortium of leading national cybersecurity institutions, including academic research centers,
government laboratories, and non-profit organizations. It was founded in September 2001 to help meet a
well-documented need for improved research and development (R&D) to protect the nation's information
infrastructure against catastrophic failures. The institute's main role is to coordinate a national cybersecurity
R&D program and help build bridges between academia, industry, and government. The I3P continues to
work toward identifying and addressing critical research problems in information infrastructure protection
and opening information channels between researchers, policymakers, and infrastructure operators.
Currently, the I3P does the following:


Fosters collaboration among academia, industry, and government on pressing cybersecurity problems.



Develops, manages, and supports national-scale research projects.



Provides research fellowship opportunities to qualified post-doctoral researchers, faculty, and research
scientists.



Hosts workshops, meetings, and events on cybersecurity and information infrastructure protection
issues.



Builds and supports a knowledge base as an online vehicle for sharing and distributing information to
I3P members and others working on information security challenges.

289

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

電気電子技術者協䌚IEEE
http://www.ieee.org
IEEE 1686-2007 – 倉電所 IED サむバヌセキュリティ芏栌。重芁むンフラ防護プログラムに合った
倉電所情報電子デバむスIEDsに蚘茉する機胜・特性は、この芏栌で定矩される。アクセス、
運甚、構成、ファヌムり゚ア改正及び IED からのデヌタ取埗は、この芏栌で取り䞊げられる。電
力システム保護甚通信通信保護は察象倖ずなる。SCADA を含めた倉電所内倖でのセキュア
なデヌタ通信のための暗号化は、別に扱われるため、この芏栌では取り䞊げられない。
IEEE P1711 - 倉電所シリアルリンクのサむバヌセキュリティ甚暗号化プロトコル芏栌。この芏栌
は暗号化プロトコルに぀いお定め、シリアルリンクの完党性及びオプションの機密性に぀いお芏
定する。特定のアプリケヌションやハヌドり゚ア実装は取り䞊げず、基本通信プロトコルには䟝
存しおいない。
IEEE 1815-2012 - 電力システム通信・配電網プロトコル芏栌(DNP3)。この芏栌は、DNP3 セキュ
ア認蚌(DNP3-SAv5)ず呌ばれるアプリケヌション局認蚌手順のバヌゞョン 5 を取り入れた、
DNP3 SCADA に぀いお蚘述しおいる。DNP3-SAv5 は HMAC プロセスを䜿甚しお、挔算及び通信
オヌバヌヘッドを抑え぀぀、暩限あるナヌザ又はデバむスからデヌタ及びコマンドを改竄な
く受信したかどうかを怜蚌する。SAv5 は、察称技術又は PKI 技術を甚いおナヌザ認蚌情報の
遠隔曎新远加・倉曎・取消をサポヌトする。認蚌は行うが、機密性がないためメッセヌゞの
暗号化は行わない。機密性が必芁な堎合は、TLS や IEEE 1711 等の暗号化技術を䜵甚する。
情報むンフラ保護研究所I3P
http://www.thei3p.org/
I3P は倧孊の研究所、囜立研究所、NPO 等の䞻芁サむバヌセキュリティ機関からなるコン゜ヌシ
アムである。囜の情報むンフラを壊滅的障害から守る目的で、研究開発を改善しお文曞化するた
め 2001 幎 9 月に創蚭された。䞻な圹割は、囜のサむバヌセキュリティ研究開発プログラムの調
敎を行い、産官孊の連携を図るこずにある。I3P は情報むンフラの保護における重芁な研究䞊の
問題を明らかにしお取り䞊げるずずもに、研究者、政策立案者及びむンフラ運甚者間の情報経路
の開拓を目指しおいる。珟圚次のような取組を行っおいる。

 サむバヌセキュリティ問題ず取り組む産官孊間の連携匷化
 囜家芏暡の研究プロゞェクトの策定・管理・支揎
 有資栌博士課皋修了埌研究者・教員・研究者ぞの研究機䌚の提䟛
 サむバヌセキュリティ・情報むンフラ保護問題に関するワヌクショップ・䌚議・むベントの
開催
 I3P メンバヌその他情報セキュリティ問題関係者ぞの情報共有・配信媒䜓ずしおの知識基盀
の構築

290

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

International Electrotechnical Commission (IEC) Technical Committees 65 and 57
http://www.iec.ch/
IEC is a standards organization that prepares and publishes international standards for all electrical,
electronic, and related technologies. These standards serve as a basis for creating national standards and as
references for drafting international tenders and contracts. IEC’s members include manufacturers, providers,
distributors, vendors, consumers, and users, all levels of governmental agencies, professional societies,
trade associations, and standards developers from over 60 countries.
In 2004 the IEC Technical Sub-Committee 65C (Industrial Networks), through its working group WG13
(cybersecurity), started to address security issues - within the IEC 61784 standard – for field buses and
other industrial communication networks. Results of this work are outlined in part 4, entitled “Digital data
communications for measurement and control – Profiles for secure communications in industrial
networks.”
TC65 WG10 is working to extend this field level communication to address security standards across
common automation networking scenarios. The standard being drafted as a result of this work is IEC 62443,
entitled “Security for industrial process measurement and control – Network and system security.” It is
based on a modular security architecture consisting of requirement sets. These modules are mapped into
ICS component and network architecture. The resulting requirements can then be formulated for use as the
basis for Requests for Proposals (RFP) for data communication standards, and security audits.
TC 57 is focused on Power Systems Management and Associated Information Exchange and is divided up
into a series of working groups. Each working group is comprised of members of national standards
committees from the countries that participate in the IEC. Each working group is responsible for the
development of standards within its domain. The current working groups are:


WG 3: Telecontrol protocols.



WG 9: Distribution automation using distribution line carrier systems.



WG 10: Power system IED communication and associated data models.



WG 13: Energy management system application program interface (EMS-API).



WG 14: System interfaces for distribution management (SIDM).



WG 15: Data and communication security.



WG 16: Deregulated energy market communications.



WG 17: Communications Systems for Distributed Energy Resources (DER).



WG 18: Hydroelectric power plants – Communication for monitoring and control.



WG 19: Interoperability within TC 57 in the long term.



WG 20: Planning of (single-sideband) power line carrier systems (IEC 60495) Planning of (singlesideband) power line carrier systems (IEC 60663).



WG 21: Interfaces and protocol profiles relevant to systems connected to the electrical grid.

291

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

囜際電気暙準䌚議IEC技術委員䌚 65 及び 57
http://www.iec.ch/
IEC はあらゆる電気、電子及び関連技術に関する囜際芏栌を䜜成し、発衚する芏栌組織である。
芏栌は、囜の芏栌䜜成の根拠ずなり、囜際入札・契玄を起草する際の参考ずなる。IEC メンバヌ
はメヌカヌ、プロバむダ、流通業者、ベンダヌ、消費者・ナヌザ、各玚レベルの行政機関、専門
家協䌚、貿易協䌚及び 60 か囜の芏栌䜜成団䜓である。
IEC 技術䞋郚委員䌚 65C産業甚ネットワヌクは 2004 幎、その䜜業グルヌプ WG13サむバヌ
セキュリティを通じお、IEC61784 芏栌の䞀郚ずしお、フィヌルドバスその他産業甚通信ネッ
トワヌクのセキュリティ問題の怜蚎に着手した。この䜜業の結果は、パヌト 4「蚈枬制埡のため
のデゞタルデヌタ通信産業甚ネットワヌクにおけるセキュアな通信のプロファむル」に抂説さ
れおいる。
TC65 WG10 は、このフィヌルドレベル通信を拡匵しお、共通オヌトメヌションネットワヌキン
グシナリオでのセキュリティ芏栌を取り䞊げた。その結果起草された芏栌が IEC 62433 で、『産
業甚蚈枬制埡のセキュリティ - ネットワヌク及びシステムセキュリティ』ず題する。いく぀かの
芁件からなるモゞュヌル匏のセキュリティアヌキテクチャを基本ずしおいる。それぞれのモゞュ
ヌルは、ICS コンポヌネント及びネットワヌクアヌキテクチャにマッピングされる。そこから芁
件が定められ、デヌタ通信芏栌及びセキュリティ監査に察する提案芁求RFPの基瀎ずしお利
甚される。
TC57 は電力システム管理及び関連情報亀換に特化しおおり、䞀連のグルヌプに分化しおいる。
各䜜業グルヌプは、IEC 加盟各囜の芏栌委員䌚メンバヌで構成されおいる。各グルヌプは、それ
ぞれのドメむン内での芏栌䜜成を担圓する。珟圚の䜜業グルヌプは以䞋のずおり。

 WG 3遠隔制埡プロトコル
 WG 9配電線搬送システムを利甚した配電自動化
 WG 10電力システム IED 通信及び関連デヌタモデル
 WG 13緊急管理システムアプリケヌションプログラムむンタフェヌスEMS-API
 WG 14配電管理システムむンタフェヌスSIDM
 WG 15デヌタ及び通信セキュリティ
 WG 16゚ネルギヌ垂堎通信の芏制緩和
 WG 17分散゚ネルギヌリ゜ヌス通信システムDER
 WG 18氎力発電所 - 監芖制埡甚通信
 WG 19TC57 内での長期盞互運甚性
 WG 20単偎波垯送電線搬送システムのプランニングIEC 60495、単偎波垯送
電線搬送システムのプランニングIEC 60663
 WG 21配電網接続システムに係るむンタフェヌス及びプロトコルプロファむル

292

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ISA99 Industrial Automation and Control Systems Security Standards
http://www.isa.org/isa99
The ISA99 standards development committee brings together industrial cybersecurity experts from across
the globe to develop ISA standards on industrial automation and control system (IACS) security. This
original and ongoing ISA99 work is being standardized by the IEC in producing the multi-standard IEC
62443 series. The committee’s focus is to improve the confidentiality, integrity, and availability of
components or systems used for automation or control and provides criteria for procuring and
implementing secure control systems. Compliance with the committee’s guidance will improve industrial
automation and control system electronic security, and will help identify vulnerabilities and address them,
thereby reducing the risk of compromising confidential information or causing industrial automation
control system degradation or failure.
All ISA-62443 standards and technical reports are organized into four general categories called General,
Policies and Procedures, System, and Component.


General category includes common or foundational information such as concepts, models and
terminology. Also included are work products that describe security metrics and security life cycles for
IACS.



Policies and Procedures category of work products targets the Asset Owner. These address various
aspects of creating and maintaining an effective IACS security program.



System category includes work products that describe system design guidance and requirements for
the secure integration of control systems. Core in this is the zone and conduit design model.



Component category includes work products that describe the specific product development and
technical requirements of control system products. This is primarily intended for control product
vendors, but can be used by integrator and asset owners for to assist in the procurement of secure
products.

The current status of the ISA-62443 documents is provided on the ISA99 Wiki at
http://isa99.isa.org/ISA99 Wiki/
General
 ISA-62443-1-1 (IEC/TS 62443-1-1) (formerly referred to as "ISA-99 Part 1") was originally
published as ISA standard ANSI/ISA-99.00.01-2007, as well as an IEC technical specification IEC/TS
62443-1-1. The ISA99 committee is currently revising it to make it align with other documents in the
series, and to clarify normative content.


ISA-TR62443-1-2 (IEC 62443-1-2) is a master glossary of terms used by the ISA99 committee. This
document is a working draft.



ISA-62443-1-3 (IEC 62443-1-3) identifies a set of compliance metrics for IACS security. This
document is currently under development and the committee will be releasing a draft for comment in
2013.



ISA-TR62443-1-4 (IEC/TS 62443-1-4) defines the IACS security life cycle and use case. This work
product has been proposed as part of the series, but as of January 2013 development had not yet
started.

293

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ISA99 産業オヌトメヌション及び制埡システムセキュリティ芏栌
http://www.isa.org/isa99
ISA99 芏栌䜜成委員䌚は、䞖界の産業サむバヌセキュリティ専門家を招集しお、産業オヌトメヌ
ション制埡システムIACSセキュリティの ISA 芏栌の䜜成に取り組んでいる。圓初及び珟行
の ISA99 䜜業は、IEC により暙準化され、耇数の芏栌 IEC62443 シリヌズの䜜成を目指しおいる。
委員䌚の焊点は、自動化や制埡に䜿甚するコンポヌネントやシステムの機密性・完党性・可甚性
を改善し、セキュアな制埡システムの調達・実装基準を定めるこずにある。委員䌚のガむダンス
に埓うこずで、産業オヌトメヌションや制埡システムの電子的セキュリティが改善され、脆匱性
ず察凊方法が明らかになり、秘密情報の挏掩や産業オヌトメヌション制埡システムの劣化・故障
リスクが枛る。
ISA-62443 芏栌及び技術報告曞は、どれも党般、ポリシヌ・手順、システム及びコンポヌネント
のいずれかに分類される。

 党般区分には抂念・モデル・甚語ずいった共通的又は基本的情報が含たれる。たた、IACS
のセキュリティ評䟡基準及びセキュリティラむフサむクルに぀いお蚘述した䜜業成果も含た
れる。
 䜜業成果のポリシヌ・手順区分は、資産保有者を察象にしたものである。効果的な IACS セ
キュリティプログラムの䜜成及び保守の様々な面を取り䞊げおいる。
 システム区分には、制埡システムのセキュアな統合化に関するシステム蚭蚈ガむダンスず芁
件に぀いお蚘述した䜜業成果が含たれる。䞭心ずなるのは地域及びコンゞット蚭蚈モデルで
ある。
 コンポヌネント区分には、特定補品の開発ず制埡システム補品の技術芁件に぀いお蚘述した
䜜業成果が含たれる。䞻な察象は制埡補品ベンダヌであるが、むンテグレヌタや資産保有者
がセキュアな補品を調達する際の資ずするこずもできる。
ISA-62443 文曞の珟状に぀いおは、次の ISA99 Wiki サむトで確認できる。
http://isa99.isa.org/ISA99 Wiki/
党般
 ISA-62443-1-1 (IEC/TS 62443-1-1)旧称『ISA-99 Part 1』は圓初 ISA 芏栌 ANSI/ISA99.00.01-2007 及び IEC 技術仕様曞 IEC/TS 62443-1-1 ずしお発衚された。ISA99 委員䌚は、シ
リヌズの他の文曞ずの敎合性を確保し、暙準的な内容を明確にするため、珟圚これの芋盎し
䞭である。

 ISA-TR62443-1-2 (IEC 62443-1-2)は、ISA99 が䜿甚する甚語の総甚語集である。ただ草案段
階にある。
 ISA-62443-1-3 (IEC 62443-1-3)は、IACS セキュリティの䞀連のコンプラむアンス評䟡基準ず
なる。珟圚䜜成䞭で、2013 幎に案を発衚し、意芋を募集する。
 ISA-TR62443-1-4 (IEC/TS 62443-1-4)は、IACS のセキュリティラむフサむクルず䜿甚䟋を蚘
茉しおいる。この䜜業成果はシリヌズの䞀郚ずしお提唱されたが、2013 幎 1 月時点で䜜成
に未着手である。

294

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Policies and Procedures
 ISA-62443-2-1 (IEC 62443-2-1) (formerly referred to as "ANSI/ISA 99.02.01-2009 or ISA-99 Part
2") addresses how to establish an IACS security program. This standard is approved and published the
IEC as IEC 62443-2-1. It now being revised to permit closer alignment with the ISO 27000 series of
standards.


ISA-TR62443-2-2 (IEC 62443-2-2) addresses how to operate an IACS security program. This
standard is currently under development.



ISA-TR62443-2-3 (IEC/TR 62443-2-3) is a technical report on the subject of patch management in
IACS environments. This report is currently under development.



ISA-62443-2-4 (IEC 62443-2-4) focuses on the certification of IACS supplier security policies and
practices. This document was adopted from the WIB organization and is now a working product of the
IEC TC65/WG10 committee. The proposed ISA version will be a U.S. national publication of the IEC
standard.

System
 ISA-TR62443-3-1 (IEC/TR 62443-3-1) is a technical report on the subject of suitable technologies
for IACS security. This report is approved and published as ANSI/ISA-TR99.00.01-2007 and is now
being revised.


ISA-62443-3-2 (IEC 62443-3-2) addresses how to define security assurance levels using the zones
and conduits concept. This standard is currently under development.



ISA-62443-3-3 (IEC 62443-3-3) defines detailed technical requirements for IACS security. This
standard has been published as ANSI/ISA-62443-3-3 (99.03.03)-2013. It was previously numbered as
ISA-99.03.03.

Component
 ISA-62443-4-1 (IEC 62443-4-1) addresses the requirements for the development of secure IACS
products and solutions. This standard is currently under development.


ISA-62443-4-2 (IEC 62443-4-2) series address detailed technical requirements for IACS components
level. This standard is currently under development.

ISA100 Wireless Systems for Automation
http://www.isa.org/isa100
The ISA100 Committee will establish standards, recommended practices, technical reports, and related
information that will define procedures for implementing wireless systems in the automation and control
environment with a focus on the field level. Guidance is directed towards those responsible for the
complete life cycle including the designing, implementing, on-going maintenance, scalability or managing
industrial automation and control systems, and shall apply to users, system integrators, practitioners, and
control systems manufacturers and vendors.

295

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ポリシヌ及び手順
 ISA-62443-2-1 (IEC 62443-2-1) (旧称『ANSI/ISA 99.02.01-2009 又は ISA-99 Part 2』)は、IACS
セキュリティプログラムの策定方法を取り䞊げおいる。この芏栌は承認され、IEC 62443-21 ずしお発衚された。珟圚 ISO27000 シリヌズ芏栌ずの敎合性を確保するため改蚂䞭である。

 ISA-TR62443-2-2 (IEC 62443-2-2)は、IACS セキュリティプログラムの運甚方法を取り䞊げる。
この芏栌は珟圚䜜成䞭である。
 ISA-TR62443-2-3 (IEC/TR 62443-2-3)は、IACS 環境におけるパッチ管理に関する技術報告曞
である。この報告曞は珟圚䜜成䞭である。
 ISA-62443-2-4 (IEC 62443-2-4)は、IACS サプラむダのセキュリティポリシヌ及び芏範の認定
曞に特化しおいる。本曞は WIB 組織が採甚し、IEC TC65/WG10 委員䌚の䜜業成果ずなっお
いる。ISA 版の案は、IEC 芏栌の政府文曞ずなろう。
システム
 ISA-TR62443-3-1 (IEC/TR 62443-3-1)は、IACS セキュリティの適合技術に関する技術報告曞
である。本報告曞は承認され、ANSI/ISA-TR99.00.01-2007 ずしお発衚され、珟圚改蚂䞭であ
る。

 ISA-62443-3-2 (IEC 62443-3-2)は、地域及びコンゞット蚭蚈抂念を利甚したセキュリティ保
蚌レベルの定矩方法に぀いお取り䞊げおいる。この芏栌は珟圚䜜成䞭である。
 ISA-62443-3-3 (IEC 62443-3-3)は、IACS セキュリティの詳现な技術芁件に぀いお明らかにし
おいる。この芏栌は ANSI/ISA-62443-3-3 (99.03.03)-2013 ずしお発衚された。旧番号は ISA99.03.03 だった。
コンポヌネント
 ISA-62443-4-1 (IEC 62443-4-1)は、セキュアな IACS 補品及び゜リュヌションの開発芁件に぀
いお取り䞊げおいる。この芏栌は珟圚䜜成䞭である。

 ISA-62443-4-2 (IEC 62443-4-2)シリヌズは、IACS コンポヌネントレベルの詳现な技術芁件に
぀いお取り䞊げおいる。この芏栌は珟圚䜜成䞭である。

ISA100 オヌトメヌション甚ワむダレスシステム
http://www.isa.org/isa100
ISA100 委員䌚は、フィヌルドレベルに特化したオヌトメヌション及び制埡環境におけるワむダ
レスシステムの手順を芏定した芏栌や掚奚芏範を定め、技術報告曞や関連情報を配信する。ガむ
ダンスは産業オヌトメヌション及び制埡システムの蚭蚈、実装、恒垞的保守、スケヌラビリティ、
管理等ラむフサむクル党般の担圓者を察象ずし、ナヌザ、システムむンテグレヌタ、実務埓事者
及び制埡システムメヌカヌ・ベンダヌに適甚される。

296

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ISO 27001
http://www.iso.org/, http://www.27000.org
ISO 27001 provides a model for establishing, implementing, operating, monitoring, reviewing, maintaining
and improving an Information Security Management System. The objective of the standard itself is to
"provide requirements for establishing, implementing, maintaining and continuously improving an
Information Security Management System (ISMS).” Regarding its adoption, this should be a strategic
decision. Further, "The design and implementation of an organization's information security management
system is influenced by the organization's needs and objectives, security requirements, the organizational
processes used and the size and structure of the organization.” The content sections of the standard include:


Context of the Organization.



Information Security Leadership.



Planning an ISMS.



Support.



Operation.



Performance Evaluation.



Improvement.



Annex A – List of controls and their objectives.

The 2005 version of the standard heavily employed the Plan-Do-Check-Act model to structure the
processes, and reflect the principles set out in the OECG guidelines (see oecd.org). However, the latest,
2013 version, places more emphasis on measuring and evaluating how well an organization’s ISMS is
performing.

297

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ISO 27001
http://www.iso.org/, http://www.27000.org
ISO27001 は、情報セキュリティ管理システムの確立、実装、運甚、監芖、調査、保守及び改善
に関するモデルずなる。この䌁画の目的は、「情報セキュリティ管理システムISMSの確立、
実装、保守及び継続的改善に関する芁件を瀺す」こずにある。その採甚に぀いおは、戊略的な決
定事項ずなる。曎に「組織の情報セキュリティ管理システムの蚭蚈及び実装は、組織の必芁・目
的、セキュリティ芁件、組織的プロセス及び組織の芏暡・構造に圱響される」。芏栌の目次構成
は以䞋のずおり。

 組織の情況
 情報セキュリティの指導
 ISMS のプランニング
 支揎
 運甹
 業瞟評䟡
 改善
 付録 A - 制埡ずその目的リスト
2005 幎版芏栌では、蚈画・実行・確認・行動モデルを倧いに取り入れ、プロセスを構造化し、
OECG ガむドラむンに蚘茉されおいる原則を反映しおいるoecd.org を参照。しかし最新の
2013 幎版では、組織の ISMS 業務遂行状況の蚈枬・評䟡にいっそうの重点が眮かれおいる。

298

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ISO 27002
http://www.iso.org/, http://www.27000.org
ISO 27002 "established guidelines and general principles for initiating, implementing, maintaining, and
improving information security management within an organization." The actual controls listed in the
standard are intended to address the specific requirements identified via a formal risk assessment. The
standard is also intended to provide a guide for the development of "organizational security standards and
effective security management practices and to help build confidence in inter-organizational activities." 81
In 2013 the current version was published. ISO 27002:2013 contains 114 controls, fewer than the 133
documented in the 2005 version. However for additional granularity, these are presented in 14 sections,
rather than the original 11:


Security Policy.



Organization of Information Security.



Human Resource Security.



Asset Management.



Access Control.



Cryptography.



Physical and Environmental Security.



Operations Security.



Communications Security.



Information Systems Acquisition, Development, Maintenance.



Supplier Relationships.



Information Security Incident Management.



Information Security Aspects of Business Continuity.



Compliance.

81

http://www.27000.org/iso-27002.htm.

299

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ISO 27002
http://www.iso.org/, http://www.27000.org
ISO 27002 は「組織内における情報セキュリティ管理の開始、実装、保守及び改善に関するガ
むドラむンず䞀般原則を定めた」。芏栌のリストに含たれおいる実際の制埡は、正芏のリスク評
䟡で定められた具䜓的芁件を取り䞊げおいる。たた「組織のセキュリティ基準及び効果的なセキ
ュリティ管理芏範の発展に向けたガむドを䞎え、組織間掻動ぞの信頌の醞成に資する」こず
を目的ずしおいる。 82
珟行版は 2013 幎に発衚された。ISO 27002:2013 には 114 の制埡が玍められおおり、2005 幎版の
133 よりも枛っおいる。ただしセクションは 11 から次の 14 に増え、きめ现かくなっおいる。

 セクションポリシヌ
 情報セキュリティ組織
 人的資産のセキュリティ
 資産管理
 アクセス制埡
 暗号化
 物理的・環境的セキュリティ
 運甚セキュリティ
 通信セキュリティ
 情報システムの取埗・開発・保守
 サプラむダずの関係
 情報セキュリティむンシデント管理
 情報セキュリティ面から芋た事業継続性
 コンプラむアンス

82

http://www.27000.org/iso-27002.htm.

300

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

International Council on Large Electric Systems (CIGRE)
http://www.cigre.org/
The International Council on Large Electric Systems (CIGRE) is a nonprofit international association based
in France. It has established several study committees to promote and facilitate the international exchange
of knowledge in the electrical industry by identifying recommended practices and developing
recommendations. Three of its study committees focus on control systems:


The objectives of the B3 Substations Committee include the adoption of technological advances in
equipment and systems to achieve increased reliability and availability.



The C2 System Operation and Control Committee focuses on the technical capabilities needed for the
secure and economical operation of existing power systems including control centers and operators.



The D2 Information Systems and Telecommunication for Power Systems Committee monitors
emerging technologies in the industry and evaluates their possible impact. In addition, it focuses on
the security requirements of the information systems and services of control systems.

LOGIIC – Linking the Oil and Gas Industry to Improve Cybersecurity
http://www.dhs.gov/csd-logiic
The LOGIIC (Linking the Oil and Gas Industry to Improve Cybersecurity) program is an ongoing
collaboration of oil and natural gas companies and the DHS Science and Technology Directorate (S&T).
LOGIIC was formed in 2004 to facilitate cooperative research, development, testing, and evaluation
procedures to improve cybersecurity in petroleum industry digital control systems. The program undertakes
collaborative R&D projects to improve the level of cybersecurity in critical systems of interest to the oil
and natural gas sector. The program objective is to promote the interests of the sector while maintaining
impartiality, the independence of the participants, and vendor neutrality. After a successful first project, the
LOGIIC consortium was formally established as a collaboration between DHS, the Automation Federation,
and five of the major oil and gas companies. The LOGIIC program has completed several R&D projects,
and more projects are being planned and started.

301

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

囜際倧電力システム䌚議CIGRE
http://www.cigre.org/
CIGRE はフランスに拠点を眮く非営利囜際機関である。いく぀かの研究委員䌚があり、掚奚芏
範の定矩づけや掚奚事項の策定を通じお、電力業界における囜際的な意芋亀換を促進しおいる。
このうち次の 3 委員䌚が制埡システムに特化しおいる。

 B3 倉電所委員䌚の目的には、装備品やシステムの技術的進歩を取り入れお、信頌性ず可甚
性を確保するこずが含たれる。
 C2 システム運甚制埡委員䌚は、制埡センタヌや操䜜員を含めた既存電力システムの運甚を
セキュアか぀経枈的にするための技術力に重点を眮いおいる。
 D2 電力システム甚情報システム電気通信委員䌚は、業界の新興技術を泚芖し、その圱響を
評䟡する。たた制埡システムの情報システム・サヌビスに関するセキュリティ芁件をも重芖
しおいる。

LOGIIC – サむバヌセキュリティを改善する石油・ガス業界の連携
http://www.dhs.gov/csd-logiic
LOGIICサむバヌセキュリティを改善する石油・ガス業界の連携プログラムは、石油・ガス
䌚瀟及び DHS 科孊技術局S&T間で珟圚進展䞭の協力掻動である。LOGIIC は 2004 幎に制定
され、共同研究・開発・詊隓・評䟡手順を促進し、石油業界のデゞタル制埡システムのサむバヌ
セキュリティ向䞊を目指しおいる。 石油・倩然ガス業界の利益に盎結した重芁システムのサむ
バヌセキュリティレベルを䞊げるため、共同研究・開発を手がけおいる。プログラムの目的は、
メンバヌ間の公平、独立性及びベンダヌの䞭立性を保ち぀぀、業界の利益を促進するこずにある。
最初のプロゞェクトが成功した埌、LOGIIC コン゜ヌシアムが DHS、オヌトメヌション連盟及び
石油・ガス倧手 5 瀟間で正匏に発足した。これたでいく぀かの研究開発プロゞェクトが完了しお
おり、今埌曎に新芏蚈画が予定されおいる。

302

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

National SCADA Test Bed (NSTB)
http://energy.sandia.gov/infrastructure-security/cyber/scada-systems/testbeds/national-scada-testbed/
The National Supervisory Control and Data Acquisition (SCADA) Test Bed is a DOE Office of Electricity
Delivery and Energy Reliability (OE) -sponsored resource to help secure our nation’s energy control
systems. It combines state-of-the-art operational system testing facilities with research, development, and
training to discover and address critical security vulnerabilities and threats to the energy sector.
Working in partnership with the energy sector, the National SCADA Test Bed seeks to:


Identify and mitigate existing vulnerabilities.



Facilitate development of security standards.



Serve as an independent entity to test SCADA systems and related control system technologies.



Identify and promote best cybersecurity practices.



Increase awareness of control systems security within the energy sector.



Develop advanced control system architectures and technologies that are more secure and robust.

Partners in the NSTB include Idaho National Laboratory, Sandia National Laboratories, Argonne National
Laboratory, Pacific Northwest National Laboratory, and the National Institute of Standards and Technology.

303

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

米囜 SCADA テストベッドNSTB
http://energy.sandia.gov/infrastructure-security/cyber/scada-systems/testbeds/national-scada-testbed/
米囜 SCADA テストベッドは、DOE の配電゚ネルギヌ信頌性局OEの支揎によるリ゜ヌスで、
米囜の゚ネルギヌ制埡システムのセキュア化を助成する。最新の運甚システム詊隓斜蚭ず研究・
開発・蚓緎を䞀䜓化しお、゚ネルギヌ業界にずっおの重倧なセキュリティ脆匱性・脅嚁を芋぀け
お取り組む。
゚ネルギヌ業界ず連携し、米囜 SCADA テストベッドは以䞋を目暙ずしおいる。

 既存の脆匱性を明らかにしお緩和する
 セキュリティ芏栌の開発を促進する
 SCADA システム技術及び関連制埡システム技術の独立詊隓機関ずしお機胜する
 サむバヌセキュリティの最良芏範を定めお促進する
 ゚ネルギヌ業界における制埡システムセキュリティに察する意識を高める
 よりセキュアで匷固な最新制埡システムアヌキテクチャ及び技術を開発する
NSTB にはアむダホ囜立研究所、サンディア囜立研究所、アヌゎン囜立研究所、倪平掋北西囜立
研究所及び米囜暙準技術局が加盟しおいる。

304

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

NIST Special Publication 800 Series Security Guidelines
http://csrc.nist.gov/publications/nistpubs/index.html
The NIST Special Publication 800 series of documents on information technology reports on the NIST
Information Technology Laboratory (ITL) research, guidance, and outreach efforts in computer security,
and its collaborative activities with industry, government, and academic organizations. Focus areas include
cryptographic technology and applications, advanced authentication, public key infrastructure,
internetworking security, criteria and assurance, and security management and support. In addition to NIST
SP 800-82, the following is a listing of some additional 800 series documents that have significant
relevance to the ICS security community. These as well as many others are available through the URL
listed above.


NIST SP 800-18 Revision 1, Guide for Developing Security Plans for Federal Information Systems
[19].



NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments [79].



NIST SP 800-37 Revision 1, Guide for Applying the Risk Management Framework to Federal
Information Systems: A Security Life Cycle Approach [21].



NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information
System View [20].



NIST SP 800-40 Revision 3, Guide to Enterprise Patch Management Technologies [40].



NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy [85].



NIST SP 800-48 Revision 1, Guide to Securing Legacy IEEE 802.11 Wireless Networks 0.



NIST SP 800-50, Building an Information Technology Security Awareness and Training Program [61].



NIST SP 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and
Organizations [22].



NIST SP 800-53A Revision 4, Assessing Security and Privacy Controls in Federal Information
Systems and Organizations: Building Effective Security Assessment Plans [23].



NIST SP 800-61 Revision 2, Computer Security Incident Handling Guide [59].



NIST SP 800-63-2, Electronic Authentication Guideline [53].



NIST SP 800-64 Revision 2, Security Considerations in the Information System Development Life
Cycle [46].



NIST SP 800-70 Revision 2, National Checklist Program for IT Products: Guidelines for Checklist
Users and Developers [26].



NIST SP 800-77, Guide to IPsec VPNs [74].



NIST SP 800-83 Revision 1, Guide to Malware Incident Prevention and Handling for Desktops and
Laptops [60].



NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response [93].

305

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

NIST 特別出版物 800 シリヌズセキュリティガむドラむン
http://csrc.nist.gov/publications/nistpubs/index.html
SP800 シリヌズは、情報技術研究所ITLの研究、ガむダンス及びコンピュヌタセキュリティ
における取組䞊びに産官孊ずの連携に関する情報技術報告曞である。重点分野ずしお暗号技術ず
その応甚、最新認蚌、公開鍵むンフラ、むンタヌネット䜜業のセキュリティ、基準・保蚌、セキ
ュリティ管理・支揎等が含たれおいる。NIST SP 800-82 に加えお、ICS セキュリティ関係者に倧
いに関係するものずしお、次の 800 シリヌズ文曞も甚意されおいる。これら以倖にも、䞊蚘の
URL から利甚できるものがある。

 NIST SP 800-18 第 1 版『連邊情報システム甚セキュリティ蚈画曞の䜜成ガむド』[19]
 NIST SP 800-30 第 1 版『リスク評䟡実斜ガむド』[79]
 NIST SP 800-37 第 1 版『連邊情報システムぞのリスク管理䜓系適甚ガむドセキュリティラ
むフサむクルアプロヌチ』[21]
 NIST SP 800-39『情報セキュリティリスクの管理組織、任務及び情報システム抂説』[20]
 NIST SP 800-40 第 3 版『䌁業パッチ管理技術ガむド』[40]
 NIST SP 800-41 第 1 版『ファむアりォヌル及びファむアりォヌルポリシヌガむドラむン』
[85]
 NIST SP 800-48 第 1 版『レガシヌIEEE 802.11 ワむダレスネットワヌクセキュリティガむ
ド』[0]
 NIST SP 800-50『情報技術セキュリティ意識蚓緎プログラムの構築』[61]
 NIST SP 800-53 第 4 版『連邊情報システム・組織のセキュリティ・プラむバシヌ管理』[22]
 NIST SP 800-53A 第 4 版『連邊情報システム・組織のセキュリティ・プラむバシヌ管理評
䟡効果的セキュリティ評䟡蚈画曞の䜜成』[23]
 NIST SP 800-61 第 2 版『コンピュヌタセキュリティむンシデント凊理ガむド』[59]
 NIST SP 800-63-2『電子認蚌ガむドラむン』[53]
 NIST SP 800-64 第 2 版『情報システム開発ラむフサむクルにおけるセキュリティ考慮事項』
[46]
 NIST SP 800-70 第 2 版『IT 補品の囜家チェックリストプログラムチェックリストナヌザ・
開発者ガむドラむン』[26]
 NIST SP 800-77『IPSsec VPNs ガむド』[74]
 NIST SP 800-83 第 1 版『マルり゚アむンシデント防止及びデスクトップ・ラップトップの取
扱ガむド』[60]
 NIST SP 800-86『むンシデント察応時の調査技術の適甚ガむド』[93]

306

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY



NIST SP 800-88 Revision 1, Guidelines for Media Sanitization [78].



NIST SP 800-92, Guide to Computer Security Log Management [68].



NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) [55].



NIST SP 800-97, Establishing Robust Security Networks: a Guide to IEEE 802.11i [64].



NIST SP 800-100, Information Security Handbook: A Guide for Managers [27].



NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices [94].



NIST SP 800-115, Technical Guide to Information Security Testing and Assessment [41].



NIST SP 800-123, Guide to General Server Security [95].



NIST SP 800-127, Guide to Securing WiMAX Wireless Communications [96].



NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems
[97].



NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information
Systems and Organizations [81].

NIST Cybersecurity Framework
http://www.nist.gov/cyberframework/index.cfm
Recognizing that the national and economic security of the United States depends on the reliable
functioning of critical infrastructure, the President issued Executive Order 13636, Improving Critical
Infrastructure Cybersecurity, in February 2013 [83]. It directed NIST to work with stakeholders to develop
a voluntary framework – based on existing standards, guidelines, and practices – for reducing cyber risks to
critical infrastructure.
NIST released the first version of the Framework for Improving Critical Infrastructure Cybersecurity
on February 12, 2014 [83]. The Framework, created through collaboration between industry and
government, consists of standards, guidelines, and practices to promote the protection of critical
infrastructure. The prioritized, flexible, repeatable, and cost-effective approach of the Framework helps
owners and operators of critical infrastructure to manage cybersecurity-related risk.
The Department of Homeland Security's Critical Infrastructure Cyber Community C³ Voluntary Program
helps align critical infrastructure owners and operators with existing resources that will assist their efforts
to adopt the Cybersecurity Framework and manage their cyber risks. Learn more about the C³ Voluntary
Program by visiting: www.dhs.gov/ccubedvp.
NIST has also issued a companion Roadmap that discusses NIST's next steps with the Framework and
identifies key areas of cybersecurity development, alignment, and collaboration.

307

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

 NIST SP 800-88 第 1 版『メディアサニタむズガむドラむン』[78]
 NIST SP 800-92『コンピュヌタセキュリティログ管理ガむド』[68]
 NIST SP 800-94『䟵入怜知防止システムIDPSガむド』[55]
 NIST SP 800-97『匷固なセキュリティネットワヌクの構築IEEE 802.11i ガむド』[64]
 NIST SP 800-100『情報セキュリティハンドブック管理者ガむド』[27]
 NIST SP 800-111『゚ンドナヌザデバむス甚ストレヌゞ暗号化技術ガむド』[94]
 NIST SP 800-115『情報セキュリティ詊隓評䟡技術ガむド』[41]
 NIST SP 800-123『䞀般的サヌバセキュリティガむド』[95]
 NIST SP 800-127『WiMAX ワむダレス通信ガむド』[96]
 NIST SP 800-128『情報システムのセキュリティ重芖蚭定管理ガむド』[97]
 NIST SP 800-137『連邊情報システム・組織の情報セキュリティ継続監芖』[81]

NIST のサむバヌセキュリティ䜓系
http://www.nist.gov/cyberframework/index.cfm
米囜の囜家・経枈安党保障は、信頌性の高い重芁むンフラの機胜に䟝存しおいるずしお、倧統領
呜什 13636 重芁むンフラサむバヌセキュリティの改善を 2013 幎 2 月に発什した[83]。その䞭で
NIST は関係者ず連携し、既存の芏栌、ガむドラむン及び芏範を基に、重芁むンフラぞのサむバ
ヌリスクの軜枛に向けお、自発的な䜓系を構築するよう呜ぜられた。
NIST は 2014 幎 2 月 14 日、重芁むンフラサむバヌセキュリティ改善䜓系第 1 版を発衚した[83]。
産・官間の連携で構築された䜓系は、重芁むンフラ保護を促進する芏栌、ガむドラむン及び芏範
から構成されおいる。優先順䜍づけされ柔軟性があり、反埩可胜で費甚効果の高い取組により、
重芁むンフラの所有者及び運甚者がサむバヌセキュリティ関連リスクを管理できるように支揎す
る。
囜土安党保障省の重芁むンフラサむバヌコミュニティ C³ 任意プログラムは、重芁むンフラの保
有者及び操䜜員が既存リ゜ヌスを掻甚し぀぀、サむバヌセキュリティ䜓系を取り入れ、サむバヌ
リスクを管理する資ずなる。C³ 任意プログラムの詳现は以䞋の URL にある。
www.dhs.gov/ccubedvp.
NIST は手匕きずなるロヌドマップも発衚し、この䜓系の次なるステップに぀いお説明し、サむ
バヌセキュリティ開発・調敎・連携の䞻な分野を明らかにしおいる。

308

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

NIST Industrial Control System Security Project
http://csrc.nist.gov/groups/SMA/fisma/ics/
As part of the continuing effort to provide effective security standards and guidance to federal agencies and
their contractors in support of the Federal Information Security Management Act and as part of the effort to
protect the nation's critical infrastructure, NIST continues to work with public and private sector entities on
sector-specific security issues.
Industrial and process control systems are an integral part of the US critical infrastructure and the
protection of those systems is a priority for the federal government. This project intends to build upon the
current FISMA security standards and provide targeted extensions and/or interpretations of those standards
for industrial and process controls systems where needed. Since many industrial and process controls
systems are supporting private sector organizations, NIST will collaborate with ongoing standards efforts
addressing these sector-specific types of systems.
NIST Cybersecurity for Manufacturing Systems Project
http://www.nist.gov/el/isd/cs/csms.cfm
Smart manufacturing systems need to be protected from vulnerabilities that may arise as a result of their
increased connectivity, use of wireless networks and sensors, and use of widespread information
technology. Manufacturers are hesitant to adopt common security technologies, such as encryption and
device authentication, due to concern for potential negative performance impacts in their systems. This is
exacerbated by a threat environment that has changed dramatically with the appearance of advanced
persistent attacks specifically targeting industrial systems, such as Stuxnet. This project will develop a
cybersecurity risk management framework with supporting guidelines, methods, metrics and tools to enable
manufacturers, technology providers, and solution providers to assess and assure cybersecurity for smart
manufacturing systems. The cybersecurity risk management framework and methodology will stimulate
manufacturer adoption and enable effective use of security technologies, leading to smart manufacturing
systems that offer security, reliability, resilience and continuity in the face of disruption and major incidents.
NIST Cybersecurity for Smart Grid Systems Project
http://www.nist.gov/el/smartgrid/cybersg.cfm
Smart grid cybersecurity must address not only deliberate attacks, such as from disgruntled employees,
industrial espionage, and terrorists, but also inadvertent compromises of the information infrastructure due
to user errors, equipment failures, and natural disasters. The Smart Grid Interoperability Panel (SGIP)
Cybersecurity Committee (SGCC), which is led and managed by the NIST Information Technology
Laboratory (ITL), Computer Security Division, is moving forward in fiscal year 2014 to address the critical
cybersecurity needs in the areas of Advanced Metering Infrastructure (AMI) security requirements, cloud
computing, supply chain, and privacy recommendations related to emerging standards. This project will
provide foundational cybersecurity guidance, cybersecurity reviews of standards and requirements,
outreach, and foster collaborations in the cross-cutting issue of cybersecurity in the smart grid.

309

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

NIST 産業甚制埡システムセキュリティプロゞェクト
http://csrc.nist.gov/groups/SMA/fisma/ics/
連邊政府機関及び連邊情報セキュリティ管理法を支える契玄業者に効果的なセキュリティ芏栌・
ガむダンスを提䟛する継続的な取組の䞀環ずしお、たた囜の重芁むンフラを保護する取組の䞀環
ずしお、NIST は官民諞団䜓ず連携しお、業界固有のセキュリティ問題ず継続的に協働しおいる。
産業甚システム及びプロセス制埡システムは、米囜の重芁むンフラの䞍可欠な䞀郚であり、これ
らシステムに察する保護は、連邊政府の優先的課題である。本プロゞェクトは、珟行 FISMA セ
キュリティ芏栌を基瀎ずしお、これら産業甚システム及びプロセス制埡システムの芏栌を、必芁
に応じお拡匵・解釈するこずを䞻県ずしおいる。倚くの産業甚システム及びプロセス制埡システ
ムは、民間業界組織を支えおいるため、NIST は、このような業界固有のシステムを察象ずした
珟行芏栌の取組ず連携しおいる。
生産システムプロゞェクト甚 NIST サむバヌセキュリティ
http://www.nist.gov/el/isd/cs/csms.cfm
スマヌト生産システムは、接続数、ワむダレスネットワヌク/センサの利甚及び広範な情報技術
の利甚が増えた結果、脆匱性が生じたため保護が必芁ずなる。メヌカヌは、システムにマむナス
の圱響が出るこずを恐れお、暗号化やデバむス認蚌ずいった、䞀般的なセキュリティ技術の採甚
に消極的である。Stuxnet のような産業甚システムに特化した執拗な攻撃が出珟したために、脅
嚁環境が激倉したこずずあいたっお、いっそう事態は悪化する。本プロゞェクトでは、根拠ずな
るガむドラむン、方法、評䟡基準及びツヌルの䌎ったサむバヌセキュリティリスク管理䜓系を策
定し、メヌカヌ、技術提䟛者及び゜リュヌション提䟛者がスマヌト生産システム甚サむバヌセキ
ュリティの評䟡・保蚌を実斜できるようにする。サむバヌセキュリティリスク管理䜓系及び方法
論は、メヌカヌがセキュリティ技術を採甚しお有効利甚する匟みを぀け、䞭断や倧芏暡むンシデ
ント時のセキュリティ、信頌性、柔軟性及び継続性を確保できるスマヌト生産システムぞ導くも
のずなる。
スマヌトグリッドシステムプロゞェクト甚 NIST サむバヌセキュリティ
http://www.nist.gov/el/smartgrid/cybersg.cfm
スマヌトグリッドサむバヌセキュリティでは、䞍満を抱いた埓業員、産業スパむ、テロリスト等
による蚈画的な攻撃だけでなく、ナヌザの過誀、装備品障害及び自然灜害に起因する情報むンフ
ラの想定倖の機胜䜎䞋も怜蚎察象にしなければならない。NIST の情報技術研究所ITLコンピ
ュヌタセキュリティ郚の監督䞋にあるスマヌトグリッド盞互運甚パネルSGIPサむバヌセキュ
リティ委員䌚は 2014 䌚蚈幎床に、最新蚈量むンフラAMIセキュリティ芁件、クラりドコン
ピュヌティング、サプラむチェヌン及び新興芏栌関連民間掚奚事項分野での重芁サむバヌセキュ
リティの必芁性の怜蚎に向けお掻動を開始した。本プロゞェクトは基本的サむバヌセキュリティ
ガむダンス、芏栌及び芁件のサむバヌセキュリティ調査に぀いお蚘述し、スマヌトグリッドの分
野暪断的なサむバヌセキュリティ問題での連携を構築する。

310

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

NIST Smart Grid System Testbed Facility
http://www.nist.gov/el/smartgrid/sgtf.cfm
NIST is charged by the 2007 Energy Independence and Security Act (EISA) with facilitation of
interoperability standards to enable successful implementation of the evolving cyber-physical national
electric grid system known as the smart grid (SG). The Smart Grid Testbed Facility will create a unique set
of interconnected and interacting labs in several key measurement areas—contiguously located on the
NIST Gaithersburg site—that will accelerate the development of SG interoperability standards by
providing a combined testbed platform for system measurements, characterization of smart grid protocols,
and validation of SG standards, with particular emphasis on microgrids. (A microgrid is defined as a subset
of the grid which has the capability of being quickly disconnected from, and functioning independently of,
the larger grid.) Measurements will include eight areas: power conditioning, synchrophasor metrology,
cybersecurity, precision time synchronization, electric power metering, modeling/evaluation of SG
communications, sensor interfaces, and energy storage. The testbed will serve as a core Smart Grid
Program research facility to address measurement needs of the evolving SG industrial community including
the measurement and validation issues.
North American Electric Reliability Corporation (NERC)
http://www.nerc.com/
NERC’s mission is to improve the reliability and security of the bulk power system in North America. To
achieve that, NERC develops and enforces reliability standards; monitors the bulk power system; assesses
future adequacy; audits owners, operators, and users for preparedness; and educates and trains industry
personnel. NERC is a self-regulatory organization that relies on the diverse and collective expertise of
industry participants. As the Electric Reliability Organization, NERC is subject to audit by the U.S. Federal
Energy Regulatory Commission and governmental authorities in Canada
NERC has issued a set of cybersecurity standards to reduce the risk of compromise to electrical generation
resources and high-voltage transmission systems above 100 kV, also referred to as bulk electric systems.
Bulk electric systems include Balancing Authorities, Reliability Coordinators, Interchange Authorities,
Transmission Providers, Transmission Owners, Transmission Operators, Generation Owners, Generation
Operators, and Load Serving Entities. The cybersecurity standards include audit measures and levels of
non-compliance that can be tied to penalties.
The set of NERC cybersecurity Standards includes the following:


CIP-002, Cyber Security - Critical Cyber Asset Identification.



CIP-003, Cyber Security - Security Management Controls.



CIP-004, Cyber Security - Personnel & Training.



CIP-005, Cyber Security - Electronic Security Perimeter(s).



CIP-006, Cyber Security - Physical Security of Critical Cyber Assets.



CIP-007, Cyber Security - Systems Security Management.



CIP-008, Cyber Security - Incident Reporting and Response Planning.



CIP-009, Cyber Security - Recovery Plans for Critical Cyber Assets.

311

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

NIST スマヌトグリッドシステムテストベッド斜蚭
http://www.nist.gov/el/smartgrid/sgtf.cfm
NIST は 2007 幎、゚ネルギヌ独立セキュリティ法EISAにより、スマヌトグリッドSGず
しお知られる囜のサむバヌ物理的配電システムを効果的に実装するための盞互運甚性芏栌を䜜成
するよう矩務づけられた。スマヌトグリッドシステムテストベッド斜蚭は、盞互接続され盞互䜜
甚する䞀連の研究所矀をいく぀かの重芁蚈枬゚リア内に構築しNIST のゲむサヌズバヌグ斜蚭
に隣接、システム蚈枬、スマヌトグリッドプロトコルの特性分析及び SG 芏栌怜蚌甚の結合テ
ストベッドプラットホヌムを提䟛するこずにより、特にマむクログリッドを重点ずした SG 盞互
運甚性芏栌の䜜成を急いでいる。マむクログリッドは、倧芏暡グリッドから迅速に分離しお、
独立した機胜胜力を発揮するグリッドサブセットず定矩される。次の 8 項目を蚈枬する。電力
状態、シンクロフェヌザ蚈枬、サむバヌセキュリティ、粟密時間同期、電力枬定、SG 通信のモ
デリング・評䟡、センサむンタヌフェむス及び゚ネルギヌ保存。テストベッドは、䞭栞的なスマ
ヌトグリッドプログラム研究斜蚭ずしお機胜し、蚈枬・怜蚌問題を含めお進展䞭の、SG 産業共
同䜓の蚈枬ニヌズに察応しおいる。
北米電力信頌性評議䌚NERC
http://www.nerc.com/
NERC の任務は、北米における倧電力システムの信頌性ずセキュリティを改善するこずにある。
このため NERC は、信頌性芏栌の䜜成・斜行、倧電力システムの監芖、将来的な劥圓性の評䟡、
保有者・操䜜員・ナヌザの即応性監査、業界職員の教育蚓緎を行っおいる。NERC は自䞻芏制組
織で、業界参加者の倚様か぀包括的専門知識に䟝存しおいる。電力信頌性組織ずしお、米囜の連
邊゚ネルギヌ芏制委員䌚ずカナダの行政圓局の監査を受ける矩務がある。
発電リ゜ヌス及び 100kV 超高電圧送電システム倧電力システムずもいうの機胜䜎䞋リスクを
軜枛するため、NERC は䞀連のサむバヌセキュリティ芏栌を発衚しおきた。倧電力システには事
業者Balancing Authorities、信頌性コヌディネヌタ、送電プロバむダ、送電保有者、送電事業
者、発電保有者、発電事業者及び小売事業者が含たれる。サむバヌセキュリティ芏栌には、監査
手段及び眰則に結び぀く各玚ノンコンプラむアンスが含たれる。
䞀連の NERC サむバヌセキュリティ芏栌には以䞋のものがある。

 CIP-002『サむバヌセキュリティ - 重芁サむバヌ資産の識別』
 CIP-003『サむバヌセキュリティ - セキュリティ管理察策』
 CIP-004『サむバヌセキュリティ - 職員及び蚓緎』
 CIP-005『サむバヌセキュリティ - 電子セキュリティの呚蟺』
 CIP-006『サむバヌセキュリティ - 重芁サむバヌ資産の物理的セキュリティ』
 CIP-007『サむバヌセキュリティ - システムセキュリティ管理』
 CIP-008『サむバヌセキュリティ - むンシデントの届出及び察応蚈画の立案』
 CIP-009『サむバヌセキュリティ - 重芁サむバヌ資産埩旧蚈画』

312

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SANS ICS Security Courses
http://ics.sans.org/
The ICS curriculum provides hands-on training courses focused on Attacking and Defending ICS
environments. These courses equip both security professionals and control system engineers with the
knowledge and skills they need to safeguard our critical infrastructures.
The Global Industrial Cyber Security Professional (GICSP) is the newest certification in the Global
Information Assurance Certification (GIAC) family and focuses on the foundational knowledge of securing
critical infrastructure assets. The GICSP bridges together IT, engineering and cybersecurity to achieve
security for industrial control systems from design through retirement.
Smart Grid Interoperability Panel (SGIP) Cyber Security Working Group (CSWG)
http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/CyberSecurityCTG
The primary goal of the working group is to develop an overall cybersecurity strategy for the Smart Grid
that includes a risk mitigation strategy to ensure interoperability of solutions across different
domains/components of the infrastructure. The cybersecurity strategy needs to address prevention,
detection, response, and recovery. Implementation of a cybersecurity strategy requires the definition and
implementation of an overall cybersecurity risk assessment process for the Smart Grid.
The working group’s effort is documented in NIST Interagency Report (NISTIR) 7628 Revision 1,
Guidelines for Smart Grid Cybersecurity [98].

313

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

SANS ICS セキュリティ課皋
http://ics.sans.org/
ICS カリキュラムは、ICS 環境に察する攻撃ず防埡に特化した実地蚓緎課皋である。セキュリテ
ィ専門員ず制埡システム゚ンゞニア双方に、重芁むンフラを守るための知識ず技量を教瀺する。
䞖界産業サむバヌセキュリティ専門家GICSPは、䞖界情報保蚌認定曞GIACファミリの
䞭でも最新の認定曞で、重芁むンフラ資産のセキュリティに関する基本知識を重芖しおいる。
GICSP は、IT、゚ンゞニアリング及びサむバヌセキュリティの架け橋ずなり、蚭蚈から甚途廃止
たで、産業甚制埡システムのセキュリティを実珟する。

スマヌトグリッド盞互運甚性パネルSGIPサむバヌセキュリティ䜜業グルヌプCSWG
http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/CyberSecurityCTG
䜜業グルヌプの䞻な目的は、スマヌトグリッドのサむバヌセキュリティ戊略を策定するこずにあ
り、それにはむンフラの皮々の領域・コンポヌネントにたたがる゜リュヌションの盞互運甚性を
確保するためのリスク緩和策も含たれる。サむバヌセキュリティ戊略は、予防・怜知・察応・埩
旧を取り䞊げる必芁がある。サむバヌセキュリティ戊略を実斜するには、スマヌトグリッドの党
般的サむバヌセキュリティリスク評䟡プロセスを明らかにしお、実斜する必芁がある。
䜜業グルヌプの取組は、NIST 政府機関間報告曞NISTIR7628 第 1 版『スマヌトグリッドサむ
バヌセキュリティガむドラむン』に蚘茉されおいる[98]。

314

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix E—ICS Security Capabilities and Tools
This section provides an overview of security capabilities that are available to or being developed in
support of the ICS community. There are several security products that are marketed specifically for ICS,
while others are general IT security products that are being used with ICS. Many of the products available
offer “single point solutions,” where a single security product offers multiple levels of protection. In
addition to available products, this section also discusses some research and development work towards
new products and technologies. Each organization should make a risk-based determination whether to
employ the security capabilities and tools mentioned in this appendix.
Data Diode
A data diode (also referred to as a unidirectional gateway, deterministic one-way boundary device or
unidirectional network) is a network appliance or device allowing data to travel only in one direction, used
in guaranteeing information security or protection of critical digital systems, such as industrial control
systems, from inbound cyber attacks. While use of these devices is common in high security environments
such as defense, where they serve as connections between two or more networks of differing security
classifications, the technology is also being used to enforce one-way communications outbound from
critical digital systems to untrusted networks.
Encryption
Encryption protects the confidentiality of data by encoding the data to ensure that only the intended
recipient can decode it. There are some commercially available encryption products designed specifically
for ICS applications, as well as general encryption products that support basic serial and Ethernet-based
communications.
Firewalls
Firewalls are commonly used to segregate networks to protect and isolate ICS. These implementations use
commercially available firewalls that are focused on Internet and corporate application layer protocols and
are not equipped to handle ICS protocols. Research was performed by an IT security vendor in 2003 to
develop a Modbus-based firewall that allows policy decisions to be made on Modbus/TCP header values
just as traditional firewalls filter on TCP/UDP ports and IP addresses [76]. There are currently several
firewalls available for ICS.
Intrusion Detection and Prevention
Intrusion detection systems (IDS) and intrusion prevention systems (IPS) are being deployed on ICS
networks and components to detect well-known cyber attacks. Network IDS products monitor network
traffic and use various detection methods, such as comparing portions of the traffic to signatures of known
attacks. In contrast, host intrusion detection uses software loaded on a host computer, often with attack
signatures, to monitor ongoing events and data on a computer system for possible exploits. IPS products
take intrusion detection a step further by automatically acting on detected exploits to attempt to stop them
[57].
The required task of a security team to constantly monitor, evaluate, and quickly respond to intrusion
detection events is sometimes contracted to a managed security service provider (MSSP). MSSPs have
correlation and analysis engines to process and reduce the vast amounts of events logged per day to a small
subset that needs to be manually evaluated. There are also correlation and analysis engine products
available to large organizations wanting to perform this function in-house. Security information and event

315

SP800-82 第 2 版

付録 E

産業甚制埡システムICSセキュリティガむド

ICS セキュリティ機胜及びツヌル

このセクションでは、ICS 共同䜓が利甚できるセキュリティ機胜や、珟圚開発䞭のものに぀いお
抂説する。垂堎には ICS に特化したセキュリティ補品がいく぀かあり、ICS で利甚されおいる䞀
般的な IT セキュリティ補品もある。入手可胜な補品の倚くは「単䞀゜リュヌション」で、1 ぀の
セキュリティ補品が倚様なレベルの保護を䞎えおいる。入手可胜な補品に加えお、このセクショ
ンでは、新補品・新技術に向けた研究開発に぀いおもいく぀か取り䞊げる。各組織は、この付録
で蚀及されおいるセキュリティ機胜及びツヌルの採甚の是非に぀いお、リスクに立脚しお刀断す
べきである。
デヌタダむオヌド
デヌタダむオヌド単方向ゲヌトりェむ、決定論的䞀方通行境界デバむス又は単方向ネットワヌ
クずも呌ばれるは、ネットワヌク機噚又はデバむスで、デヌタを䞀方向にのみ流しお、情報セ
キュリティを保蚌し、産業甚制埡システム等の重芁デゞタルシステムを倖郚サむバヌ攻撃から保
護する。このようなデバむスの利甚は、囜防等のハむセキュリティ環境では普通に芋られ、異皮
セキュリティ区分を有する、2 ぀以䞊のネットワヌク間の接続を確立し、その技術は、重芁デゞ
タルシステムから倖郚の信頌できないネットワヌクに向かう単方向の通信にも利甚される。
暗号化
暗号化は、デヌタをコヌド化しお所期の受信者だけが埩号できるようにするこずで、デヌタの機
密性を保護する。ICS 甚途に特化した垂販の暗号化補品がいく぀かあり、基本的なシリアル及び
Ethernet ベヌスの通信に察応した汎甚暗号化補品もある。
ファむアりォヌル
ファむアりォヌルは通垞、ネットワヌクを分離しお ICS を保護・隔離するために䜿甚する。実装
は、むンタヌネット及び䌁業アプリケヌション局プロトコルに特化し、ICS プロトコルは凊理し
ない垂販のファむアりォヌルを䜿甚しお行う。2003 幎に IT セキュリティベンダヌが Modbus ベ
ヌスファむアりォヌルの開発に向けお研究を行った。これは埓来のファむアりォヌルが
TCP/UDP ポヌト及び IP アドレスでフィルタリングを行うように、Modbus/TCP ヘッダヌ倀でポ
リシヌ決定を行うこずができる。珟圚 ICS 甚に利甚できるファむアりォヌルがいく぀かある。
䟵入怜知及び防止
䟵入怜知システムIDS及び䟵入防止システムIPSは、既知のサむバヌ攻撃を怜知するため、
ICS ネットワヌク及びコンポヌネントに展開されおいる。ネットワヌク IDS 補品はネットワヌク
トラフィックを監芖し、既知の攻撃のトラフィックシグネチャの䞀郚を比范するなど、皮々の怜
知方法を利甚しおいる。察照的にホスト䟵入怜知では、ホストコンピュヌタにむンストヌルした
゜フトり゚アを利甚し、倚くは攻撃シグネチャを参考にしお、コンピュヌタシステム䞊で進行䞭
の事象及びデヌタを監芖し、悪甚の有無を怜知する。IPS 補品は、䟵入怜知から䞀歩進めお、怜
知した悪甚の䞭止を詊みる[57]。
セキュリティチヌムに求められる䟵入怜知の垞続監芖・評䟡・迅速察応ずいう業務は、管理セキ
ュリティサヌビスプロバむダMSSPに委蚗されるこずもある。MSSP の盞関分析゚ンゞンは、
毎日蚘録される膚倧な事象を凊理しお小さなサブセットにし、マニュアル操䜜で評䟡できるよう
にする。この機胜を瀟内で果たしたい倧䌁業向けに、盞関分析゚ンゞン補品が甚意されおいる。
セキュリティ情報・事象管理SIEM補品を利甚しお、IDS 及び IPS ログの事象のほか、他のコ
ンピュヌタシステム、アプリケヌション、むンフラ装備品その他ハヌドり゚ア/゜フトり゚アの
監査ログを監芖・分析・盞関しお、䟵入のもくろみを怜出しおいる組織もある。

316

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

management (SIEM) products are used in some organizations to monitor, analyze, and correlate events
from IDS and IPS logs, as well as audit logs from other computer systems, applications, infrastructure
equipment, and other hardware and software, to look for intrusion attempts.
IDS and IPS vendors are developing and incorporating attack signatures for various ICS protocols such as
Modbus, DNP3, and ICCP [58]. Snort rules have been developed for Modbus TCP, DNP3, and ICCP.
Snort is an open source network intrusion detection and prevention system using a rule-driven language to
perform signature, protocol, and anomaly-based inspections. Rules for DNP3 and Modbus protocols have
also been added to the Bro IDS platform.
As with any software added to an ICS component, the addition of host IDS or IPS software could affect
system performance. IPSs are commonplace in today’s information security industry, but can be very
resource intensive. These systems have the ability to automatically reconfigure systems if an intrusion
attempt is identified. This automated and fast reaction is designed to prevent successful exploits; however,
an automated tool such as this could be used by an adversary to adversely affect the operation on an ICS by
shutting down segments of a network or server. False positives can also hinder ICS operation.
Malware/Antivirus Software
Because early malware threats were primarily viruses, the software to detect and remove malware has
historically been called “antivirus software,” even though it can detect many types of malware. Antivirus
software is used to counter the threats of malware by evaluating files on a computer’s storage devices
(some tools also detect malware in real-time at the network perimeter and/or on the user’s workstation)
against an inventory of malware signature files. If one of the files on a computer matches the profile of
known malware, the malware is removed through a disinfection process so it cannot infect other local files
or communicate across a network to infect other files on other computers. There are also techniques
available to identify unknown malware “in-the-wild” when a signature file is not yet available.
Many end-users and vendors of ICS are recommending the use of COTS antivirus software with their
systems and have even developed installation and configuration guidance based on their own laboratory
testing. Some ICS vendors recommend the use of antivirus software with their products, but offer little to
no guidance. Some end users and vendors are hesitant to use antivirus software due to fears that its use
would cause ICS performance problems or even failure. NIST and Sandia National Laboratories (SNL)
conducted a study and produced a report aimed at helping ICS owners/operators to deploy antivirus
software and to minimize and assess performance impacts of workstation and server-based antivirus
products. This study assembled ICS-based antivirus knowledge and serves as a starting point or a
secondary resource when installing, configuring, running, and maintaining antivirus software on an ICS
[56]. In many cases, performance impacts can be reduced through configuration settings as well as antivirus
scanning and maintenance scheduling outside of the antivirus software practices recommended for typical
IT systems.
In summary, COTS antivirus software can be used successfully on most ICS components. However, special
ICS specific considerations should be taken into account during the selection, installation, configuration,
operational, and maintenance procedures. ICS end-users should consult with the ICS vendors regarding the
use of antivirus software.

317

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

IDS 及び IPS ベンダヌは、Modbus、DNP3 及び ICCP 等、皮々の ICS プロトコルの攻撃シグネチ
ャを䜜成し、組み蟌んでいる[58]。Modbus TCP、DNP3 及び ICCP 向けに Snort ルヌルが䜜成され
おいる。Snort ずはオヌプン゜ヌスネットワヌク䟵入怜知防止システムのこずで、ルヌルドリブ
ン蚀語を䜿甚しお、シグネチャ、プロトコル及び異状を䞻䜓に怜査を行う。DNP3 及び Modbus
プロトコルのルヌルも Bro IDS プラットホヌムに远加されおいる。
ICS コンポヌネントに远加される他の゜フトり゚アず同様、ホスト IDS 又は IPS ゜フトり゚アの
远加は、システムパフォヌマンスに圱響するこずがある。IPSs は昚今の情報セキュリティ業界で
は普通に芋られるが、極めお資源を消費する。これらのシステムでは、䟵入のもくろみが怜知さ
れるず、システム蚭定を自動的に倉曎する胜力が備わっおいる。このような自動迅速察応は悪甚
を防止するためのものであるが、攻撃偎に逆甚され、ネットワヌクやサヌバのセグメントを切断
するこずにより、ICS 運甚に悪圱響が及ぶ堎合がある。擬陜性によっおも ICS 運甚が阻害される。
マルり゚ア/アンチりむルス゜フトり゚ア
初期のマルり゚ア脅嚁は䞻にりむルスであったため、マルり゚ア怜出・排陀゜フトり゚アは、
皮々のマルり゚アに察する怜出胜力を持぀ものの、埓来「アンチりむルス゜フトり゚ア」ず呌ば
れおきた。アンチりむルス゜フトり゚アは、マルり゚アシグネチャファむルの目録に照らしお、
コンピュヌタのストレヌゞデバむス䞊のファむルを評䟡しツヌルによっおはネットワヌク呚蟺
又はナヌザワヌクステヌション䞊でリアルタむムにマルり゚アを怜出するものもある、マルり
゚アの脅嚁に察抗する。コンピュヌタ䞊のファむルの 1 ぀が既知のマルり゚アのプロファむルに
䞀臎するず、消毒プロセスを経おそのマルり゚アは排陀され、他のロヌカルファむルやネットワ
ヌクを越えた他のコンピュヌタ䞊のファむルぞの感染は生じなくなる。たたシグネチャファむル
がない堎合でも、未知の「野生」マルり゚アを識別する技術も利甚できる。
倚くの ICS ゚ンドナヌザ及びベンダヌは、システムぞの COTS アンチりむルス゜フトり゚アの導
入を掚奚しおおり、独自のラボ詊隓を基に、むンストヌル・蚭定ガむダンスも䜜成しおいる。
ICS ベンダヌによっおは、自瀟補品にアンチりむルス゜フトり゚アの䜿甚を掚奚しおいるものの、
ガむダンスが党く又はほずんど甚意できおいない堎合もある。アンチりむルス゜フトり゚アの利
甚により、ICS のパフォヌマンス問題や障害が発生するのを恐れお、䜿甚に消極的なナヌザやベ
ンダヌもいる。NIST ずサンディア囜立研究所SNLは調査を行い、ICS 保有者・操䜜員向けレ
ポヌトを䜜成し、アンチりむルス゜フトり゚アの展開を助け、ワヌクステヌション/サヌバベヌ
スアンチりむルス補品のパフォヌマンス圱響を最小化し、評䟡する資ずしおいる。本研究により
ICS ベヌスのアンチりむルス知芋がたずたり、ICS ぞのアンチりむルス゜フトり゚アのむンスト
ヌル・蚭定・実行・保守を行う際の出発点又は二次リ゜ヌスずなっおいる[56]。倚くの堎合、蚭
定やアンチりむルススキャニング・保守スケゞュヌルを、䞀般的な IT システムで掚奚されおい
るアンチりむルス゜フトり゚ア芏範を離れお実斜するこずで、パフォヌマンス圱響を枛らすこず
ができる。
たずめずしお、COTS アンチりむルス゜フトり゚アは、ほずんどの ICS コンポヌネントで䜿甚可
胜である。ただしその遞定・むンストヌル・蚭定・運甚・保守手順に際しおは、特殊な ICS 固有
の考慮事項を怜蚎に入れるべきである。ICS ゚ンドナヌザは、アンチりむルス゜フトり゚アの䜿
甚に関しお、ICS ベンダヌに盞談すべきである。

318

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Vulnerability Assessment Tools
There are many tools available for performing network vulnerability assessments for typical IT networks;
however, the impacts these tools may have on the operation of an ICS should be carefully considered [77].
The additional traffic and exploits used during active vulnerability and penetration testing, combined with
the limited resources of many ICS, have been known to cause ICS to malfunction. As guidance in this area,
SNL developed a preferred list of vulnerability and penetration testing techniques for ICS [77]. These are
less intrusive methods, passive instead of active, to collect the majority of information that is often queried
by automated vulnerability and penetration testing tools. These methods are intended to allow collection of
the necessary vulnerability information without the risk of causing a failure while testing.
Sophia is a patent-pending, passive, real-time diagnostic and security tool designed and built specifically
for control systems professionals. Sophia builds and maintains an ICS network fingerprint and continuously
monitors activity against it, with white, gray and black-listing capabilities, alerting its managers of any
abnormal activity for further investigation, monitoring and/or action. Beta testing conducted by the Battelle
Energy Alliance (BEA) at the Idaho National Laboratories (INL) recently concluded with a group of over
30 participants, including major utilities and control system vendors. Those Beta participants reported
immediate benefits in the fingerprinting process and longer-term benefits in monitoring, securing, and
making on-going modifications to ICS configurations during the Beta testing period. Beta participants, as
well as non-participants, who have been following the development of Sophia by BEA/INL, have long
expressed interest in obtaining commercial grade Sophia software, services and support. Beta testing has
proven that this suite of tools offers unique capabilities, including visualization of activity and tailored
reporting to meet customer needs.
Shodan is a search engine that lets you find specific types of computers (routers, servers, etc.) on the
Internet using a variety of filters. Some have also described it as a search engine of service banners, which
are meta-data the server sends back to the client. This can be information about the server software, what
options the service supports, a welcome message or anything else that the client can find out before
interacting with the server. Shodan users are able to find systems including traffic lights, security cameras,
home heating systems as well as control systems. Users can use Shodan to determine if any of the devices
on their ICS are accessible from the internet.
The Cyber Security Evaluation Tool (CSET) is a Department of Homeland Security (DHS) product that
assists organizations in protecting their key national cyber assets. It was developed under the direction of
the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) by cybersecurity
experts and with assistance from NIST. This tool provides users with a systematic and repeatable approach
for assessing the security posture of their cyber systems and networks. It includes both high-level and
detailed questions related to all industrial control and IT systems. CSET is a desktop software tool that
guides users through a step-by-step process to assess their control system and information technology
network security practices against recognized industry standards. The output from CSET is a prioritized list
of recommendations for improving the cybersecurity posture of the organization's enterprise and industrial
control cyber systems. The tool derives the recommendations from a database of cybersecurity standards,
guidelines, and practices. Each recommendation is linked to a set of actions that can be applied to enhance
cybersecurity controls. CSET has been designed for easy installation and use on a stand-alone laptop or
workstation. It incorporates a variety of available standards from organizations such as NIST, NERC, TSA,
DoD, and others. When the tool user selects one or more of the standards, CSET will open a set of
questions to be answered. The answers to these questions will be compared against a selected security
assurance level, and a detailed report will be generated to show areas for potential improvement. CSET
provides an excellent means to perform a self-assessment of the security posture of your control system
environment.

319

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

脆匱性評䟡ツヌル
䞀般的な IT ネットワヌクの脆匱性評䟡甚ツヌルは倚数あるが、これらが ICS の運甚に及がす圱
響を慎重に怜蚎すべきである[77]。倚くの ICS のリ゜ヌスを制限した、アクティブ脆匱性・ペネ
トレヌション・テストにおいお、付加的なトラフィックや脆匱性の悪甚があるず、ICS に障害の
出るこずが分かっおいる。この分野でのガむダンスずしお、SNL は ICS の奜たしい脆匱性・ペネ
トレヌション・テスト技術リストを䜜成した[77]。これらはより䟵襲性の少ない方法で、アクテ
ィブずいうよりもパッシブであり、自動化脆匱性・ペネトレヌション・テストツヌルから照䌚を
受けるこずが倚い情報の倧半を収集できる。このような方法は、詊隓時に障害を発生させるこず
なく、必芁な脆匱性情報を収集できるようになっおいる。
Sophia は特蚱申請䞭のパッシブ、リアルタむム蚺断・セキュリティツヌルで、制埡システム専門
員甚に蚭蚈・構築されおいる。ICS ネットワヌクフィンガヌプリントを生成しお維持し、それに
察する掻動を垞続的に監芖する。ホワむトリスト、グレヌリスト及びブラックリストの䜜成胜力
があり、詳现な調査・監芖・行動を芁する異垞掻動に぀いお管理者に譊報を発する。アむダホ囜
立研究所INLにおいお Battelle Energy AllianceBEAによるベヌタ詊隓が行われ、倧手公共
䌁業や制埡システムベンダヌ等 30 を超えるグルヌプが参加しお、このほど終了した。
参加者は、フィンガヌプリント凊理には圓面の利益があり、ベヌタ詊隓期間䞭の ICS 蚭定の監
芖・セキュリティ確保・蚭定倉曎には長期的利益があるず報告しおいる。参加者のみならず、
BEA/INL による Sophia の成り行きを泚芖しおきた非参加者も、垂販レベルの Sophia ゜フトり゚
ア、サヌビス及びサポヌトに関心を寄せおいる。ベヌタ詊隓により、このツヌルには掻動の芖芚
化、顧客需芁に合わせたカスタマむズ化報告等のナニヌクな機胜があるこずが実蚌されおいる。
Shodan は怜玢゚ンゞンで、皮々のフィルタを䜿甚しお、むンタヌネット䞊の特殊なコンピュヌ
タルヌタ、サヌバ等を探し出すこずができる。サヌバがクラむアントに送り返すメタデヌタ
である、サヌビスバナヌの怜玢゚ンゞンず評する向きもある。これはサヌバ゜フトり゚ア、サヌ
ビスの察応オプション、りェルカムメッセヌゞ、サヌバずの盞互䜜甚を行う前にクラむアントが
怜玢できるその他に぀いおの情報ずなる。Shodan ナヌザは信号機、セキュリティカメラ、家庭
暖房システム、制埡システム等のシステムを怜玢できる。これを利甚すれば、むンタヌネット経
由でアクセス可胜な ICS 䞊のデバむスを刀別できる。
サむバヌセキュリティ評䟡ツヌル(CSET)は、組織が囜の重芁サむバヌ資産を守るのを支揎する囜
土安党保障省(DHS)の補品である。DHS 産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)
の指導䞋で、NIST の支揎を埗おサむバヌセキュリティ専門家が開発した。サむバヌシステム及
びネットワヌクのセキュリティ状態を評䟡する際の䜓系的か぀反埩的な取組が可胜ずなる。あら
ゆる産業甚制埡及び IT システムに関係した高床の詳现な疑問に答えおいる。CSET はデスクトッ
プ゜フトり゚アツヌルで、制埡システム及び情報技術ネットワヌクセキュリティ芏範を、広く認
められた業界基準に照らしお、段階的に評䟡するこずができる。CSET により、組織の䌁業・産
業甚制埡サむバヌシステムのサむバヌセキュリティ状態を改善するための優先的掚奚事項リスト
を䜜成できる。このツヌルは、サむバヌセキュリティ基準、ガむドラむン及び芏範デヌタベヌス
から掚奚事項を導き出す。それぞれの掚奚事項は、サむバヌセキュリティ制埡の拡匵に適甚可胜
な䞀連の行動に結び぀いおいる。CSET は、スタンドアロヌンラップトップやワヌクステヌショ
ンに、簡単にむンストヌルしお利甚できるようになっおいる。NIST、NERC、TSA、DoD その他
の組織から入手可胜な皮々の基準が取りたずめおられおいる。ツヌルのナヌザがこれら基準のい
ずれかを遞択するず、䞀連の質問が提瀺される。質問ぞの回答を、遞択されたセキュリティ保蚌
レベルず照らし合わせ、改善できる分野を瀺した詳现なレポヌトが䜜成されるようになっおいる。
CSET は、制埡システム環境のセキュリティ状態を自己評䟡できる優れた手段ずなる。

320

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SamuraiSTFU is the Samurai Project’s Security Testing Framework for Utilities and takes best in breed
security tools for traditional network and web penetration testing and adds specialized tools for embedded
and RF testing and mixes in energy sector context, documentation and sample files. It also includes
emulators for SCADA, Smart Meters, and other types of energy sector systems to provide leverage for a
full test lab.
ICS owners must make the individuals using vulnerability assessment tools aware of the criticality of
continuous operation and the risks involved with performing these tests on operational systems. It may be
possible to mitigate these risks by performing tests on ICS components such as redundant servers or
independent test systems in a laboratory setting. Laboratory tests can be used to screen out test procedures
that might harm the operational system. Even with very good configuration management to assure that the
test system is highly representative, tests on the actual system are likely to uncover flaws not represented in
the laboratory.

321

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

SamuraiSTFU は、ナヌティリティ甚サムラむプロゞェクトのセキュリティ詊隓䜓系で、䌝統的な
ネットワヌク/りェブペネトレヌション・テスト甚セキュリティツヌルの最良のものを䜿甚し、
組蟌み/RF 詊隓甚の特殊ツヌルを加え、゚ネルギヌ業界においお文曞ずファむルを䞀䜓化する。
たた SCADA、スマヌトメヌタヌその他゚ネルギヌ業界のシステム甚゚ミュレヌタを組み蟌んで、
党面詊隓ラボに匟みを付けおいる。
ICS 保有者は、脆匱性評䟡ツヌルを䜿甚しお、個々人が継続運甚の重芁性ず、こうした詊隓を運
甚システムで行う堎合のリスクを認識させなければならない。冗長サヌバやラボ環境にある独立
詊隓システム等の ICS コンポヌネントで詊隓を行うこずにより、このようなリスクを緩和するこ
ずができる。ラボ詊隓を行えば、運甚システムに有害な詊隓手順を排陀できる。極めお良奜な蚭
定管理で詊隓システムが代衚的なものになるようにしおも、実際のシステムで行う詊隓は、ラボ
では分からない欠陥を怜出できるこずがある。

322

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix F—References
[1] Fraser, Roy E., Process Measurement and Control:Introduction to Sensors, Communication,
Adjustment, and Control, Upper Saddle River, New Jersey:Prentice-Hall, Inc., 2001.
[2] Falco, Joe, et al., IT Security for Industrial Control Systems, NIST Internal Report (NISTIR) 6859,
February 2002, http://www.nist.gov/customcf/get_pdf.cfm?pub_id=821684 [accessed 4/16/15].
[3] Bailey, David, and Edwin Wright, Practical SCADA for Industry, Vancouver: IDC Technologies, 2003.
[4] Boyer, Stuart, SCADA:Supervisory Control and Data Acquisition.4th ed. Research Triangle Park,
North Carolina:International Society of Automation, 2010.
[5] American Gas Association, AGA Report No. 12, Cryptographic Protection of SCADA
Communications, Part 1:Background, Policies and Test Plan, September, March 14, 2006.
[6] Erickson, Kelvin, and John Hedrick, Plantwide Process Control, New York:John Wiley & Sons, Inc.,
1999.
[7] Berge, Jonas, Fieldbuses for Process Control:Engineering, Operation, and Maintenance, Research
Triangle Park, North Carolina:ISA, 2002.
[8] Peerenboom, James, “Infrastructure Interdependencies:Overview of Concepts and Terminology,”
invited paper, NSF/OSTP Workshop on Critical Infrastructure:Needs in Interdisciplinary Research and
Graduate Training, Washington, D.C., June 14-15, 2001.
[9] Rinaldi, Steven, et al., “Identifying, Understanding, and Analyzing Critical Infrastructure
Interdependencies,” IEEE Control Systems Magazine, (December 2001), pp. 11-25,
http://dx.doi.org/10.1109/37.969131.
[10] GAO-04-354, Critical Infrastructure Protection:Challenges and Efforts to Secure Control Systems,
U.S. GAO, 2004, http://www.gao.gov/new.items/d04354.pdf.
[11] Weiss, Joseph, “Current Status of Cybersecurity of Control Systems,” Presentation to Georgia Tech
Protective Relay Conference, May 8, 2003.
[12] Keeney, Michelle et al., Insider Threat Study:Computer System Sabotage in Critical Infrastructure
Sectors, United States Secret Service and Carnegie Mellon Software Institute, 2005,
http://www.cert.org/archive/pdf/insidercross051105.pdf.
[13] Federal Information Security Management Act of 2002, Pub.L. 107-347 (Title III), 116 Stat 2946,
http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf [accessed 4/16/15].
[14] Federal Information Security Management Act Implementation Project [Web site],
http://csrc.nist.gov/groups/SMA/fisma/index.html [accessed 4/16/15].
[15] U.S. Department of Commerce, Federal Information Processing Standards (FIPS) Publication 199,
Standards for Security Categorization of Federal Information and Information Systems, February 2004,
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf [accessed 4/16/15].

323

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

324

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[16] U.S. Department of Commerce, Federal Information Processing Standards (FIPS) Publication 200,
Minimum Security Requirements for Federal Information and Information Systems, March 2006,
http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf [accessed 4/16/15].
[17] Knapp, Eric, Industrial Network Security:Securing Critical Infrastructure Networks for Smart Grid,
SCADA, and Other Industrial Control Systems, Waltham, Massachusetts:Syngress, 2011.
[18] U.S. Government Accountability Office (GAO), GAO-15-6, Federal Facility Cybersecurity:DHS and
GSA Should Address Cyber Risk to Building and Access Control Systems, December 12, 2014,
http://www.gao.gov/products/GAO-15-6 [accessed 4/16/15].
[19] Swanson, Marianne, et al., NIST SP 800-18 Revision 1, Guide for Developing Security Plans for
Federal Information Systems, February 2006,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-18
[accessed 4/16/15].
[20] Joint Task Force Transformation Initiative, NIST SP 800-39, Managing Information Security
Risk:Organization, Mission, and Information System View, March 2011,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-39
[accessed 4/16/15].
[21] Joint Task Force Transformation Initiative, NIST SP 800-37 Revision 1, Guide for Applying the Risk
Management Framework to Federal Information Systems: a Security Life Cycle Approach, February
2010 (updated June 5, 2014), http://dx.doi.org/10.6028/NIST.SP.800-37r1.
[22] Joint Task Force Transformation Initiative, NIST SP 800-53 Revision 4, Security and Privacy
Controls for Federal Information Systems and Organizations, April 2013 (updated January 22, 2015),
http://dx.doi.org/10.6028/NIST.SP.800-53r4.
[23] Joint Task Force Transformation Initiative, NIST SP 800-53A Revision 4, Assessing Security and
Privacy Controls in Federal Information Systems and Organizations:Building Effective Security
Assessment Plans, December 2014 (updated December 18, 2014),
http://dx.doi.org/10.6028/NIST.SP.800-53Ar4.
[24] Barker, William, NIST SP 800-59, Guideline for Identifying an Information System as a National
Security System, August 2003,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-59
[accessed 4/16/15].
[25] Stine, Kevin, et al., NIST SP 800-60 Revision 1 (2 vols.), Guide for Mapping Types of Information and
Information systems to Security Categories, August 2008,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-60
[accessed 4/16/15].
[26] Quinn, Stephen, et al., NIST SP 800-70 Revision 2, National Checklist Program for IT
Products:Guidelines for Checklist Users and Developers, February 2011,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-70
[accessed 4/16/15].

325

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

326

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[27] Bowen, Pauline, et al., NIST SP 800-100, Information Security Handbook:A Guide for Managers,
October 2006 (updated March 7, 2007),
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-100
[accessed 4/16/15].
[28] NIST Security Configurations Checklists Program for IT Products [Web site],
http://web.nvd.nist.gov/view/ncp/repository [accessed 4/16/15].
[29] Stamp, Jason, et al., Common Vulnerabilities in Critical Infrastructure Control Systems, Sandia
National Laboratories, 2003,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.3264&rep=rep1&type=pdf.
[30] SCADA Security - Advice for CEOs, IT Security Expert Advisory Group (ITSEAG)
[31] Franz, Matthew, Vulnerability Testing of Industrial Network Devices, Critical Infrastructure Assurance
Group, Cisco Systems, 2003, http://blogfranz.googlecode.com/files/franz-isa-device-testing-oct03.pdf.
[32] Duggan, David, et al., Penetration Testing of Industrial Control Systems, Sandia National Laboratories,
Report No SAND2005-2846P, 2005.
[33] President’s Critical Infrastructure Protection Board, and U.S. Department of Energy, Office of Energy
Assurance, 21 Steps to Improve Cybersecurity of SCADA Networks, [2002],
http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/21_Steps_-_SCADA.pdf [accessed
4/16/15].
[34] ISA-62443[multiple parts], Security for Industrial Automation and Control Systems, Research Triangle
Park, North Carolina:International Society of Automation,
http://isa99.isa.org/ISA99%20Wiki/WP_List.aspx [accessed 4/16/15].
[35] Centre for the Protection of National Infrastructure (CPNI), Firewall Deployment for SCADA and
Process Control Networks:Good Practice Guide, February 15, 2005,
http://energy.gov/sites/prod/files/Good%20Practices%20Guide%20for%20Firewall%20Deployment.pd
f [accessed 4/16/15].
[36] U.S. Department of Homeland Security, Recommended Practice:Improving Industrial Control Systems
Cybersecurity with Defense-in-Depth Strategies, October 2009, https://ics-cert.uscert.gov/sites/default/files/recommended_practices/Defense_in_Depth_Oct09.pdf [accessed 4/16/15].
[37] Industrial Automation Open Networking Association (IAONA), The IAONA Handbook for Network
Security, Version 1.3, 2005, http://www.iaona.org/pictures/files/1122888138-IAONA_HNS_1_3reduced_050725.pdf [accessed 4/16/15].
[38] U.S. Department of Homeland Security, Common Cybersecurity Vulnerabilities in Industrial Control
Systems, May 2011, https://ics-cert.uscert.gov/sites/default/files/recommended_practices/DHS_Common_Cybersecurity_Vulnerabilities_I
CS_2010.pdf [accessed 4/16/15].
[39] NIST SP 800-12, An Introduction to Computer Security:The NIST Handbook, 1995,
http://csrc.nist.gov/publications/PubsSPs.html.

327

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

328

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[40] Souppaya, Murugiah, and Karen Scarfone, NIST SP 800-40 Revision 3, Guide to Enterprise Patch
Management Technologies, July 2013, http://dx.doi.org/10.6028/NIST.SP.800-40r3.
[41] Scarfone, Karen, et al., NIST SP 800-115, Technical Guide to Information Security Testing and
Assessment, September 2008,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-115
[accessed 4/16/15].
[42] Roback, Edward, NIST SP 800-23, Guidelines to Federal Organizations on Security Assurance and
Acquisition/ Use of Tested/Evaluated Products, August 2000,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-23
[accessed 4/16/15].
[43] Stoneburner, Gary, et al., NIST SP 800-27 Revision A, Engineering Principles for Information
Technology Security (A Baseline for Achieving Security), June 2004,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-27A
[accessed 4/16/15].
[44] Grance, Tim, et al., NIST SP 800-35, Guide to Information Technology Security Services, October
2003,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-35
[accessed 4/16/15].
[45] Grance, Tim, et al., NIST SP 800-36, Guide to Selecting Information Technology Security Products,
October 2003,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-36
[accessed 4/16/15].
[46] Grance, Tim, et al., NIST SP 800-64 Revision 2, Security Considerations in the System Development
Life Cycle, October 2008,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-64
[accessed 4/16/15].
[47] Hash, Joan, et al., NIST SP 800-65, Integrating IT Security into the Capital Planning and Investment
Control Process, January 2005,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-65
[accessed 4/16/15].
[48] U.S. Department of Homeland Security, Department of Homeland Security:Cyber Security
Procurement Language for Control Systems, September 2009 https://ics-cert.uscert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf [accessed 4/16/15].
[49] Dray, James, et al., NIST SP 800-73-3, Interfaces for Personal Identity Verification (4 parts), February
2010,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-73
[accessed 4/16/15].
[50] Grother, Patrick, et al., NIST SP 800-76-2, Biometric Data Specification for Personal Identity
Verification, July 2013, http://dx.doi.org/10.6028/NIST.SP.800-76-2.

329

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

330

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[51] Kuhn, D. Richard, et al., NIST SP 800-46 Revision 1, Guide to Enterprise Telework and Remote
Access Security, June 2009,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-46
[accessed 4/16/15].
[52] Swanson, Marianne, et al., NIST SP 800-34 Revision 1, Contingency Planning Guide for Federal
Information Systems, May 2010,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-34
[accessed 4/16/15].
[53] Burr, William, et al., NIST SP 800-63-2, Electronic Authentication Guideline, August 2013,
http://dx.doi.org/10.6028/NIST.SP.800-63-2.
[54] Bace, Rebecca, and Mell, Peter, NIST SP 800-31, Intrusion Detection Systems, 2001,
http://csrc.nist.gov/publications/PubsSPs.html.
[55] Scarfone, Karen, and Peter Mell, NIST SP 800-94, Guide to Intrusion Detection and Prevention
Systems (IDPS), February 2007,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-94
[accessed 4/16/15].
[56] Falco, Joe, et al., NIST SP 1058, Using Host-based Anti-virus Software on Industrial Control
Systems:Integration Guidance and a Test Methodology for Assessing Performance Impacts, September
18, 2006, http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823596 [accessed 4/16/15].
[57] Peterson, Dale, “Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks,”
ISA Automation West (AUTOWEST 2004), Long Beach, California, April 2004,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.3420&rep=rep1&type=pdf [accessed
4/16/15].
[58] Symantec Corporation, “Symantec Expands SCADA Protection for Electric Utilities,” [press release],
September 14, 2005, http://www.symantec.com/about/news/release/article.jsp?prid=20050914_01
[accessed 4/16/15].
[59] Grance, Tim, et al., NIST SP 800-61 Revision 2, Computer Security Incident Handling Guide, August
2012, http://dx.doi.org/10.6028/NIST.SP.800-61r2.
[60] Mell, Peter, et al., NIST SP 800-83 Revision 1, Guide to Malware Incident Prevention and Handling
for Desktops and Laptops, July 2013, http://dx.doi.org/10.6028/NIST.SP.800-83r1.
[61] Wilson, Mark, and Joan Hash, NIST SP 800-50, Building an Information Technology Security
Awareness and Training Program, October 2003,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-50
[accessed 4/16/15].
[62] Mix, S., Supervisory Control and Data Acquisition (SCADA) Systems Security Guide, Electric Power
Research Institute (EPRI), 2003.

331

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

332

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[63] Scarfone, Karen, et al., NIST SP 800-48 Revision 1, Guide to Securing Legacy IEEE 802.11 Wireless
Networks, July 2008,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-48
[accessed 4/16/15].
[64] Frankel, Sheila, et al, NIST SP 800-97, Establishing Wireless Robust Security Networks: a Guide to
IEEE 802.11i, February 2007,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-97
[accessed 4/16/15].
[65] U.S. Department of Commerce, Federal Information Processing Standards (FIPS) Publication 201-2,
Personal Identity Verification (PIV) of Federal Employees and Contractors, August 2013,
http://dx.doi.org/10.6028/NIST.FIPS.201-2.
[66] Dray, James, et al, NIST SP 800-96, PIV Card to Reader Interoperability Guidelines, September 2006,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-96
[accessed 4/16/15].
[67] Polk, W. Timothy, et al, NIST SP 800-78-3, Cryptographic Algorithms and Key Sizes for Personal
Identity Verification, December 2010,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-78
[accessed 4/16/15].
[68] Kent, Karen, and Murugiah Souppaya, NIST SP 800-92, Guide to Computer Security Log
Management, September 2006,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-92
[accessed 4/16/15].
[69] Jansen, Wayne, et al., NIST SP 800-28 Version 2, Guidelines on Active Content and Mobile Code,
March 2008,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-28
[accessed 4/16/15].
[70] Polk, Tim, et al., NIST SP 800-52 Revision 1, Guidelines for the Selection, Configuration, and Use of
Transport Layer Security (TLS) Implementations, April 2014, http://dx.doi.org/10.6028/NIST.SP.80052r1.
[71] Barker, Elaine, et al., NIST SP 800-56A Revision 2, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography, May 2013,
http://dx.doi.org/10.6028/NIST.SP.800-56Ar2.
[72] Baker, Elaine, et al., NIST SP 800-57 (3 parts), Recommendation for Key Management:Part 1 Revision
3, General, July 2012
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#80057pt1; Part 2, Best Practices for Key Management Organization, August 2005,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#80057pt2; Part 3 Revision 1, Application-Specific Key Management Guidance, January 2015,
http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1.

333

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

334

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[73] Kuhn, D. Richard, et al., NIST SP 800-58, Security Considerations for Voice Over IP Systems, January
2005,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-58
[accessed 4/16/15].
[74] Frankel, Sheila, et al., NIST SP 800-77, Guide to IPsec VPNs, December 2005,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-77
[accessed 4/16/15].
[75] Shirey, R., Internet Security Glossary, Version 2, RFC 4949, August 2007, http://www.rfceditor.org/rfc/rfc4949.txt [accessed 4/16/15].
[76] Franz, Matthew, and Venkat Pothamsetty, ModbusFW:Deep Packet Inspection for Industrial Ethernet,
Critical Infrastructure Assurance Group, Cisco Systems, 2004,
http://blogfranz.googlecode.com/files/franz-niscc-modbusfw-may04.pdf [accessed 4/16/15].
[77] Duggan, David, Penetration Testing of Industrial Control Systems, SAND2005-2846P, Sandia
National Laboratories, March 2005, http://energy.sandia.gov/wp/wpcontent/gallery/uploads/sand_2005_2846p.pdf [accessed 4/16/15].
[78] Kissel, Richard, et al., NIST SP 800-88 Revision 1, Guidelines for Media Sanitization, December 2014,
http://dx.doi.org/10.6028/NIST.SP.800-88r1.
[79] Joint Task Force Transformation Initiative, NIST SP 800-30 Revision 1, Guide for Conducting Risk
Assessments, September 2012,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-30
[accessed 4/16/15].
[80] Johnson, Arnold, et al., NIST SP 800-128, Guide for Security-Focused Configuration Management of
Information Systems, August 2011,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-128
[accessed 4/16/15].
[81] Dempsey, Kelley, et al., NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for
Federal Information Systems and Organizations, September 2011,
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-137
[accessed 4/16/15].
[82] Waltermire, David, et al., NIST SP 800-126 Revision 2, The Technical Specification for the Security
Content Automation Protocol (SCAP):SCAP Version 1.2, September 2011 (updated March 19, 2012),
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html#800-126rev2 [accessed 4/16/15].
[83] Executive Order no. 13636, Improving Critical Infrastructure Cybersecurity, DCPD-201300091,
February 12, 2013, http://www.gpo.gov/fdsys/pkg/FR-2013-02-19/pdf/2013-03915.pdf [accessed
4/16/15].

335

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

336

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[84] National Institute of Standards and Technology, Framework for Improving Critical Infrastructure
Cybersecurity, version 1.0, February 12, 2014,
http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf [accessed 4/16/15].
[85] Scarfone, Karen, and Paul Hoffman, NIST SP 800-41 Revision 1, Guidelines on Firewalls and
Firewall Policy, September 2009, http://csrc.nist.gov/publications/PubsSPs.html#800-41 [accessed
4/16/15].
[86] Office of Management and Budget, OMB Memorandum M-07-16, Safeguarding Against and
Responding to the Breach of Personally Identifiable Information, May 22, 2007,
https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2007/m07-16.pdf [accessed 4/16/15].
[87] Office of Management and Budget, OMB Memorandum M-10-22, Guidance for Online Use of Web
Measurement and Customization Technologies, June 25, 2010,
https://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-22.pdf [accessed
4/16/15].
[88] McCallister, Erika, et al., NIST SP 800-122, Guide to Protecting the Confidentiality of Personally
Identifiable Information (PII), April 2010, http://csrc.nist.gov/publications/PubsSPs.html#800-122
[accessed 4/16/15].
[89] Federal Enterprise Architecture Security and Privacy Profile, Version 3.0, September 2010,
https://cio.gov/wp-content/uploads/downloads/2012/09/FEA-Security-Privacy-Profile-v3-09-302010.pdf [accessed 4/16/15].
[90] U.S. Department of Commerce, Federal Information Processing Standards (FIPS) Publication 140-2,
Security Requirements for Cryptographic Modules, May 25, 2001 (Change Notice 2, 12/3/2002),
http://csrc.nist.gov/publications/PubsFIPS.html#140-2 [accessed 4/16/15].
[91] Tracy, Miles, et al., NIST SP 800-45 Version 2, Guidelines on Electronic Mail Security, February
2007, http://csrc.nist.gov/publications/PubsSPs.html#800-45 [accessed 4/16/15].
[92] Grance, Tim, et al., NIST SP 800-47, Security Guide for Interconnecting Information Technology
Systems, August 2002, http://csrc.nist.gov/publications/PubsSPs.html#800-47 [accessed 4/16/15].
[93] Kent, Karen, et al., NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response,
August 2006, http://csrc.nist.gov/publications/PubsSPs.html#800-86 [accessed 4/16/15].
[94] Scarfone, Karen, et al., NIST SP 800-111, Guide to Storage Encryption Technologies for End User
Devices, November 2007, http://csrc.nist.gov/publications/PubsSPs.html#800-111 [accessed 4/16/15].
[95] Scarfone, Karen, et al., NIST SP 800-123, Guide to General Server Security, July 2008,
http://csrc.nist.gov/publications/PubsSPs.html#800-123 [accessed 4/16/15].
[96] Scarfone, Karen, et al., NIST SP 800-127, Guide to Securing WiMAX Wireless Communications,
September 2010, http://csrc.nist.gov/publications/PubsSPs.html#800-127 [accessed 4/16/15].

337

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

338

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

[97] Johnson, Arnold, et al., NIST SP 800-128, Guide for Security-Focused Configuration Management of
Information Systems, August 2011, http://csrc.nist.gov/publications/PubsSPs.html#800-128 [accessed
4/16/15].

[98] Smart Grid Interoperability Panel, Smart Grid Cybersecurity Committee, NISTIR 7628 Revision 1,
Guidelines for Smart Grid Cybersecurity, September 2014, http://dx.doi.org/10.6028/NIST.IR.7628r1
[accessed 4/16/15].
[99] Kissel, Richard (ed.), NISTIR 7298 Revision 2, Glossary of Key Information Security Terms, May
2013, http://dx.doi.org/10.6028/NIST.IR.7298r2 [accessed 4/16/15].

339

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

340

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Appendix G—ICS Overlay
NOTE TO READERS

The ICS overlay is a partial tailoring of the controls and control baselines in SP 800-53, Revision 4,
and adds supplementary guidance specific to ICS. The concept of overlays is introduced in Appendix I
of SP 800-53, Revision 4. The ICS overlay is intended to be applicable to all ICS systems in all
industrial sectors. Further tailoring can be performed to add specificity to a particular sector (e.g.,
pipeline, energy). Ultimately, an overlay may be produced for a specific system (e.g., the XYZ
company). This ICS overlay constitutes supplemental guidance and tailoring for SP 800-53, Revision
4. Please be sure you are looking at the correct version of SP 800-53. Duplicating Appendix F of SP
800-53 would increase the size of this Appendix by over 65 pages. Therefore, the drafting committee
has decided to not duplicate Appendix F. The reader should have SP 800-53, Revision 4 available. The
authoring team also considered that this ICS overlay may serve as a model for other overlays.
Feedback on this Appendix’s structure would be appreciated, especially in the following areas: the
level of abstraction and whether the examples provided in the supplemental guidance are
sufficient/beneficial for implementation.
Since the ICS overlay exists in the context of SP 800-53, Revision 4, it is important to review that
context. SP 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and
Organizations, represents the most comprehensive update to the security controls catalog since its
inception in 2005. This update was motivated principally by the expanding threat space—
characterized by the increasing sophistication of cyber attacks and the operations tempo of adversaries
(i.e., the frequency of such attacks, the professionalism of the attackers, and the persistence of
targeting by attackers). State-of-the-practice security controls and control enhancements have been
developed and integrated into the catalog addressing such areas as: mobile and cloud computing;
applications security; trustworthiness, assurance, and resiliency of information systems; insider threat;
supply chain security; and the advanced persistent threat.
To take advantage of the expanded set of security and privacy controls, and to give organizations
greater flexibility and agility in defending their information systems, the concept of overlays was
introduced in this revision. Overlays provide a structured approach to help organizations tailor security
control baselines and develop specialized security plans that can be applied to specific
missions/business functions, environments of operation, and/or technologies. This specialization
approach is important as the number of threat-driven controls and control enhancements in the catalog
increases and organizations develop risk management strategies to address their specific protection
needs within defined risk tolerances.

341

SP800-82 第 2 版

付録 G

産業甚制埡システムICSセキュリティガむド

ICS オヌバヌレむ
読者ぞの泚蚘

ICS オヌバヌレむは、SP 800-53 第 4 版に瀺される制埡及び制埡ベヌスラむンを郚分的にカスタマ
むズしたもので、ICS に特化した補足ガむダンスずなる。オヌバヌレむの抂念は SP 800-53 第 4
版の付録 I に説明がある。ICS オヌバヌレむは、あらゆる産業界のあらゆる ICS システムに適甚
するようにできおいる。曎にカスタマむズしお、特定の業界向けにするこずもできるパむプラ
むン、゚ネルギヌ等。最終的には、1 ぀のオヌバヌレむを 1 ぀のシステム甚に䜜成できる
XYZ 瀟甚等。ICS オヌバヌレむは、SP 800-53 第 4 版の補足ガむダンスカスタマむズ版ずな
る。該圓する SP 800-53 を䜿甚するよう留意されたい。SP 800-53 の付録 F を再録するず、玙数が
65 ペヌゞ増えるこずになるので、起案委員䌚は耇写しないこずにした。読者は SP 800-53 第 4 版
を手蚱に眮くようにすべきである。たた執筆チヌムは、この ICS オヌバヌレむが他のオヌバヌレ
むのひな圢ずなるようにした。付録の構成、特に抂念化のレベル及び補足ガむダンスの提瀺䟋
は、実装䞊十分で圹立぀かどうかに぀いお、フィヌドバックをいただければ幞いである。
ICS オヌバヌレむは、SP 800-53 第 4 版の文脈に沿っお存圚しおいるため、その文脈を芋盎すこず
は肝芁である。SP 800-53 第 4 版の連邊情報システム・組織のセキュリティ・プラむバシヌ管理
には、2005 幎の抂念化以来のセキュリティ察策カタログに察する包括的な曎新内容が瀺されお
いる。曎新は、サむバヌ攻撃がたすたす巧劙化し、脅嚁が拡倧しおいるこずが䞻な理由である
攻撃の頻床、攻撃偎の専門化、暙的に察する執拗性等。実甚に䟛されるセキュリティ察策や
管理拡匵は、進展を遂げ、次の分野のカタログに組み蟌たれおいる。モバむル/クラりドコンピ
ュヌティング。アプリケヌションセキュリティ。情報システムの信頌性・保蚌・匟力性。むンサ
むダヌ脅嚁。サプラむチェヌンセキュリティ。最新の持続的脅嚁。
拡匵されたセキュリティ/プラむバシヌ管理を利甚し、情報システムを守るための柔軟性ず機敏
性を組織に増し加えるため、オヌバヌレむ抂念がこの版に導入された。オヌバヌレむは系統立っ
た取組で、組織がセキュリティ察策のベヌスラむンを埮調敎し、固有の任務・事業機胜、運甚環
境又は技術に適甚可胜な独自のセキュリティ蚈画曞を䜜成するのを支揎する。脅嚁に察応したカ
タログの管理及びその拡匵件数が増えおおり、各組織はリスク管理戊略を䜜成し、固有の保護ニ
ヌズを芏定のリスクトレランス内で取り䞊げおいるため、この独自化に向けた取組は肝芁であ
る。

342

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Identification
This overlay may be referenced as the NIST Special Publication 800-82 Revision 2 Industrial Control
System Overlay (“NIST SP 800-82 Rev 2 ICS Overlay”). It is based on NIST SP 800-53 Revision 4 [22].
NIST developed this overlay in furtherance of its statutory responsibilities under the Federal Information
Security Modernization Act (FISMA) of 2014 (Public Law 113-283), Presidential Policy Directive (PPD)21 and Executive Order 13636. NIST is responsible for developing standards and guidelines, including
minimum requirements, for providing adequate information security for all agency operations and assets,
but such standards and guidelines shall not apply to national security systems without the express approval
of appropriate federal officials exercising policy authority over such systems. Comments may be directed to
icsoverlaycomments@nist.gov.
Overlay Characteristics
Industrial Control Systems (ICS) are typically used in industries such as electric, water and wastewater, oil
and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete
manufacturing (e.g., automotive, aerospace, and durable goods). Supervisory control and data acquisition
(SCADA) systems are generally used to control dispersed assets using centralized data acquisition and
supervisory control. Distributed Control Systems (DCS) are generally used to control production systems
within a local area such as a factory using supervisory and regulatory control. Programmable Logic
Controllers (PLCs) are generally used for discrete control for specific applications and generally provide
regulatory control. These control systems are vital to the operation of the U.S. critical infrastructures that
are often highly interconnected and mutually dependent systems. It is important to note that approximately
90 percent of the nation's critical infrastructures are privately owned and operated. Federal agencies also
operate many of the ICS mentioned above; other examples include air traffic control and materials handling
(e.g., Postal Service mail handling.)
Applicability
The purpose of this overlay is to provide guidance for securing ICS, including SCADA and DCS systems,
PLCs, and other systems performing industrial control functions. This overlay has been prepared for use by
federal agencies. It may be used by nongovernmental organizations on a voluntary basis.
Overlay Summary
Table G-1 provides a summary of the security controls and control enhancements from NIST SP 800-53
Appendix F [22, App. F] that have been allocated to the initial security control baselines (i.e., Low,
Moderate, and High) along with indications of ICS Supplemental Guidance and ICS tailoring. Controls and
control enhancements for which there is ICS Supplemental Guidance are bolded. If the control baselines
are supplemented by the addition of a control to the baseline, the control or control enhancement is
underlined. If a control or control enhancement is removed from the baseline, the control or control
enhancement is struck out.
Example:
AU-4

Audit Storage Capacity

AU-4 (1)

AU-4 (1)

AU-4 (1)

In this example, ICS Supplemental Guidance was added to Control Enhancement 1 of AU-4 (bolded). In
addition, Control Enhancement 1 of AU-4 was added to the Low, Moderate (Mod), and High baselines
(underlined).

343

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

識別
このオヌバヌレむは NIST SP 800-82 第 2 版産業甚制埡システムオヌバヌレむ(『NIST SP 800-82
第 2 版 ICS オヌバヌレむ』)ず呌ばれるこずがある。これは NIST SP 800-53 第 4 版[22]に基づい
おいる。
NIST は、2014 幎連邊情報匷化法(FISMA)(Public Law 113-283)、倧統領政策指瀺(PPD)-21 及び
倧統領呜什 13636 に埓い、その法的責務を掚進するためにこのオヌバヌレむを䜜成した。NIST
はあらゆる政府機関業務・資産の情報セキュリティを確保するため、最䜎芁件等を含んだ芏栌及
びガむドラむンの䜜成を担圓しおいるが、このような芏栌及びガむドラむンは、このようなシス
テムに察する斜策暩限を持った連邊行政官の明確な承認がなければ、囜のセキュリティシステム
には適甚されない。意芋は次宛に寄せられたい。icsoverlaycomments@nist.gov.
オヌバヌレむの特城
産業甚制埡システムICSは䞀般的に電気、䞊䞋氎、石油・ガス、茞送、化孊、医薬品、パル
プ・補玙、食品・飲料及び組立補造自動車、航空宇宙、耐久消費財等業界で利甚されおいる。
SCADA は、通垞、集䞭デヌタ取埗監芖制埡により、分散化された資産を制埡するために䜿甚する。
DCS は、通垞、ロヌカル゚リア内にある工堎等の生産システムを、監芖・芏制制埡により制埡す
るために䜿甚する。プログラマブル論理コントロヌラPLCは、通垞、特殊甚途での離散制埡
に䜿甚し、芏制制埡を通垞行う。このような制埡システムは、高床に連携・盞互䟝存したシステ
ムずなる、米囜の重芁むンフラの運営に緊芁な圹割を果たしおいる。囜の重芁むンフラのおよそ
90%は、私䌁業が保有し運営しおいる点を銘蚘するのは肝芁である。連邊政府機関も前述の ICS
の倚くを運営しおいるが、そのほかにも航空亀通管制や物流凊理枯湟業務、郵䟿等などがあ
る。
適甚性
このオヌバヌレむの目的は、SCADA システム、DCS システム、PLC その他産業甚制埡機胜を぀か
さどるシステム等、ICS のセキュリティを確保するためのガむダンスずなる。連邊政府機関向け
に準備されおいる。非政府組織が自䞻的に利甚しおもかたわない。
オヌバヌレむのたずめ
è¡š G-1 は、NIST SP 800-53 付録 F[22, App. F]のセキュリティ察策及び管理拡匵をたずめたもの
である。管理拡匵は、圓初のセキュリティ察策ベヌスラむン䜎・䞭・高に、ICS 補足ガむダ
ンス及び ICS のカスタマむズずずもに割り圓おられたものである。ICS 補足ガむダンスのある管
理及び管理拡匵は倪字になっおいる。察策ベヌスラむンに補足管理が远加されおいる堎合、管理
及び管理拡匵に䞋線が付いおいる。管理及び管理拡匵がベヌスラむンから削陀されおいる堎合、
線で消されおいる。
䟋
AU-4

監査ストレヌゞ容量

AU-4 (1)

AU-4 (1)

AU-4 (1)

この䟋では、ICS 補足ガむダンスが管理拡匵 AU-4 の 1倪字に远加されおいる。たた、管理拡
匵 AU-4 の 1 が䜎・䞭・高ベヌスラむンに远加されおいる䞋線。

344

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Table G-1 Security Control Baselines

CNTL

INITIAL CONTROL BASELINES

CONTROL NAME

NO.

LOW

MOD

HIGH

AC-1

Access Control Policy and Procedures

AC-1

AC-1

AC-1

AC-2

Account Management

AC-2

AC-2 (1) (2) (3) (4)

AC-2 (1) (2) (3) (4)

AC-3

Access Enforcement

AC-3

AC-3

AC-4

Information Flow Enforcement

Not Selected

AC-4

AC-4

AC-5

Separation of Duties

Not Selected

AC-5

AC-5

AC-6

Least Privilege

Not Selected

AC-6 (1) (2) (5) (9)

AC-6 (1) (2) (3) (5)

(10)

(9) (10)

AC-7

Unsuccessful Logon Attempts

AC-7

AC-7

AC-7

AC-8

System Use Notification

AC-8

AC-8

AC-8

AC-10

Concurrent Session Control

Not Selected

Not Selected

AC-10

AC-11

Session Lock

Not Selected

AC-11 (1)

AC-11 (1)

AC-12

Session Termination

Not Selected

AC-12

AC-12

AC-14

Permitted Actions without Identification or

AC-14

AC-14

AC-14

(5) (11) (12) (13)
AC-3

Authentication
AC-17

Remote Access

AC-17

AC-17 (1) (2) (3) (4)

AC-17 (1) (2) (3) (4)

AC-18

Wireless Access

AC-18

AC-18 (1)

AC-18 (1) (4) (5)

AC-19

Access Control for Mobile Devices

AC-19

AC-19 (5)

AC-19 (5)

AC-20

Use of External Information Systems

AC-20

AC-20 (1) (2)

AC-20 (1) (2)

AC-21

Collaboration and Information Sharing

AC-21

AC-21

AC-21

AC-22

Publicly Accessible Content

AC-22

AC-22

AC-22

AT-1

Security Awareness and Training Policy and

AT-1

AT-1

AT-1

Procedures
AT-2

Security Awareness Training

AT-2

AT-2 (2)

AT-2 (2)

AT-3

Role-Based Security Training

AT-3

AT-3

AT-3

AT-4

Security Training Records

AT-4

AT-4

AT-4

AU-1

Audit and Accountability Policy and

AU-1

AU-1

AU-1

AU-2

AU-2 (3)

AU-2 (3)

AU-3

AU-3 (1)

AU-3 (1) (2)

AU-4 (1)

AU-4 (1)

AU-4 (1)

Procedures
AU-2

Audit Events

AU-3

Content of Audit Records

AU-4

Audit Storage Capacity

AU-5

Response to Audit Processing Failures

AU-5

AU-5

AU-5 (1) (2)

AU-6

Audit Review, Analysis, and Reporting

AU-6

AU-6 (1) (3)

AU-6 (1) (3) (5) (6)

AU-7

Audit Reduction and Report Generation

Not Selected

AU-7 (1)

AU-7 (1)

AU-8

Time Stamps

AU-8

AU-8 (1)

AU-8 (1)

AU-9

Protection of Audit Information

AU-9

AU-9 (4)

AU-9 (2) (3) (4)

AU-10

Non-repudiation

Not Selected

Not Selected

AU-10

AU-11

Audit Record Retention

AU-11

AU-11

AU-11

345

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

è¡š G-1 セキュリティ察策ベヌスラむン
管理番号

管理名

AC-1
AC-2

アクセス制埡ポリシヌ・手順
アカりント管理

AC-3
AC-4
AC-5
AC-6

䜎

圓初の察策ベヌスラむン
äž­

AC-1
AC-2

AC-1
AC-2 (1) (2)
(3) (4)

アクセス斜行
情報フロヌ斜行
任務の分割
最小暩限

AC-3
未遞択
未遞択
未遞択

AC-7
AC-8
AC-10
AC-11
AC-12
AC-14
AC-17

ログむン倱敗
システム利甚通知
珟行セッション管理
セッションロック
セッション終了
識別・認蚌のない蚱可枈み行為
リモヌトアクセス

AC-7
AC-8
未遞択
未遞択
未遞択
AC-14
AC-17

AC-3
AC-4
AC-5
AC-6 (1) (2)
(5) (9) (10)
AC-7
AC-8
未遞択

AC-18

ワむダレスアクセス

AC-18

AC-11 (1)
AC-12
AC-14
AC-17 (1) (2)
(3) (4)
AC-18 (1)

AC-19
AC-20
AC-21
AC-22
AT-1
AT-2
AT-3
AT-4
AU-1
AU-2
AU-3
AU-4
AU-5
AU-6

モバむルデバむス甚アクセス制埡
倖郚情報システムの利甚
連携・情報共有
公開コンテンツ
セキュリティ意識・蚓緎ポリシヌ・手順
セキュリティ意識蚓緎
圹割ベヌスセキュリティ蚓緎
セキュリティ蚓緎蚘録
監査・説明責任ポリシヌ・手順
監査事象
監査蚘録内容
監査ストレヌゞ容量
監査凊理䞍備ぞの察応
監査の審査・分析・報告

AC-19
AC-20
AC-21
AC-22
AT-1
AT-2
AT-3
AT-4
AU-1
AU-2
AU-3
AU-4 (1)
AU-5
AU-6

AC-19 (5)
AC-20 (1) (2)
AC-21
AC-22
AT-1
AT-2 (2)
AT-3
AT-4
AU-1
AU-2 (3)
AU-3 (1)
AU-4 (1)
AU-5
AU-6 (1) (3)

AU-7
AU-8
AU-9
AU-10
AU-11

監査削枛・報告曞䜜成
タむムスタンプ
監査情報の保護
吊認防止
監査蚘録保留

未遞択

AU-7 (1)
AU-8 (1)
AU-9 (4)
未遞択
AU-11

AU-8
AU-9
未遞択
AU-11

346

高

AC-1
AC-2 (1) (2)
(3) (4) (5) (11)
(12) (13)
AC-3
AC-4
AC-5
AC-6 (1) (2)
(3) (5) (9) (10)
AC-7
AC-8
AC-10
AC-11 (1)
AC-12
AC-14
AC-17 (1) (2)
(3) (4)
AC-18 (1) (4)
(5)
AC-19 (5)
AC-20 (1) (2)
AC-21
AC-22
AT-1
AT-2 (2)
AT-3
AT-4
AU-1
AU-2 (3)
AU-3 (1) (2)
AU-4 (1)
AU-5 (1) (2)
AU-6 (1) (3) (5)
(6)
AU-7 (1)
AU-8 (1)
AU-9 (2) (3) (4)
AU-10
AU-11

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AU-12

Audit Generation

AU-12

AU-12

AU-12 (1) (3)

CA-1

Security Assessment and Authorization

CA-1

CA-1

CA-1

Policies and Procedures
CA-2

Security Assessments

CA-2

CA-2 (1)

CA-2 (1) (2)

CA-3

System Interconnections

CA-3

CA-3 (5)

CA-3 (5)

CA-5

Plan of Action and Milestones

CA-5

CA-5

CA-5

CA-6

Security Authorization

CA-6

CA-6

CA-6

CA-7

Continuous Monitoring

CA-7

CA-7 (1)

CA-7 (1)

CA-8

Penetration Testing

Not Selected

Not Selected

CA-8

CA-9

Internal System Connections

CA-9

CA-9

CA-9

CM-1

Configuration Management Policy and

CM-1

CM-1

CM-1

Procedures
CM-2

Baseline Configuration

CM-3

Configuration Change Control

CM-4

Security Impact Analysis

CM-5

Access Restrictions for Change

CM-6

Configuration Settings

CM-7

Least Functionality

CM-8

Information System Component Inventory

CM-2

CM-2 (1) (3) (7)

CM-2 (1) (2) (3) (7)

Not Selected

CM-3 (2)

CM-3 (1) (2)

CM-4

CM-4

CM-4 (1)

Not Selected

CM-5

CM-5 (1) (2) (3)

CM-6

CM-6

CM-6 (1) (2)

CM-7 (1)

CM-7 (1) (2) (4) (5)

CM-7 (1) (2) (5)

CM-8

CM-8 (1) (3) (5)

CM-8 (1) (2) (3) (4)
(5)

CM-9

Configuration Management Plan

Not Selected

CM-9

CM-9

CM-10

Software Usage Restrictions

CM-10

CM-10

CM-10

CM-11

User-Installed Software

CM-11

CM-11

CM-11

CP-1

Contingency Planning Policy and Procedures

CP-1

CP-1

CP-1

CP-2

Contingency Plan

CP-2

CP-2 (1) (3) (8)

CP-2 (1) (2) (3) (4)
(5) (8)

CP-3

Contingency Training

CP-3

CP-3

CP-3 (1)

CP-4

Contingency Plan Testing

CP-4

CP-4 (1)

CP-4 (1) (2)

CP-6

Alternate Storage Site

Not Selected

CP-6 (1) (3)

CP-6 (1) (2) (3)

CP-7

Alternate Processing Site

Not Selected

CP-7 (1) (2) (3)

CP-7 (1) (2) (3) (4)

CP-8

Telecommunications Services

Not Selected

CP-8 (1) (2)

CP-8 (1) (2) (3) (4)

CP-9

Information System Backup

CP-9

CP-9 (1)

CP-9 (1) (2) (3) (5)

CP-10

Information System Recovery and

CP-10

CP-10 (2)

CP-10 (2) (4)

CP-12

CP-12

CP-12

IA-1

IA-1

IA-1

IA-2 (1) (12)

IA-2 (1) (2) (3) (8)

IA-2 (1) (2) (3) (4)

(11) (12)

(8) (9) (11) (12)

IA-3

IA-3 (1) (4)

IA-3 (1) (4)

Reconstitution
CP-12

Safe Mode

IA-1

Identification and Authentication Policy and
Procedures

IA-2

Identification and Authentication
(Organizational Users)

IA-3

Device Identification and Authentication

IA-4

Identifier Management

IA-5

Authenticator Management

IA-4

IA-4

IA-4

IA-5 (1) (11)

IA-5 (1) (2) (3) (11)

IA-5 (1) (2) (3) (11)

347

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

CA-2
CA-3
CA-5
CA-6
CA-7
CA-8
CA-9
CM-1
CM-2

監査䜜成
セキュリティ評䟡・暩限付䞎ポリシヌ・
手順
セキュリティ評䟡
システム盞互連接
行動・マむルストヌン蚈画曞
セキュリティ暩限
継続監芖
ペネトレヌション・テスト
内郚システム接続
蚭定管理ポリシヌ・手順
ベヌスラむン蚭定

CM-3
CM-4
CM-5
CM-6
CM-7

蚭定倉曎管理
接続圱響分析
倉曎甚アクセス制限
構成蚭定
最䜎限機胜

CM-8

情報システムコンポヌネント目録

CM-9
CM-10
CM-11
CP-1
CP-2

蚭定管理蚈画曞
゜フトり゚ア䜿甚制限
ナヌザがむンストヌルした゜フトり゚ア
䞍枬事態蚈画ポリシヌ・手順
緊急時察応蚈画

未遞択

CP-3
CP-4
CP-6
CP-7

䞍枬事態蚓緎
緊急時察応蚈画蚓緎
代替ストレヌゞサむト
代替凊理サむト

CP-3
CP-4
未遞択
未遞択

CM-9
CM-10
CM-11
CP-1
CP-2 (1) (3)
(8)
CP-3
CP-4 (1)
CP-6 (1) (3)
CP-7 (1) (2) (3)

CP-8

電気通信サヌビス

未遞択

CP-8 (1) (2)

CP-9

情報システムバックアップ

CP-9

CP-9 (1)

CP-10
CP-12
IA-1
IA-2

情報システムの埩旧・再構築
セヌフモヌド
識別・認蚌ポリシヌ・手順
識別・認蚌組織ナヌザ

CP-10
CP-12
IA-1
IA-2 (1) (12)

デバむス識別・認蚌
識別子管理
認蚌コヌド管理

IA-3
IA-4
IA-5 (1) (11)

CP-10 (2)
CP-12
IA-1
IA-2 (1) (2)
(3) (8) (11)
(12)
IA-3 (1) (4)
IA-4
IA-5 (1) (2) (3)
(11)

AU-12
CA-1

IA-3
IA-4
IA-5

AU-12
CA-1

AU-12
CA-1

AU-12 (1) (3)
CA-1

CA-2
CA-3
CA-5
CA-6
CA-7
未遞択

CA-2 (1)
CA-3 (5)
CA-5
CA-6
CA-7 (1)
未遞択

CA-9
CM-1
CM-2

CA-9
CM-1
CM-2 (1) (3) (7)

未遞択

CM-3 (2)
CM-4
CM-5
CM-6
CM-7 (1) (2)
(4) (5)
CM-8 (1) (3) (5)

CA-2 (1) (2)
CA-3 (5)
CA-5
CA-6
CA-7 (1)
CA-8
CA-9
CM-1
CM-2 (1) (2) (3)
(7)
CM-3 (1) (2)
CM-4 (1)
CM-5 (1) (2) (3)
CM-6 (1) (2)
CM-7 (1) (2) (5)

CM-4
未遞択
CM-6
CM-7 (1)
CM-8

CM-10
CM-11
CP-1
CP-2

348

CM-8 (1) (2) (3)
(4) (5)
CM-9
CM-10
CM-11
CP-1
CP-2 (1) (2) (3)
(4) (5) (8)
CP-3 (1)
CP-4 (1) (2)
CP-6 (1) (2) (3)
CP-7 (1) (2) (3)
(4)
CP-8 (1) (2) (3)
(4)
CP-9 (1) (2) (3)
(5)
CP-10 (2) (4)
CP-12
IA-1
IA-2 (1) (2) (3)
(4) (8) (9) (11)
(12)
IA-3 (1) (4)
IA-4
IA-5 (1) (2) (3)
(11)

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

IA-6

IA-6

IA-6

IA-6

Authenticator Feedback

IA-7

Cryptographic Module Authentication

IA-7

IA-7

IA-7

IA-8

Identification and Authentication (Non-

IA-8 (1) (2) (3) (4)

IA-8 (1) (2) (3) (4)

IA-8 (1) (2) (3) (4)

Organizational Users)
IR-1

Incident Response Policy and Procedures

IR-1

IR-1

IR-1

IR-2

Incident Response Training

IR-2

IR-2

IR-2 (1) (2)

IR-3

Incident Response Testing

Not Selected

IR-3 (2)

IR-3 (2)

IR-4

Incident Handling

IR-4

IR-4 (1)

IR-4 (1) (4)

IR-5

Incident Monitoring

IR-5

IR-5

IR-5 (1)

IR-6

Incident Reporting

IR-6

IR-6 (1)

IR-6 (1)

IR-7

Incident Response Assistance

IR-7

IR-7 (1)

IR-7 (1)

IR-8

Incident Response Plan

IR-8

IR-8

IR-8

MA-1

System Maintenance Policy and Procedures

MA-1

MA-1

MA-1

MA-2

Controlled Maintenance

MA-2

MA-2

MA-2 (2)

MA-3

Maintenance Tools

Not Selected

MA-3 (1) (2)

MA-3 (1) (2) (3)

MA-4

Nonlocal Maintenance

MA-4

MA-4 (2)

MA-4 (2) (3)

MA-5

Maintenance Personnel

MA-5

MA-5

MA-5 (1)

MA-6

Timely Maintenance

Not Selected

MA-6

MA-6

MP-1

Media Protection Policy and Procedures

MP-1

MP-1

MP-1

MP-2

Media Access

MP-2

MP-2

MP-2

MP-3

Media Marking

Not Selected

MP-3

MP-3

MP-4

Media Storage

Not Selected

MP-4

MP-4

MP-5

Media Transport

Not Selected

MP-5 (4)

MP-5 (4)

MP-6

Media Sanitization

MP-6

MP-6

MP-6 (1) (2) (3)

MP-7

Media Use

MP-7

MP-7 (1)

MP-7 (1)

PE-1

Physical and Environmental Protection Policy

PE-1

PE-1

PE-1

PE-2

PE-2

PE-2

and Procedures
PE-2

Physical Access Authorizations

PE-3

Physical Access Control

PE-3

PE-3

PE-3 (1)

PE-4

Access Control for Transmission Medium

Not Selected

PE-4

PE-4

PE-5

Access Control for Output Devices

Not Selected

PE-5

PE-5

PE-6

Monitoring Physical Access

PE-6

PE-6 (1) (4)

PE-6 (1) (4)

PE-8

Visitor Access Records

PE-8

PE-8

PE-8 (1)

PE-9

Power Equipment and Cabling

Not Selected

PE-9 (1)

PE-9 (1)

PE-10

Emergency Shutoff

Not Selected

PE-10

PE-10

PE-11

Emergency Power

PE-11 (1)

PE-11 (1)

PE-11 (1) (2)

PE-12

Emergency Lighting

PE-12

PE-12

PE-12

PE-13

Fire Protection

PE-13

PE-13 (3)

PE-13 (1) (2) (3)

PE-14

Temperature and Humidity Controls

PE-14

PE-14

PE-14

PE-15

Water Damage Protection

PE-15

PE-15

PE-15 (1)

PE-16

Delivery and Removal

PE-16

PE-16

PE-16

PE-17

Alternate Work Site

Not Selected

PE-17

PE-17

PE-18

Location of Information System Components

Not Selected

Not Selected

PE-18

PL-1

Security Planning Policy and Procedures

PL-1

PL-1

PL-1

PL-2

System Security Plan

PL-2 (3)

PL-2 (3)

PL-2 (3)

PL-4

Rules of Behavior

PL-4

PL-4 (1)

PL-4 (1)

PL-7

Security Concept of Operations

PL-7

PL-7

349

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

IA-6

認蚌フィヌドバック

IA-6

IA-6

IA-6

IA-7

暗号化モゞュヌル認蚌

IA-7

IA-7

IA-7

IA-8

識別・認蚌組織倖ナヌザ

IA-8 (1) (2)
(3) (4)

IA-8 (1) (2)
(3) (4)

IA-8 (1) (2) (3)
(4)

IR-1

むンシデント察応ポリシヌ・手順

IR-1

IR-1

IR-1

IR-2

むンシデント察応蚓緎

IR-2

IR-2

IR-2 (1) (2)

IR-3

むンシデント察応詊隓

未遞択

IR-3 (2)

IR-3 (2)

IR-4

むンシデント凊理

IR-4

IR-4 (1)

IR-4 (1) (4)

IR-5

むンシデント監芖

IR-5

IR-5

IR-5 (1)

IR-6

むンシデント報告

IR-6

IR-6 (1)

IR-6 (1)

IR-7

むンシデント察応支揎

IR-7

IR-7 (1)

IR-7 (1)

IR-8

むンシデント察応蚈画曞

IR-8

IR-8

IR-8

MA-1

MA-1

MA-1

MA-1

システム保守ポリシヌ・手順

MA-2

管理保守

MA-2

MA-2

MA-2 (2)

MA-3

保守ツヌル

未遞択

MA-3 (1) (2)

MA-3 (1) (2) (3)

MA-4

ロヌカル以倖の保守

MA-4

MA-4 (2)

MA-4 (2) (3)

MA-5

保守芁員

MA-5

MA-5

MA-5 (1)

MA-6

適時的保守

未遞択

MA-6

MA-6

MP-1

メディア保護ポリシヌ・手順

MP-1

MP-1

MP-1

MP-2

メディアアクセス

MP-2

MP-2

MP-2

MP-3

メディアマヌキング

未遞択

MP-3

MP-3

MP-4

メディアストレヌゞ

未遞択

MP-4

MP-4

MP-5

メディア転送

未遞択

MP-5 (4)

MP-5 (4)

MP-6

メディアサニタむズ

MP-6

MP-6

MP-6 (1) (2) (3)

MP-7

メディア利甚

MP-7

MP-7 (1)

MP-7 (1)

PE-1

物理環境保護ポリシヌ・手順

PE-1

PE-1

PE-1

PE-2

物理的アクセス暩限

PE-2

PE-2

PE-2

PE-3

物理的アクセス制埡

PE-3

PE-3

PE-3 (1)

PE-4

通信メディアのアクセス制埡

未遞択

PE-4

PE-4

PE-5

出力デバむスのアクセス制埡

未遞択

PE-5

PE-5

PE-6

物理的アクセス監芖

PE-6

PE-6 (1) (4)

PE-6 (1) (4)

PE-8

来蚪者立入蚘録

PE-8

PE-8

PE-8 (1)

PE-9

電気装眮及び配線

未遞択

PE-9 (1)

PE-9 (1)

PE-10

緊急遮断

未遞択

PE-10

PE-10

PE-11

緊急電源

PE-11 (1)

PE-11 (1)

PE-11 (1) (2)

PE-12

緊急照明

PE-12

PE-12

PE-12

PE-13

防火

PE-13

PE-13 (3)

PE-13 (1) (2) (3)

PE-14

枩床・湿床制埡

PE-14

PE-14

PE-14

PE-15

氎害防護

PE-15

PE-15

PE-15 (1)

PE-16

配送・撀去

PE-16

PE-16

PE-16

PE-17

代替䜜業堎

未遞択

PE-17

PE-17

PE-18

情報システムコンポヌネントの堎所

未遞択

未遞択

PE-18

PL-1

セキュリティ蚈画ポリシヌ・手順

PL-1

PL-1

PL-1

PL-2

システムセキュリティ蚈画曞

PL-2 (3)

PL-2 (3)

PL-2 (3)

PL-4

行動芏則

PL-4

PL-4 (1)

PL-4 (1)

PL-7

運甚セキュリティ抂念

PL-7

PL-7

350

SPECIAL PUBLICATION 800-82 REVISION 2

PL-8

Information Security Architecture

PS-1
PS-2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Not Selected

PL-8

PL-8

Personnel Security Policy and Procedures

PS-1

PS-1

PS-1

Position Risk Designation

PS-2

PS-2

PS-2

PS-3

Personnel Screening

PS-3

PS-3

PS-3

PS-4

Personnel Termination

PS-4

PS-4

PS-4 (2)

PS-5

Personnel Transfer

PS-5

PS-5

PS-5

PS-6

Access Agreements

PS-6

PS-6

PS-6

PS-7

Third-Party Personnel Security

PS-7

PS-7

PS-7

PS-8

Personnel Sanctions

PS-8

PS-8

PS-8

RA-1

Risk Assessment Policy and Procedures

RA-1

RA-1

RA-1

RA-2

Security Categorization

RA-2

RA-2

RA-2

RA-3

Risk Assessment

RA-3

RA-3

RA-3

RA-5

Vulnerability Scanning

RA-5

RA-5 (1) (2) (5)

RA-5 (1) (2) (4) (5)

SA-1

System and Services Acquisition Policy and

SA-1

SA-1

SA-1

Procedures
SA-2

Allocation of Resources

SA-2

SA-2

SA-2

SA-3

System Development Life Cycle

SA-3

SA-3

SA-3

SA-4

Acquisition Process

SA-4 (10)

SA-4 (1) (2) (9) (10)

SA-4 (1) (2) (9) (10)

SA-5

Information System Documentation

SA-5

SA-5

SA-5

SA-8

Security Engineering Principles

Not Selected

SA-8

SA-8

SA-9

External Information System Services

SA-9

SA-9 (2)

SA-9 (2)

SA-10

Developer Configuration Management

Not Selected

SA-10

SA-10

SA-11

Developer Security Testing and Evaluation

Not Selected

SA-11

SA-11

SA-12

Supply Chain Protection

Not Selected

Not Selected

SA-12

SA-15

Development Process, Standards, and Tools

Not Selected

Not Selected

SA-15

SA-16

Developer-Provided Training

Not Selected

Not Selected

SA-16

SA-17

Developer Security Architecture and Design

Not Selected

Not Selected

SA-17

SC-1

SC-1

SC-1

SC-1

System and Communications Protection Policy
and Procedures

SC-2

Application Partitioning

Not Selected

SC-2

SC-2

SC-3

Security Function Isolation

Not Selected

Not Selected

SC-3

SC-4

Information in Shared Resources

Not Selected

SC-4

SC-4

SC-5

Denial of Service Protection

SC-5

SC-5

SC-5

SC-7

Boundary Protection

SC-7

SC-7 (3) (4) (5) (7)

SC-7 (3) (4) (5) (7)

(18)

(8) (18) (21)
SC-8 (1)

SC-8

Transmission Confidentiality and Integrity

Not Selected

SC-8 (1)

SC-10

Network Disconnect

Not Selected

SC-10

SC-10

SC-12

Cryptographic Key Establishment and

SC-12

SC-12

SC-12 (1)

Management
SC-13

Cryptographic Protection

SC-13

SC-13

SC-13

SC-15

Collaborative Computing Devices

SC-15

SC-15

SC-15

SC-17

Public Key Infrastructure Certificates

Not Selected

SC-17

SC-17

SC-18

Mobile Code

Not Selected

SC-18

SC-18

SC-19

Voice Over Internet Protocol

Not Selected

SC-19

SC-19

SC-20

SC-20

SC-20

SC-20

Secure Name /Address Resolution Service
(Authoritative Source)

351

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

PL-8
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-5

情報セキュリティアヌキテクチャ
人員のセキュリティポリシヌ・手順
配眮リスク指定
人遞
退職
転勀
アクセス同意
サヌドパヌティ瀟員セキュリティ
懲戒
リスク評䟡ポリシヌ・手順
セキュリティ分類
リスク評䟡
脆匱性怜玢

未遞択

SA-1
SA-2
SA-3
SA-4

システム及びサヌビス取埗ポリシヌ・手順
リ゜ヌス割圓
システム開発ラむフサむクル
取埗プロセス

SA-1
SA-2
SA-3
SA-4 (10)

SA-5
SA-8
SA-9
SA-10
SA-11
SA-12
SA-15
SA-16
SA-17
SC-1
SC-2
SC-3
SC-4
SC-5
SC-7

情報システム文曞化
セキュリティ゚ンゞニアリング原則
倖郚情報システムサヌビス
開発者蚭定管理
開発者セキュリティ詊隓評䟡
サプラむチェヌン保護
開発プロセス・芏栌・ツヌル
開発者による蚓緎
開発者セキュリティアヌキテクチャ・蚭蚈
システム通信保護ポリシヌ・手順
アプリケヌション分割
セキュリティ機胜隔絶
共有リ゜ヌス内情報
サヌビス保護劚害
境界の保護

SA-5
未遞択

SC-8
SC-10
SC-12
SC-13
SC-15
SC-17
SC-18
SC-19
SC-20

通信機密性・完党性
ネットワヌク切断
暗号鍵蚭定管理
暗号保護
共同コンピュヌティングデバむス
PKI 蚌明曞
モバむルコヌド

未遞択
未遞択

PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-5

SA-9
未遞択
未遞択
未遞択
未遞択
未遞択
未遞択
SC-1
未遞択
未遞択
未遞択
SC-5
SC-7

SC-12
SC-13
SC-15
未遞択
未遞択
未遞択

VoIP
セキュアな名前/アドレス解決サヌビス
暩限゜ヌス

SC-20

352

PL-8
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-5 (1) (2)
(5)
SA-1
SA-2
SA-3
SA-4 (1) (2)
(9) (10)
SA-5
SA-8
SA-9 (2)
SA-10
SA-11
未遞択
未遞択
未遞択
未遞択
SC-1
SC-2
未遞択
SC-4
SC-5
SC-7 (3) (4) (5)
(7) (18)
SC-8 (1)
SC-10
SC-12
SC-13
SC-15
SC-17
SC-18
SC-19
SC-20

PL-8
PS-1
PS-2
PS-3
PS-4 (2)
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-5 (1) (2) (4)
(5)
SA-1
SA-2
SA-3
SA-4 (1) (2) (9)
(10)
SA-5
SA-8
SA-9 (2)
SA-10
SA-11
SA-12
SA-15
SA-16
SA-17
SC-1
SC-2
SC-3
SC-4
SC-5
SC-7 (3) (4) (5)
(7) (8) (18) (21)
SC-8 (1)
SC-10
SC-12 (1)
SC-13
SC-15
SC-17
SC-18
SC-19
SC-20

SPECIAL PUBLICATION 800-82 REVISION 2

SC-21

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SC-21

SC-21

SC-21

SC-22

SC-22

SC-22

Not Selected

SC-23

SC-23
SC-24

Secure Name /Address Resolution Service
(Recursive or Caching Resolver)

SC-22

Architecture and Provisioning for
Name/Address Resolution Service

SC-23

Session Authenticity

SC-24

Fail in Known State

Not Selected

SC-24

SC-28

Protection of Information at Rest

Not Selected

SC-28

SC-28

SC-39

Process Isolation

SC-39

SC-39

SC-39

SC-41

Port and I/O Device Access

SC-41

SC-41

SC-41

SI-1

SI-1

SI-1
SI-2 (1) (2)

SI-1

System and Information Integrity Policy and
Procedures

SI-2

Flaw Remediation

SI-2

SI-2 (2)

SI-3

Malicious Code Protection

SI-3

SI-3 (1) (2)

SI-3 (1) (2)

SI-4

Information System Monitoring

SI-4

SI-4 (2) (4) (5)

SI-4 (2) (4) (5)

SI-5

Security Alerts, Advisories, and Directives

SI-5

SI-5

SI-5 (1)

SI-6

Security Function Verification

Not Selected

Not Selected

SI-6

SI-7

Software, Firmware, and Information Integrity

Not Selected

SI-7 (1) (7)

SI-7 (1) (2) (5) (7)

SI-8

Spam Protection

Not Selected

SI-8 (1) (2)

SI-8 (1) (2)

SI-10

Information Input Validation

Not Selected

SI-10

SI-10

SI-11

Error Handling

Not Selected

SI-11

SI-11

SI-12

Information Handling and Retention

SI-12

SI-12

SI-12

SI-13

Predictable Failure Prevention

Not Selected

Not Selected

SI-13

SI-14

Non-Persistence

Not Selected

Not Selected

Not Selected

SI-15

Information Output Filtering

Not Selected

Not Selected

Not Selected

SI-16

Memory Protection

Not Selected

SI-16

SI-16

SI-17

Fail-Safe Procedures

SI-17

SI-17

SI-17

(14)

353

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

SC-21

セキュアな名前/アドレス解決サヌビス
再垰又はキャッシングリゟルバ

SC-21

SC-21

SC-21

SC-22

名前/アドレス解決サヌビス甚アヌキテク
チャヌプロビゞョニング

SC-22

SC-22

SC-22

SC-23

セッション信頌性

未遞択

SC-23

SC-23

SC-24

既知状態の倱敗

未遞択

SC-24

SC-24

SC-28

䌑眠情報の保護

未遞択

SC-28

SC-28

SC-39

プロセス隔離

SC-39

SC-39

SC-39

SC-41

ポヌト及び I/O デバむスアクセス

SC-41

SC-41

SC-41

SI-1

システム情報完党性ポリシヌ・手順

SI-1

SI-1

SI-1

SI-2

欠陥修正

SI-2

SI-2 (2)

SI-2 (1) (2)

SI-3

悪意あるコヌド保護

SI-3

SI-3 (1) (2)

SI-3 (1) (2)

SI-4

情報システム監芖

SI-4

SI-4 (2) (4)
(5)

SI-4 (2) (4) (5)

SI-5

セキュリティ譊報・勧告・指瀺

SI-5

SI-5

SI-5 (1)

SI-6

セキュリティ機胜怜蚌

未遞択

未遞択

SI-6

SI-7

゜フトり゚ア・ファヌムり゚ア・情報の完
党性

未遞択

SI-7 (1) (7)

SI-7 (1) (2) (5)
(7) (14)

SI-8

スパム保護

未遞択

SI-8 (1) (2)

SI-8 (1) (2)

SI-10

情報入力怜蚌

未遞択

SI-10

SI-10

SI-11

゚ラヌ凊理

未遞択

SI-11

SI-11

SI-12

情報凊理保留

SI-12

SI-12

SI-12

SI-13

予想される故障の防止

未遞択

未遞択

SI-13

SI-14

非執拗性

未遞択

未遞択

未遞択

SI-15

情報出力フィルタリング

未遞択

未遞択

未遞択

SI-16

メモリ保護

未遞択

SI-16

SI-16

SI-17

フェヌルセヌフ手順

SI-17

SI-17

SI-17

354

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

The PM-family is deployed organization-wide, supporting the information security program. It is not
associated with security control baselines and is independent of any system impact level.

PM-1

Information Security Program Plan

PM-1

PM-2

Senior Information Security Officer

PM-2

PM-3

Information Security Resources

PM-3

PM-4

Plan of Action and Milestones Process

PM-4

PM-5

Information System Inventory

PM-5

PM-6

Information Security Measures of Performance

PM-6

PM-7

Enterprise Architecture

PM-7

PM-8

Critical Infrastructure Plan

PM-8

PM-9

Risk Management Strategy

PM-9

PM-10

Security Authorization Process

PM-10

PM-11

Mission/Business Process Definition

PM-11

PM-12

Insider Threat Program

PM-12

PM-13

Information Security Workforce

PM-13

PM-14

Testing, Training, and Monitoring

PM-14

PM-15

Contacts with Security Groups and Associations

PM-15

PM-16

Threat Awareness Program

PM-16

355

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

PM ファミリは党組織に展開され、情報セキュリティプログラムを支えおいる。セキュリティ察
策ベヌスラむンは付随しおおらず、いかなるシステム圱響レベルずも無関係である。
PM-1
PM-2
PM-3
PM-4
PM-5
PM-6
PM-7
PM-8
PM-9
PM-10
PM-11
PM-12
PM-13
PM-14
PM-15
PM-16

情報セキュリティプログラム蚈画曞
䞊玚情報セキュリティ担圓官
情報セキュリティリ゜ヌス
行動・マむルストヌンプロセス蚈画曞
情報システム目録
情報セキュリティに関するパフォヌマンスの蚈枬
䌁業アヌキテクチャ
重芁むンフラ蚈画曞
リスク管理戊略
セキュリティ暩限プロセス
任務・事業プロセス定矩
むンサむダヌ脅嚁プログラム
情報セキュリティリワヌクフォヌス
詊隓・蚓緎・監芖
セキュリティグルヌプ・協䌚ずの契玄
脅嚁意識プログラム

356

PM-1
PM-2
PM-3
PM-4
PM-5
PM-6
PM-7
PM-8
PM-9
PM-10
PM-11
PM-12
PM-13
PM-14
PM-15
PM-16

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Tailoring Considerations
Due to the unique characteristics of ICS, these systems may require a greater use of compensating security
controls than is the case for general purpose information systems. Compensating controls are not
exceptions or waivers to the baseline controls; rather, they are alternative safeguards and countermeasures
employed within the ICS that accomplish the intent of the original security controls that could not be
effectively employed. See “Selecting Compensating Security Controls” in section 3.2 of NIST SP 800-53
Rev. 4 [22].
In situations where the ICS cannot support, or the organization determines it is not advisable to implement,
particular security controls or control enhancements in an ICS (e.g., performance, safety, or reliability are
adversely impacted), the organization provides a complete and convincing rationale for how the selected
compensating controls provide an equivalent security capability or level of protection for the ICS and why
the related baseline security controls could not be employed.
In accordance with the Technology-related Considerations of the Scoping Guidance in NIST SP 800-53
Rev. 4, section 3.2, if automated mechanisms are not readily available, cost-effective, or technically
feasible in the ICS, compensating security controls, implemented through nonautomated mechanisms or
procedures are employed [22].
Compensating controls are alternative security controls employed by organizations in lieu of specific
controls in the baselines—controls that provide equivalent or comparable protection for organizational
information systems and the information processed, stored, or transmitted by those systems. 83 This may
occur, for example, when organizations are unable to effectively implement specific security controls in the
baselines or when, due to the specific nature of the ICS or environments of operation, the controls in the
baselines are not a cost-effective means of obtaining the needed risk mitigation. Compensating controls
may include control enhancements that supplement the baseline. Using compensating controls may involve
a trade-off between additional risk and reduced functionality. Every use of compensating controls should
involve a risk-based determination of: (i) how much residual risk to accept, and (ii) how much functionality
should be reduced. Compensating controls may be employed by organizations under the following
conditions:


Organizations select compensating controls from NIST SP 800-53 Rev. 4, Appendix F. If appropriate
compensating controls are not available, organizations adopt suitable compensating controls from
other sources 84



Organizations provide supporting rationale for how compensating controls provide equivalent security
capabilities for organizational information systems and why the baseline security controls could not be
employed.



Organizations assess and accept the risk associated with implementing compensating controls in ICS.

Organizational decisions on the use of compensating controls are documented in the security plan for the
ICS.

83

84

42 More than one compensating control may be required to provide the equivalent protection for a particular
security control in Appendix F. For example, organizations with significant staff limitations may compensate
for the separation of duty security control by strengthening the audit, accountability, and personnel
security controls.
43 Organizations should make every attempt to select compensating controls from the security control catalog
in Appendix F. Organization-defined compensating controls are employed only when organizations determine
that the security control catalog does not contain suitable compensating controls.

357

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

カスタマむズの考慮事項
ICS 独特の特城から、これらシステムに必芁ずされる補償セキュリティ管理は、汎甚の情報シス
テムよりも倚い。代替管理はベヌスラむン管理の䟋倖や攟棄ではなく、代替の安党策及び察策ず
しお ICS 内で採甚され、有効利甚できない元のセキュリティ察策の目的を果たす。NIST SP 80053 第 4 版[22]のセクション 3.2「補償セキュリティ察策」を参照のこず。
ICS が ICS におけるセキュリティ察策若しくは管理拡匵に察応しおいない堎合又は組織が ICS に
おけるセキュリティ察策若しくは管理拡匵の実装を䞍適ず刀断する堎合パフォヌマンス、安党
性、信頌性ぞの悪圱響等、遞定した補償的管理策に同等のセキュリティ機胜又は同等レベルの
ICS 保護胜力があり、関連ベヌスラむンセキュリティ察策が採甚できなかった理由に぀いお、組
織は玍埗のいく理由を瀺す。
自動化メカニズムがすぐに利甚できない、費甚効果がない又は技術的に䞍可胜な堎合、NIST SP
800-53 第 4 版のセクション 3.2 の「適甚範囲ガむダンスの技術関連考慮事項」に埓い、補償セ
キュリティ察策を非自動化メカニズム又は手順の実斜を通じお採甚する[22]。
補償的管理策は、特定のベヌスラむン管理に代えお組織が取る代替セキュリティ察策で、組織の
情報システムずそこで凊理、保管又は送信される情報に同等の保護を䞎えるものをいう。85 䟋え
ば、特定のベヌスラむン管理を効果的に実斜できない堎合や、ICS 固有の性質若しくは運甚環境
に起因しお、ベヌスラむンの管理がリスク緩和䞊費甚察効果のない堎合に、補償的管理策が講じ
られる。補償的管理策には、ベヌスラむンを補完する管理拡匵が含たれるこずがある。補償的管
理策を行うには、リスク増加ず機胜䜎䞋のバランスが関係しおくる。必ず(1)蚱容できるリスク
の皋床ず、2どの皋床機胜が䜎䞋するかを、リスクに基づいお刀断すべきである。組織は、
次のような条件の䞋で補償的管理策を採甚できる。

 適圓な補償的管理策を NIST SP 800-53 第 4 版付録 F から遞ぶ 86。適圓な補償的管理策が同付
録にない堎合、他の゜ヌスから適圓な補償的管理策を採甚する。
 組織は、補償的管理策が情報システムに察しお同等のセキュリティ機胜を有し、ベヌスラむ
ンセキュリティ察策が採甚できなかった根拠ずなる理由を瀺す。
 組織は、ICS における補償的管理策の実斜に付随するリスクを評䟡し受け入れる。
代替管理を利甚する組織の決定は、ICS のセキュリティ蚈画曞に蚘録する。

85

86

付録 F の特定のセキュリティ察策に同等の保護を䞎えるには、補償管理が耇数必芁ずなるこずもある。䟋えば、職員数が
限られおいる組織では、監査管理、説明責任管理及び職員のセキュリティ察策を匷化しお、セキュリティ管理任務を分割
するこずになろう。
組織はあらゆる努力を払っお、付録 F のセキュリティ察策カタログから補償的管理策を遞ぶべきである。組織が自ら定矩
した補償的管理策は、同カタログに適圓なものがない堎合にのみ採甚する。

358

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Controls that contain assignments (e.g., Assignment: organization-defined conditions or trigger events)
may be tailored out of the baseline. This is equivalent to assigning a value of “none.” The assignment may
take on different values for different impact baselines.
Non-Addressable and Non-Routable Communications
The unique network properties within ICS warrant specific attention when applying certain security
controls. Many of the controls in NIST SP 800-53 Rev. 4 that pertain to communication, devices, and
interfaces implicitly assume the applicability of addressable and routable protocols such as the TCP/IP
Internet protocol suite 87 or layers 1, 2, and 3 of the Open Systems Interconnection (OSI) model (ISO/IEC
7498-1). Some devices, or subsystems, used in ICS are exceptions to this assumption. This section
addresses how the controls may be appropriately tailored. Tailoring is primarily required due to the
following situations:


Capabilities not present. The intent of certain controls may be more easily achieved through
compensating controls due to certain network properties or capabilities not existing in the ICS
subsystem. For example, physical protections (e.g., locked cabinets) may be used to secure an entire
point-to-point communication channel as a means to compensate for a lack of protocols that support
authentication. Security controls may warrant additional supplemental guidance to help ensure the
implementation of the control or compensating control provides the appropriate level of protection.



Non-applicable security controls. Many communication protocols found within an ICS may have
limited functionality (e.g., not addressable or routable). Security controls dealing with addressing and
routing may not be applicable to these protocols.

Security controls for devices that communicate point-to-point using standards and protocols that do not
include addressing generally require tailoring. A modem connected to a computer through an RS-232
interface is an example. RS-232 was commonly employed in ICS equipment that is currently in use, even if
it has been superseded in newer equipment. In telecommunications, RS-232 is the traditional name for a
series of standards for serial binary single-ended data and control signals connecting between DTE (data
terminal equipment) and DCE (data circuit-terminating equipment, originally defined as data
communication equipment). The current version of the standard is Telecommunications Industry
Association (TIA)-232-F, Interface Between Data Terminal Equipment and Data Circuit-Terminating
Equipment Employing Serial Binary Data Interchange, issued in 1997.
An RS-232 serial port was once a standard feature of small computing devices, such as ICS subsystems,
used for connections to peripheral devices. However, the low transmission speed, large voltage swing, and
large standard connectors motivated development of the Universal Serial Bus (USB), which has displaced
RS-232 from most of its peripheral interface roles. RS-232 devices are still found, especially in industrial
machines, networking equipment, and scientific instruments.
Layered Network Models
The layered network models used in both TCP/IP and OSI can provide a basis for understanding the
various properties of network communications and will help identify how security controls can be
appropriately applied to systems and networks. The following table introduces key properties about the
physical, data link, and network layers regarding the application of security controls.

87

44 Currently, the Internet Engineering Task Force, or IETF, manages the TCP/IP protocol suite.

359

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

割圓組織が定矩した条件やトリガヌ事象等は、ベヌスラむンを基にカスタマむズできる。こ
れは「なし」の倀を割り圓おるのず同じこずである。割圓は、圱響ベヌスラむンが異なるず倀も
異なるこずがある。
アドレス指定又は経路指定のない通信
特定のセキュリティ察策を適甚する堎合、ICS 内での固有のネットワヌク特性に特に留意すべき
である。NIST SP 800-53 第 4 版の通信、デバむス及びむンタフェヌスに関する管理の倚くは、
TCP/IP むンタヌネットスむヌト 88やオヌプンシステム間盞互連接OSIモデル(ISO/IEC 74981)の TCP/IP レむダヌ1、2、3 等、アドレス指定可胜又は経路指定可胜プロトコルを適甚するこ
ずを暗黙の前提にしおいる。ICS で䜿甚するある皮のデバむスやサブシステムは、この前提の䟋
倖ずなる。このセクションでは、管理の適正なカスタマむズ方法に぀いお取り䞊げる。カスタマ
むズは、䞻ずしお次のような堎合に必芁ずなる。

 機胜がない。特定の管理の目的は、特定のネットワヌク特性又は機胜が ICS サブシステムに
ないため、補償的管理策により容易に達成可胜である。䟋えば物理的保護キャビネットの
斜錠等は、認蚌機胜付きプロトコルがない堎合の補償手段ずしお、2 点間通信チャンネル
のセキュア化に利甚できる。セキュリティ察策は付加的な補足ガむダンスずしお、管理又は
補償的管理策による適性レベルの保護の確保に圹立぀。
 適甚可胜なセキュリティ察策がない。ICS で䜿甚されおいるプロトコルの倚くは、機胜が限
られおいるアドレス指定やルヌト指定ができない等。アドレス及びルヌトに関するセキ
ュリティ察策は、このようなプロトコルには適甚できない。
アドレス指定のない芏栌及びプロトコルを䜿甚した 2 点間通信を行うデバむスのセキュリティ察
策には、通垞、カスタマむズが必芁ずなる。RS-232 むンタフェヌス経由のコンピュヌタに接続
されたモデルがその䞀䟋である。RS-232 は、珟圚利甚されおいる ICS 装備品で䞀般的に䜿甚さ
れおいたそうした装備品が新しいものに換装されおいる堎合であっおも。電気通信においお
RS-232 は、DTEデヌタ端末装眮ず DCEデヌタ回線終端装眮、元はデヌタ通信装眮間のシ
リアルバむナリシングル゚ンドデヌタ制埡信号芏栌の䌝統的な名称である。珟行版芏栌は米囜電
気通信工業䌚TIA-232-F「シリアルバむナリデヌタ亀換によるデヌタ端末装眮デヌタ回線端
末装眮間むンタフェヌス」ずしお、1997 幎に発衚された。
RS-232 シリアルポヌトは、ICS サブシステム等の小型コンピュヌティングデバむスの芏栌機胜ず
しお、呚蟺デバむスぞの接続に䜿甚された。しかし通信速床が遅く、電圧振幅が倧きく、芏栌コ
ネクタが倧きいこずから USB が開発され、RS-232 の呚蟺むンタフェヌスずしおの圹割は終わっ
た。RS-232 デバむスは、特に産業甚マシン、ネットワヌキング装眮及び科孊蚈装機噚で今でも
䜿甚されおいる。
階局型ネットワヌクモデル
TCP/IP ず OSI の双方で䜿甚されおいる 階局型ネットワヌクモデルは、ネットワヌク通信を理解
する基本で、システム及びネットワヌクに適甚すべきセキュリティ察策芁領の識別に圹立぀。次
の衚は、セキュリティ察策の適甚に関する物理的階局、デヌタリンク階局及びネットワヌク階局
の重芁特性を瀺す。

88

珟圚むンタヌネットタスクフォヌスIETFが TCP/IP プロトコルスむヌトの管理を行っおいる。

360

SPECIAL PUBLICATION 800-82 REVISION 2

Network Layer
Physical

Data link

Network

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Layer properties
Physical Medium – A network’s physical medium, specifically whether it’s wired or
wireless can drive the application/tailoring of certain controls. Wireless connections
cannot be physically protected; therefore, compensating controls focusing on physical
security cannot be used.
Topology – The physical topologies may also determine how controls are tailored. For
example point-to-point topologies (e.g., RS-232) generally do not need physically
addressable interfaces, while multipoint topologies (e.g., IEEE 802.3 Ethernet) do
require physically addressable interfaces.
Physically Addressable – Multipoint protocols require physically addressable
interfaces to allow for multiple systems to communicate. Systems that are not
physically addressable can only be accessed by those systems with which it shared
point-to-point connections.
Network Addressable/Routable – Network addressable/routable systems can be
accessed by any system on an internetwork. That is, communications can be routed
between networks. If a system is not network addressable/routable, it can only be
accessed by systems with which it shares a local network connection.

Definitions
Terms used in this overlay are defined in Appendix B— or in NIST Internal Report (NISTIR) 7298
Revision 2, Glossary of Key Information Security Terms [99].
Additional Information or Instructions
None at this time. Organizations may provide any additional information or instructions relevant to the
overlay not covered in the previous sections.

361

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ネットワヌク局 階局特性
物理
物理的媒䜓 - ネットワヌクの物理的媒䜓で、特に有線/無線の違いにより、特定の
管理の適甚かカスタマむズかが決たる。
ワむダレス接続は物理的に保護できないため、物理的セキュリティに特化した補
償的管理策は利甚できない。
トポロゞヌ - 物理的トポロゞヌも管理のカスタマむズ方法を決定づける。䟋えば
2 点間トポロゞヌRS-232 等は、通垞、物理的にアドレス指定可胜なむンタフ
ェヌスが䞍芁であるが、マルチポむントトポロゞヌIEEE 802.3 Ethernet 等で
は必芁ずなる。
デヌタリンク

物理的アドレス指定可胜 - マルチポむントプロトコルは、耇数システム間の通信
甚に、物理的にアドレス指定可胜なむンタフェヌスを必芁ずする。物理的アドレ
ス指定䞍胜のシステムには、共有 2 点間通信のあるシステム以倖にはアクセスで
きない。

ネットワヌク

ネットワヌクアドレス指定可胜/ルヌト指定可胜 - アドレス/ルヌト指定可胜シス
テムには、ネットワヌク間のどのシステムからもアクセスできる。぀たり通信
は、ネットワヌク間で経路指定される。あるシステムがアドレス/ルヌト指定䞍胜
の堎合、アクセスできるのはロヌカルネットワヌク接続を共有するシステムのみ
ずなる。

定矩
このオヌバヌレむで䜿甚する甚語は、付録 B 又は NIST 内郚報告曞(NISTIR)7298 第 2 版芁情報セ
キュリティ甚語集[99]に定矩がある。
補足情報又は指瀺
珟圚のずころない。組織は、前のセクションにないオヌバヌレむに関する補足情報又は指瀺を䞎
えるこずができる。

362

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Detailed Overlay Control Specifications
This Overlay is based on the NIST SP 800-53 Rev. 4, Security and Privacy Controls for Federal
Information Systems and Organizations, which provides a catalog of security and privacy controls for
federal information systems and organizations and a process for selecting controls to protect organizational
operations (including mission, functions, image, and reputation), organizational assets, individuals, other
organizations, and the Nation from a diverse set of threats including hostile cyber attacks, natural disasters,
structural failures, and human errors (both intentional and unintentional). The security and privacy controls
are customizable and implemented as part of an organization-wide process that manages information
security and privacy risk. The controls address a diverse set of security and privacy requirements across the
federal government and critical infrastructure, derived from legislation, Executive Orders, policies,
directives, regulations, standards, and/or mission/business needs. The publication also describes how to
develop specialized sets of controls, or overlays, tailored for specific types of missions/business functions,
technologies, or environments of operation. Finally, the catalog of security controls addresses security from
both a functionality perspective (the strength of security functions and mechanisms provided) and an
assurance perspective (the measures of confidence in the implemented security capability). Addressing both
security functionality and assurance helps to ensure that information technology component products and
the information systems built from those products using sound system and security engineering principles
are sufficiently trustworthy.
In preparation for selecting and specifying the appropriate security controls for organizational information
systems and their respective environments of operation, organizations first determine the criticality and
sensitivity of the information to be processed, stored, or transmitted by those systems. This process is
known as security categorization. FIPS 199 [15] enables federal agencies to establish security categories for
both information and information systems. Other documents, such as those produced by ISA and CNSS,
also provide guidance for defining low, moderate, and high levels of security based on impact. The security
categories are based on the potential impact on an organization or on people (employees and/or the public)
should certain events occur which jeopardize the information and information systems needed by the
organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain
its day-to-day functions, and protect individuals’ safety, health and life. Security categories are to be used
in conjunction with vulnerability and threat information in assessing the risk to an organization.
This overlay provides ICS Supplemental Guidance for the security controls and control enhancements
prescribed for an information system or an organization designed to protect the confidentiality, integrity,
and availability of its information and to meet a set of defined security requirements. This overlay contains
a tailoring of the security control baselines; its specification may be more stringent or less stringent than the
original security control baseline specification and can be applied to multiple information systems. This
overlay is high-level, applicable to all ICS; it may be used as the basis for more specific overlays. Use cases
for specific systems in specific environments may be separately published (e.g., as a NISTIR).

363

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

詳现オヌバヌレむ管理仕様曞
このオヌバヌレむは NIST SP 800-53 第 4 版「連邊情報システム・組織のセキュリティ・プラむ
バシヌ管理」を基にしおいる。第 4 版には組織運甚任務、機胜、むメヌゞ、評刀等、組織資
産、個人、他の組織及び囜を敵のサむバヌ攻撃、自然灜害、構造的障害及び人的過誀意図的又
は偶発的等の様々な脅嚁から保護するための連邊情報システム・組織及び管理遞定プロセスの
セキュリティ・プラむバシヌ管理カタログが瀺されおいる。セキュリティ・プラむバシヌ管理は
カスタマむズが可胜で、情報セキュリティ・プラむバシヌのリスクを管理する党組織的プロセス
の䞀環ずしお実斜される。管理は、法什、倧統領什、政策、指瀺、芏則、芏栌又は任務・事業ニ
ヌズから生じた連邊政府及び重芁むンフラ党䜓の様々なセキュリティ・プラむバシヌ芁件を察象
ずしおいる。この文曞には、特殊管理やオヌバヌレむを固有の任務・事業機胜、技術又は運甚環
境に合わせお策定する方法が説明されおいる。最埌にセキュリティ察策カタログは、機胜的な面
セキュリティ機胜・メカニズムの匷床ず保蚌面実斜したセキュリティ胜力の信頌性の䞡
方からセキュリティを怜蚎する。機胜ず保蚌の䞡面を取り䞊げるこずで、情報技術コンポヌネン
ト補品ず、その補品を䜿甚しお、しっかりしたシステム原則ずセキュリティ゚ンゞニアリング原
則を適甚し、構築された情報システムが十分信頌に応えられるものずなる。
組織の情報システムずそれぞれの運甚環境に察するセキュリティ察策を遞定・指定するための準
備ずしお、たず組織は、それらシステムにより凊理、保管又は送信される情報の重芁性ず芁泚意
性を刀定する。このプロセスはセキュリティ分類ずしお知られおいる。FIPS 199[15]は、連邊政
府機関が情報及び情報システム甚のセキュリティ分類を蚭定できるように瀺しおいる。ISA や
CNSS により䜜成された他の文曞も、圱響床に応じお䜎・䞭・高レベルを定めるガむダンスを瀺
しおいる。
セキュリティ分類は、特定の事象が起きお、組織の任務遂行、資産保護、法的責任の遂行、日垞
業務の維持及び個人の安党・健康・生呜保護に必芁ずされる情報や情報システムが危険に陥る堎
合の、組織又は個人埓業員又は囜民に及ぶ圱響床を基にしおいる。セキュリティ分類は脆匱
性及び脅嚁情報ず合わせお、組織に察するリスク評䟡に䜿甚すべきである。
このオヌバヌレむは、情報の機密性、完党性及び可甚性を保護するために、たた、定められた䞀
連のセキュリティ芁件を満たすために、情報システムや組織向けに䜜成されたセキュリティ察
策・管理拡匵甚 ICS 補足ガむダンスずなる。セキュリティ管理ベヌスラむンのカスタマむズが含
たれ、その仕様は元のセキュリティ管理ベヌスラむン仕様よりも厳しい堎合もあれば緩い堎合も
あり、皮々の情報システムに適甚可胜である。このオヌバヌレむは高レベルで、党おの ICS に適
甚可胜であり、より倚くの個別オヌバヌレむの基瀎ずしお䜿甚できる。具䜓的な環境における特
定システムでの䜿甚䟋は別途瀺されおいるNISTIR 等。

364

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Figure G-1 uses the AU-4 control as an example of the format and content of the detailed overlay control
specifications.
 Control number and title.
 Column for control and control enhancement number.
 Column for control and control enhancement name.
 Columns for baselines. If the baselines have been supplemented, then SUPPLEMENTED appears.
 A row for each control or control enhancement.
 Columns for LOW, MODERATE, and HIGH baselines.
 “Selected” indicates the control is selected in NIST SP 800-53 Rev. 4. “Added” indicates the
control is added to a baseline in the ICS overlay. A blank cell indicates the control is not selected.
“Removed” indicates the control is removed from the baseline.
 The ICS Supplemental Guidance. If there is none, that is stated.
 The Control Enhancement ICS Supplemental Guidance. If there is none, that is stated.
 The rationale for changing the presence of a control or control enhancement in the baseline.



AU-4 AUDIT STORAGE CAPACITY







CONTROL NAME
CNTL NO.



SUPPLEMENTED
CONTROL BASELINES

Control Enhancement Name

LOW

MOD

HIGH

AU-4

Audit Storage Capacity

Selected

Selected

Selected

AU-4 (1)

AUDIT STORAGE CAPACITY | TRANSFER TO ALTERNATE STORAGE

Added

Added

Added







No ICS Supplemental Guidance.
Control Enhancement: (1) ICS Supplemental Guidance: Legacy ICS typically are typically configured with
remote storage on a separate information system (e.g., the historian in the DMZ accumulates historical operational ICS
data and is backed up for storage at a different site). ICS are currently using online backup services and increasingly
moving to Cloud based and Virtualized services. Retention of some data (e.g., SCADA telemetry) may be required by
regulatory authorities.
 Rationale for adding control to baseline: Legacy ICS components typically do not have capacity to store or
analyze audit data. The retention periods for some data, particularly compliance data, may require large volumes of
storage.

Figure G-1 Detailed Overlay Control Specifications Illustrated

NIST SP 800-53 Rev. 4, Appendix F, contains Supplemental Guidance for all Controls and Control
Enhancements [22]. ICS Supplemental Guidance in this overlay provides organizations with additional
information on the application of the security controls and control enhancements in NIST SP 800-53 Rev. 4,
Appendix F, to ICS and the environments in which these specialized systems operate. The ICS
Supplemental Guidance also provides information as to why a particular security control or control
enhancement may not be applicable in some ICS environments and may be a candidate for tailoring (i.e.,
the application of scoping guidance and/or compensating controls).

365

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

図 G-1 は、詳现なオヌバヌレむ管理仕様の様匏及び内容の䞀䟋ずしお、AU-4 管理を䜿甚しおい
る。
 管理の番号ず題名
 管理・管理拡匵番号を瀺すカラム
 管理・管理拡匵名を瀺すカラム
 ベヌスラむンを瀺すカラム。ベヌスラむンの補足がある堎合、「補足SUPPLEMENTED」ず衚
瀺される。
各管理・管理拡匵を瀺す行。









䜎・䞭・高及び高ベヌスラむンを瀺すカラム
「遞定」は NIST SP 800-53 第 4 版で管理が遞定されおいるこずを瀺す。「远加」は管理
が ICS オヌバヌレむのベヌスラむンに远加されおいるこずを瀺す。空癜セルは管理が遞
定されおいないこずを瀺す。「削陀」は管理がベヌスラむンから削陀されたこずを瀺す。
ICS 補足ガむダンス。䜕もない堎合、その旚の蚘述がある。
管理拡匵 ICS 補足ガむダンス。䜕もない堎合、その旚の蚘述がある。
ベヌスラむンの管理・管理拡匵の有無が倉わった理由



AU-4 AUDIT STORAGE CAPACITY







CONTROL NAME

CONTROL BASELINES

Control Enhancement Name

CNTL NO.



SUPPLEMENTED
LOW

MOD

HIGH

AU-4

Audit Storage Capacity

Selected

Selected

Selected

AU-4 (1)

AUDIT STORAGE CAPACITY | TRANSFER TO ALTERNATE STORAGE

Added

Added

Added






ICS 補足ガむダンスなし



管理拡匵(1) ICS 補足ガむダンスレガシヌICS は、䞀般に別個の情報システム䞊の遠隔ストレヌゞで蚭定されお
いるDMZ のヒストリアン等で、ICS の運甚履歎デヌタを蓄積し、別サむトのストレヌゞに保管する。ICS は今
のずころオンラむンバックアップサヌビスを利甚しおいるが、クラりドベヌスの仮想サヌビスに次第に移行しおい
る。特定のデヌタSCADA テレメトリ-等の保持が芏制圓局から矩務づけられる堎合がある。



ベヌスラむンに管理を远加する理由䞀般にレガシヌICS コンポヌネントには、監査デヌタの保存又は分析容量が
ない。特定のデヌタ、特にコンプラむアンスデヌタの保持期間によっお、保管量が倧きくなる。

図 G-1 詳现オヌバヌレむ管理仕様の説明

NIST SP 800-53 第 4 版付録 F に、党おの管理・管理拡匵補足ガむダンスがある[22]。このオヌ
バヌレむの ICS 補足ガむダンスは、NIST SP 800-53 第 4 版の付録 F に蚘茉されるセキュリティ
察策及び管理拡匵を、ICS 及びこれら専甚システムの実行環境に適甚するための補足情報を瀺す。
たた、ICS 環境によっおは特定のセキュリティ察策や管理拡匵が適甚できず、調敎が必芁ずなる
理由に぀いおも瀺すスコヌピングガむダンス又は補償制埡。

366

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ACCESS CONTROL – AC
Tailoring Considerations for Access Control Family
Before implementing controls in the AC family, consider the tradeoffs among security, privacy, latency, performance, throughput, and
reliability. For example, the organization considers whether latency induced from the use of confidentiality and integrity mechanisms
employing cryptographic mechanisms would adversely impact the operational performance of the ICS.
In situations where the ICS cannot support the specific Access Control requirements of a control, the organization employs
compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as
appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
AC-1 ACCESS CONTROL POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
AC-1

CONTROL BASELINES

Control Enhancement Name
Access Control Policy and Procedures

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems. ICS access by vendors and maintenance staff can occur over a very large facility footprint or geographic area and into
unobserved spaces such as mechanical/electrical rooms, ceilings, floors, field substations, switch and valve vaults, and pump stations.
AC-2 ACCOUNT MANAGEMENT
CONTROL NAME
CNTL NO.
AC-2
AC-2 (1)

CONTROL BASELINES

Control Enhancement Name
Account Management
ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT

LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

Selected

Selected

MANAGEMENT
AC-2 (2)

ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY /
EMERGENCY ACCOUNTS

AC-2 (3)

ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS

Selected

Selected

AC-2 (4)

ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS

Selected

Selected

AC-2 (5)

ACCOUNT MANAGEMENT | INACTIVITY LOGOUT / TYPICAL

Selected

USAGE MONITORING
AC-2 (11)

ACCOUNT MANAGEMENT | USAGE CONDITIONS

Selected

AC-2 (12)

ACCOUNT MANAGEMENT | ACCOUNT MONITORING /

Selected

ATYPICAL USAGE
AC-2 (13)

ACCOUNT MANAGEMENT | ACCOUNT REVIEWS

Selected

ICS Supplemental Guidance: Example compensating controls include providing increased physical security, personnel security,
intrusion detection, auditing measures.
Control Enhancement: (1, 3, 4) ICS Supplemental Guidance: Example compensating controls include employing nonautomated
mechanisms or procedures.
Control Enhancement: (2) ICS Supplemental Guidance: In situations where the ICS (e.g., field devices) cannot support
temporary or emergency accounts, this enhancement does not apply. Example compensating controls include employing nonautomated
mechanisms or procedures.
Control Enhancement: (5) ICS Supplemental Guidance: Example compensating controls include employing nonautomated
mechanisms or procedures.
Control Enhancement: (11, 12, 13) No ICS Supplemental Guidance.

367

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

アクセス制埡 - AC
アクセス制埡ファミリのカスタマむズ考慮事項
AC ファミリで管理を実斜する前に、セキュリティ、プラむバシヌ、埅ち時間、パフォヌマンス、
スルヌプット、信頌性を比范考量する。䟋えば、暗号メカニズムを採甚しお機密性及び完党性メ
カニズムを利甚するこずにより生じる埅ち時間が、ICS の運甚パフォヌマンスを阻害しないか組
織は怜蚎する。
ICS がある制埡の特定のアクセス制埡芁件に察応しおいない状況では、党䜓的なカスタマむズガ
むダンスに埓っお補償的管理策を採甚する。補償管理の䟋が必芁に応じお、管理策ごずに瀺され
る。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、ICS 補足ガむダンスず䜵甚すべきである。
AC-1

アクセス制埡ポリシヌ・手順

管理番号

管理名

管理ベヌスラむン

管理拡匵名
アクセス制埡ポリシヌ・手順

AC-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの関係
を取り䞊げる。ベンダヌ及び保守芁員による ICS ぞのアクセスは、機械・電気宀、倩井、床、倉
電蚭備、スむッチ・バルブ宀、ポンプ宀等、広範な斜蚭及び地域や監芖䞋にない空間にたたがっ
おいる。
AC-2

アカりント管理

管理番号

管理名

管理ベヌスラむン

管理拡匵名

äž­

高

遞定

遞定

遞定

AC-2 (1)

アカりント管理 | 動システムアカりント管理

遞定

遞定

AC-2 (2)

アカりント管理 |臚時・緊急甚アカりントの削陀

遞定

遞定

AC-2 (3)

アカりント管理 |無掻動アカりントの無効化

遞定

遞定

AC-2 (4)

アカりント管理 | 自動監査行為

遞定

遞定

AC-2 (5)

アカりント管理 | 無掻動ログアりト・䞀般的利甚監芖

AC-2

アカりント管理

䜎

遞定

AC-2 (11) アカりント管理 | 利甚状態

遞定

AC-2 (12) アカりント管理 | アカりント監芖・非察称利甚

遞定

AC-2 (13) アカりント管理 | アカりント審査

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、物理的セキュリティ、人的セキュリティ、
䟵入怜知、監査手段の匷化がある。
管理拡匵(1, 3, 4) ICS 補足ガむダンス補償的管理策の䟋ずしお、非自動メカニズム又は手
順がある。
管理拡匵(2) ICS 補足ガむダンスICSフィヌルドデバむス等が臚時又は緊急アカりン
トに察応できない堎合、この拡匵は適甚されない。補償的管理策の䟋ずしお、非自動メカニズム
又は手順がある。
管理拡匵(5) ICS 補足ガむダンス補償的管理策の䟋ずしお、非自動メカニズム又は手順があ
る。
管理拡匵(11, 12, 13) ICS 補足ガむダンスなし

368

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AC-3 ACCESS ENFORCEMENT
CONTROL NAME
CNTL NO.
AC-3

CONTROL BASELINES

Control Enhancement Name
Access Enforcement

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The organization ensures that access enforcement mechanisms do not adversely impact the
operational performance of the ICS. Example compensating controls include encapsulation. Policy for logical access control to NonAddressable and Non-Routable system resources and the associated information is made explicit. Access control mechanisms include
hardware, firmware, and software that controls or has device access, such as device drivers and communications controllers. Physical access
control may serve as a compensating control for logical access control, however, it may not provide sufficient granularity in situations where
users require access to different functions. Logical access enforcement may be implemented in encapsulating hardware and software.
AC-4 INFORMATION FLOW ENFORCEMENT
CONTROL NAME
CNTL NO.
AC-4

CONTROL BASELINES

Control Enhancement Name

LOW

Information Flow Enforcement

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Physical addresses (e.g., a serial port) may be implicitly or explicitly associated with labels or
attributes (e.g., hardware I/O address). Manual methods are typically static. Label or attribute policy mechanisms may be implemented in
hardware, firmware, and software that controls or has device access, such as device drivers and communications controllers. Information
flow policy may be supported by labeling or coloring physical connectors as an aid to manual hookup. Inspection of message content may
enforce information flow policy. For example, a message containing a command to an actuator may not be permitted to flow between the
control network and any other network.
AC-5 SEPARATION OF DUTIES
CONTROL NAME
CNTL NO.
AC-5

CONTROL BASELINES

Control Enhancement Name

LOW

Separation of Duties

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include providing increased personnel security and auditing. The
organization carefully considers the appropriateness of a single individual performing multiple critical roles.
AC-6 LEAST PRIVILEGE
CONTROL NAME
CNTL NO.

CONTROL BASELINES

Control Enhancement Name

MOD

HIGH

Least Privilege

Selected

Selected

AC-6 (1)

LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY
FUNCTIONS

Selected

Selected

AC-6 (2)

LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR
NONSECURITY FUNCTIONS

Selected

Selected

AC-6 (3)

LEAST PRIVILEGE | NETWORK ACCESS TO PRIVILEGED
COMMANDS

AC-6 (5)

LEAST PRIVILEGE | PRIVILEGED ACCOUNTS

Selected

Selected

AC-6 (9)

LEAST PRIVILEGE | AUDITING USE OF PRIVILEGED
FUNCTIONS

Selected

Selected

AC-6 (10)

LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS
FROM EXECUTING PRIVILEGED FUNCTIONS

Selected

Selected

AC-6

LOW

Selected

ICS Supplemental Guidance: Example compensating controls include providing increased personnel security and auditing. The
organization carefully considers the appropriateness of a single individual having multiple critical

369

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

アクセスの斜行

AC-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名
アクセス斜行

AC-3

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス組織は、アクセス斜行メカニズムが ICS の運甚パフォヌマンスに悪圱
響しないようにする。補償管理にはカプセル化がある。アドレス/ルヌト指定䞍胜システムリ゜
ヌス及び関連情報ぞの論理アクセス制埡ポリシヌは明確にする。アクセス制埡メカニズムには、
ハヌドり゚ア、ファヌムり゚アのほか、デバむスドラむバや通信コントロヌラ等、デバむスの制
埡又はアクセスを行う゜フトり゚アがある。物理的アクセス制埡は、論理アクセス制埡に代わる
補償的管理策ずなるが、ナヌザが別機胜ぞのアクセスを求める堎合のきめ现かさがない。論理ア
クセス斜行は、ハヌドり゚アず゜フトり゚アのカプセル化で実斜できる。
AC-4

情報フロヌの斜行
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
情報フロヌ斜行

AC-4

äž­

高

遞定

遞定

ICS 補足ガむダンス物理アドレスシリアルポヌト等は、黙瀺的又は明瀺的にラベル又
は属性ハヌドり゚ア I/O アドレス等に関連づける。マニュアル操䜜は䞀般に静的である。ラ
ベル又は属性メカニズムは、ハヌドり゚ア、ファヌムり゚アのほか、デバむスドラむバや通信コ
ントロヌラ等、デバむスの制埡又はアクセスを行う゜フトり゚アに実装される。情報フロヌポリ
シヌは、マニュアル操䜜䜜業の助けずしお、物理的コネクタぞのラベル付けや着色により支えら
れる。メッセヌゞ内容の怜査は、情報フロヌポリシヌを斜行するものずなる。䟋えば、アクチュ
゚ヌタぞのコマンドを含んだメッセヌゞは、制埡ネットワヌクず他のネットワヌク間で流れない
ようにしなければならない。
AC-5

任務分担
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
任務分担

AC-5

äž­

高

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、人的セキュリティず監査の匷化がある。組
織は、1 人で耇数の重芁な圹割を果たすのが適切かどうか、慎重に怜蚎する。
AC-6

最小暩限
管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

最小暩限

䜎

遞定

遞定

AC-6 (1)

最小暩限 | セキュリティ機胜ぞのアクセス蚱可

遞定

遞定

AC-6 (2)

最小暩限 | 非セキュリティ機胜ぞの無暩限アクセス

遞定

遞定

AC-6 (3)

最小暩限 | 特暩コマンドぞのネットワヌクアクセス

AC-6 (5)

最小暩限 | 特暩アカりント

遞定

遞定

AC-6 (9)

最小暩限 | 特暩機胜の監査利甚

遞定

遞定

AC-6 (10)

最小暩限 | 無暩限ナヌザによる特暩機胜の実行犁止

遞定

遞定

AC-6

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、人的セキュリティず監査の匷化がある。組
織は、1 人で耇数の重芁特暩を持぀のが適切かどうか、慎重に怜蚎する。

370

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

privileges. System privilege models may be tailored to enforce integrity and availability (e.g., lower privileges include read access and higher
privileges include write access).
Control Enhancement: (1) ICS Supplemental Guidance: In situations where the ICS cannot support access control to security
functions, the organization employs nonautomated mechanisms or procedures as compensating controls in accordance with the general
tailoring guidance.
Control Enhancement: (2) ICS Supplemental Guidance: In situations where the ICS cannot support access control to nonsecurity
functions, the organization employs nonautomated mechanisms or procedures as compensating controls in accordance with the general
tailoring guidance.
Control Enhancement: (3) ICS Supplemental Guidance: In situations where the ICS cannot support network access control to
privileged commands, the organization employs nonautomated mechanisms or procedures as compensating controls in accordance with the
general tailoring guidance.
Control Enhancement: (5) ICS Supplemental Guidance: In situations where the ICS cannot support access control to privileged
accounts, the organization employs nonautomated mechanisms or procedures as compensating controls in accordance with the general
tailoring guidance.
Control Enhancement: (9) ICS Supplemental Guidance: In general, audit record processing is not performed on the ICS, but on a
separate information system. Example compensating controls include providing an auditing capability on a separate information system.
Control Enhancement: (10) ICS Supplemental Guidance: Example compensating controls include enhanced auditing.
AC-7 UNSUCCESSFUL LOGIN ATTEMPTS
CONTROL NAME
CNTL NO.
AC-7

CONTROL BASELINES

Control Enhancement Name
Unsuccessful Login Attempts

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Many ICS must remain continuously on and operators remain logged onto the system at all times. A
“log-over” capability may be employed. Example compensating controls include logging or recording all unsuccessful login attempts and
alerting ICS security personnel though alarms or other means when the number of organization-defined consecutive invalid access attempts
is exceeded.
AC-8 SYSTEM USE NOTIFICATION
CONTROL NAME
CNTL NO.
AC-8

CONTROL BASELINES

Control Enhancement Name
System Use Notification

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Many ICS must remain continuously on and system use notification may not be supported or
effective. Example compensating controls include posting physical notices in ICS facilities.
AC-10 CONCURRENT SESSION CONTROL
CONTROL NAME
CNTL NO.
AC-10

CONTROL BASELINES

Control Enhancement Name

LOW

MOD

Concurrent Session Control

HIGH
Selected

ICS Supplemental Guidance: The number, account type, and privileges of concurrent sessions takes into account the roles and
responsibilities of the affected individuals. Example compensating controls include providing increased auditing measures.

371

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

システム特暩モデルをカスタマむズしお、完党性ず可甚性を斜行できるより䜎い特暩には読み
取りアクセス、より高い特暩には曞き蟌みアクセスがある。
管理拡匵(1) ICS 補足ガむダンスICS がセキュリティ機胜ぞのアクセス制埡に察応しおい
ない状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順を
採甚する。
管理拡匵(2) ICS 補足ガむダンスICS が非セキュリティ機胜ぞのアクセス制埡に察応しお
いない状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順
を採甚する。
管理拡匵(3) ICS 補足ガむダンスICS が特暩コマンドぞのネットワヌクアクセス制埡に察
応しおいない状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又
は手順を採甚する。
管理拡匵(5) ICS 補足ガむダンスICS が特暩アカりントぞのアクセス制埡に察応しおいな
い状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順を採
甚する。
管理拡匵(9) ICS 補足ガむダンス総じお、監査蚘録凊理は ICS で行われず、別個の情報シ
ステムで行われる。補償的管理策の䟋ずしお、別個の情報システムぞの監査胜力の付䞎がある。
管理拡匵(10) ICS 補足ガむダンス補償的管理策の䟋ずしお、拡匵監査がある。

AC-7

ログむン倱敗
管理名

管理番号

管理ベヌスラむン

管理拡匵名
ログむン倱敗

AC-7

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス倚くの ICS は電源を入れたたたにしなければならず、操䜜員も垞時シ
ステムにログオン状態を維持しおいる。「ログオヌバヌ」機胜を採甚できる。補償的管理策の䟋
ずしお、党おログむン倱敗時のログ又は蚘録を取り、予め決めた連続倱敗数に達するず、ICS セ
キュリティ担圓者にアラヌムその他の手段で譊報を送るようにできる。
AC-8

システム利甚通知
管理名

管理番号

管理ベヌスラむン

管理拡匵名
システム利甚通知

AC-8

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス倚くの ICS は電源を入れたたたにしおおかなければならず、システム
利甚通知は察応しないか効果的でない。補償的管理策の䟋ずしお、ICS 斜蚭内に通知を掲瀺する
方法がある。
AC-10

同時セッション管理
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

AC-10

同時セッション管理

äž­

高
遞定

ICS 補足ガむダンス同時セッションの番号、アカりントタむプ及び特暩には、圱響を受け
る個人の圹割ず責任を考慮に入れる。補償的管理策の䟋ずしお、監査手段の匷化がある。

372

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AC-11 SESSION LOCK
CONTROL NAME
CNTL NO.
AC-11
AC-11 (1)

CONTROL BASELINES

Control Enhancement Name

MOD

HIGH

Session Lock

LOW

Selected

Selected

SESSION LOCK | PATTERN-HIDING DISPLAYS

Selected

Selected

ICS Supplemental Guidance: This control assumes a staffed environment where users interact with information system displays.
When this assumption does not apply the organization tailors the control appropriately (e.g., the ICS may be physically protected by
placement in a locked enclosure). The control may also be tailored for ICS that are not configured with displays, but which have the
capability to support displays (e.g., ICS to which a maintenance technician may attach a display). In some cases, session lock for ICS
operator workstations/nodes is not advised (e.g., when immediate operator responses are required in emergency situations). Example
compensating controls include locating the display in an area with physical access controls that limit access to individuals with permission
and need-to-know for the displayed information.
Control Enhancement: (1) ICS Supplemental Guidance: ICS may employ physical protection to prevent access to a display or to
prevent attachment of a display. In situations where the ICS cannot conceal displayed information, the organization employs nonautomated
mechanisms or procedures as compensating controls in accordance with the general tailoring guidance.
AC-12 SESSION TERMINATION
CONTROL NAME
CNTL NO.
AC-12

CONTROL BASELINES

Control Enhancement Name

LOW

Session Termination

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include providing increased auditing measures or limiting remote
access privileges to key personnel.
AC-14 PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION
CONTROL NAME
CNTL NO.
AC-14

CONTROL BASELINES

Control Enhancement Name

LOW

Permitted Actions without Identification or Authentication

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
AC-17 REMOTE ACCESS
CONTROL NAME
CNTL NO.
AC-17

CONTROL BASELINES

Control Enhancement Name
Remote Access

LOW

MOD

HIGH

Selected

Selected

Selected

AC-17 (1)

REMOTE ACCESS | AUTOMATED MONITORING / CONTROL

Selected

Selected

AC-17 (2)

REMOTE ACCESS | PROTECTION OF CONFIDENTIALITY /

Selected

Selected

INTEGRITY USING ENCRYPTION
AC-17 (3)

REMOTE ACCESS | MANAGED ACCESS CONTROL POINTS

Selected

Selected

AC-17 (4)

REMOTE ACCESS | PRIVILEGED COMMANDS / ACCESS

Selected

Selected

ICS Supplemental Guidance: In situations where the ICS cannot implement any or all of the components of this control, the
organization employs other mechanisms or procedures as compensating controls in accordance with the general tailoring guidance.
Control Enhancement: (1) ICS Supplemental Guidance: Example compensating controls include employing nonautomated
mechanisms or procedures as compensating controls (e.g., following manual authentication [see IA-2], dial-in remote access may be enabled
for a specified period of time or a call may be placed from the ICS site to the authenticated remote entity.

373

SP800-82 第 2 版

AC-11

産業甚制埡システムICSセキュリティガむド

セッションロック
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
セッションロック

AC-11

AC-11 (1) セッションロック パタヌン非衚瀺

äž­

高

遞定

遞定

遞定

遞定

ICS 補足ガむダンスこの管理は、ナヌザが情報システムディスプレむずやり取りを行う有
人環境を想定しおいる。想定ず異なる環境では、組織は管理を適切にカスタマむズする鍵のか
かるキャビネットなど ICS の物理的保護等。補償的管理策の䟋ずしお、ディスプレむが蚭定さ
れおいないものの、接続しようず思えばできる ICS のカスタマむズがある保守技術者によるデ
ィスプレむの蚭眮等。堎合によっおは、ICS 操䜜員ワヌクステヌション/ノヌドのセッションロ
ックが掚奚できないこずもある緊急時に操䜜員の即時察応が必芁等。補償的管理策の䟋ずし
お、暩限があり衚瀺情報を知る必芁のある人員だけが立入できる堎所に、ディスプレむを蚭眮す
るこずがある。
管理拡匵(1) ICS 補足ガむダンスディスプレむぞのアクセスやディスプレむの接続を防止
する物理的保護を採甚できる。ICS が衚瀺情報を隠蔜できない状況では、党䜓的なカスタマむズ
ガむダンスに埓っお、組織は非自動メカニズム又は手順を補償的管理策ずしお採甚する。
AC-12

セッション終了
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
セッション終了

AC-12

äž­

高

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、監査手段の匷化やリモヌトアクセス特暩を
重芁な人員に制限する方法がある。
AC-14

識別・認蚌のない蚱可された行為
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
識別・認蚌のない蚱可された行為

AC-14

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
AC-17

リモヌトアクセス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

遞定

遞定

遞定

AC-17 (1) リモヌトアクセス | 自動監芖・管理

遞定

遞定

AC-17 (2) リモヌトアクセス | 暗号化による機密性・完党性の保護

遞定

遞定

AC-17 (3) リモヌトアクセス | 管理アクセス制埡ポむント

遞定

遞定

AC-17 (4) リモヌトアクセス | 特暩コマンド・アクセス

遞定

遞定

AC-17

リモヌトアクセス

ICS 補足ガむダンスICS がこの管理芁玠の䞀郚又は党郚を実行できない状況では、党䜓的
なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順を補償的管理策ずしお採
甚する。
管理拡匵(1) ICS 補足ガむダンス補償的管理策の䟋ずしお、非自動メカニズム又は手順を
補償的管理策ずしお採甚できる手動認蚌に埓い[IA-2 参照]、ダむアルむンリモヌトアクセスを
䞀定期間有効にするか、発呌を ICS サむトから認蚌枈み遠隔機関に移蚭するなど。

374

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Control Enhancement: (2) ICS Supplemental Guidance: ICS security objectives often rank confidentiality below availability and
integrity. The organization explores all possible cryptographic mechanism (e.g., encryption, digital signature, hash function). Each
mechanism has a different delay impact. Example compensating controls include providing increased auditing for remote sessions or limiting
remote access privileges to key personnel).
Control Enhancement: (3) ICS Supplemental Guidance: Example compensating controls include connection-specific manual
authentication of the remote entity.
Control Enhancement: (4) No ICS Supplemental Guidance.
ICS Supplemental Guidance: Example compensating controls include employing nonautomated mechanisms or procedures as
compensating controls in accordance with the general tailoring guidance.
AC-18 WIRELESS ACCESS
CONTROL NAME
CNTL NO.
AC-18

CONTROL BASELINES

Control Enhancement Name
Wireless Access

LOW
Selected

MOD

HIGH

Selected

Selected

Selected

Selected

AC-18 (1)

WIRELESS ACCESS | AUTHENTICATION AND ENCRYPTION

AC-18 (4)

WIRELESS ACCESS | RESTRICT CONFIGURATIONS BY
USERS

Selected

AC-18 (5)

WIRELESS ACCESS | CONFINE WIRELESS
COMMUNICATIONS

Selected

ICS Supplemental Guidance: In situations where the ICS cannot implement any or all of the components of this control, the
organization employs other mechanisms or procedures as compensating controls in accordance with the general tailoring guidance.
Control Enhancement: (1) ICS Supplemental Guidance: See AC-17 Control Enhancement: (1) ICS Supplemental Guidance.
Example compensating controls include providing increased auditing for wireless access or limiting wireless access privileges to key
personnel.
Control Enhancement: (4) (5) No ICS Supplemental Guidance.
AC-19 ACCESS CONTROL FOR MOBILE DEVICES
CONTROL NAME
CNTL NO.
AC-19
AC-19 (5)

CONTROL BASELINES

Control Enhancement Name
Access Control for Mobile Devices

LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE /
CONTAINER-BASED ENCRYPTION

No ICS Supplemental Guidance.
AC-20 USE OF EXTERNAL INFORMATION SYSTEMS
CONTROL NAME
CNTL NO.
AC-20

CONTROL BASELINES

Control Enhancement Name
Use of External Information Systems

LOW

MOD

HIGH

Selected

Selected

Selected

AC-20 (1)

USE OF EXTERNAL INFORMATION SYSTEMS | LIMITS ON
AUTHORIZED USE

Selected

Selected

AC-20 (2)

USE OF EXTERNAL INFORMATION SYSTEMS | PORTABLE
STORAGE MEDIA

Selected

Selected

ICS Supplemental Guidance: Organizations refine the definition of “external” to reflect lines of authority and responsibility;
granularity of organization entity; and their relationships. An organization may consider a system to be external if that system performs
different functions, implements different policies, comes under different managers, or does not provide sufficient visibility into the
implementation of security controls to allow the establishment of a satisfactory trust relationship. For example, a process control system and
a business data processing system would typically be considered external to each other. Access to an ICS for support by a business partner,
such as a vendor or support contractor, is another common example. The definition and trustworthiness of external information systems is
reexamined with respect to ICS functions, purposes, technology, and limitations to

375

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

管理拡匵(2) ICS 補足ガむダンスICS のセキュリティ目暙では、機密性が可甚性及び完党
性よりも䞋䜍にランクされるこずが倚い。組織はあらゆる暗号メカニズムを掻甚する暗号化、
デゞタル眲名、ハッシュ関数等。各メカニズムの遅延圱響はそれぞれ異なる。補償的管理策の
䟋ずしお、遠隔セッションに察する監査の匷化やリモヌトアクセス特暩を重芁な人員に制限する
方法がある。
管理拡匵(3) ICS 補足ガむダンス補償的管理策の䟋ずしお、遠隔機関の接続固有の手動認
蚌がある。
管理拡匵(4) ICS 補足ガむダンスなし
ICS 補足ガむダンス補償的管理策の䟋ずしお、党䜓的なカスタマむズガむダンスに埓っお、
非自動メカニズム又は手順を補償的管理策ずしお採甚できる。
AC-18

ワむダレスアクセス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
ワむダレスアクセス

AC-18

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

AC-18 (1) ワむダレスアクセス | 認蚌・暗号化
AC-18 (4) ワむダレスアクセス | ナヌザ蚭定の制限

遞定

AC-18 (5) ワむダレスアクセス | ワむダレス通信の封じ蟌め

遞定

ICS 補足ガむダンスICS がこの管理芁玠の䞀郚又は党郚を実行できない状況では、党䜓的
なカスタマむズガむダンスに埓っお、組織は他のメカニズム又は手順を補償的管理策ずしお採甚
する。
管理拡匵(1) ICS 補足ガむダンスAC-17 管理拡匵を参照(1) ICS 補足ガむダンス。補償
的管理策の䟋ずしお、ワむダレスアクセスに察する監査の匷化やワむダレスアクセス特暩を重芁
な人員に制限する方法がある。
管理拡匵(4) (5) ICS 補足ガむダンスなし
AC-19

モバむルデバむス甚アクセス制埡
管理名

管理番号

AC-19

管理ベヌスラむン

管理拡匵名
モバむルデバむス甚アクセス制埡

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

AC-19 (5) モバむルデバむス甚アクセス制埡 | フルデバむス/コンテナベヌス

暗号化

ICS 補足ガむダンスなし
AC-20 倖郚情報システムの利甚
管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

遞定

遞定

遞定

AC-20 (1) 倖郚情報システムの利甚 | 蚱可された利甚の制限

遞定

遞定

AC-20 (2) 倖郚情報システムの利甚 | 携行ストレヌゞメディア

遞定

遞定

AC-20

倖郚情報システムの利甚

䜎

ICS 補足ガむダンス「倖郚」の定矩を粟査しお、暩限・責任、組織実䜓の粒床及びそれら
の関係を反映する。あるシステムが違う機胜を実行し、違うポリシヌを採甚し、管理者が違い、
満足できる信頌関係を築くためのセキュリティ察策の可芖化が䞍十分な堎合、組織はそれを倖郚
ずみなせる。䟋えば、プロセス制埡システムず事業甚デヌタ凊理システムは、通垞盞互に倖郚ず
みなされる。ベンダヌやサポヌト契玄者等、事業提携者からの支揎で ICS にアクセスする堎合も、
よくある倖郚の䟋である。ICS の機胜、目的、技術及び制限に関しお、倖郚情報システムの定矩
ず信頌性を再怜蚌し、

376

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

establish a clear documented technical or business case for use and an acceptance of the risk inherent in the use of an external information
system.
Control Enhancement: (1, 2) No ICS Supplemental Guidance.
AC-21 INFORMATION SHARING
CONTROL NAME
CNTL NO.
AC-21

CONTROL BASELINES

Control Enhancement Name
Collaboration and Information Sharing

LOW

MOD

HIGH

Added

Selected

Selected

ICS Supplemental Guidance: The organization should collaborate and share information about potential incidents on a timely basis.
The DHS National Cybersecurity & Communications Integration Center (NCCIC), http://www.dhs.gov/about-national-cybersecuritycommunications-integration-center serves as a centralized location where operational elements involved in cybersecurity and
communications reliance are coordinated and integrated. The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)
http://ics-cert.us-cert.gov/ics-cert/ collaborates with international and private sector Computer Emergency Response Teams (CERTs) to share
control systems-related security incidents and mitigation measures. Organizations should consider having both an unclassified and classified
information sharing capability.
Rationale for adding AC-21 to low baseline: ICS systems provide essential services and control functions and are often connected
to other ICS systems or business systems that can be vectors of attack. It is therefore necessary to provide a uniform defense encompassing
all baselines.
AC-22 PUBLICLY ACCESSIBLE CONTENT
CONTROL NAME
CNTL NO.
AC-22

CONTROL BASELINES

Control Enhancement Name
Publicly Accessible Content

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Generally, public access to ICS systems is not permitted. Selected information may be transferred to a
publicly accessible information system, possibly with added controls (e.g., introduction of fuzziness or delay).

377

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

倖郚情報システムの利甚ず、利甚に䌎うリスクを受け入れる旚の明確な技術・事業文曞を䜜成す
る。
管理拡匵(1) (2) ICS 補足ガむダンスなし
AC-21

情報共有
管理名

管理番号

管理ベヌスラむン

管理拡匵名
連携・情報共有

AC-21

䜎

äž­

高

远加

遞定

遞定

ICS 補足ガむダンス組織は、生じ埗るむンシデントに関しお、連携し情報を適時に共有す
べきである。䞋蚘 DHS 囜家サむバヌセキュリティ通信統合センタヌ(NCCIC)は集䞭所圚地ずしお
機胜し、サむバヌセキュリティず通信の信頌性に関わる運甚芁玠はそこで調敎され、統合化され
おいる。http://www.dhs.gov/about-national-cybersecurity-communications-integration-center
䞋蚘産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)は、海倖及び民間のコンピュヌ
タ緊急察応チヌム(CERT)ず連携しお、制埡システム関連セキュリティむンシデント情報ず緩和
察策を共有しおいる。
http://ics-cert.us-cert.gov/ics-cert/
組織は、秘密情報ず普通情報の共有化に぀いお怜蚎すべきである。
AC-21 を䜎ベヌスラむンに远加する理由ICS システムは、重芁なサヌビスず制埡機胜を提
䟛しおおり、攻撃経路ずなり埗る他の ICS システムや事業システムに接続しおいるこずが倚い。
したがっお、党おのベヌスラむンを網矅した統䞀的な防埡が必芁ずなる。
AC-22

公開コンテンツ
管理名

管理番号

AC-22

管理ベヌスラむン

管理拡匵名
公開コンテンツ

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス䞀般的に、ICS システムぞの公開アクセスは蚱可されおいない。遞別
した情報が、付加的な管理制限曖昧さや遅れ等を加えた䞊で、公開の情報システムに転送さ
れるこずもある。

378

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AWARENESS AND TRAINING – AT
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
AT-1 SECURITY AWARENESS AND TRAINING POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
AT-1

CONTROL BASELINES

Control Enhancement Name
Security Awareness and Training Policy and Procedures

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
AT-2 SECURITY AWARENESS TRAINING
CONTROL NAME
CNTL NO.
AT-2

CONTROL BASELINES

Control Enhancement Name
Security Awareness

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Security awareness training includes initial and periodic review of ICS-specific policies, standard
operating procedures, security trends, and vulnerabilities. The ICS security awareness program is consistent with the requirements of the
security awareness and training policy established by the organization.
Control Enhancement: (2) No ICS Supplemental Guidance.
AT-3 ROLE-BASED SECURITY TRAINING
CONTROL NAME
CNTL NO.
AT-3

CONTROL BASELINES

Control Enhancement Name
Role-Based Security Training

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Security training includes initial and periodic review of ICS-specific policies, standard operating
procedures, security trends, and vulnerabilities. The ICS security training program is consistent with the requirements of the security
awareness and training policy established by the organization.
AT-4 SECURITY TRAINING RECORDS
CONTROL NAME
CNTL NO.
AT-4

CONTROL BASELINES

Control Enhancement Name
Security Training Records

No ICS Supplemental Guidance.

379

LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

意識・蚓緎 – AT
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
AT-1

セキュリティ意識・蚓緎ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名

セキュリティ意識・蚓緎ポリシヌ・手順

AT-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
AT-2

セキュリティ意識蚓緎
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ意識

AT-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスセキュリティ意識蚓緎には、ICS 固有ポリシヌ、暙準運甚手順、セキ
ュリティ動向及び脆匱性に察する圓初の蚓緎ず定期的な埩習が含たれる。ICS セキュリティ意識
プログラムは、組織が蚭定したセキュリティ意識・蚓緎ポリシヌ芁件ず敎合しおいる。
管理拡匵(2) ICS 補足ガむダンスなし
AT-3

圹割ベヌスセキュリティ蚓緎
管理名

管理番号

管理ベヌスラむン

管理拡匵名
圹割ベヌスセキュリティ蚓緎

AT-3

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスセキュリティ蚓緎には、ICS 固有ポリシヌ、暙準運甚手順、セキュリ
ティ動向及び脆匱性に察する圓初の蚓緎ず定期的な埩習が含たれる。ICS セキュリティプログラ
ムは、組織が蚭定したセキュリティ意識・蚓緎ポリシヌ芁件ず敎合しおいる。
AT-4

セキュリティ蚓緎蚘録
管理名

管理番号

AT-4

管理ベヌスラむン

管理拡匵名
セキュリティ蚓緎蚘録

ICS 補足ガむダンスなし

380

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AUDITING AND ACCOUNTABILITY – AU
Tailoring Considerations for Audit Family
In general, audit information and audit tools are not present on legacy ICS, but on a separate information system (e.g., the historian).
In situations where the ICS cannot support the specific Audit and Accountability requirements of a control, the organization employs
compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as
appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
AU-1 AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-1

Audit and Accountability Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
AU-2 AUDIT EVENTS
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-2
AU-2 (3)

Auditable Events

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected
Selected

Selected
Selected

AUDITABLE EVENTS | REVIEWS AND UPDATES

ICS Supplemental Guidance: The organization may designate ICS events as audit events, requiring that ICS data and/or telemetry
be recorded as audit data.
Control Enhancement: (3) No ICS Supplemental Guidance.
AU-3 CONTENT OF AUDIT RECORDS

CNTL NO.
AU-3
AU-3 (1)
AU-3 (2)

CONTROL NAME
Control Enhancement Name
Content of Audit Records

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected
Selected

Selected
Selected

CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT
INFORMATION
CONTENT OF AUDIT RECORDS | CENTRALIZED
MANAGEMENT OF PLANNED AUDIT RECORD CONTENT

Selected

ICS Supplemental Guidance: Example compensating controls include providing an auditing capability on a separate information
system.
Control Enhancement: (1, 2) No ICS Supplemental Guidance.
AU-4 AUDIT STORAGE CAPACITY

CNTL NO.
AU-4
AU-4 (1)

CONTROL NAME
Control Enhancement Name
Audit Storage Capacity
AUDIT STORAGE CAPACITY | TRANSFER TO ALTERNATE
STORAGE

CONTROL BASELINES
LOW

MOD

HIGH

Selected
Added

Selected
Added

Selected
Added

No ICS Supplemental Guidance.
Control Enhancement: (1) ICS Supplemental Guidance: Legacy ICS are typically configured with remote storage on a separate
information system (e.g., the historian accumulates historical operational ICS data and is backed up for

381

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

監査・説明責任 – AU
監査ファミリのカスタマむズ考慮事項
䞀般に、監査情報や監査ツヌルは、レガシヌICS にはないが、別個の情報システム䞊にあるヒ
ストリアン等。ICS がある制埡の特定の監査・説明責任芁件に察応しおいない状況では、党䜓
的なカスタマむズガむダンスに埓っお補償的管理策を採甚する。補償的管理策の䟋が必芁に応じ
お、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
AU-1

監査・説明責任ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査・説明責任ポリシヌ・手順

AU-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
AU-2

監査事象
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査事象

AU-2
AU-2 (3)

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

監査事象 | 審査・曎新

ICS 補足ガむダンス組織は ICS 事象を監査事象ず指定し、ICS デヌタやテレメトリ-を監査
デヌタずしおの蚘録を矩務づける。
管理拡匵(3) ICS 補足ガむダンスなし
AU-3

監査蚘録内容
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査蚘録内容

AU-3
AU-3 (1)

監査蚘録内容| 補足監査情報

AU-3 (2)

監査蚘録内容 | 蚈画監査蚘録内容の集䞭管理

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、別個の情報システムぞの監査胜力の付䞎が
ある。
管理拡匵(1) (2) ICS 補足ガむダンスなし
AU-4

監査ストレヌゞ容量
管理名

管理番号

AU-4
AU-4 (1)

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

監査ストレヌゞ容量

遞定

遞定

遞定

監査ストレヌゞ容量 | 代替ストレヌゞぞの移行

远加

远加

远加

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンス通垞レガシヌICS は、別個の情報システム䞊の遠隔ストレヌゞ
に蚭定があるヒストリアンは ICS の運甚履歎デヌタを蓄積し、別サむトのストレヌゞに保管する。

382

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

storage at a different site). ICS are currently using online backup services and increasingly moving to Cloud based and Virtualized services.
Retention of some data (e.g., SCADA telemetry) may be required by regulatory authorities.
Rationale for adding AU-4 (1) to all baselines: Legacy ICS components typically do not have capacity to store or analyze audit data.
The retention periods for some data, particularly compliance data, may require large volumes of storage.
AU-5 RESPONSE TO AUDIT PROCESSING FAILURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-5
AU-5 (1)

Response to Audit Processing Failures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

RESPONSE TO AUDIT PROCESSING FAILURES | AUDIT STORAGE

Selected

CAPACITY
AU-5 (2)

RESPONSE TO AUDIT PROCESSING FAILURES | REAL-TIME ALERTS

Selected

No ICS Supplemental Guidance.
AU-6 AUDIT REVIEW, ANALYSIS, AND REPORTING
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-6
AU-6 (1)

Audit Review, Analysis, and Reporting

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

Selected

Selected

AUDIT REVIEW, ANALYSIS, AND REPORTING | PROCESS
INTEGRATION

AU-6 (3)

AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT
REPOSITORIES

AU-6 (5)

AUDIT REVIEW, ANALYSIS, AND REPORTING | INTEGRATION /

Selected

SCANNING AND MONITORING CAPABILITIES
AU-6 (6)

AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATION WITH

Selected

PHYSICAL MONITORING

No ICS Supplemental Guidance.
Control Enhancement: (1) ICS Supplemental Guidance: Example compensating controls include manual mechanisms or
procedures.
Control Enhancement: (3, 5, 6) No ICS Supplemental Guidance.
AU-7 AUDIT REDUCTION AND REPORT GENERATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-7
AU-7 (1)

CONTROL BASELINES
MOD

HIGH

Audit Reduction and Report Generation

LOW

Selected

Selected

AUDIT REDUCTION AND REPORT GENERATION | AUTOMATIC

Selected

Selected

PROCESSING

No ICS Supplemental Guidance.
Control Enhancement: (1) No ICS Supplemental Guidance.
AU-8 TIME STAMPS
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-8
AU-8 (1)

Time Stamps
TIME STAMPS | SYNCHRONIZATION WITH AUTHORITATIVE TIME

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

SOURCE

ICS Supplemental Guidance: Example compensating controls include using a separate information system designated as an
authoritative time source.
Control Enhancement: (1) ICS Supplemental Guidance: ICS employ suitable mechanisms (e.g., GPS, IEEE 1588) for time
stamps.

383

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

ICS は今のずころオンラむンバックアップサヌビスを利甚しおいるが、クラりドベヌスの仮想サ
ヌビスに次第に移行しおいる。特定のデヌタSCADA テレメトリヌ等の保持が芏制圓局から
矩務づけられる堎合がある。
AU-4 (1)を党おのベヌスラむンに远加する理由䞀般にレガシヌICS コンポヌネントには、
監査デヌタの保存又は分析容量がない。特定のデヌタ、特にコンプラむアンスデヌタの保持期間
によっお保管量が倧きくなる。
監査凊理䞍備ぞの察応

AU-5

管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査凊理䞍備ぞの察応

AU-5

䜎

äž­

高

遞定

遞定

遞定

AU-5 (1)

監査凊理䞍備ぞの察応 | 監査ストレヌゞ容量

遞定

AU-5 (2)

監査凊理䞍備ぞの察応 | リアルタむム譊報

遞定

ICS 補足ガむダンスなし
AU-6

監査の審査・分析・報告
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査の審査・分析・報告

AU-6

䜎

äž­

高

遞定

遞定

遞定

AU-6 (1)

監査の審査・分析・報告 | プロセスの䞀䜓化

遞定

遞定

AU-6 (3)

監査の審査・分析・報告 | 監査レポゞトリの盞関

遞定

遞定

AU-6 (5)

監査の審査・分析・報告 | 䞀䜓化

遞定

スキャン・監芖胜力
AU-6 (6)

監査の審査・分析・報告 | 物理的監芖ずの盞関

遞定

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンス補償的管理策の䟋ずしお、手動メカニズム又は手順があ
る。
管理拡匵(3, 5, 6) ICS 補足ガむダンスなし
AU-7

監査削枛・報告曞䜜成
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

AU-7
AU-7 (1)

äž­

高

監査削枛・報告曞䜜成

遞定

遞定

監査削枛・報告曞䜜成 | 自動凊理

遞定

遞定

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンスなし
AU-8

タむムスタンプ
管理名

管理番号

AU-8
AU-8 (1)

管理ベヌスラむン

管理拡匵名
タむムスタンプ

タむムスタンプ | 公認時間゜ヌスずの同期

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、公認時間゜ヌスに指定された別個の情報シ
ステムを利甚する方法がある。
管理拡匵(1) ICS 補足ガむダンスタむムスタンプずしお、ICS では適正なメカニズムを採
甚する党地球枬䜍システム[GPS]、IEEE 1588 等。

384

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

AU-9 PROTECTION OF AUDIT INFORMATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-9
AU-9 (2)

Protection of Audit Information

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected
Selected

PROTECTION OF AUDIT INFORMATION | AUDIT BACKUP ON
SEPARATE PHYSICAL SYSTEMS / COMPONENTS

AU-9 (3)

Selected

PROTECTION OF AUDIT INFORMATION | CRYPTOGRAPHIC
PROTECTION

AU-9 (4)

Selected

PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF

Selected

PRIVILEGED USERS

No ICS Supplemental Guidance.
AU-10 NON-REPUDIATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-10

CONTROL BASELINES
LOW

MOD

HIGH
Selected

Non-repudiation

ICS Supplemental Guidance: Example compensating controls include providing non-repudiation on a separate information system.
AU-11 AUDIT RECORD RETENTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-11

Audit Record Retention

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
AU-12 AUDIT GENERATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
AU-12
AU-12 (1)

Audit Generation

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

AUDIT GENERATION | SYSTEM-WIDE / TIME-CORRELATED AUDIT

Selected

TRAIL
AU-12 (3)

AUDIT GENERATION | CHANGES BY AUTHORIZED INDIVIDUALS

Selected

No ICS Supplemental Guidance.
Control Enhancement: (1) ICS Supplemental Guidance: Example compensating controls include providing time-correlated audit
records on a separate information system.
Control Enhancement: (3) ICS Supplemental Guidance: Example compensating controls include employing nonautomated
mechanisms or procedures.

385

SP800-82 第 2 版

AU-9

産業甚制埡システムICSセキュリティガむド

監査情報の保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査情報の保護

AU-9
AU-9 (2)

䜎

äž­

高

遞定

遞定

遞定

監査情報の保護 | 別の物理システム/コンポヌネントぞの監査バッ

遞定

クアップ
AU-9 (3)

監査情報の保護 | 暗号化保護

AU-9 (4)

監査情報の保護 | 特暩ナヌザのサブセットによるアクセス

遞定
遞定

遞定

ICS 補足ガむダンスなし
AU-10

吊認防止
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

吊認防止

AU-10

高
遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、別個の情報システムぞの吊認防止機胜の付
䞎がある。
AU-11

監査蚘録保持
管理名

管理番号

管理ベヌスラむン

管理拡匵名
監査蚘録保留

AU-11

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
AU-12

監査䜜成
管理名

管理番号

AU-12

管理ベヌスラむン

管理拡匵名
監査䜜成

䜎

äž­

高

遞定

遞定

遞定

AU-12 (1) 監査䜜成 | 党システム | 時間盞関監査蚌跡

遞定

AU-12 (3) 監査䜜成 | 暩限ある個人による倉曎

遞定

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンス補償的管理策の䟋ずしお、別個の情報システムぞの時間
盞関監査蚘録の付䞎がある。
管理拡匵(3) ICS 補足ガむダンス補償的管理策の䟋ずしお、非自動メカニズム又は手
順がある。

386

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SECURITY ASSESSMENT AND AUTHORIZATION – CA
Tailoring Considerations for Security Assessment and Authorization Family
In situations where the ICS cannot support the specific Security Assessment and Authorization requirements of a control, the
organization employs compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given
with each control, as appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
CA-1 SECURITY ASSESSMENT AND AUTHORIZATION POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
CA-1

Security Assessment and Authorization Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
CA-2 SECURITY ASSESSMENTS

CNTL NO.
CA-2

CONTROL NAME
Control Enhancement Name
Security Assessments

CA-2 (1)

SECURITY ASSESSMENTS | INDEPENDENT ASSESSORS

CA-2 (2)

SECURITY ASSESSMENTS | TYPES OF ASSESSMENTS

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected
Selected

ICS Supplemental Guidance: Assessments are performed and documented by qualified assessors (i.e., experienced in assessing
ICS) authorized by the organization. The organization ensures that assessments do not interfere with ICS functions. The individual/group
conducting the assessment fully understands the organizational information security policies and procedures, the ICS security policies and
procedures, and the specific health, safety, and environmental risks associated with a particular facility and/or process. The organization
ensures that the assessment does not affect system operation or result in unintentional system modification. If assessment activities must be
performed on the production ICS, it may need to be taken off-line before an assessment can be conducted. If an ICS must be taken off-line to
conduct an assessment, the assessment is scheduled to occur during planned ICS outages whenever possible.
Control Enhancement: (1) No ICS Supplemental Guidance.
Control Enhancement: (2) ICS Supplemental Guidance: The organization conducts risk analysis to support the selection of
assessment target (e.g., the live system, an off-line replica, a simulation).
CA-3 SYSTEM INTERCONNECTIONS

CNTL NO.
CA-3
CA-3 (5)

CONTROL NAME
Control Enhancement Name
Information System Connections
SYSTEM INTERCONNECTIONS | RESTRICTIONS ON EXTERNAL

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected
Selected

SYSTEM CONNECTIONS

ICS Supplemental Guidance: Organizations perform risk-benefit analysis to support determination whether an ICS should be
connected to other information system(s). The Authorizing Official fully understands the organizational information security policies and
procedures; the ICS security policies and procedures; the risks to organizational operations and assets, individuals, other organizations, and
the Nation associated with the connection to other information system(s); and the specific health, safety, and environmental risks associated
with a particular interconnection. The AO documents risk acceptance in the ICS system security plan.
Control Enhancement: (5) No ICS Supplemental Guidance.

387

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

セキュリティ評䟡・暩限付䞎 – CA
セキュリティ評䟡・暩限付䞎ファミリのカスタマむズ考慮事項
ICS がある制埡の特定のセキュリティ評䟡・暩限付䞎芁件に察応しおいない状況では、党䜓的な
カスタマむズガむダンスに埓っお補償的管理策を採甚する。補償管理の䟋が必芁に応じお、管理
策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
CA-1

セキュリティ評䟡・暩限付䞎ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ評䟡・暩限付䞎ポリシヌ・手順

CA-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
CA-2

セキュリティ評䟡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ評䟡

CA-2
CA-2 (1)

セキュリティ評䟡 | 独立評䟡者

CA-2 (2)

セキュリティ評䟡 | 評䟡の皮類

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

ICS 補足ガむダンス有資栌者ICS 評䟡熟緎者による評䟡を行い文曞化し、組織の承認
を埗る。評䟡が ICS 機胜ず干枉しないようにする。評䟡を行う個人やグルヌプは、組織の情報セ
キュリティポリシヌ・手順、ICS のセキュリティポリシヌ・手順及び特定の斜蚭やプロセスに付
随する具䜓的な健康・安党・環境リスクを十分理解する。組織は評䟡によっおシステム運甚が圱
響を受けず、意図しないシステム倉曎にならないようにする。評䟡掻動を生産 ICS で実斜しなけ
ればならない堎合、評䟡の実斜前にオフラむンにする必芁がある堎合がある。オフラむンにしな
ければならない堎合、可胜であれば、予め蚈画された ICS の操業停止時に評䟡を行うように予定
を組む。
管理拡匵(1) ICS 補足ガむダンスなし
管理拡匵(2) ICS 補足ガむダンス組織はリスク分析を行い、評䟡察象の遞別を支揎する
ラむブシステム、オフラむンレプリカ、シミュレヌション等。
CA-3

システム連接
管理名

管理番号

CA-3
CA-3 (5)

管理ベヌスラむン

管理拡匵名
情報システムの接続

システム連接 | 倖郚システムずの接続制限

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

ICS 補足ガむダンス組織はリスク䟿益分析を行い、ICS ず他の情報システムずの接続の是
非を刀断する。蚱可暩者は、次の事項に぀いお十分理解する。組織の情報セキュリティポリシ
ヌ・手順。ICS のセキュリティポリシヌ・手順。他の情報システムぞの接続に付随する組織の運
甚、資産、個人、他の組織及び囜に察するリスク。特定の連接に付随する具䜓的な健康・安党・
環境リスク。AO は、ICS システムセキュリティ蚈画曞におけるリスク受容性に぀いお蚘茉しおい
る。
管理拡匵(5) ICS 補足ガむダンスなし

388

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CA-5 PLAN OF ACTION AND MILESTONES
CONTROL NAME
Control Enhancement Name

CNTL NO.
CA-5

Plan of Action and Milestones

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
CA-6 SECURITY AUTHORIZATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
CA-6

Security Authorization

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
CA-7 CONTINUOUS MONITORING
CONTROL NAME
Control Enhancement Name

CNTL NO.
CA-7
CA-7 (1)

Continuous Monitoring

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

CONTINUOUS MONITORING | INDEPENDENT ASSESSMENT

ICS Supplemental Guidance: Continuous monitoring programs for ICS are designed, documented, and implemented by qualified
personnel (i.e., experienced with ICS) selected by the organization. The organization ensures that continuous monitoring does not interfere
with ICS functions. The individual/group designing and conducting the continuous monitoring fully understands the organizational
information security policies and procedures, the ICS security policies and procedures, and the specific health, safety, and environmental
risks associated with a particular facility and/or process. The organization ensures that continuous monitoring does not affect system
operation or result in intentional or unintentional system modification. Example compensating controls include external monitoring.
Control Enhancement: (1) No ICS Supplemental Guidance.
CA-8 PENETRATION TESTING

CNTL NO.
CA-8

CONTROL NAME
Control Enhancement Name

CONTROL BASELINES
LOW

MOD

HIGH
Selected

Penetration Testing

ICS Supplemental Guidance: Penetration testing is used with care on ICS networks to ensure that ICS functions are not adversely
impacted by the testing process. In general, ICS are highly sensitive to timing constraints and have limited resources. Example compensating
controls include employing a replicated, virtualized, or simulated system to conduct penetration testing. Production ICS may need to be taken
off-line before testing can be conducted. If ICS are taken off-line for testing, tests are scheduled to occur during planned ICS outages
whenever possible. If penetration testing is performed on non-ICS networks, extra care is taken to ensure that tests do not propagate into the
ICS network.

389

SP800-82 第 2 版

CA-5

産業甚制埡システムICSセキュリティガむド

行動・マむルストヌン蚈画曞
管理名

管理番号

管理ベヌスラむン

管理拡匵名
行動・マむルストヌン蚈画曞

CA-5

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
CA-6

セキュリティ暩限
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ暩限

CA-6

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
CA-7

継続監芖
管理名

管理番号

管理ベヌスラむン

管理拡匵名
継続監芖

CA-7
CA-7 (1)

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

継続監芖 | 独立評䟡

ICS 補足ガむダンスICS の継続監芖は、組織が遞任した有資栌者が考案し、文曞化し、実
斜するICS の熟緎者等。継続監芖が ICS 機胜ず干枉しないようにする。継続監芖を考案しお
実斜する個人やグルヌプは、組織の情報セキュリティポリシヌ・手順、ICS のセキュリティポリ
シヌ・手順及び特定の蚈接やプロセスに付随する具䜓的な健康・安党・環境リスクを十分理解す
る。組織は継続監芖によっおシステム運甚が圱響を受けず、故意又は意図しないシステム倉曎に
ならないようにする。補償的管理策の䟋ずしお、倖郚監芖がある。
管理拡匵(1) ICS 補足ガむダンスなし
CA-8

ペネトレヌション・テスト
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

CA-8

ペネトレヌション・テスト

äž­

高
遞定

ICS 補足ガむダンスICS ネットワヌクでのペネトレヌション・テストは慎重に行い、詊隓
プロセスにより ICS 機胜に悪圱響が及ばないようにする。総じお ICS は、時間的制玄に敏感で、
リ゜ヌスに限界がある。補償的管理策の䟋ずしお、耇補、仮想又は暡擬システムでペネトレヌシ
ョン・テストを行う方法がある。生産 ICS は、詊隓前にオフラむンにする必芁がある。オフラむ
ンにする堎合、可胜であれば、予め蚈画された ICS の操業停止時に詊隓を行うように予定を組む。
ペネトレヌション・テストを ICS 以倖のネットワヌクで行う堎合、詊隓が ICS に持ち蟌たれない
ように泚意する。

390

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CA-9 INTERNAL SYSTEM CONNECTIONS

CNTL NO.
CA-9

CONTROL NAME
Control Enhancement Name
Internal System Connections

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Organizations perform risk-benefit analysis to support determination whether an ICS should be
connected to other internal information system(s) and (separate) constituent system components. The Authorizing Official fully understands
the organizational information security policies and procedures; the ICS security policies and procedures; the risks to organizational
operations and assets, individuals, other organizations, and the Nation associated with the connected to other information system(s) and
(separate) constituent system components, whether by authorizing each individual internal connection or authorizing internal connections for
a class of components with common characteristics and/or configurations; and the specific health, safety, and environmental risks associated
with a particular interconnection. The AO documents risk acceptance in the ICS system security plan.

391

SP800-82 第 2 版

CA-9

内郚システム接続
管理名

管理番号

CA-9

産業甚制埡システムICSセキュリティガむド

管理ベヌスラむン

管理拡匵名
内郚システム接続

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス組織はリスク䟿益分析を行い、ICS ず他の内郚情報システムや別
構成システムコンポヌネントずの接続の是非を刀断する。蚱可暩者は、次の事項に぀いお十分理
解する。組織の情報セキュリティポリシヌ・手順。ICS のセキュリティポリシヌ・手順。個々人
の内郚接続を蚱可するか、共通特性・蚭定のコンポヌネントクラスぞの内郚接続を蚱可するこず
により、他の情報システム及び別構成システムコンポヌネントぞの接続に䌎う組織の運甚、
資産、個人、他の組織及び囜に察するリスク。特定の連接に付随する具䜓的な健康・安党・環境
リスク。AO は、ICS システムセキュリティ蚈画曞におけるリスク受容性に぀いお蚘茉しおいる。

392

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CONFIGURATION MANAGEMENT – CM
Tailoring Considerations for Configuration Management Family
In situations where the ICS cannot be configured to restrict the use of unnecessary functions or cannot support the use of automated
mechanisms to implement configuration management functions, the organization employs nonautomated mechanisms or procedures as
compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as
appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
CM-1 CONFIGURATION MANAGEMENT POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-1

Configuration Management Policy and Procedures

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
CM-2 BASELINE CONFIGURATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-2
CM-2 (1)
CM-2 (2)
CM-2 (3)
CM-2 (7)

Baseline Configuration
BASELINE CONFIGURATION | REVIEWS AND UPDATES
BASELINE CONFIGURATION | AUTOMATION SUPPORT FOR
ACCURACY / CURRENCY
BASELINE CONFIGURATION | RETENTION OF PREVIOUS
CONFIGURATIONS
BASELINE CONFIGURATION | CONFIGURE SYSTEMS,
COMPONENTS, OR DEVICES FOR HIGH-RISK AREAS

CONTROL BASELINES
LOW
Selected

MOD
Selected
Selected

HIGH
Selected
Selected
Selected

Selected

Selected

Selected

Selected

No ICS Supplemental Guidance.
CM-3 CONFIGURATION CHANGE CONTROL
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-3
CM-3 (1)
CM-3 (2)

CONTROL BASELINES
LOW

Configuration Change Control
CONFIGURATION CHANGE CONTROL | AUTOMATED
DOCUMENT / NOTIFICATION / PROHIBITION OF CHANGES
CONFIGURATION CHANGE CONTROL | TEST / VALIDATE /
DOCUMENT CHANGES

MOD
Selected

HIGH
Selected
Selected

Selected

Selected

No ICS Supplemental Guidance.
CM-4 SECURITY IMPACT ANALYSIS

CNTL NO.
CM-4
CM-4 (1)

CONTROL NAME
Control Enhancement Name
Security Impact Analysis
SECURITY IMPACT ANALYSIS | SEPARATE TEST
ENVIRONMENTS

CONTROL BASELINES
LOW
Selected

ICS Supplemental Guidance: The organization considers ICS safety and security interdependencies.
Control Enhancement: (1) No ICS Supplemental Guidance.

393

MOD
Selected

HIGH
Selected
Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

蚭定管理 – CM
蚭定管理ファミリのカスタマむズ考慮事項
ICS で䞍芁な機胜の制限や蚭定管理機胜の自動メカニズムの利甚ができない状況では、党䜓的な
カスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順を補償的管理策ずしお採甚
する。補償的管理策の䟋が必芁に応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
CM-1

蚭定管理ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
蚭定管理ポリシヌ・手順

CM-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
CM-2

ベヌスラむン蚭定
管理名

管理番号

管理ベヌスラむン

管理拡匵名
ベヌスラむン蚭定

CM-2
CM-2 (1)

ベヌスラむン蚭定 | 審査・曎新

CM-2 (2)

ベヌスラむン蚭定 | 正確性・カレンシヌの自動サポヌト

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

CM-2 (3) ベヌスラむン蚭定 | 以前の蚭定保持
CM-2 (7)

ベヌスラむン蚭定 | 高リスク゚リア甚システム・コンポヌネン

遞定

遞定

遞定

遞定

ト・デバむスの蚭定

ICS 補足ガむダンスなし
CM-3

蚭定倉曎管理
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
蚭定倉曎管理

CM-3
CM-3 (1)

äž­

高

遞定

遞定

蚭定倉曎管理 | 自動文曞化・

遞定

通知・倉曎犁止
CM-3 (2)

蚭定倉曎管理 | 詊隓・怜蚌・文曞倉曎

遞定

遞定

ICS 補足ガむダンスなし
CM-4

セキュリティ圱響分析
管理名

管理番号

CM-4
CM-4 (1)

管理ベヌスラむン

管理拡匵名
セキュリティ圱響分析

セキュリティ圱響分析 | 独立詊隓環境

䜎

äž­

高

遞定

遞定

遞定
遞定

ICS 補足ガむダンス組織は ICS の安党性ずセキュリティの盞互関係を怜蚎する。
管理拡匵(1) ICS 補足ガむダンスなし

394

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CM-5 ACCESS RESTRICTIONS FOR CHANGE
CONTROL NAME
Control Enhancement Name

CNTL NO.

CONTROL BASELINES
LOW

CM-5
CM-5 (1)

Access Restrictions for Change
ACCESS RESTRICTIONS FOR CHANGE | AUTOMATED
ACCESS ENFORCEMENT / AUDITING
CM-5 (2)
ACCESS RESTRICTIONS FOR CHANGE | AUDIT SYSTEM
CHANGES
CM-5 (3)
ACCESS RESTRICTIONS FOR CHANGE | SIGNED
COMPONENTS
No ICS Supplemental Guidance.

MOD
Selected

HIGH
Selected
Selected
Selected
Selected

CM-6 CONFIGURATION SETTINGS
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-6
CM-6 (1)

Configuration Settings
CONFIGURATION SETTINGS | AUTOMATED CENTRAL
MANAGEMENT / APPLICATION / VERIFICATION
CM-6 (2)
CONFIGURATION SETTINGS | RESPOND TO UNAUTHORIZED
CHANGES
No ICS Supplemental Guidance.

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected
Selected
Selected

CM-7 LEAST FUNCTIONALITY

CNTL NO.
CM-7
CM-7 (1)
CM-7 (2)
CM-7 (4)

CONTROL NAME
Control Enhancement Name
Least Functionality
LEAST FUNCTIONALITY | PERIODIC REVIEW
LEAST FUNCTIONALITY | PREVENT PROGRAM EXECUTION
LEAST FUNCTIONALITY | UNAUTHORIZED SOFTWARE

CONTROL BASELINES
LOW
Selected
Added

MOD
Selected
Selected
Removed
Added

HIGH
Selected
Selected
Selected
Selected

ICS Supplemental Guidance: Ports, as used in NIST SP 800-53 Rev. 4, are part of the address space in network protocols and are
often associated with specific protocols or functions. As such, ports are not relevant to non-routable protocols and devices. When dealing
with non-routable and non-addressable protocols and devices, prohibiting or restricting the use of specified functions, protocols, and/or
services must be implemented for the (sub)system granularity that is available (e.g., at a low level, interrupts could be disabled; at a high
level, set points could be made read-only except for privileged users). Example compensating controls include employing nonautomated
mechanisms or procedures.
Control Enhancement: (1, 2, 5) No ICS Supplemental Guidance.
Control Baseline Supplement Rationale: (1) Periodic review and removal of unnecessary and/or nonsecure functions,
ports, protocols, and services are added to the LOW baseline because many of the LOW impact ICS components could
adversely affect the systems to which they are connected.
(4, 5) Whitelisting (CE 5) is more effective than blacklisting (CE 4). The set of applications that run in ICS is essentially
static, making whitelisting practical. ICS-CERT recommends deploying application whitelisting on ICS. Reference: http://icscert.us-cert.gov/tips/ICS-TIP-12-146-01B
CM-8 INFORMATION SYSTEM COMPONENT INVENTORY

CNTL NO.
CM-8
CM-8 (1)
CM-8 (2)
CM-8 (3)

CONTROL NAME
Control Enhancement Name
Information System Component Inventory
INFORMATION SYSTEM COMPONENT INVENTORY |
UPDATES DURING INSTALLATIONS / REMOVALS
INFORMATION SYSTEM COMPONENT INVENTORY |
AUTOMATED MAINTENANCE
INFORMATION SYSTEM COMPONENT INVENTORY |
AUTOMATED UNAUTHORIZED COMPONENT DETECTION

395

CONTROL BASELINES
LOW
Selected

MOD
Selected
Selected

HIGH
Selected
Selected
Selected

Selected

Selected

SP800-82 第 2 版

CM-5

産業甚制埡システムICSセキュリティガむド

倉曎甚アクセス制限
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
倉曎甚アクセス制限

CM-5

äž­

高

遞定

遞定

CM-5 (1)

倉曎甚アクセス制限 | 自動アクセスの斜行 / 監査

遞定

CM-5 (2)

倉曎甚アクセス制限 | 監査システム倉曎

遞定

CM-5 (3)

倉曎甚アクセス制限 | 眲名コンポヌネント

遞定

ICS 補足ガむダンスなし
CM-6

構成蚭定
管理名

管理番号

管理ベヌスラむン

管理拡匵名
構成蚭定

CM-6
CM-6 (1)

䜎

äž­

高

遞定

遞定

遞定

構成蚭定 | 自動集䞭管理

遞定

アプリケヌション / 怜蚌
CM-6 (2)

構成蚭定 | 無断倉曎察応

遞定

ICS 補足ガむダンスなし
CM-7

最小暩限
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

最䜎限機胜

遞定

遞定

遞定

CM-7 (1)

最䜎限機胜 | 定期的芋盎し

远加

遞定

遞定

CM-7 (2)

最䜎限機胜 | プログラム実行防止

削陀

遞定

CM-7 (4)

最䜎限機胜 | 未蚱可゜フトり゚ア

远加

遞定

CM-7

ICS 補足ガむダンスNIST SP 800-53 第 4 版で䜿甚されるポヌトは、ネットワヌクプロトコルにおけるアド
レス空間の䞀郚で、特定のプロトコルや機胜に関連づけられおいるこずが倚い。このようなポヌトは、経路指定
䞍胜プロトコル及びデバむスではない。アドレス/ルヌト指定䞍胜プロトコル及びデバむスの堎合、指定機胜、プ
ロトコル又はサヌビス利甚の犁止又は制限は、利甚できるサブシステムの粒床に実装しなければならない
䜎レベルでは䞭断を無効にし、高レベルでは蚭定点を特暩ナヌザ以倖は読み取り専甚ずするなど。補償的管
理策の䟋ずしお、非自動メカニズム又は手順がある。
管理拡匵(1, 2, 5) ICS 補足ガむダンスなし
管理ベヌスラむン補足理由(1)䞍芁又はセキュアでない機胜、ポヌト、プロトコル及びサヌビスの定期的な
芋盎しず削陀を䜎ベヌスラむンに远加した。理由は圱響床䜎の ICS コンポヌネントの倚くは、接続先システムに
悪圱響を及がすため。
(4, 5) ホワむトリスト(CE 5)はブラックリスト(CE 4)よりも効果的。ICS で実行するアプリケヌションセットは基本
的に静的であるため、ホワむトリストが珟実的である。ICS-CERT は、ホワむトリストアプリケヌションの ICS 展
開を掚奚しおいる。参考文献http://ics-cert.us- cert.gov/tips/ICS-TIP-12-146-01B

CM-8

情報システムコンポヌネント目録

管理番号

CM-8

管理名

管理ベヌスラむン

管理拡匵名
情報システムコンポヌネント目録

CM-8 (1)

情報システムコンポヌネント目録 | むンストヌル・削陀時の曎新

CM-8 (2)

情報システムコンポヌネント目録 | 自動保守

CM-8 (3)

情報システムコンポヌネント目録 | 自動無蚱可コンポヌネント怜知

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

396

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-8 (4)

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CONTROL BASELINES
LOW

MOD

HIGH
Selected

INFORMATION SYSTEM COMPONENT INVENTORY |
PROPERTY ACCOUNTABILITY INFORMATION

CM-8 (5)

Selected

INFORMATION SYSTEM COMPONENT INVENTORY | ALL

Selected

COMPONENTS WITHIN AUTHORIZATION BOUNDARY
No ICS Supplemental Guidance.
CM-9 CONFIGURATION MANAGEMENT PLAN
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-9

CONTROL BASELINES
LOW

Configuration Management Plan

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
CM-10 SOFTWARE USAGE RESTRICTIONS
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-10

Software Usage Restrictions

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
CM-11 USER-INSTALLED SOFTWARE
CONTROL NAME
Control Enhancement Name

CNTL NO.
CM-11

User-Installed Software

No ICS Supplemental Guidance.

397

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

CM-8 (4)

情報システムコンポヌネント目録 | 資産説明責任情報

CM-8 (5)

情報システムコンポヌネント目録 | 党コンポヌネントが暩限内

äž­

高
遞定

遞定

遞定

ICS 補足ガむダンスなし
CM-9

蚭定管理蚈画曞
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

CM-9

蚭定管理蚈画曞

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
CM-10 ゜フトり゚ア䜿甚制限
管理名

管理番号

CM-10

管理ベヌスラむン

管理拡匵名
゜フトり゚ア䜿甚制限

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
CM-11 ナヌザがむンストヌルした゜フトり゚ア
管理名

管理番号

CM-11

管理ベヌスラむン

管理拡匵名
ナヌザがむンストヌルした゜フトり゚ア

ICS 補足ガむダンスなし

398

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CONTINGENCY PLANNING - CP
Tailoring Considerations for Contingency Planning Family
ICS systems often contain a physical component at a fixed location. Such components may not be relocated logically. Some replacement
components may not be readily available. Continuance of essential missions and business functions with little or no loss of operational
continuity may not be possible. In situations where the organization cannot provide necessary essential services, support, or automated
mechanisms during contingency operations, the organization provides nonautomated mechanisms or predetermined procedures as
compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as
appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
CP-1 CONTINGENCY PLANNING POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-1

Contingency Planning Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
CP-2 CONTINGENCY PLAN
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-2

Contingency Plan

CP-2 (1)

CONTINGENCY PLAN | COORDINATE WITH RELATED PLANS

CP-2 (2)

CONTINGENCY PLAN | CAPACITY PLANNING

CP-2 (3)

CONTINGENCY PLAN | RESUME ESSENTIAL MISSIONS /

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected
Selected

Selected

Selected

BUSINESS FUNCTIONS
CP-2 (4)

CONTINGENCY PLAN | RESUME ALL MISSIONS / BUSINESS

Selected

FUNCTIONS
CP-2 (5)

CONTINGENCY PLAN | CONTINUE ESSENTIAL MISSIONS /

Selected

BUSINESS FUNCTIONS
CP-2 (8)

CONTINGENCY PLAN | IDENTIFY CRITICAL ASSETS

Selected

Selected

ICS Supplemental Guidance: The organization defines contingency plans for categories of disruptions or failures. In the event of a
loss of processing within the ICS or communication with operational facilities, the ICS executes predetermined procedures (e.g., alert the
operator of the failure and then do nothing, alert the operator and then safely shut down the industrial process, alert the operator and then
maintain the last operational setting prior to failure).
Control Enhancement: (1) ICS Supplemental Guidance: Organizational elements responsible for related plans may include
suppliers such as electric power, fuel, fresh water and wastewater.
Control Enhancement: (2) No ICS Supplemental Guidance.
Control Enhancement: (3, 4) ICS Supplemental Guidance: Plans for the resumption of essential missions and business functions,
and for resumption of all missions and business functions take into account the effects of the disruption on the environment of operation.
Restoration and resumption plans should include prioritization of efforts. Disruptions may affect the quality and quantity of resources in the
environment, such as electric power, fuel, fresh water and wastewater, and the ability of these suppliers to also resume provision of essential
mission and business functions. Contingency plans for widespread disruption may involve specialized organizations (e.g., FEMA, emergency
services, regulatory authorities). Reference: NFPA 1600: Standard on Disaster/Emergency Management and Business Continuity Programs.
Control Enhancement: (5, 8) No ICS Supplemental Guidance.

399

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

䞍枬事態蚈画 - CP
䞍枬事態蚈画ファミリのカスタマむズ考慮事項
ICS システムには、定められた堎所に物理コンポヌネントがある堎合が倚い。それらは論理的な
移動ができない。代わりのコンポヌネントがすぐに利甚できないものもある。䞭断がほずんど又
は党く蚱されない重芁任務や事業もある。䞍枬事態運甚䞭に、必芁な重芁サヌビス、サポヌト又
は自動メカニズムを提䟛できない状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は
非自動メカニズム又は事前蚭定手順を補償的管理策ずしお採甚する。補償的管理策の䟋が必芁に
応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
CP-1

䞍枬事態蚈画ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䞍枬事態蚈画ポリシヌ・手順

CP-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
CP-2

緊急時察応蚈画
管理名

管理番号

CP-2

管理ベヌスラむン

管理拡匵名
緊急時察応蚈画

CP-2 (1)

緊急時察応蚈画 | 関連蚈画曞ずの敎合

CP-2 (2)

緊急時察応蚈画 | 容量蚈画

CP-2 (3)

緊急時察応蚈画 | 重芁任務・事業機胜の再開

CP-2 (4)

緊急時察応蚈画 | 党任務・事業機胜の再開

CP-2 (5)

緊急時察応蚈画 | 重芁任務・事業機胜の再開

CP-2 (8)

緊急時察応蚈画 | 重芁資産識別

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

遞定

遞定
遞定
遞定

遞定

遞定

ICS 補足ガむダンス組織は、䞭断や故障の分類別に緊急時察応蚈画を定める。ICS 内での
凊理や運甚斜蚭ずの通信が倱われた堎合、ICS は予め定められた手順を実行する操䜜員に譊報
を発信しお䜕もしない、操䜜員に譊報を発信しお産業プロセスを安党に遮断する、操䜜員に譊報
を発信しお故障盎前の動䜜を維持するなど。
管理拡匵(1) ICS 補足ガむダンス関連蚈画曞の担圓郚眲には、電力、燃料、䞊䞋氎道等の
サプラむダも含たれる。
管理拡匵(2) ICS 補足ガむダンスなし
管理拡匵(3, 4) ICS 補足ガむダンス重芁任務・事業機胜の再開に関する蚈画曞及び党おの
任務・事業機胜の再開に関する蚈画曞には、運甚環境が厩壊した堎合の圱響を考慮に入れる。埩
旧・再開蚈画曞には、取組の優先順䜍を含めるべきである。䞭断が生じるず電力、燃料、䞊䞋氎
道等のリ゜ヌスの質・量のみならず、重芁任務・事業を再開するサプラむダの胜力にも圱響が出
る。倧芏暡䞭断の緊急時察応蚈画には、特別組織を含めるFEMA、緊急サヌビス、芏制圓局
等。参考文献NFPA 1600:灜害・気球時管理・事業継続プログラムの基準
管理拡匵(5) (8) ICS 補足ガむダンスなし

400

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CP-3 CONTINGENCY TRAINING
CONTROL NAME
Control Enhancement Name

CNTL NO.

CP-3
Contingency Training
CP-3 (1)
CONTINGENCY TRAINING | SIMULATED EVENTS
No ICS Supplemental Guidance.

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected
Selected

CP-4 CONTINGENCY PLAN TESTING
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-4
CP-4 (1)

Contingency Plan Testing
CONTINGENCY PLAN TESTING | COORDINATE WITH RELATED
PLANS
P-4 (2)
CONTINGENCY PLAN TESTING | ALTERNATE PROCESSING SITE
No ICS Supplemental Guidance.

CONTROL BASELINES
LOW
Selected

MOD
Selected
Selected

HIGH
Selected
Selected
Selected

CP-6 ALTERNATE STORAGE SITE

CNTL NO.

CONTROL NAME
Control Enhancement Name

CP-6
CP-6 (1)

Alternate Storage Site
ALTERNATE STORAGE SITE | SEPARATION FROM PRIMARY SITE

CONTROL BASELINES
LOW

ALTERNATE STORAGE SITE | RECOVERY TIME / POINT
OBJECTIVES
CP-6 (3)
ALTERNATE STORAGE SITE | ACCESSIBILITY
No ICS Supplemental Guidance.

MOD
Selected
Selected

CP-6 (2)

HIGH
Selected
Selected
Selected

Selected

Selected

CP-7 ALTERNATE PROCESSING SITE

CNTL NO.

CONTROL NAME
Control Enhancement Name

CONTROL BASELINES
LOW

CP-7
CP-7 (1)

Alternate Processing Site
ALTERNATE PROCESSING SITE | SEPARATION FROM PRIMARY
SITE
CP-7 (2)
ALTERNATE PROCESSING SITE | ACCESSIBILITY
CP-7 (3)
ALTERNATE PROCESSING SITE | PRIORITY OF SERVICE
CP-7 (4)
ALTERNATE PROCESSING SITE | CONFIGURATION FOR USE
No ICS Supplemental Guidance.

MOD
Selected
Selected

HIGH
Selected
Selected

Selected
Selected

Selected
Selected
Selected

CP-8 TELECOMMUNICATIONS SERVICES

CNTL NO.

CONTROL NAME
Control Enhancement Name

CP-8
CP-8 (1)

Telecommunications Services
TELECOMMUNICATIONS SERVICES | PRIORITY OF SERVICE
PROVISIONS
CP-8 (2)
TELECOMMUNICATIONS SERVICES | SINGLE POINTS OF
FAILURE
CP-8 (3)
TELECOMMUNICATIONS SERVICES | SEPARATION OF PRIMARY
/ ALTERNATE PROVIDERS
CP-8 (4)
TELECOMMUNICATIONS SERVICES | PROVIDER CONTINGENCY
PLAN
ICS Supplemental Guidance: Quality of service factors for ICS include latency and throughput.
Control Enhancement: (1, 2, 3, 4) No ICS Supplemental Guidance.

401

CONTROL BASELINES
LOW

MOD
Selected
Selected

HIGH
Selected
Selected

Selected

Selected
Selected
Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

䞍枬事態蚓緎

CP-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䞍枬事態蚓緎

CP-3
CP-3 (1)

䜎

äž­

高

遞定

遞定

遞定

䞍枬事態蚓緎 | 暡擬事象

遞定

ICS 補足ガむダンスなし
CP-4

緊急時察応蚈画の怜蚌
管理名

管理番号

管理ベヌスラむン

管理拡匵名
緊急時察応蚈画の怜蚌

CP-4
CP-4 (1)

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

緊急時察応蚈画の怜蚌 | 関連蚈画曞ずの敎合
緊急時察応蚈画の怜蚌 | 代替凊理サむト

P-4 (2)

遞定

ICS 補足ガむダンスなし
CP-6

代替ストレヌゞサむト
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

代替ストレヌゞサむト

遞定

遞定

CP-6 (1)

代替ストレヌゞサむト | プラむマリサむトからの分離

遞定

遞定

CP-6 (2)

代替ストレヌゞサむト | 埩旧時間・ポむント目暙

CP-6 (3)

代替ストレヌゞサむト | アクセシビリティ

CP-6

遞定
遞定

遞定

ICS 補足ガむダンスなし
CP-7

代替凊理サむト
管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

代替凊理サむト

䜎

遞定

遞定

CP-7 (1)

代替凊理サむト | プラむマリサむトからの分離

遞定

遞定

CP-7 (2)

代替凊理サむト | アクセシビリティ

遞定

遞定

CP-7 (3)

代替凊理サむト | サヌビスの優先順䜍

遞定

遞定

CP-7 (4)

代替凊理サむト | 利甚向け蚭定

CP-7

遞定

ICS 補足ガむダンスなし
CP-8

電気通信サヌビス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

CP-8
CP-8 (1)
CP-8 (2)
CP-8 (3)
CP-8 (4)

電気通信サヌビス

電気通信サヌビス | サヌビス提䟛の優先順䜍
電気通信サヌビス | 障害単点
電気通信サヌビス | 䞻・副プロバむダの分割
電気通信サヌビス | プロバむダの䞍枬事態䜓蚈画曞

äž­

高

遞定
遞定

遞定
遞定

遞定

遞定
遞定
遞定

ICS 補足ガむダンスICS のサヌビス品質には埅ち時間ずスルヌプットが含たれる。
管理拡匵(1, 2, 3, 4) ICS 補足ガむダンスなし

402

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

CP-9 INFORMATION SYSTEM BACKUP
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-9
CP-9 (1)

Information System Backup

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

INFORMATION SYSTEM BACKUP | TESTING FOR RELIABILITY
/ INTEGRITY

CP-9 (2)

INFORMATION SYSTEM BACKUP | TEST RESTORATION

Selected

USING SAMPLING
CP-9 (3)

INFORMATION SYSTEM BACKUP | SEPARATE STORAGE FOR

Selected

CRITICAL INFORMATION
CP-9 (5)

INFORMATION SYSTEM BACKUP | TRANSFER TO

Selected

ALTERNATE SITE
No ICS Supplemental Guidance.
CP-10 INFORMATION SYSTEM RECOVERY AND RECONSTITUTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-10
CP-10 (2)

Information System Recovery and Reconstitution

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

INFORMATION SYSTEM RECOVERY AND RECONSTITUTION |
TRANSACTION RECOVERY

CP-10 (4)

INFORMATION SYSTEM RECOVERY AND RECONSTITUTION |

Selected

RESTORE WITHIN TIME PERIOD
ICS Supplemental Guidance: Reconstitution of the ICS includes consideration whether system state variables should be restored to
initial values or values before disruption (e.g., are valves restored to full open, full closed, or settings prior to disruption). Restoring system
state variables may be disruptive to ongoing physical processes (e.g., valves initially closed may adversely affect system cooling).
Control Enhancement: (2, 4) No ICS Supplemental Guidance.
CP-12 SAFE MODE
CONTROL NAME
Control Enhancement Name

CNTL NO.
CP-12

Safe Mode

CONTROL BASELINES
LOW

MOD

HIGH

Added

Added

Added

ICS Supplemental Guidance: The organization-defined conditions and corresponding restrictions of safe mode of operation may
vary among baselines. The same condition(s) may trigger different response depending on the impact level. The conditions may be external
to the ICS (e.g., electricity supply brown-out). Related controls: SI-17.
Rationale for adding CP-12 to all baselines: This control provides a framework for the organization to plan their policy and
procedures for dealing with conditions beyond their control in the environment of operations. Creating a written record of the decision
process for selecting incidents and appropriate response is part of risk management in light of changing environment of operations.

403

SP800-82 第 2 版

CP-9

産業甚制埡システムICSセキュリティガむド

情報システムバックアップ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
情報システムバックアップ

CP-9

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

CP-9 (1)

情報システムバックアップ | 信頌性・完党性の怜蚌

CP-9 (2)

情報システムバックアップ | サンプリングによる埩旧詊隓

遞定

CP-9 (3)

情報システムバックアップ | 重芁情報の分離保管

遞定

CP-9 (5)

情報システムバックアップ | 代替サむトぞの移行

遞定

ICS 補足ガむダンスなし
CP-10

情報システムの埩旧・再構築
管理名

管理番号

管理ベヌスラむン

管理拡匵名
情報システムの埩旧・再構築

CP-10

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

CP-10 (2) 情報システムの埩旧・再構築 |

トランザクションの埩旧
CP-10 (4) 情報システムの埩旧・再構築 | 期限内の埩旧

遞定

ICS 補足ガむダンスICS の再構築には、システム状態倉数を䞭断前の初期倀に戻すかどう
かの怜蚎が含たれるバルブは党開か党閉か、䞭断前の蚭定倀かなど。システム状態倉数を元
に戻すず、進行䞭の物理プロセスが䞭断する堎合があるバルブが閉じおシステムの冷华に悪圱
響等。
管理拡匵(2) (4) ICS 補足ガむダンスなし
CP-12

セヌフモヌド
管理名

管理番号

CP-12

管理ベヌスラむン

管理拡匵名
セヌフモヌド

䜎

äž­

高

远加

远加

远加

ICS 補足ガむダンス組織が定矩した条件及び察応する安党運甚モヌドの制限は、ベヌスラ
むンによっおたちたちである。同じ条件でも、圱響床によっお別の察応ずなる。条件は ICS にず
っお、倖郚のものずなる停電等。関連する管理SI-17
CP-12 を党おのベヌスラむンに远加する理由この管理は、組織が運甚環境で自らの制埡が
及ばない条件を扱う堎合に、ポリシヌ・手順を蚈画する䜓系ずなる。むンシデントず適切な察応
を遞ぶ際の決定プロセスを文曞にするこずは、運甚環境の倉化ずいう芳点から、リスク管理の䞀
郚ずなる

404

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

IDENTIFICATION AND AUTHENTICATION - IA
Tailoring Considerations for Identification and Authentication Family
Before implementing controls in the IA family, consider the tradeoffs among security, privacy, latency, performance, and throughput.
For example, the organization considers whether latency induced from the use of authentication mechanisms employing cryptographic
mechanisms would adversely impact the operational performance of the ICS.
In situations where the ICS cannot support the specific Identification and Authentication requirements of a control, the organization
employs compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each
control, as appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
IA-1 IDENTIFICATION AND AUTHENTICATION POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-1

Security Identification and Authentication Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
IA-2 USER IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-2
IA-2 (1)

CONTROL BASELINES
LOW

MOD

HIGH

Identification and Authentication (Organizational Users)

Selected

Selected

Selected

IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO

Selected

Selected

Selected

Selected

Selected

Selected

Selected

PRIVILEGED ACCOUNTS
IA-2 (2)

IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO
NON-PRIVILEGED ACCOUNTS

IA-2 (3)

IDENTIFICATION AND AUTHENTICATION | LOCAL ACCESS TO
PRIVILEGED ACCOUNTS

IA-2 (4)

IDENTIFICATION AND AUTHENTICATION | LOCAL ACCESS TO NON-

Selected

PRIVILEGED ACCOUNTS
IA-2 (8)

IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO

Selected

Selected

PRIVILEGED ACCOUNTS - REPLAY RESISTANT
IA-2 (9)

IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO

Selected

NON-PRIVILEGED ACCOUNTS - REPLAY RESISTANT
IA-2 (11)

IDENTIFICATION AND AUTHENTICATION | REMOTE ACCESS -

Selected

Selected

Selected

Selected

SEPARATE DEVICE
IA-2 (12)

IDENTIFICATION AND AUTHENTICATION | ACCEPTANCE OF PIV

Selected

CREDENTIALS

ICS Supplemental Guidance: Where users function as a single group (e.g., control room operators), user identification and
authentication may be role-based, group-based, or device-based. For certain ICS, the capability for immediate operator interaction is critical.
Local emergency actions for ICS are not hampered by identification or authentication requirements. Access to these systems may be
restricted by appropriate physical security controls. Example compensating controls include providing increased physical security, personnel
security, and auditing measures. For example, manual voice authentication of remote personnel and local, manual actions may be required in
order to establish a remote access. See AC-17 ICS Supplemental Guidance. Local user access to ICS components is enabled only when
necessary, approved, and authenticated.

405

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

識別及び認蚌 - IA
識別及び認蚌ファミリのカスタマむズ考慮事項
IA ファミリで管理を実斜する前に、セキュリティ、プラむバシヌ、埅ち時間、パフォヌマンス、
スルヌプットを比范考量する。䟋えば、暗号メカニズムを採甚しお認蚌メカニズムを利甚するに
より生じる埅ち時間が、ICS の運甚パフォヌマンスを阻害しないか組織は怜蚎する。
ICS がある制埡の特定の識別・認蚌芁件に察応しおいない状況では、党䜓的なカスタマむズガむ
ダンスに埓っお補償的管理策を採甚する。
補償的管理策の䟋が必芁に応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお ICS 補足ガむダンスず䜵甚すべきである。
IA-1

識別・認蚌ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ識別・認蚌ポリシヌ・手順

IA-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
IA-2

ナヌザ識別・認蚌組織ナヌザ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

識別・認蚌組織ナヌザ

遞定

遞定

遞定

IA-2 (1)

識別・認蚌 | 特暩アカりントぞのネットワヌクアクセス

遞定

遞定

遞定

IA-2 (2)

識別・認蚌 | 特暩のないアカりントぞのネットワヌクアクセス

遞定

遞定

IA-2 (3)

識別・認蚌 | 特暩アカりントぞのロヌカルアクセス

遞定

遞定

IA-2 (4)

識別・認蚌 | 特暩のないアカりントぞのロヌカルアクセス

IA-2 (8)

識別・認蚌 | 特暩アカりントぞのネットワヌクアクセス - リプレヌ

IA-2

遞定
遞定

遞定

抵抗
IA-2 (9)

識別・認蚌 | 特暩のないアカりントぞのネットワヌクアクセス - リ

遞定

プレヌ抵抗
IA-2 (11)

識別・認蚌 | リモヌトアクセス - 別デバむス

IA-2 (12)

識別・認蚌 | PIV 認蚌情報の受諟

遞定

遞定

遞定

遞定

遞定

ICS 補足ガむダンスナヌザが 1 ぀のグルヌプずしお機胜する堎合制埡宀操䜜員等、ナ
ヌザの識別及び認蚌は圹割ベヌス、グルヌプベヌス又はデバむスベヌスずなる。ある皮の ICS で
は、操䜜員の即時察応が緊芁である。ICS のロヌカル緊急察応は、識別・認蚌芁件に阻害されな
い。このようなシステムぞのアクセスは、適正な物理的セキュリティ察策により制限される。
補償的管理策の䟋ずしお、物理的セキュリティ、人的セキュリティ、監査手段の匷化がある。䟋
えば、リモヌトアクセスを確立するために、遠隔職員の手動音声認蚌及びロヌカルの手動察応が
必芁ずなる。AC-17 補足ガむダンスを参照。ICS コンポヌネントぞのロヌカルナヌザアクセスは、
必芁時に承認ず暩限がある堎合のみ蚱可される。

406

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Control Enhancement: (1, 2, 3, 4) ICS Supplemental Guidance: Example compensating controls include implementing physical
security measures.
Control Enhancement: (8, 9) ICS Supplemental Guidance: Example compensating controls include provide replay-resistance in
an external system.
Control Enhancement: (11) No ICS Supplemental Guidance.
Control Enhancement: (12) ICS Supplemental Guidance: Example compensating controls include implementing support for PIV
external to the ICS.
IA-3 DEVICE IDENTIFICATION AND AUTHENTICATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-3
IA-3 (1)

Device Identification and Authentication

CONTROL BASELINES
LOW

MOD

HIGH

Added

Selected

Selected

Added

Added

Added

Added

DEVICE IDENTIFICATION AND AUTHENTICATION |
CRYPTOGRAPHIC BIDIRECTIONAL AUTHENTICATION

IA-3 (4)

DEVICE IDENTIFICATION AND AUTHENTICATION | DEVICE
ATTESTATION

ICS Supplemental Guidance: The organization may permit connection of devices, also known as non-person entities (NPE),
belonging to and authorized by another organization (e.g., business partners) to their ICS. Especially when these devices are non-local, their
identification and authentication can be vital. Organizations may perform risk and impact analysis to determine the required strength of
authentication mechanisms. Example compensating controls for devices and protocols which do not provide authentication for remote
network connections, include implementing physical security measures.
Control Enhancement: (1, 4) ICS Supplemental Guidance: Configuration management for NPE identification and authentication
customarily involves a human surrogate or representative for the NPE. Devices are provided with their identification and authentication
credentials based on assertions by the human surrogate. The human surrogate also responds to events and anomalies (e.g., credential
expiration). Credentials for software entities (e.g., autonomous processes not associated with a specific person) based on properties of that
software (e.g., digital signatures) may change every time the software is changed or patched. Special purpose hardware (e.g., custom
integrated circuits and printed-circuit boards) may exhibit similar dependencies. Organization definition of parameters may be different
among the impact levels.
Rationale (applies to control and control enhancements): ICS may exchange information with many external systems and
devices. Identifying and authenticating the devices introduces situations that do not exist with humans. These controls include assignments
that enable the organization to categorize devices by types, models, or other group characteristics. Assignments also enable the organizations
to select appropriate controls for local, remote, and network connections.
IA-4 IDENTIFIER MANAGEMENT
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-4

Identifier Management

No ICS Supplemental Guidance.

407

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

管理拡匵(1, 2, 3, 4) ICS 補足ガむダンス補償的管理策の䟋ずしお、物理的セキュリティ察
策がある。
管理拡匵(8, 9) ICS 補足ガむダンス補償的管理策の䟋ずしお、倖郚システムぞのリプレヌ
抵抗性の付䞎がある。
管理拡匵(11) ICS 補足ガむダンスなし
管理拡匵(12) ICS 補足ガむダンス補償的管理策の䟋ずしお、ICS 倖郚に察する PIV 察応
の実装がある。
デバむス識別・認蚌

IA-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名
デバむス識別・認蚌

IA-3

䜎

äž­

高

远加

遞定

遞定

IA-3 (1)

デバむス識別・認蚌 | 暗号化双方向認蚌

远加

远加

IA-3 (4)

デバむス識別・認蚌 | デバむス認蚌

远加

远加

ICS 補足ガむダンス組織は、よその組織提携䌁業等が承認しおいる保有デバむス人
間以倖の実䜓[NPE]ずしおも知られるによる自瀟 ICS ぞの接続を認める堎合がある。このよう
なデバむスがロヌカル以倖の堎合、識別ず認蚌が重芁ずなる。組織はリスク・圱響分析を行い、
認蚌メカニズムの必芁匷床を刀定する。遠隔ネットワヌク接続の認蚌がないデバむス及びプロト
コルに察する補償的管理策の䟋ずしお、物理的セキュリティ察策がある。
管理拡匵(1, 4) ICS 補足ガむダンスNEP の識別・認蚌に察する蚭定管理には、通垞、人物
を NEP に代える方法がある。人物の代理認蚌を基に、デバむスに識別・認蚌情報が付䞎される。
人物の代理により、事象及び異状事態にも察応する認蚌情報の期限切れ等。゜フトり゚アの
特性デゞタル眲名等に基づく゜フトり゚ア実䜓の認蚌情報特定の人物に関連づけられおい
ない自埋プロセス等は、゜フトり゚アが倉曎され、パッチが圓おられるたびに倉わる。特殊目
的のハヌドり゚アカスタム IC 基板やプリント基板等は、䌌たような䟝存性を持぀。組織の
パラメヌタ定矩は、圱響床により異なる。
理由管理・管理拡匵に適甚ICS は、倚数の倖郚システムやデバむスず情報亀換を行う。
デバむスの識別・認蚌は、人間では存圚しない状況を生じる。このような管理には、組織がデバ
むスをタむプ、モデルその他グルヌプ特性で分類するための割圓が含たれる。たたこの割圓によ
り、ロヌカル接続、遠隔接続及びネットワヌク接続を遞択するこずができる。
識別子管理

IA-4

管理名

管理番号

IA-4

管理ベヌスラむン

管理拡匵名
識別子管理

ICS 補足ガむダンスなし

408

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

IA-5 AUTHENTICATOR MANAGEMENT
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-5
IA-5 (1)
IA-5 (2)
IA-5 (3)
IA-5 (11)

Authenticator Management
AUTHENTICATOR MANAGEMENT | PASSWORD-BASED
AUTHENTICATION
AUTHENTICATOR MANAGEMENT | PKI-BASED
AUTHENTICATION
AUTHENTICATOR MANAGEMENT | IN PERSON
REGISTRATION
AUTHENTICATOR MANAGEMENT | HARDWARE TOKENBASED AUTHENTICATION

CONTROL BASELINES
LOW
Selected
Selected

Selected

MOD
Selected
Selected

HIGH
Selected
Selected

Selected

Selected

Selected

Selected

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include physical access control, encapsulating the ICS to provide
authentication external to the ICS.
Control Enhancement: (1, 2, 3, 11) No ICS Supplemental Guidance.
IA-6 AUTHENTICATOR FEEDBACK
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-6

Authenticator Feedback

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected

ICS Supplemental Guidance: This control assumes a visual interface that provides feedback of authentication information during
the authentication process. When ICS authentication uses an interface that does not support visual feedback, (e.g., protocol-based
authentication) this control may be tailored out.
IA-7 CRYPTOGRAPHIC MODULE AUTHENTICATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-7

Cryptographic Module Authentication

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected

No ICS Supplemental Guidance.
IA-8 IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS)
CONTROL NAME
Control Enhancement Name

CNTL NO.
IA-8
IA-8 (1)

CONTROL BASELINES
LOW

MOD

HIGH

Identification and Authentication (Non-Organizational Users)

Selected

Selected

Selected

IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

USERS) | ACCEPTANCE OF PIV CREDENTIALS FROM OTHER
AGENCIES
IA-8 (2)

IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL
USERS) | ACCEPTANCE OF THIRD-PARTY CREDENTIALS

IA-8 (3)

IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL
USERS) | USE OF FICAM-APPROVED PRODUCTS

IA-8 (4)

IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL
USERS) | USE OF FICAM-ISSUED PROFILES

ICS Supplemental Guidance: The ICS Supplemental Guidance for IA-2, Identification and Authentication (Organizational Users),
is applicable for Non- Organizational Users.
Control Enhancement: (1, 2, 3, 4) ICS Supplemental Guidance: Example compensating controls include implementing support
external to the ICS and multi-factor authentication.

409

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

認蚌コヌド管理

IA-5

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

認蚌コヌド管理

遞定

遞定

遞定

IA-5 (1)

認蚌コヌド管理 | パスワヌドベヌス認蚌

遞定

遞定

遞定

IA-5 (2)

認蚌コヌド管理 | PKI ベヌス認蚌

遞定

遞定

IA-5 (3)

認蚌コヌド管理 | 盎接登録

遞定

遞定

IA-5 (11)

認蚌コヌド管理 | ハヌドり゚アのトヌクンベヌス認蚌

遞定

遞定

IA-5

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、物理的アクセス制埡、ICS のカプセル化に
よる ICS 倖郚認蚌がある。
管理拡匵(1, 2, 3, 11) ICS 補足ガむダンスなし
認蚌コヌドフィヌドバック

IA-6

管理名

管理番号

管理ベヌスラむン

管理拡匵名
認蚌フィヌドバック

IA-6

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスこの管理は、認蚌䞭の認蚌情報をフィヌドバックする芖芚むンタフェ
ヌスを想定しおいる。芖芚フィヌドバックに察応しおいないむンタフェヌスの ICS 認蚌の堎合
プロトコルベヌス認蚌等、カスタマむズする。
暗号化モゞュヌル認蚌

IA-7

管理名

管理番号

IA-7

管理ベヌスラむン

管理拡匵名
暗号化モゞュヌル認蚌

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
IA-8

識別・認蚌(組織倖ナヌザ)

管理番号

管理名

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

識別・認蚌組織倖ナヌザ

遞定

遞定

遞定

IA-8 (1)

識別・認蚌組織倖ナヌザ | 他機関 PIV 認蚌情報の蚱諟

遞定

遞定

遞定

IA-8 (2)

識別・認蚌組織倖ナヌザ | サヌドパヌティ認蚌情報の蚱諟

遞定

遞定

遞定

IA-8 (3)

識別・認蚌組織倖ナヌザ | FICAM 認定補品の䜿甚

遞定

遞定

遞定

IA-8 (4)

識別・認蚌組織倖ナヌザ | FICAM 発行プロファむルの䜿甚

遞定

遞定

遞定

IA-8

ICS 補足ガむダンスIA-2 識別・認蚌に関する ICS 補足ガむダンス組織ナヌザは、組織
倖ナヌザに適甚できる。
管理拡匵(1, 2, 3, 4) ICS 補足ガむダンス補償的管理策の䟋ずしお、ICS の倖郚及び倚芁玠
認蚌ぞの察応実装がある。

410

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

INCIDENT RESPONSE - IR
Tailoring Considerations for Incident Response Family
The automated mechanisms used to support the tracking of security incidents are typically not part of, or connected to, the ICS.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
IR-1 INCIDENT RESPONSE POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-1

Incident Response Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
IR-2 INCIDENT RESPONSE TRAINING
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-2

Incident Response Training

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

IR-2 (1)

INCIDENT RESPONSE TRAINING | SIMULATED EVENTS

Selected

IR-2 (2)

INCIDENT RESPONSE TRAINING | AUTOMATED TRAINING

Selected

ENVIRONMENTS
No ICS Supplemental Guidance.
IR-3 INCIDENT RESPONSE TESTING
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-3
IR-3 (2)

CONTROL BASELINES
MOD

HIGH

Incident Response Testing

LOW

Selected

Selected

INCIDENT RESPONSE TESTING | COORDINATION WITH

Selected

Selected

RELATED PLANS
No ICS Supplemental Guidance.
IR-4 INCIDENT HANDLING
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-4
IR-4 (1)

Incident Handling
INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

PROCESSES
IR-4 (4)

INCIDENT HANDLING | INFORMATION CORRELATION

No ICS Supplemental Guidance.

411

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

むンシデント察応 - IR
むンシデント察応ファミリのカスタマむズ考慮事項
接続むンシデント远跡甚に䜿甚する自動メカニズムは、通垞 ICS の䞀郚ではなく、ICS に接続さ
れおもいない。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
むンシデント察応ポリシヌ・手順

IR-1

管理名

管理番号

管理ベヌスラむン

管理拡匵名
むンシデント察応ポリシヌ・手順

IR-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
むンシデント察応蚓緎

IR-2

管理名

管理番号

管理ベヌスラむン

管理拡匵名
むンシデント察応蚓緎

IR-2

䜎

äž­

高

遞定

遞定

遞定

IR-2 (1)

むンシデント察応蚓緎 | 暡擬事象

遞定

IR-2 (2)

むンシデント察応蚓緎 | 自動蚓緎環境

遞定

ICS 補足ガむダンスなし
むンシデント察応詊隓

IR-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

IR-3
IR-3 (2)

äž­

高

むンシデント察応詊隓

遞定

遞定

むンシデント察応蚓緎 | 関連蚈画曞ずの敎合

遞定

遞定

ICS 補足ガむダンスなし
むンシデントハンドリング

IR-4

管理名

管理番号

IR-4

管理ベヌスラむン

管理拡匵名
むンシデント凊理

IR-4 (1)

むンシデント凊理 | 自動むンシデント凊理プロセス

IR-4 (4)

むンシデント凊理 | 情報盞関

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定
遞定

ICS 補足ガむダンスなし

412

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

IR-5 INCIDENT MONITORING
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-5
IR-5 (1)

Incident Monitoring

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

INCIDENT MONITORING | AUTOMATED TRACKING / DATA

Selected

COLLECTION / ANALYSIS
No ICS Supplemental Guidance.
IR-6 INCIDENT REPORTING
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-6
IR-6 (1)

Incident Reporting

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

INCIDENT REPORTING | AUTOMATED REPORTING

ICS Supplemental Guidance: The organization should report incidents on a timely basis. The DHS National Cybersecurity &
Communications Integration Center (NCCIC), http://www.dhs.gov/about-national-cybersecurity-communications-integration-center, serves
as a centralized location where operational elements involved in cybersecurity and communications reliance are coordinated and integrated.
The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) http://ics-cert.us-cert.gov/ics-cert/, collaborates with
international and private sector Computer Emergency Response Teams (CERTs) to share control systems-related security incidents and
mitigation measures.
Control Enhancement: (1) ICS Supplemental Guidance: The automated mechanisms used to support the incident reporting process are
not necessarily part of, or connected to, the ICS.
IR-7 INCIDENT RESPONSE ASSISTANCE
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-7
IR-7 (1)

Incident Response Assistance

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR
AVAILABILITY OF INFORMATION / SUPPORT

No ICS Supplemental Guidance.
IR-8 INCIDENT RESPONSE PLAN
CONTROL NAME
Control Enhancement Name

CNTL NO.
IR-8

Incident Response Plan

CONTROL BASELINES
LOW
Selected

No ICS Supplemental Guidance.

413

MOD
Selected

HIGH
Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

IR-5 むンシデント監芖
管理名

管理番号

管理ベヌスラむン

管理拡匵名
むンシデント監芖

IR-5

䜎

äž­

高

遞定

遞定

遞定

むンシデント監芖 | 自動远跡・デヌタ収集・分析

IR-5 (1)

遞定

ICS 補足ガむダンスなし
むンシデント報告

IR-6

管理名

管理番号

管理ベヌスラむン

管理拡匵名
むンシデント報告

IR-6

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

むンシデント報告 | 自動報告

IR-6 (1)

ICS 補足ガむダンス組織は、タむムリヌにむンシデント報告を行うべきである。䞋蚘 DHS
囜家サむバヌセキュリティ通信統合センタヌ(NCCIC)は集䞭所圚地ずしお機胜し、サむバヌセキ
ュリティず通信の信頌性に関わる運甚郚眲はそこで調敎され、統合化されおいる。
http://www.dhs.gov/about-national-cybersecurity-communications-integration-center
䞋蚘産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)は、海倖及び民間のコンピュヌタ緊
急察応チヌム(CERT)ず連携しお、制埡システム関連セキュリティむンシデント情報ず緩和察策
を共有しおいる。http://ics-cert.us-cert.gov/ics-cert/
管理拡匵(1) ICS 補足ガむダンスむンシデント報告プロセスぞの察応に䜿甚する自動メカ
ニズムは、必ずしも ICS の䞀郚ではなく、ICS に接続されおいるわけではない。
むンシデント察応支揎

IR-7

管理名

管理番号

管理ベヌスラむン

管理拡匵名
むンシデント察応支揎

IR-7

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

むンシデント察応支揎 | 情報・サポヌト可甚性ぞの自動察応

IR-7 (1)

ICS 補足ガむダンスなし
むンシデント察応蚈画

IR-8

管理名

管理番号

IR-8

管理ベヌスラむン

管理拡匵名
むンシデント察応蚈画曞

ICS 補足ガむダンスなし

414

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

MAINTENANCE - MA
Tailoring Considerations for Maintenance Family
The automated mechanisms used to schedule, conduct, and document maintenance and repairs are not necessarily part of, or connected to,
the ICS.
In situations where the ICS cannot support the specific Maintenance requirements of a control, the organization employs compensating
controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NISTSP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
MA-1 SYSTEM MAINTENANCE POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-1

Maintenance Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
MA-2 CONTROLLED MAINTENANCE
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-2
MA-2 (2)

Controlled Maintenance

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

CONTROLLED MAINTENANCE | AUTOMATED MAINTENANCE

Selected

ACTIVITIES
No ICS Supplemental Guidance.
MA-3 MAINTENANCE TOOLS
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-3

CONTROL BASELINES
LOW

MOD

HIGH

Maintenance Tools

Selected

Selected

MA-3 (1)

MAINTENANCE TOOLS | INSPECT TOOLS

Selected

Selected

MA-3 (2)

MAINTENANCE TOOLS | INSPECT MEDIA

Selected

Selected

MA-3 (3)

MAINTENANCE TOOLS | PREVENT UNAUTHORIZED
REMOVAL

No ICS Supplemental Guidance.

415

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

保守 - MA
保守ファミリのカスタマむズ考慮事項
保守・修理の予定䜜成、実斜及び文曞化に䜿甚する自動メカニズムは、必ずしも ICS の䞀郚では
なく、ICS に接続されおいるわけではない。
ICS がある制埡の特定の保守芁件に察応しおいない状況では、党䜓的なカスタマむズガむダンス
に埓っお補償的管理策を採甚する。補償的管理策の䟋が必芁に応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
MA-1

システム保守ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
保守ポリシヌ・手順

MA-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
MA-2

管理保守
管理名

管理番号

管理ベヌスラむン

管理拡匵名
管理保守

MA-2

䜎

äž­

高

遞定

遞定

遞定

MA-2 (2) 管理保守 | 自動保守掻動

遞定

ICS 補足ガむダンスなし
MA-3

保守ツヌル
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

遞定

遞定

MA-3 (1) 保守ツヌル | 怜査ツヌル

遞定

遞定

MA-3 (2) 保守ツヌル | 怜査媒䜓

遞定

遞定

MA-3

保守ツヌル

MA-3 (3) 保守ツヌル | 無断削陀防止

遞定

ICS 補足ガむダンスなし

416

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

MA-4 NONLOCAL MAINTENANCE
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-4

Non-Local Maintenance

MA-4 (2)

NON-LOCAL MAINTENANCE | DOCUMENT NON-LOCAL

CONTROL BASELINES
LOW
Selected

MOD

HIGH

Selected

Selected

Selected

Selected

MAINTENANCE
MA-4 (3)

NON-LOCAL MAINTENANCE | COMPARABLE SECURITY /

Selected

SANITIZATION
No ICS Supplemental Guidance.
Control Enhancement: (2) No ICS Supplemental Guidance.
Control Enhancement: (3) ICS Supplemental Guidance: In crisis or emergency situations, the organization may need immediate
access to non-local maintenance and diagnostic services in order to restore essential ICS operations or services. Example compensating
controls include limiting the extent of the maintenance and diagnostic services to the minimum essential activities, carefully monitoring and
auditing the non-local maintenance and diagnostic activities.
MA-5 MAINTENANCE PERSONNEL
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-5
MA-5 (1)

Maintenance Personnel

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

MAINTENANCE PERSONNEL | INDIVIDUALS WITHOUT

Selected

APPROPRIATE ACCESS
No ICS Supplemental Guidance.
MA-6 TIMELY MAINTENANCE
CONTROL NAME
Control Enhancement Name

CNTL NO.
MA-6

Timely Maintenance

No ICS Supplemental Guidance.

417

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

SP800-82 第 2 版

MA-4

産業甚制埡システムICSセキュリティガむド

非ロヌカル保守
管理名

管理番号

管理ベヌスラむン

管理拡匵名
非ロヌカル保守

MA-4

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

MA-4 (2) 非ロヌカル保守 | 非ロヌカル保守の文曞化
MA-4 (3) 非ロヌカル保守 | 同等セキュリティ・サニタむズ

遞定

ICS 補足ガむダンスなし
管理拡匵(2) ICS 補足ガむダンスなし
管理拡匵(3) ICS 補足ガむダンス危機又は緊急事態には、重芁 ICS 運甚又はサヌビスを埩
旧するため、組織は非ロヌカル保守及び蚺断サヌビスを盎ちに利甚する必芁がある。補償的管理
策の䟋ずしお、保守及び蚺断サヌビスを最䜎限必芁な皋床に限定し、非ロヌカル保守及び蚺断掻
動を慎重に監芖・監査する。
MA-5

保守芁員
管理名

管理番号

管理ベヌスラむン

管理拡匵名
保守芁員

MA-5

䜎

äž­

高

遞定

遞定

遞定

MA-5 (1) 保守芁員 | 適性アクセス以倖の個人

遞定

ICS 補足ガむダンスなし
MA-6

適時的保守
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

MA-6

適時的保守

ICS 補足ガむダンスなし

418

äž­

高

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

MEDIA PROTECTION –MP
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
MP-1 MEDIA PROTECTION POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-1

Media Protection Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
MP-2 MEDIA ACCESS
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-2

Media Access

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
MP-3 MEDIA MARKING
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-3

CONTROL BASELINES
LOW

Media Marking

MOD
Selected

HIGH
Selected

No ICS Supplemental Guidance.
MP-4 MEDIA STORAGE
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-4

CONTROL BASELINES
LOW

Media Storage

MOD
Selected

HIGH
Selected

No ICS Supplemental Guidance.
MP-5 MEDIA TRANSPORT
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-5
MP-5 (4)

CONTROL BASELINES
MOD

HIGH

Media Transport

Selected

Selected

MEDIA TRANSPORT | CRYPTOGRAPHIC PROTECTION

Selected

Selected

No ICS Supplemental Guidance.

419

LOW

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

メディア保護 –MP
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
MP-1

メディア保護ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
メディア保護ポリシヌ・手順

MP-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
MP-2

メディアアクセス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
メディアアクセス

MP-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
MP-3

メディアマヌキング
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
メディアマヌキング

MP-3

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
MP-4

メディアストレヌゞ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
メディアストレヌゞ

MP-4

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
MP-5

メディア転送
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

MP-5
MP-5 (4)

äž­

高

メディア転送

遞定

遞定

メディア転送 | 暗号化保護

遞定

遞定

ICS 補足ガむダンスなし

420

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

MP-6 MEDIA SANITIZATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
MP-6
MP-6 (1)

Media Sanitization

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

MEDIA SANITIZATION | TRACKING / DOCUMENTING /

Selected

VERIFYING
MP-6 (2)

MEDIA SANITIZATION | EQUIPMENT TESTING

Selected

MP-6 (3)

MEDIA SANITIZATION | NON-DESTRUCTIVE TECHNIQUES

Selected

No ICS Supplemental Guidance.
MP-7 MEDIA USE
CONTROL NAME
Control Enhancement Name

CNTL NO.

MP-7
MP-7 (1)

Media Use
MEDIA USE | ORGANIZATIONAL RESTRICTIONS

No ICS Supplemental Guidance.

421

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected
Selected

Selected
Selected

SP800-82 第 2 版

MP-6

産業甚制埡システムICSセキュリティガむド

メディアサニタむズ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
メディアサニタむズ

MP-6

䜎

äž­

高

遞定

遞定

遞定

MP-6 (1)

メディアサニタむズ | 远跡・文曞化・怜蚌

遞定

MP-6 (2)

メディアサニタむズ | 装備品詊隓

遞定

MP-6 (3)

メディアサニタむズ | 非砎壊技術

遞定

ICS 補足ガむダンスなし
MP-7

メディア利甚
管理名

管理番号

MP-7
MP-7 (1)

管理ベヌスラむン

管理拡匵名
メディア利甚

メディア利甚 | 組織䞊の制限

ICS 補足ガむダンスなし

422

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PHYSICAL AND ENVIRONMENTAL PROTECTION – PE
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
PE-1 PHYSICAL AND ENVIRONMENTAL PROTECTION POLICY AND PROCEDURES

CNTL NO.

CONTROL NAME
Control Enhancement Name

PE-1

Physical and Environmental Protection Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems. The ICS components can be distributed over a large facility footprint or geographic area and can be an entry point into
the entire organizational network ICS. Regulatory controls may also apply.
PE-2 PHYSICAL ACCESS AUTHORIZATIONS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-2

Physical Access Authorizations

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
PE-3 PHYSICAL ACCESS CONTROL
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-3
PE-3 (1)

Physical Access Control

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

PHYSICAL ACCESS CONTROL | INFORMATION SYSTEM

Selected

ACCESS
ICS Supplemental Guidance: The organization considers ICS safety and security interdependencies. The organization considers
access requirements in emergency situations. During an emergency-related event, the organization may restrict access to ICS facilities and
assets to authorized individuals only. ICS are often constructed of devices that either do not have or cannot use comprehensive access control
capabilities due to time-restrictive safety constraints. Physical access controls and defense-in-depth measures are used by the organization
when necessary and possible to supplement ICS security when electronic mechanisms are unable to fulfill the security requirements of the
organization’s security plan. Primary nodes, distribution closets, and mechanical/electrical rooms should be locked and require key or
electronic access control and incorporate intrusion detection sensors.
Control Enhancement: (1) No ICS Supplemental Guidance.
PE-4 ACCESS CONTROL FOR TRANSMISSION MEDIUM
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-4

Access Control for Transmission Medium

No ICS Supplemental Guidance.

423

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

物理的環境的保護 – PE
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
PE-1

物理的環境的保護ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
物理環境保護ポリシヌ・手順

PE-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。ICS コンポヌネントは、広範な斜蚭及び地域にたたがっお分散しおおり、組
織の ICS ネットワヌクぞの入口になっおいる堎合もある。芏制管理も適甚できよう。
PE-2

物理的アクセス暩限
管理名

管理番号

管理ベヌスラむン

管理拡匵名
物理的アクセス暩限

PE-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
PE-3

物理的アクセス制埡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
物理的アクセス制埡

PE-3
PE-3 (1)

䜎

äž­

高

遞定

遞定

遞定

物理的アクセス制埡 | 情報システムアクセス

遞定

ICS 補足ガむダンス組織は ICS の安党性ずセキュリティの盞互関係を怜蚎する。組織は、
緊急状況䞋でのアクセス芁件を怜蚎する。緊急関連事象が発生した堎合、組織は ICS 斜蚭及び資
産ぞのアクセスを暩限のある人物だけに制限する。ICS は、時間的な制玄から安党性に限界があ
るため、包括的なアクセス制埡胜力がないか利甚できないデバむスで構成されおいるこずが倚い。
電子的メカニズムでは組織のセキュリティ蚈画曞芁件に満たない堎合、ICS セキュリティにずっ
お必芁か぀補足可胜であれば、物理的アクセス制埡及び倚局防埡察策を採甚する。䞻芁ノヌド、
配電クロヌれット及び機械・電気宀は斜錠し、鍵又は電子的手段でアクセス制埡し、䟵入怜知セ
ンサを取り付ける。
管理拡匵(1) ICS 補足ガむダンスなし
PE-4

通信メディアのアクセス制埡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

PE-4

通信メディアのアクセス制埡

ICS 補足ガむダンスなし

424

äž­

高

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PE-5 ACCESS CONTROL FOR OUTPUT DEVICES
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-5

CONTROL BASELINES
LOW

Access Control for Output Devices

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
PE-6 MONITORING PHYSICAL ACCESS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-6
PE-6 (1)

Monitoring Physical Access

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

Added

Selected

MONITORING PHYSICAL ACCESS | INTRUSION ALARMS /
SURVEILLANCE EQUIPMENT

PE-6 (4)

MONITORING PHYSICAL ACCESS | MONITORING PHYSICAL
ACCESS TO INFORMATION SYSTEMS

ICS Supplemental Guidance: Physical access controls and defense-in-depth measures are used as compensating controls by the
organization when necessary and possible to supplement ICS security when electronic mechanisms are unable to monitor, detect and alarm
when an ICS has been accessed. These compensating controls are in addition to the PE-6 controls (e.g., employing PE-3(4) Lockable Casings
and/or PE-3(5) Tamper Protection).
Control Enhancement: (1) No ICS Supplemental Guidance.
Control Enhancement: (4) ICS Supplemental Guidance: The locations of ICS components (e.g., field devices, remote terminal
units) can include various remote locations (e.g., substations, pumping stations).
Rationale (adding CE 4 to MODERATE baseline): Many of the ICS components are in remote geographical and dispersed
locations with little capability to monitor all ICS components. Other components may be in ceilings, floors, or distribution closets with
minimal physical barriers to detect, delay or deny access to the devices and no electronic surveillance or guard forces response capability.
PE-8 VISITOR ACCESS RECORDS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-8
PE-8 (1)

Visitor Access Records

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

VISITOR ACCESS RECORDS | AUTOMATED RECORDS

Selected

MAINTENANCE / REVIEW
No ICS Supplemental Guidance.
PE-9 POWER EQUIPMENT AND CABLING
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-9
PE-9 (1)

CONTROL BASELINES
LOW

Power Equipment and Cabling
POWER EQUIPMENT AND CABLING | REDUNDANT CABLING

No ICS Supplemental Guidance.
Control Enhancement: (1) No ICS Supplemental Guidance.
Rationale (for adding (1): Continuity of ICS control and operation requires redundant power cabling.

425

MOD

HIGH

Selected

Selected

Added

Added

SP800-82 第 2 版

PE-5

産業甚制埡システムICSセキュリティガむド

出力デバむスのアクセス制埡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
出力デバむスのアクセス制埡

PE-5

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
PE-6

物理的アクセス監芖
管理名

管理番号

管理ベヌスラむン

管理拡匵名
物理的アクセス監芖

PE-6

䜎

äž­

高

遞定

遞定

遞定

PE-6 (1)

物理的アクセス監芖 | 䟵入アラヌム・サヌベむランス装眮

遞定

遞定

PE-6 (4)

物理的アクセス監芖 | 情報システムぞの物理的アクセス監芖

远加

遞定

ICS 補足ガむダンス電子的メカニズムでは ICS ぞのアクセスを監芖・怜知・譊報できない
堎合、ICS セキュリティにずっお必芁か぀補足可胜であれば、物理的アクセス制埡及び倚局防埡
察策を補償的管理策ずしお採甚する。このような補償的管理策は、PE-6 管理を補足するものずな
るPE-3(4)斜錠可胜金庫又は PE-3(5)改竄防止。
管理拡匵(1) ICS 補足ガむダンスなし
管理拡匵(4) ICS 補足ガむダンスICS コンポヌネントフィヌルドデバむス、遠隔端末装
眮等の堎所には、様々な遠隔地が含たれる倉電所、ポンプステヌション等。
理由CE 4 を䞭ベヌスラむンに远加ICS コンポヌネントの倚くは遠隔地に点圚しおいる
ため、すべおを監芖するこずはほが䞍可胜である。倩井、床及び配電クロヌれットに配眮されお
いるものもあり、アクセスを怜知・遅延・防止する物理的障壁は乏しく、電子的サヌベむランス
や譊備員等の備えもない。
PE-8

来蚪者立入蚘録
管理名

管理番号

管理ベヌスラむン

管理拡匵名
来蚪者立入蚘録

PE-8
PE-8 (1)

䜎

äž­

高

遞定

遞定

遞定

来蚪者立入蚘録 | 自動蚘録保守

遞定

芋盎し

ICS 補足ガむダンスなし
PE-9

電気装眮及び配線
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

PE-9
PE-9 (1)

äž­

高

電気装眮及び配線

遞定

遞定

電気装眮及び配線 | 冗長配線

远加

远加

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンスなし
理由(1)の远加ICS 制埡・運甚を継続するために電源ケヌブルの冗長化が必芁。

426

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PE-10 EMERGENCY SHUTOFF
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-10

CONTROL BASELINES
LOW

Emergency Shutoff

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: It may not be possible or advisable to shutoff power to some ICS. Example compensating controls
include fail in known state and emergency procedures.
PE-11 EMERGENCY POWER
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-11
PE-11 (1)

CONTROL BASELINES
LOW

MOD

HIGH

Emergency Power

Added

Selected

Selected

EMERGENCY POWER | LONG-TERM ALTERNATE POWER

Added

Added

Selected

SUPPLY - MINIMAL OPERATIONAL CAPABILITY
PE-11 (2)

EMERGENCY POWER | LONG-TERM ALTERNATE POWER

Added

SUPPLY - SELF-CONTAINED
ICS Supplemental Guidance: Emergency power production, transmission and distribution systems are a type of ICS that are
required to meet extremely high performance specifications. The systems are governed by international, national, state and local building
codes, must be tested on a continual basis, and must be repaired and placed back into operations within a short period of time. Traditionally,
emergency power has been provided by generators for short to mid-term power (typically for fire and life safety systems, some IT load, and
evacuation transport) and UPS battery packs in distribution closets and within work areas to allow some level of business continuity and for
the orderly shutdown of non-essential IT and facility systems. Traditional emergency power systems typically are off-line until a loss of
power occurs and are typically on a separate network and control system specific to the facility they support. New methods of energy
generation and storage (e.g., solar voltaic, geothermal, flywheel, microgrid, distributed energy) that have a real-time demand and storage
connection to local utilities or cross connected to multiple facilities should be carefully analyzed to ensure that the power can meet the load
and signal quality without disruption of mission essential functions.
Control Enhancement: (1) No ICS Supplemental Guidance.
Rationale for adding control to baseline: ICS may support critical activities which will be needed for safety and reliability even in
the absence of reliable power from the public grid.
PE-12 EMERGENCY LIGHTING
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-12

Emergency Lighting

No ICS Supplemental Guidance.

427

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

PE-10

産業甚制埡システムICSセキュリティガむド

緊急遮断
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
緊急遮断

PE-10

äž­

高

遞定

遞定

ICS 補足ガむダンス特定の ICS の電源遮断は䞍可胜又は掚奚できない。補償的管理策の䟋
ずしお、既知状態の倱敗及び緊急手順がある。
PE-11

緊急電源
管理名

管理番号

管理ベヌスラむン

管理拡匵名
緊急電源

PE-11

PE-11 (1) 緊急電源 | 長期代替電源 - 最䜎限の運甚胜力

䜎

äž­

高

远加

遞定

遞定

远加

远加

遞定

PE-11 (2) 緊急電源 | 長期代替電源 - 内蔵型

远加

ICS 補足ガむダンス緊急発電・送配電システムは䞀皮の ICS で、極めお高床な性胜仕様芁
件が課される。囜際・囜家・州・自治䜓の建築法に準拠し、定期的詊隓が課され、短期間に修
理・埩旧できなければならない。埓来、緊急電源ずしお短・䞭期甚発電機通垞火灜・安党装眮、
特定の IT 䜜業及び避難茞送ず UPS バッテリヌパックが配電クロヌれットや䜜業゚リアに蚭眮
されおおり、ある皋床の事業継続や䞍芁 IT 装眮・斜蚭装眮の秩序だった遮断ができるようになっ
おいる。埓来緊急電源装眮は、電源が倱われるたでオフラむンになっおいるこずが倚く、察応す
る斜蚭固有の別ネットワヌク及び制埡システム䞊に眮かれおいる。新たな゚ネルギヌ発生・保存
手段倪陜光、地熱、フラむホむヌル、マむクログリッド、分散゚ネルギヌ等で、地方公共事
業者や耇数斜蚭にリアルタむム需芁・蓄積接続しおものに぀いおは、重倧な任務・機胜を䞭断す
るこずなく、電力が負荷・信号品質芁件を満たせるか、慎重に分析すべきである。
管理拡匵(1) ICS 補足ガむダンスなし
ベヌスラむンに管理を远加する理由公共配電網からの電力を圓おにできない堎合であっお
も、ICS は、安党性や信頌性の確保に必芁な重芁掻動を支えおいる。
PE-12

緊急照明
管理名

管理番号

PE-12

管理ベヌスラむン

管理拡匵名
緊急照明

ICS 補足ガむダンスなし

428

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PE-13 FIRE PROTECTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-13

Fire Protection

PE-13 (1)

FIRE PROTECTION | DETECTION DEVICES / SYSTEMS

PE-13 (2)

FIRE PROTECTION | SUPPRESSION DEVICES / SYSTEMS

PE-13 (3)

FIRE PROTECTION | AUTOMATIC FIRE SUPPRESSION

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected
Selected
Selected

Selected

Selected

ICS Supplemental Guidance: Fire suppression mechanisms should take the ICS environment into account (e.g., water sprinkler
systems could be hazardous in specific environments).
Control Enhancement: (1, 2, 3) No ICS Supplemental Guidance.
PE-14 TEMPERATURE AND HUMIDITY CONTROLS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-14

Temperature and Humidity Controls

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Temperature and humidity controls are typically components of other ICS systems such as the HVAC,
process, or lighting systems, or can be a standalone and unique ICS system. ICS can operate in extreme environments and both interior and
exterior locations. For a specific ICS, the temperature and humidity design and operational parameters dictate the performance specifications.
As ICS and IS become interconnected and the network provides connectivity across the hybrid domain, power circuits, distribution closets,
routers and switches that support fire protection and life safety systems must be maintained at the proper temperature and humidity.
PE-15 WATER DAMAGE PROTECTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-15
PE-15 (1)

Water Damage Protection

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

WATER DAMAGE PROTECTION | AUTOMATION SUPPORT

Selected

ICS Supplemental Guidance: Water damage protection and use of shutoff and isolation valves is both a procedural action, and also
a specific type of ICS. ICS that are used in the manufacturing, hydropower, transportation/navigation, water and wastewater industries rely
on the movement of water and are specifically designed to manage the quantity/flow and pressure of water. As ICS and IS become
interconnected and the network provides connectivity across the hybrid domain, power circuits, distribution closets, routers and switches that
support fire protection and life safety systems should ensure that water will not disable the system (e.g. a fire that activates the sprinkler
system does not spray onto the fire control servers, router, switches and short out the alarms, egress systems, emergency lighting, and
suppression systems).
Control Enhancement: (1) No ICS Supplemental Guidance.
PE-16 DELIVERY AND REMOVAL
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-16

Delivery and Removal

No ICS Supplemental Guidance.

429

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

PE-13

産業甚制埡システムICSセキュリティガむド

防火
管理名

管理番号

管理ベヌスラむン

管理拡匵名
防火

PE-13

䜎

äž­

高

遞定

遞定

遞定

PE-13 (1) 防火 | 怜知デバむス・システム

遞定

PE-13 (2) 防火 | 消火デバむス・システム

遞定

PE-13 (3) 防火 | 自動消火

遞定

遞定

ICS 補足ガむダンス消化機構には ICS 環境を考慮に入れるスプリンクラヌは環境により
有害。
管理拡匵(1, 2, 3) ICS 補足ガむダンスなし
PE-14

枩床・湿床制埡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
枩床・湿床制埡

PE-14

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス枩床・湿床制埡は HVAC、プロセス、照明装眮等の ICS システムのコ
ンポヌネントであり、スタンドアロヌン型システムもあれば特有の ICS システムもある。ICS は
屋内倖の過酷な環境䞋に眮かれる堎合がある。ある皮の ICS は、枩床・湿床蚭蚈や運甚パラメヌ
タによっお性胜仕様が決たる。ICS ず IS は連接され、ネットワヌクはハむブリッド領域にたたが
るため、防火装眮や生呜安党装眮を支える電気回路、配電クロヌれット、ルヌタ及びスむッチは、
適性枩床・湿床に保たれなければならない。
PE-15

氎害防護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
氎害防護

PE-15

䜎

äž­

高

遞定

遞定

遞定

PE-15 (1) 氎害防護 | 自動察応

遞定

ICS 補足ガむダンス氎害防護ず閉止・遮断匁の䜿甚は、ずもに手順行為であり、同時にあ
る皮の ICS でもある。補造・氎力発電・茞送/運航・䞊䞋氎道業界で䜿甚される ICS は、氎の運動
に䟝存しおおり、特に氎の量・流量及び圧力を管理するように蚭蚈されおいる。ICS ず IS は連接
され、ネットワヌクはハむブリッドドメむンにたたがるため、防火装眮や生呜安党装眮を支える
電気回路、配電クロヌれット、ルヌタ及びスむッチは、氎害でシステムが䜜動䞍胜にならないよ
うにすべきである火事でスプリンクラヌが䜜動しおも、防火サヌバ、ルヌタ、スむッチには氎
がかからないようにし、アラヌム、脱出システム、緊急照明、消火システムがショヌトしないよ
うにする。
管理拡匵(1) ICS 補足ガむダンスなし
PE-16

配送・撀去
管理名

管理番号

PE-16

管理ベヌスラむン

管理拡匵名
配送・撀去

ICS 補足ガむダンスなし

430

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PE-17 ALTERNATE WORK SITE
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-17

CONTROL BASELINES
LOW

Alternate Work Site

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
PE-18 LOCATION OF INFORMATION SYSTEM COMPONENTS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PE-18

Location of Information System Components

No ICS Supplemental Guidance.

431

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

PE-17

産業甚制埡システムICSセキュリティガむド

代替䜜業堎
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
代替䜜業堎

PE-17

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
PE-18

情報システムコンポヌネントの堎所
管理名

管理番号

PE-18

管理ベヌスラむン

管理拡匵名
情報システムコンポヌネント

ICS 補足ガむダンスなし

432

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PLANNING – PL
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
PL-1 SECURITY PLANNING POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
Control Enhancement Name
PL-1

Security Planning Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
PL-2 SYSTEM SECURITY PLAN
CONTROL NAME
Control Enhancement Name

CNTL NO.
PL-2
PL-2 (3)

System Security Plan
SYSTEM SECURITY PLAN | PLAN / COORDINATE WITH

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Added

Selected

Selected

OTHER ORGANIZATIONAL ENTITIES
No ICS Supplemental Guidance.
Control Enhancement: (3) No ICS Supplemental Guidance.
Rationale for adding PL-2 (3) to low baseline: When systems are highly inter-connected, coordinated planning is essential. A low
impact system could adversely affect a higher impact system.
PL-4 RULES OF BEHAVIOR
CONTROL NAME
Control Enhancement Name

CNTL NO.
PL-4
PL-4 (1)

Rules of Behavior

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

RULES OF BEHAVIOR | SOCIAL MEDIA AND NETWORKING
RESTRICTIONS

No ICS Supplemental Guidance.
PL-7 SECURITY CONCEPT OF OPERATIONS (CONOPS)
CONTROL NAME
Control Enhancement Name

CNTL NO.
PL-7

Security Concept of Operations

CONTROL BASELINES
LOW

MOD

HIGH

Added

Added

No ICS Supplemental Guidance.
Rationale for adding PL-7 to moderate and high baselines: ICS are complex systems. Organizations typically employ a
CONOPS to help define a system and share that understanding with personnel involved with that system and other systems with which it
interacts. A CONOPS often helps identify information protection requirements.

433

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

プランニング – PL
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
PL-1

セキュリティ蚈画ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ蚈画ポリシヌ・手順

PL-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
PL-2

システムのセキュリティ蚈画曞
管理名

管理番号

PL-2
PL-2 (3)

管理ベヌスラむン

管理拡匵名
䜎

äž­

高

システムセキュリティ蚈画曞

遞定

遞定

遞定

システムセキュリティ蚈画曞 | 他の組織ずの蚈画・調敎

远加

遞定

遞定

ICS 補足ガむダンスなし
管理拡匵(3) ICS 補足ガむダンスなし
PL-2 (3)を䜎ベヌスラむンに远加する理由システム同士が高床に盞互連接しおいる堎合、
蚈画の調敎が肝芁である。圱響床の䜎いシステムが高いシステムに悪圱響を䞎えるこずがある。
PL-4

行動芏則
管理名

管理番号

管理ベヌスラむン

管理拡匵名
行動芏則

PL-4
PL-4 (1)

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

行動芏則 | ゜ヌシャルメディア/ネットワヌキングの制限

ICS 補足ガむダンスなし
PL-7

運甚セキュリティ抂念 (CONOPS)
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

PL-7

運甚セキュリティ抂念

äž­

高

远加

远加

ICS 補足ガむダンスなし
PL-7 を䞭・高ベヌスラむンに远加する理由ICS システムが耇雑なため。通垞、組織は
CONOPS を採甚しお、システムを定矩し、圓該システムや盞互䜜甚を行う他のシステムの関係者
ず理解を共有する。CONOPS は、情報保護芁件を明らかにする䞊で圹立぀こずが倚い。

434

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PL-8 INFORMATION SECURITY ARCHITECTURE
CONTROL NAME
Control Enhancement Name

CNTL NO.
PL-8

Information Security Architecture

No ICS Supplemental Guidance.

435

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

SP800-82 第 2 版

PL-8

産業甚制埡システムICSセキュリティガむド

情報セキュリティアヌキテクチャ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

PL-8

情報セキュリティアヌキテクチャ

ICS 補足ガむダンスなし

436

äž­

高

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PERSONNEL SECURITY – PS
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
PS-1 PERSONNEL SECURITY POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-1

Personnel Security Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
PS-2 POSITION RISK DESIGNATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-2

Position Risk Designation

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
PS-3 PERSONNEL SCREENING
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-3

Personnel Screening

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
PS-4 PERSONNEL TERMINATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-4

Personnel Termination

PS-4 (2)

PERSONNEL TERMINATION | AUTOMATED NOTIFICATION

CONTROL BASELINES
LOW
Selected

MOD
Selected

HIGH
Selected
Selected

No ICS Supplemental Guidance.
PS-5 PERSONNEL TRANSFER
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-5

Personnel Transfer

No ICS Supplemental Guidance.

437

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

人員のセキュリティ – PS
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
人員のセキュリティポリシヌ・手順

PS-1

管理名

管理番号

管理ベヌスラむン

管理拡匵名
人員のセキュリティポリシヌ・手順

PS-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
配眮リスク指定

PS-2

管理名

管理番号

管理ベヌスラむン

管理拡匵名
配眮リスク指定

PS-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
人遞

PS-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名
人遞

PS-3

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
退職

PS-4

管理名

管理番号

管理ベヌスラむン

管理拡匵名
退職

PS-4

䜎

äž­

高

遞定

遞定

遞定

退職 | 自動通知

PS-4 (2)

遞定

ICS 補足ガむダンスなし
転勀

PS-5

管理名

管理番号

PS-5

管理ベヌスラむン

管理拡匵名
転勀

ICS 補足ガむダンスなし

438

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PS-6 ACCESS AGREEMENTS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-6

Access Agreements

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
PS-7 THIRD-PARTY PERSONNEL SECURITY
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-7

Third-Party Personnel Security

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
PS-8 PERSONNEL SANCTIONS
CONTROL NAME
Control Enhancement Name

CNTL NO.
PS-8

Personnel Sanctions

No ICS Supplemental Guidance.

439

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

アクセス同意

PS-6

管理名

管理番号

管理ベヌスラむン

管理拡匵名
アクセス同意

PS-6

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
サヌドパヌティ瀟員セキュリティ

PS-7

管理名

管理番号

管理ベヌスラむン

管理拡匵名
サヌドパヌティ瀟員セキュリティ

PS-7

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
懲戒

PS-8

管理名

管理番号

PS-8

管理ベヌスラむン

管理拡匵名
懲戒

ICS 補足ガむダンスなし

440

䜎

äž­

高

遞定

遞定

遞定

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

RISK ASSESSMENT – RA
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
RA-1 RISK ASSESSMENT POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
RA-1

CONTROL BASELINES

Control Enhancement Name
Risk Assessment Policy and Procedures

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
RA-2 SECURITY CATEGORIZATION
CONTROL NAME
CNTL NO.
RA-2

CONTROL BASELINES

Control Enhancement Name
Security Categorization

LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
RA-3 RISK ASSESSMENT
CONTROL NAME
CNTL NO.
RA-3

CONTROL BASELINES

Control Enhancement Name
Risk Assessment

LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
RA-5 VULNERABILITY SCANNING
CONTROL NAME
CNTL NO.
RA-5

CONTROL BASELINES

Control Enhancement Name
Vulnerability Scanning

LOW

MOD

HIGH

Selected

Selected

Selected

RA-5 (1)

VULNERABILITY SCANNING | UPDATE TOOL CAPABILITY

Selected

Selected

RA-5 (2)

VULNERABILITY SCANNING | UPDATE BY FREQUENCY /
PRIOR TO NEW SCAN / WHEN IDENTIFIED

Selected

Selected

RA-5 (4)

VULNERABILITY SCANNING | DISCOVERABLE INFORMATION

RA-5 (5)

VULNERABILITY SCANNING | PRIVILEGED ACCESS

Selected
Selected

Selected

ICS Supplemental Guidance: Active vulnerability scanning, which introduces network traffic, is used with care on ICS systems to
ensure that ICS functions are not adversely impacted by the scanning process. The organization makes a risk-based determination whether to
employ active scanning. Passive monitoring /sniffing may be used as part of a compensating control. Example compensating controls include
providing a replicated, virtualized, or simulated system to conduct scanning. Production ICS may need to be taken off-line before scanning
can be conducted. If ICS are taken off-line for scanning, scans are scheduled to occur during planned ICS outages whenever possible. If
vulnerability scanning tools are used on non-ICS networks, extra care is taken to ensure that they do not scan the ICS network. Network
scanning is not applicable to non-addressable communications. Vulnerability examination may be performed using other mechanisms than
scanning to identify the objects being examined. Host-based vulnerability examination is an example compensating control.
Control Enhancement: (1, 2, 4, 5) No ICS Supplemental Guidance.

441

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

リスク評䟡 – RA
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
RA-1

リスク評䟡ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
リスク評䟡ポリシヌ・手順

RA-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
RA-2

セキュリティ分類
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ分類

RA-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
RA-3

リスク評䟡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
リスク評䟡

RA-3

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
RA-5

脆匱性怜玢
管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

遞定

遞定

遞定

RA-5 (1)

脆匱性怜玢 | 曎新ツヌル機胜

遞定

遞定

RA-5 (2)

怜脆匱性玢 | 新芏スキャン前・識別時の呚波数による曎新

遞定

遞定

RA-5 (4)

脆匱性怜玢 | 怜出可胜情報

RA-5 (5)

脆匱性怜玢 | 特暩アクセス

RA-5

脆匱性怜玢

䜎

遞定
遞定

遞定

ICS 補足ガむダンスアクティブ脆匱性蚈画怜玢は、ネットワヌクトラフィックを生じるの
で ICS システム䞊で慎重に行い、怜玢プロセスにより ICS 機胜に悪圱響が及ばないようにする。
組織はリスクに立脚しお、アクティブ怜玢実行の是非を刀断する。パッシブ監芖・スニッフィン
グは、補償的管理策の䞀環ずしお䜿甚できる。補償的管理策の䟋ずしお、耇補、仮想又は暡擬シ
ステムで怜玢する方法がある。生産 ICS は、怜玢前にオフラむンにする必芁がある。オフラむン
にする堎合、可胜であれば、予め蚈画された ICS の操業停止時に怜玢を行うように予定を組む。
脆匱性怜玢ツヌルを ICS 以倖のネットワヌクで行う堎合、怜玢が ICS ネットワヌクに及ばないよ
うに泚意する。ネットワヌク怜玢は、アドレス指定䞍胜の通信には適甚されない。
脆匱性怜蚌は、怜蚌䞭の察象を識別する怜玢以倖のメカニズムを䜿甚しお行う。ホストベヌ
スの脆匱性怜蚌は、補償的管理策の䞀䟋である。
管理拡匵(1, 2, 4, 5) ICS 補足ガむダンスなし

442

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SYSTEM AND SERVICES ACQUISITION – SA
Tailoring Considerations for System and Services Acquisition Family
In situations where the ICS cannot support the specific System and Services Acquisition requirements of a control, the organization
employs compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each
control, as appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
SA-1 SYSTEM AND SERVICES ACQUISITION POLICY AND PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-1

System and Services Acquisition Policy and Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
SA-2 ALLOCATION OF RESOURCES
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-2

Allocation of Resources

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SA-3 SYSTEM DEVELOPMENT LIFE CYCLE
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-3

System Development Life Cycle

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SA-4 ACQUISITION PROCESS

CNTL NO.
SA-4
SA-4 (1)
SA-4 (2)
SA-4 (9)
SA-4 (10)

CONTROL NAME
Control Enhancement Name
Acquisition Process
ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF
SECURITY CONTROLS
ACQUISITION PROCESS | DESIGN / IMPLEMENTATION
INFORMATION FOR SECURITY CONTROLS
ACQUISITION PROCESS | FUNCTIONS / PORTS /
PROTOCOLS / SERVICES IN USE
ACQUISITION PROCESS | USE OF APPROVED PIV
PRODUCTS

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected
Selected

Selected
Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

ICS Supplemental Guidance: Since ICS security has historically focused on physical protection and isolation, vendors and
developers may be unfamiliar with cybersecurity. Organizations should anticipate a need to engage with ICS suppliers to raise awareness of
cybersecurity needs. The SCADA/Control Systems Procurement Project provides example cybersecurity procurement language for ICS.
References: Web: https://ics-cert.us-cert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf
Control Enhancements: (1, 2, 9) ICS Supplemental Guidance: Developers may not have access to required information.

443

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

システム及びサヌビス取埗 – SA
システム及びサヌビス取埗ファミリのカスタマむズ考慮事項
ICS がある制埡の特定のシステム及びサヌビス取埗芁件に察応しおいない状況では、党䜓的なカ
スタマむズガむダンスに埓っお補償的管理策を採甚する。
補償的管理策の䟋が必芁に応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
SA-1

システム及びサヌビス取埗ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
システム及びサヌビス取埗ポリシヌ・手順

SA-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
SA-2

リ゜ヌス割圓
管理名

管理番号

管理ベヌスラむン

管理拡匵名
リ゜ヌス割圓

SA-2

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SA-3

システム開発ラむフサむクル
管理名

管理番号

管理ベヌスラむン

管理拡匵名
システム開発ラむフサむクル

SA-3

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SA-4

取埗プロセス
管理名

管理番号

SA-4

管理ベヌスラむン

管理拡匵名
取埗プロセス

䜎

äž­

高

遞定

遞定

遞定

SA-4 (1)

取埗プロセス | セキュリティ察策の機胜特性

遞定

遞定

SA-4 (2)

取埗プロセス | セキュリティ察策の蚭蚈・実装情報

遞定

遞定

SA-4 (9)

取埗プロセス | 機胜・ポヌト・プロトコル

遞定

遞定

遞定

遞定

実甚サヌビス
SA-4 (10) 取埗プロセス | 認可枈み PIV 補品の利甚

遞定

ICS 補足ガむダンスICS のセキュリティは、歎史的に物理的な保護ず隔離が重点だったた
め、ベンダヌや開発者はサむバヌセキュリティになじみがない。組織は ICS サプラむダずずもに、
サむバヌセキュリティに察する意識高揚の必芁性を予期すべきである。SCADA 制埡システム調
達プロゞェクトには、ICS のサむバヌセキュリティ甚語が瀺されおいる。参考文献りェブ
https://ics-cert.us- cert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf
管理拡匵(1, 2, 9) ICS 補足ガむダンス開発者は必芁な情報を利甚できない可胜性がある。

444

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

Control Enhancement: (10) ICS Supplemental Guidance: Example compensating controls include employing external products
on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability in conjunction with ICS products.
SA-5 INFORMATION SYSTEM DOCUMENTATION
CONTROL NAME
CNTL NO.
SA-5

CONTROL BASELINES

Control Enhancement Name
Information System Documentation

LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SA-8 SECURITY ENGINEERING PRINCIPLES
CONTROL NAME
CNTL NO.
SA-8

CONTROL BASELINES

Control Enhancement Name

LOW

Security Engineering Principles

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SA-9 EXTERNAL INFORMATION SYSTEM SERVICES
CONTROL NAME
CNTL NO.
SA-9
SA-9 (2)

CONTROL BASELINES

Control Enhancement Name
External Information System Services

LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

EXTERNAL INFORMATION SYSTEMS | IDENTIFICATION OF
FUNCTIONS / PORTS / PROTOCOLS / SERVICES

No ICS Supplemental Guidance.
SA-10 DEVELOPER CONFIGURATION MANAGEMENT
CONTROL NAME
CNTL NO.
SA-10

CONTROL BASELINES

Control Enhancement Name

LOW

Developer Configuration Management

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SA-11 DEVELOPER SECURITY TESTING AND EVALUATION
CONTROL NAME
CNTL NO.
SA-11

CONTROL BASELINES

Control Enhancement Name

LOW

Developer Security Testing and Evaluation

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SA-12 SUPPLY CHAIN PROTECTION
CONTROL NAME
CNTL NO.
SA-12

CONTROL BASELINES

Control Enhancement Name
Supply Chain Protection

LOW

MOD

HIGH
Selected

No ICS Supplemental Guidance.

445

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

管理拡匵(10) ICS 補足ガむダンス補償的管理策の䟋ずしお、ICS 補品に関連した身分蚌
明PIV機胜の FIPS 201 承認補品リストの倖郚補品採甚がある。
SA-5

情報システム文曞化
管理名

管理番号

管理ベヌスラむン

管理拡匵名
情報システム文曞化

SA-5

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SA-8

セキュリティ゚ンゞニアリング原則
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
セキュリティ゚ンゞニアリンク原則

SA-8

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SA-9

倖郚情報システムサヌビス
管理名

管理番号

管理ベヌスラむン

管理拡匵名

SA-9

倖郚情報システムサヌビス

SA-9 (2)

倖郚情報システム | 機胜・

䜎

äž­

高

遞定

遞定

遞定

遞定

遞定

ポヌト・プロトコル・サヌビスの識別

ICS 補足ガむダンスなし
SA-10

開発者蚭定管理
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
開発者蚭定管理

SA-10

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SA-11

開発者セキュリティ詊隓評䟡
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
開発者セキュリティ詊隓評䟡

SA-11

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SA-12

サプラむチェヌン保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SA-12

サプラむチェヌン保護

äž­

高
遞定

ICS 補足ガむダンスなし

446

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SA-15 DEVELOPMENT PROCESS, STANDARDS, AND TOOLS
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-15

Development Process, Standards, and Tools

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SA-16 DEVELOPER-PROVIDED TRAINING
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-16

CONTROL BASELINES
LOW

MOD

Developer-Provided Training

HIGH
Selected

No ICS Supplemental Guidance.
SA-17 DEVELOPER SECURITY ARCHITECTURE AND DESIGN
CONTROL NAME
Control Enhancement Name

CNTL NO.
SA-17

Developer Security Architecture and Design

CONTROL BASELINES
LOW

MOD

HIGH
Selected

No ICS Supplemental Guidance.

447

SP800-82 第 2 版

SA-15

産業甚制埡システムICSセキュリティガむド

開発プロセス・芏栌・ツヌル
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

開発プロセス・芏栌・ツヌル

SA-15

高
遞定

ICS 補足ガむダンスなし
SA-16

開発者による蚓緎
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

開発者による蚓緎

SA-16

高
遞定

ICS 補足ガむダンスなし
SA-17

開発者セキュリティアヌキテクチャ・蚭蚈
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SA-17

開発者セキュリティアヌキテクチャ・蚭蚈

äž­

高
遞定

ICS 補足ガむダンスなし

448

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SYSTEM AND COMMUNICATIONS PROTECTION - SC
Tailoring Considerations for System and Communications Protection Family
The use of cryptography is determined after careful consideration of the security needs and the potential ramifications on system
performance. For example, the organization considers whether latency induced from the use of cryptography would adversely impact the
operational performance of the ICS. While the legacy devices commonly found within ICS often lack direct support of cryptographic
functions, compensating controls (e.g., encapsulations) may be used to meet the intent of the control.
In situations where the ICS cannot support the specific System and Communications Protection requirements of a control, the
organization employs compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given
with each control, as appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
SC-1 SYSTEM AND COMMUNICATIONS PROTECTION POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
SC-1

CONTROL BASELINES

Control Enhancement Name
System and Communications Protection Policy and
Procedures

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
SC-2 APPLICATION PARTITIONING
CONTROL NAME
CNTL NO.
SC-2

CONTROL BASELINES

Control Enhancement Name

LOW

Application Partitioning

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Systems used to manage the ICS should be separate from the operational ICS components. Example
compensating controls include providing increased auditing measures.
SC-3 SECURITY FUNCTION ISOLATION
CONTROL NAME
CNTL NO.
SC-3

CONTROL BASELINES

Control Enhancement Name

LOW

MOD

Security Function Isolation

HIGH
Selected

ICS Supplemental Guidance: Example compensating controls include providing increased auditing measures, limiting network
connectivity, architectural allocation.
SC-4 INFORMATION IN SHARED RESOURCES
CONTROL NAME
CNTL NO.
SC-4

CONTROL BASELINES

Control Enhancement Name
Information in Shared Resources

LOW

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include architecting the use of the ICS to prevent sharing system
resources.

449

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

システム及び通信保護 - SC
システム及び通信保護ファミリのカスタマむズ考慮事項
暗号化の䜿甚は、セキュリティ䞊の必芁性ずシステムパフォヌマンスぞの悪圱響を慎重に考慮し
お刀断する。䟋えば、暗号を利甚するにより生じる埅ち時間が、ICS の運甚パフォヌマンスを阻
害しないか組織は怜蚎する。通垞 ICS に芋られるレガシヌデバむスは、暗号関数に盎接察応しお
いないこずが倚いため、補償的管理策カプセル化等を䜿甚しお、管理目的を達成する。
ICS がある制埡の特定のシステム及び通信保護芁件に察応しおいない状況では、党䜓的なカスタ
マむズガむダンスに埓っお補償的管理策を採甚する。補償的管理策の䟋が必芁に応じお、管理策
ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
SC-1

システム及び通信保護ポリシヌ・手順
管理名

管理番号

管理ベヌスラむン

管理拡匵名
システム通信保護ポリシヌ・手順

SC-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
SC-2

アプリケヌション分割
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
アプリケヌション分割

SC-2

äž­

高

遞定

遞定

ICS 補足ガむダンスICS の管理に䜿甚するシステムは、実甚 ICS コンポヌネントず別にす
べきである。補償的管理策の䟋ずしお、監査手段の匷化がある。
SC-3

セキュリティ機胜の隔離
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

äž­

セキュリティ機胜の隔離

SC-3

高
遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、監査手段の匷化、ネットワヌク接続の制限、
アヌキテクチャ割圓がある。
SC-4

共有リ゜ヌス内情報
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SC-4

共有リ゜ヌス内情報

äž­

高

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、ICS の䜿甚芁領を蚭定しおシステムリ゜ヌ
スを共有しないようにする方法がある。

450

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SC-5 DENIAL OF SERVICE PROTECTION
CONTROL NAME
CNTL NO.
SC-5

CONTROL BASELINES

Control Enhancement Name
Denial of Service Protection

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include ensuring a loss of communication results in the ICS
operating in nominal or safe mode. Risk-based analysis informs the establishment of policy and procedure.
SC-7 BOUNDARY PROTECTION
CONTROL NAME
CNTL NO.
SC-7

CONTROL BASELINES

Control Enhancement Name
Boundary Protection

LOW

MOD

HIGH

Selected

Selected

Selected

SC-7 (3)

BOUNDARY PROTECTION | ACCESS POINTS

Selected

Selected

SC-7 (4)

BOUNDARY PROTECTION | EXTERNAL
TELECOMMUNICATIONS SERVICES

Selected

Selected

SC-7 (5)

BOUNDARY PROTECTION | DENY BY DEFAULT / ALLOW BY
EXCEPTION

Selected

Selected

SC-7 (7)

BOUNDARY PROTECTION | PREVENT SPLIT TUNNELING FOR
REMOTE DEVICES

Selected

Selected

SC-7 (8)

BOUNDARY PROTECTION | ROUTE TRAFFIC TO
AUTHENTICATED PROXY SERVERS

SC-7 (18)

BOUNDARY PROTECTION | FAIL SECURE

SC-7 (21)

BOUNDARY PROTECTION | ISOLATION OF INFORMATION
SYSTEM COMPONENTS

Selected
Added

Selected
Selected

No ICS Supplemental Guidance.
Control Enhancement: (3, 4, 5, 7, 8, 21) No ICS Supplemental Guidance.
Control Enhancement: (18) ICS Supplemental Guidance: The organization selects an appropriate failure mode (e.g., permit or
block all communications).
Rationale for adding SC-7 (18) to Moderate Baseline: As part of the architecture and design of the ICS, the organization selects
an appropriate failure mode in accordance with the function performed by the ICS and the operational environment. The ability to choose the
failure mode for the physical part of the ICS differentiates the ICS from other IT systems. This choice may be a significant influence in
mitigating the impact of a failure.
SC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY
CONTROL NAME
CNTL NO.
SC-8
SC-8 (1)

CONTROL BASELINES

Control Enhancement Name

MOD

HIGH

Transmission Confidentiality and Integrity

LOW

Selected

Selected

transmission confidentiality and integrity | cryptographic or
alternate physical protection

Selected

Selected

No ICS Supplemental Guidance.
Control Enhancement: (1) ICS Supplemental Guidance: The organization explores all possible cryptographic integrity
mechanisms (e.g., digital signature, hash function). Each mechanism has a different delay impact.
SC-10 NETWORK DISCONNECT
CONTROL NAME
CNTL NO.
SC-10

CONTROL BASELINES

Control Enhancement Name
Network Disconnect

LOW

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include providing increased auditing measures or limiting remote
access privileges to key personnel.

451

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

サヌビス保護劚害

SC-5

管理名

管理番号

管理ベヌスラむン

管理拡匵名
サヌビス保護劚害

SC-5

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、通信喪倱時に ICS の運甚が公称モヌド又は
セヌフモヌドになるようにする方法がある。リスクに立脚した分析により、ポリシヌ・手順の蚭
定情報が埗られる。
SC-7

境界の保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
境界の保護

SC-7

䜎

äž­

高

遞定

遞定

遞定

SC-7 (3)

境界の保護 | アクセスポむント

遞定

遞定

SC-7 (4)

境界の保護 | 倖郚電気通信サヌビス

遞定

遞定

SC-7 (5)

境界の保護 | デフォルトで拒絶・䟋倖で蚱諟

遞定

遞定

SC-7 (7)

境界の保護 | 遠隔デバむスのスプリットトンネリング防止

遞定

遞定

SC-7 (8)

境界の保護 | 認蚌枈みプロぞのキシサヌバトラフィックの経路指

遞定

定
SC-7 (18) 境界の保護 | フェヌルセキュア

远加

SC-7 (21) 境界の保護 | 情報システムコンポヌネントの隔離

遞定
遞定

ICS 補足ガむダンスなし
管理拡匵(3, 4, 5, 7, 8, 21) ICS 補足ガむダンスなし
管理拡匵(18) ICS 補足ガむダンス組織は適圓な故障モヌドを遞択する党おの通信を蚱
可又はブロック等。
SC-7 (18)を䞭ベヌスラむンに远加する理由ICS アヌキテクチャ及び蚭蚈の䞀貫ずしお、組
織は、ICS 及び運甚環境が実斜する機胜に埓い、適圓な故障モヌドを遞択する。ICS の物理郚分に
故障モヌドを遞択できる胜力は、ICS ず他の IT システムずの違いである。この遞択は、故障の圱
響を緩和する䞊で倧きな効果がある。
SC-8

通信機密性・完党性
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SC-8
SC-8 (1)

äž­

高

通信機密性・完党性

遞定

遞定

通信機密性・完党性 | 暗号化又は代替物理的保護

遞定

遞定

ICS 補足ガむダンスなし
管理拡匵(1) ICS 補足ガむダンス組織はあらゆる暗号保党メカニズムを掻甚するデゞタ
ル眲名、ハッシュ関数等。各メカニズムの遅延圱響はそれぞれ異なる。
SC-10

ネットワヌク切断
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SC-10

ネットワヌク切断

äž­

高

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、監査手段の匷化やリモヌトアクセス特暩を
重芁な人員に制限する方法がある。

452

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT
CONTROL NAME
CNTL NO.
SC-12
SC-12 (1)

CONTROL BASELINES

Control Enhancement Name
Cryptographic Key Establishment and Management

LOW

MOD

HIGH

Selected

Selected

Selected

CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT
| AVAILABILITY

Selected

ICS Supplemental Guidance: The use of cryptographic key management in ICS is intended to support internal nonpublic use.
Control Enhancement: (1) No ICS Supplemental Guidance.
SC-13 CRYPTOGRAPHIC PROTECTION
CONTROL NAME
CNTL NO.
SC-13

CONTROL BASELINES

Control Enhancement Name
Cryptographic Protection

LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SC-15 COLLABORATIVE COMPUTING DEVICES
CONTROL NAME
CNTL NO.
SC-15

CONTROL BASELINES

Control Enhancement Name
Collaborative Computing Devices

LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SC-17 PUBLIC KEY INFRASTRUCTURE CERTIFICATES
CONTROL NAME
CNTL NO.
SC-17

CONTROL BASELINES

Control Enhancement Name

LOW

Public Key Infrastructure Certificates

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SC-18 MOBILE CODE
CONTROL NAME
CNTL NO.
SC-18

CONTROL BASELINES

Control Enhancement Name

LOW

Mobile Code

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SC-19 VOICE OVER INTERNET PROTOCOL
CONTROL NAME
CNTL NO.
SC-19

CONTROL BASELINES

Control Enhancement Name
Voice Over Internet Protocol

LOW

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: The use of VoIP technologies is determined after careful consideration and after verification that it
does not adversely impact the operational performance of the ICS.

453

SP800-82 第 2 版

SC-12

産業甚制埡システムICSセキュリティガむド

暗号鍵蚭定管理
管理名

管理番号

管理ベヌスラむン

管理拡匵名
暗号鍵蚭定管理

SC-12

䜎

äž­

高

遞定

遞定

遞定

SC-12 (1) 暗号鍵蚭定管理 |

遞定

可甚性

ICS 補足ガむダンス暗号鍵管理を ICS で䜿甚する目的は、内郚の非公開利甚に察応するた
めである。
管理拡匵(1) ICS 補足ガむダンスなし
SC-13

暗号保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
暗号保護

SC-13

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SC-15 共同コンピュヌティングデバむス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
共同コンピュヌティングデバむス

SC-15

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SC-17

公開鍵むンフラ蚌明曞
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
公開鍵むンフラ蚌明曞

SC-17

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SC-18

モバむルコヌド
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
モバむルコヌド

SC-18

äž­
遞定

高
遞定

ICS 補足ガむダンスなし
SC-19

VoIP
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SC-19

VoIP

äž­

高

遞定

遞定

ICS 補足ガむダンスVoIP 技術の利甚は、ICS の運甚に悪圱響がないこずを怜蚌し、慎重に
怜蚎しおから刀断する。

454

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SC-20 SECURE NAME / ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE)
CONTROL NAME
CNTL NO.
SC-20

CONTROL BASELINES

Control Enhancement Name
Secure Name /Address Resolution Service
(Authoritative Source)

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The use of secure name/address resolution services is determined after careful consideration and after
verification that it does not adversely impact the operation of the ICS.
SC-21 SECURE NAME / ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING RESOLVER)
CONTROL NAME
CNTL NO.
SC-21

CONTROL BASELINES

Control Enhancement Name
Secure Name /Address Resolution Service
(Recursive or Caching Resolver)

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The use of secure name/address resolution services is determined after careful consideration and after
verification that it does not adversely impact the operation of the ICS.
SC-22 ARCHITECTURE AND PROVISIONING FOR NAME / ADDRESS RESOLUTION SERVICE
CONTROL NAME
CNTL NO.
SC-22

CONTROL BASELINES

Control Enhancement Name
Architecture and Provisioning for
Name/Address Resolution Service

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The use of secure name/address resolution services is determined after careful consideration and after
verification that it does not adversely impact the operational performance of the ICS.
SC-23 SESSION AUTHENTICITY
CONTROL NAME

CONTROL BASELINES

CNTL NO.

Control Enhancement Name

SC-23

Session Authenticity

LOW

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include auditing measures.
SC-24 FAIL IN KNOWN STATE
CONTROL NAME

CONTROL BASELINES

CNTL NO.

Control Enhancement Name

SC-24

Fail in Known State

LOW

MOD

HIGH

Added

Selected

ICS Supplemental Guidance: The organization selects an appropriate failure state. Preserving ICS state information includes
consistency among ICS state variables and the physical state which the ICS represents (e.g., whether valves are open or closed,
communication permitted or blocked, continue operations).
Rationale for adding SC-24 to moderate baseline: As part of the architecture and design of the ICS, the organization selects an
appropriate failure state of an ICS in accordance with the function performed by the ICS and the operational environment. The ability to
choose the failure mode for the physical part of the ICS differentiates the ICS from other IT systems. This choice may be a significant
influence in mitigating the impact of a failure, since it may be disruptive to ongoing physical processes (e.g., valves failing in closed position
may adversely affect system cooling).

455

SP800-82 第 2 版

SC-20

産業甚制埡システムICSセキュリティガむド

セキュアな名前/アドレス解決サヌビス暩限゜ヌス
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュアな名前/アドレス解決サヌビス暩限゜ヌス

SC-20

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスセキュアな名前/アドレス解決サヌビスの利甚は、ICS の運甚に悪圱響
がないこずを怜蚌し、慎重に怜蚎しおから刀断する。
SC-21

セキュアな名前/アドレス解決サヌビス再垰又はキャッシングリゟルバ
管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュアな名前/アドレス解決サヌビス再垰又はキャッシングリ

SC-21

䜎

äž­

高

遞定

遞定

遞定

ゟルバ

ICS 補足ガむダンスセキュアな名前/アドレス解決サヌビスの利甚は、ICS の運甚に悪圱響
がないこずを怜蚌し、慎重に怜蚎しおから刀断する。
SC-22

名前/アドレス解決サヌビス甚アヌキテクチャヌプロビゞョニング
管理名

管理番号

管理ベヌスラむン

管理拡匵名
名前/アドレス解決サヌビス甚アヌキテクチャヌプロビゞョニング

SC-22

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスセキュアな名前/アドレス解決サヌビスの利甚は、ICS の運甚に悪圱響
がないこずを怜蚌し、慎重に怜蚎しおから刀断する。
SC-23

セッション認蚌
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
セッション認蚌

SC-23

äž­

高

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、監査手段がある。
SC-24

既知状態の倱敗
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SC-24

既知状態の倱敗

äž­

高

远加

遞定

ICS 補足ガむダンス組織は適圓な故障状態を遞択する。ICS 状態情報の保存には、ICS 状
態倉数ず ICS の物理的状態の敎合性が含たれるバルブの開又は閉、通信の蚱可又はブロック
等。
SC-24 を䞭ベヌスラむンに远加する理由ICS アヌキテクチャ及び蚭蚈の䞀貫ずしお、組織
は、ICS 及び運甚環境が実斜する機胜に埓い、適圓な ICS の故障状態を遞択する。ICS の物理郚
分に故障モヌドを遞択できる胜力は、ICS ず他の IT システムずの違いである。この遞択は、進行
䞭の物理プロセスを䞭断するため、故障の圱響を緩和する䞊で倧きな効果があるバルブが閉䜍
眮になるずシステム冷华に悪圱響が出るなど。

456

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SC-28 PROTECTION OF INFORMATION AT REST
CONTROL NAME
CNTL NO.
Control Enhancement Name
SC-28

CONTROL BASELINES
LOW

Protection of Information at Rest

MOD

HIGH

Selected

Selected

ICS Supplemental Guidance: The use of cryptographic mechanisms is determined after careful consideration and after verification
that it does not adversely impact the operational performance of the ICS.
SC-39 PROCESS ISOLATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
SC-39

Process Isolation

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: Example compensating controls include partition processes to separate platforms.
SC-41 PORT AND I/O DEVICE ACCESS
CONTROL NAME
Control Enhancement Name

CNTL NO.
SC-41

Port and I/O Device Access

CONTROL BASELINES
LOW

MOD

HIGH

Added

Added

Added

No ICS Supplemental Guidance.
Rationale for adding SC-24 to all baselines: The function of ICS can be readily determined in advance, making it easier to identify
ports and I/O devices that are unnecessary. Disabling or removing ports reinforces air-gap policy.

457

SP800-82 第 2 版

SC-28

産業甚制埡システムICSセキュリティガむド

䌑眠情報の保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
䌑眠情報の保護

SC-28

äž­

高

遞定

遞定

ICS 補足ガむダンス暗号メカニズムの利甚は、ICS の運甚に悪圱響がないこずを怜蚌し、
慎重に怜蚎しおから刀断する。
SC-39

プロセス隔離
管理名

管理番号

管理ベヌスラむン

管理拡匵名
プロセス隔離

SC-39

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンス補償的管理策の䟋ずしお、プラットホヌムを分離するためのパヌティ
ションプロセスがある。
SC-41

ポヌト及び I/O デバむスアクセス

管理番号

SC-41

管理名

管理ベヌスラむン

管理拡匵名
ポヌト及び I/O デバむスアクセス

䜎

äž­

高

远加

远加

远加

ICS 補足ガむダンスなし
SC-24 を党おのベヌスラむンに远加する理由ICS の機胜は予めすぐに決められるようにし、
䞍芁なポヌト及び I/O デバむスの識別を容易にする。ポヌトの無効化や削陀は、゚アギャップポ
リシヌを匷化する。

458

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SYSTEM AND INFORMATION INTEGRITY - SI
Tailoring Considerations for System and Information Integrity Family
In situations where the ICS cannot support the specific System and Information Integrity requirements of a control, the organization employs
compensating controls in accordance with the general tailoring guidance. Examples of compensating controls are given with each control, as
appropriate.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in conjunction
with the ICS Supplemental Guidance in this overlay, if any.
SI-1 SYSTEM AND INFORMATION INTEGRITY POLICY AND PROCEDURES
CONTROL NAME
CNTL NO.
SI-1

CONTROL BASELINES

Control Enhancement Name
System and Information Integrity Policy and Procedures

LOW

MOD

HIGH

Selected

Selected

Selected

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS and the relationship
to non-ICS systems.
SI-2 FLAW REMEDIATION
CONTROL NAME
CNTL NO.
SI-2

CONTROL BASELINES

Control Enhancement Name
Flaw Remediation

SI-2 (1)

FLAW REMEDIATION | CENTRAL MANAGEMENT

SI-2 (2)

FLAW REMEDIATION | AUTOMATED FLAW REMEDIATION
STATUS

LOW

MOD

HIGH

Selected

Selected

Selected
Selected

Selected

Selected

ICS Supplemental Guidance: Flaw Remediation is complicated since many ICS employ operating systems and other software that
is not current, is no longer being maintained by the vendors, and is not resistant to current threats. ICS operators are often dependent on
product vendors to validate the operability of a patch and also sometimes to perform the installation. Often flaws cannot be remediated based
on circumstances outside of the ICS operator's control (e.g., lack of a vendor patch). Sometime the organization has no choice but to accept
additional risk. In these situations, compensating controls should be implemented (e.g., limit the exposure of the vulnerable system). Other
compensating controls that do not decrease the residual risk but increase the ability to respond may be desirable (e.g., provide a timely
response in case of an incident; devise a plan to ensure the ICS can identify the exploitation of the flaw). Testing flaw remediation in an ICS
may require more resources than the organization can commit.
Control Enhancement: (1) No ICS Supplemental Guidance.
Control Enhancement: (2) ICS Supplemental Guidance: In situations where the ICS cannot support the use of automated
mechanisms to conduct and report on the status of flaw remediation, the organization employs nonautomated mechanisms or procedures
which incorporate methods to apply, track, and verify mitigation efforts as compensating controls in accordance with the general tailoring
guidance.
SI-3 MALICIOUS CODE PROTECTION
CONTROL NAME
CNTL NO.
SI-3

CONTROL BASELINES

Control Enhancement Name
Malicious Code Protection

LOW

MOD

HIGH

Selected

Selected

Selected

SI-3 (1)

MALICIOUS CODE PROTECTION | CENTRAL MANAGEMENT

Selected

Selected

SI-3 (2)

MALICIOUS CODE PROTECTION | AUTOMATIC UPDATES

Selected

Selected

ICS Supplemental Guidance: The use and deployment of malicious code protection is determined after careful consideration and
after verification that it does not adversely impact the operation of the ICS. Malicious code

459

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

システム及び情報の完党性 - SI
システム及び情報の安党性ファミリのカスタマむズ考慮事項
ICS がある制埡の特定のシステム及び情報完党性芁件に察応しおいない状況では、党䜓的なカ
スタマむズガむダンスに埓っお補償的管理策を採甚する。
補償的管理策の䟋が必芁に応じお、管理策ごずに瀺される。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダ
ンスを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
システム及び情報完党性ポリシヌ・手順

SI-1

管理名

管理番号

管理ベヌスラむン

管理拡匵名
システム情報完党性ポリシヌ・手順

SI-1

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスポリシヌは特に ICS の固有の特性・芁件及び ICS 以倖のシステムずの
関係を取り䞊げる。
欠陥修正

SI-2

管理名

管理番号

管理ベヌスラむン

管理拡匵名
欠陥修正

SI-2
SI-2 (1)

欠陥修正 | 集䞭管理

SI-2 (2)

欠陥修正 | 自動欠陥修正状態

䜎

äž­

高

遞定

遞定

遞定
遞定

遞定

遞定

ICS 補足ガむダンスICS の倚くは最新版以倖の OS や゜フトり゚アを䜿甚し、ベンダヌも
保守を行っおおらず、最新の脅嚁に抵抗性がないため、欠陥修正は耇雑ずなる。ICS 操䜜員は、
パッチの動䜜怜蚌や、ずきにはむンストヌルを行うだけでも、補品ベンダヌに䟝存するこずが倚
い。ICS 操䜜員の管理胜力を超えおいる状況では、欠陥の修正ができないこずが倚いベンダヌ
パッチの欠劂等。組織は、付加的なリスクを受け入れざるを埗ないこずがある。このような状
況では、補償的管理策を行う脆匱なシステムの露出制限等。その他の補償的管理策ずしおは、
残留リスクは枛らせないたでも、察応胜力が高めるようなものが望たしいむンシデント時にタ
むムリヌな察応や、悪甚されおいる欠陥を特定できる蚈画の䜜成等。ICS の欠陥修正怜蚌は、
組織が投入できる以䞊のリ゜ヌスを芁する堎合がある。
管理拡匵(1) ICS 補足ガむダンスなし
管理拡匵(2) ICS 補足ガむダンスICS が欠陥修正実斜・報告の自動メカニズムに察応しお
いない状況では、党䜓的なカスタマむズガむダンスに埓っお、組織は非自動メカニズム又は手順
を緩和努力の適甚・远跡・怜蚌のための補償的管理策ずしお採甚する。
悪意あるコヌド保護

SI-3

管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

遞定

遞定

遞定

SI-3 (1)

悪意あるコヌド保護 | 集䞭管理

遞定

遞定

SI-3 (2)

悪意あるコヌド保護 | 自動曎新

遞定

遞定

SI-3

悪意あるコヌド保護

䜎

ICS 補足ガむダンス悪意あるコヌド保護の利甚は、ICS の運甚に悪圱響がないこずを怜蚌
し、慎重に怜蚎しおから刀断する。悪意あるコヌド

460

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

protection tools should be configured to minimize their potential impact on the ICS (e.g., employ notification rather than quarantine).
Example compensating controls include increased traffic monitoring and auditing.
Control Enhancement: (1) ICS Supplemental Guidance: The organization implements central management of malicious code
protection with consideration of the impact on operation of the ICS. Example compensating controls include increased auditing.
Control Enhancement: (2) ICS Supplemental Guidance: The organization implements automatic updates of malicious code
protection with consideration of the impact on operation of the ICS. In situations where the ICS cannot support the use of automatic update
of malicious code protection, the organization employs nonautomated procedures as compensating controls in accordance with the general
tailoring guidance.
SI-4 INFORMATION SYSTEM MONITORING
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-4
SI-4 (2)

Information System Monitoring

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

Selected

INFORMATION SYSTEM MONITORING | AUTOMATED TOOLS
FOR REAL-TIME ANALYSIS

SI-4 (4)

INFORMATION SYSTEM MONITORING | INBOUND AND
OUTBOUND COMMUNICATIONS TRAFFIC

SI-4 (5)

INFORMATION SYSTEM MONITORING | SYSTEM-GENERATED
ALERTS

ICS Supplemental Guidance: The organization ensures that the use of monitoring tools and techniques does not adversely impact the
operational performance of the ICS. Example compensating controls include deploying sufficient network monitoring.
Control Enhancement: (2) ICS Supplemental Guidance: In situations where the ICS cannot support the use of automated tools to
support near-real-time analysis of events, the organization employs compensating controls (e.g., providing an auditing capability on a
separate system, nonautomated mechanisms or procedures) in accordance with the general tailoring guidance.
Control Enhancement: (4) ICS Supplemental Guidance: In situations where the ICS cannot monitor inbound and outbound
communications traffic, the organization employs compensating controls include providing a monitoring capability on a separate information
system.
Control Enhancement: (5) ICS Supplemental Guidance: Example compensating controls include manual methods of generating
alerts.
SI-5 SECURITY ALERTS, ADVISORIES, AND DIRECTIVES

CNTL NO.
SI-5
SI-5 (1)

CONTROL NAME
Control Enhancement Name
Security Alerts, Advisories, and Directives

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

SECURITY ALERTS, ADVISORIES, AND DIRECTIVES |

Selected

AUTOMATED ALERTS AND ADVISORIES
ICS Supplemental Guidance: The DHS Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) generates
security alerts and advisories relative to ICS http://ics-cert.us-cert.gov/ .
Control Enhancement: (1) No ICS Supplemental Guidance.
SI-6 SECURITY FUNCTIONALITY VERIFICATION

CNTL NO.
SI-6

CONTROL NAME
Control Enhancement Name
Security Function Verification

CONTROL BASELINES
LOW

MOD

HIGH
Selected

ICS Supplemental Guidance: The shutting down and restarting of the ICS may not always be feasible upon the identification of an
anomaly; these actions should be scheduled according to ICS operational requirements.

461

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

保護ツヌルは、ICS ぞの圱響が最小になるように蚭定すべきである怜疫ではなく通知を採甚す
るなど。補償的管理策の䟋ずしお、トラフィック監芖ず監査の匷化がある。
管理拡匵(1) ICS 補足ガむダンス組織は、ICS の運甚ぞの圱響を考慮に入れお、悪意ある
コヌド保護の集䞭管理を実斜する。補償的管理策の䟋ずしお、監査の匷化がある。
管理拡匵(2) ICS 補足ガむダンス組織は、ICS の運甚ぞの圱響を考慮に入れお、悪意ある
コヌド保護の自動曎新を実斜する。ICS が悪意あるコヌド保護の自動曎新利甚に察応しおいない
状況では、組織は、党䜓的なカスタマむズガむダンスに埓っお非自動メカニズムを補償的管理策
ずしお採甚する。
情報システム監芖

SI-4

管理名

管理番号

管理ベヌスラむン

管理拡匵名
情報システム監芖

SI-4

䜎

äž­

高

遞定

遞定

遞定

SI-4 (2)

情報システム監芖 | リアルタむム分析甚自動ツヌル

遞定

遞定

SI-4 (4)

情報システム監芖 | 着信・発信通信トラフィック

遞定

遞定

SI-4 (5)

情報システム監芖 | システム生成アラヌト

遞定

遞定

ICS 補足ガむダンス組織は、監芖ツヌル・技術の利甚が ICS の運甚パフォヌマンスに悪圱
響しないようにする。補償的管理策の䟋ずしお、十分なネットワヌク監芖の展開がある。
管理拡匵(2) ICS 補足ガむダンスICS がほがリアルタむムでの事象分析察応自動ツヌルに
察応しおいない状況では、組織は、党䜓的なカスタマむズガむダンスに埓っお補償的管理策を採
甚する別システムぞの監査機胜付䞎、非自動メカニズム・手順等。
管理拡匵(4) ICS 補足ガむダンスICS が着信・発信通信トラフィックを監芖できない状況
では、組織は、別情報システムぞの監芖機胜付䞎等の補償的管理策を採甚する。
管理拡匵(5) ICS 補足ガむダンス補償的管理策の䟋ずしお、手動によるアラヌト生成があ
る。
セキュリティ譊報・勧告・指瀺

SI-5

管理名

管理番号

管理ベヌスラむン

管理拡匵名
セキュリティ譊報・勧告・指瀺

SI-5

䜎

äž­

高

遞定

遞定

遞定

セキュリティ譊報・勧告・指瀺 | 自動アラヌト・勧告

SI-5 (1)

遞定

ICS 補足ガむダンスDHS の産業甚制埡システムサむバヌ緊急察応チヌム(ICS-CERT)は、
ICS に関連した接続アラヌト及び勧告を䜜成しおいる。http://ics-cert.us-cert.gov/
管理拡匵(1) ICS 補足ガむダンスなし
セキュリティ機胜怜蚌

SI-6

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SI-6

セキュリティ機胜怜蚌

äž­

高
遞定

ICS 補足ガむダンスICS の遮断及び再起動は、異状怜出時に必ずしも盎ちに可胜ではない。
ICS 運甚芁件に埓っおスケゞュヌルを立おるべきである。

462

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SI-7 SOFTWARE AND INFORMATION INTEGRITY
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-7
SI-7 (1)

CONTROL BASELINES
LOW

MOD

HIGH

Software, Firmware, and Information Integrity

Selected

Selected

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |

Selected

Selected

INTEGRITY CHECKS
SI-7 (2)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |

Selected

AUTOMATED NOTIFICATIONS OF INTEGRITY VIOLATIONS
SI-7 (5)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |

Selected

AUTOMATED RESPONSE TO INTEGRITY VIOLATIONS
SI-7 (7)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |

Selected

Selected

INTEGRATION OF DETECTION AND RESPONSE
SI-7 (14)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |

Selected

BINARY OR MACHINE EXECUTABLE CODE
ICS Supplemental Guidance: The organization determines whether the use of integrity verification applications would adversely
impact the operation of the ICS and employs compensating controls (e.g., manual integrity verifications that do not affect performance.
Control Enhancements: (1) ICS Supplemental Guidance: The organization ensures that the use of integrity verification
applications does not adversely impact the operational performance of the ICS.
Control Enhancement: (2) ICS Supplemental Guidance: In situations where the organization cannot employ automated tools that
provide notification of integrity discrepancies, the organization employs nonautomated mechanisms or procedures. Example compensating
controls include performing scheduled manual inspections for integrity violations.
Control Enhancement: (5) ICS Supplemental Guidance: The shutting down and restarting of the ICS may not always be feasible
upon the identification of an anomaly; these actions should be scheduled according to ICS operational requirements.
Control Enhancement: (7) ICS Supplemental Guidance: In situations where the ICS cannot detect unauthorized security-relevant
changes, the organization employs compensating controls (e.g., manual procedures) in accordance with the general tailoring guidance.
Control Enhancement: (14) No ICS Supplemental Guidance.
SI-8 SPAM PROTECTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-8
SI-8 (1)

CONTROL BASELINES
LOW

MOD

HIGH

Spam Protection

Selected

Selected

SPAM PROTECTION | CENTRAL MANAGEMENT OF

Selected

Selected

Selected

Selected

PROTECTION MECHANISMS
SI-8 (2)

SPAM PROTECTION | AUTOMATIC UPDATES

ICS Supplemental Guidance: ICS spam protection may be implemented by removing spam transport mechanisms, functions and
services (e.g., electronic mail, Internet access) from the ICS. If any spam transport mechanisms, functions and services are present in the ICS,
spam protection in ICS takes into account operational characteristics of ICS that differ from general purpose information systems, (e.g.,
unusual traffic flow that may be misinterpreted and detected as spam. Example compensating controls include whitelist mail transfer agents
(MTA), digitally signed messages, acceptable sources, and acceptable message types.
Control Enhancement: (1) ICS Supplemental Guidance: Example compensating controls include employing local mechanisms or
procedures.
Control Enhancement: (2) No ICS Supplemental Guidance.

463

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

゜フトり゚ア及び情報の完党性

SI-7

管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

゜フトり゚ア・ファヌムり゚ア・情報の完党性

䜎

遞定

遞定

SI-7 (1)

゜フトり゚ア・ファヌムり゚ア・情報の完党性 | 完党性チェック

遞定

遞定

SI-7 (2)

゜フトり゚ア・ファヌムり゚ア・情報の完党性 | 完党性違反の自

SI-7

遞定

動通知
゜フトり゚ア・ファヌムり゚ア・情報の完党性 | 完党性違反の自

SI-7 (5)

遞定

動察応
゜フトり゚ア・ファヌムり゚ア・情報の完党性 |

SI-7 (7)

遞定

遞定

怜出・察応の䞀䜓化
SI-7 (14)

゜フトり゚ア・ファヌムり゚ア・情報の完党性 | バむナリ又はマ

遞定

シン実行可胜コヌド

ICS 補足ガむダンス組織は、完党性怜蚌アプリケヌションの利甚により、ICS の運甚に悪
圱響が及ばないか刀定し、補償的管理策を採甚するパフォヌマンスに圱響しない手動怜蚌等。
管理拡匵(1) ICS 補足ガむダンス組織は、完党性怜蚌アプリケヌションの利甚が ICS の運
甚パフォヌマンスに悪圱響しないようにする。
管理拡匵(2) ICS 補足ガむダンス完党性の䞍備を通知する自動ツヌルを採甚できない状況
では、組織は、非自動メカニズム・手順を採甚する。補償的管理策の䟋ずしお、完党性違反に察
するスケゞュヌル化された手動点怜の実斜がある。
管理拡匵(5) ICS 補足ガむダンスICS の遮断及び再起動は、異状怜出時に必ずしも盎ちに
可胜ずいうわけではない。ICS 運甚芁件に埓っおスケゞュヌルを立おるべきである。
管理拡匵(7) ICS 補足ガむダンスICS がセキュリティ関連の無断倉曎を怜出できない状況
では、組織は、党䜓的なカスタマむズガむダンスに埓っお補償的管理策手動手順等を採甚す
る。
管理拡匵(14) ICS 補足ガむダンスなし
スパム保護

SI-8

管理名

管理番号

管理ベヌスラむン

管理拡匵名

äž­

高

スパム保護

䜎

遞定

遞定

SI-8 (1)

スパム保護 | 保護メカニズムの集䞭管理

遞定

遞定

SI-8 (2)

スパム保護 | 自動曎新

遞定

遞定

SI-8

ICS 補足ガむダンスICS のスパム保護は、スパム転送メカニズム、機胜及びサヌビス電
子メヌル、むンタヌネットアクセス等を排陀するこずにより行われる。スパム転送メカニズム、
機胜及びサヌビスが ICS に存圚しおいる堎合、ICS のスパム保護は、汎甚的な情報システムス
パムずしお誀解・怜出される通垞ず違うトラフィックフロヌ等ずは異なる ICS の運甚特性を考
慮に入れる。補償的管理策の䟋ずしお、ホワむトリストメヌル転送゚ヌゞェントMTA、デゞ
タル眲名入りメッセヌゞ、受け入れられる゜ヌス、受け入れられるメッセヌゞタむプがある。
管理拡匵(1) ICS 補足ガむダンス補償的管理策の䟋ずしお、ロヌカルメカニズム又はロヌ
カル手順がある。
管理拡匵(2) ICS 補足ガむダンスなし

464

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

SI-10 INFORMATION INPUT VALIDATION
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-10

CONTROL BASELINES
LOW

Information Input Validation

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SI-11 ERROR HANDLING
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-11

CONTROL BASELINES
LOW

Error Handling

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SI-12 INFORMATION HANDLING AND RETENTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-12

Information Handling and Retention

CONTROL BASELINES
LOW

MOD

HIGH

Selected

Selected

Selected

No ICS Supplemental Guidance.
SI-13 PREDICTABLE FAILURE PREVENTION

CNTL NO.
SI-13

CONTROL NAME
Control Enhancement Name

CONTROL BASELINES
LOW

MOD

Predictable Failure Prevention

HIGH
Added

ICS Supplemental Guidance: Failures in ICS can be stochastic or deterministic. Stochastic failures can be analyzed using
probability theory, while analysis of deterministic failures is based on non-random properties of the system. Known ICS failure modes and
causes are considered. The calculation and use of statistical descriptors, such as Mean Time To Failure (MTTF), should incorporate
additional analysis to determine how those failures manifest within the cyber and physical domains. Knowledge of these possible
manifestations may be necessary to detect whether a failure has occurred within the ICS, as failures of the information systems may not be
easily identifiable. Emergent properties, which may arise both within the information systems and physical processes, can potentially cause
system failures should be incorporated into the analysis. For example, cumulative effects of resource exhaustion (e.g., memory leakage) or
errors (e.g., rounding and truncation) can occur when ICS processes execute for unexpectedly long periods. Deterministic failures (e.g.,
integer counter overflow), once identified, are preventable.
Often substitute components may not be available or may not be sufficient to protect against faults occurring before predicted failure.
Non-automated mechanisms or physical safeguards should be in place in order to protect against these failures.
In addition to information concerning newly discovered vulnerabilities (i.e., latent flaws) potentially affecting the system/applications that
are discovered by forensic studies, new vulnerabilities may be identified by organizations with responsibility for disseminating vulnerability
information (e.g., ICS-CERT) based upon an analysis of a similar pattern of incidents reported to them or vulnerabilities reported by other
researchers.
Related controls: IR-5, IR-6, RA-5, SI-2, SI-5, SI-11.
Rationale for adding control to baseline: ICS are designed and built with certain boundary conditions, design parameters, and
assumptions about their environment and mode of operation. ICS may run much longer than conventional systems, allowing latent flaws to
become effective that are not manifest in other environments. For example, integer overflow might never occur in systems that are reinitialized more frequently than the occurrence of the overflow. Experience and forensic studies of anomalies and incidents in ICS can lead
to identification of emergent properties that were previously unknown, unexpected, or unanticipated. Preventative and restorative

465

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

情報入力怜蚌

SI-10

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
情報入力怜蚌

SI-10

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
゚ラヌ凊理

SI-11

管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
゚ラヌ凊理

SI-11

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SI-12

情報凊理保留
管理名

管理番号

管理ベヌスラむン

管理拡匵名
情報凊理保留

SI-12

䜎

äž­

高

遞定

遞定

遞定

ICS 補足ガむダンスなし
SI-13

予想される故障の防止
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎

SI-13

予想される故障の防止

äž­

高
远加

ICS 補足ガむダンスICS における故障は、確率的なものか決定論的なもののいずれかであ
る。確率的故障は確立理論で分析でき、決定論的故障の分析は、システムの非ランダム特性を根
拠に行う。既知の ICS 故障モヌド及び原因に぀いお考慮する。平均故障時間MTTF等の統蚈
蚘述子の蚈算及び䜿甚は、サむバヌ領域及び物理領域におけるそのような故障の出珟の仕方を刀
別する際の補足的な分析力ずなる。情報システムの故障は容易には特定できないため、そうした
出珟に関する知識は、ICS での故障発生の有無を刀断するのに必芁ずなる。情報システムでも物
理プロセスでも生じる創発特性は、システム故障になりかねないため、分析に含めるべきである。
䟋えば、ICS プロセスの実行が予定以䞊に長びくず、リ゜ヌスの枯枇メモリリヌク等による
环積圱響や゚ラヌ数倀の切䞊げ・切䞋げ・切捚お等が生じる。䞀床特定された決定論的故障
敎数カりンタのオヌバヌフロヌ等は予防可胜である。
予想される故障よりも前に発生する故障に察しおは、代替コンポヌネントがないか、あっお
も十分には防止できない。このような故障に察しおは、非自動メカニズム又は物理的察策を講じ
るべきである。
調査で新たに芋぀かった、システムやアプリケヌションに圱響を䞎えかねない脆匱性朜圚
的欠陥情報に加えお、脆匱性情報の配垃担圓機関ICS-CERT 等によっおも新芏の脆匱性が
明らかにされるこずがある。そうした情報は、届出のあった同皮パタヌンや倖郚研究者らから埗
た脆匱性分析に基づいおいる。
関連する管理IR-5, IR-6, RA-5, SI-2, SI-5, SI-11
ベヌスラむンに管理を远加する理由ICS の蚭蚈及び構築には、特定の境界条件、蚭蚈パラ
メヌタ及び環境・運甚モヌド想定が盛り蟌たれおいる。ICS の運転時間は、圚来システムよりも
はるかに長く、他の環境では衚面に出おこない朜圚的欠陥が珟れる。䟋えば、敎数のオヌバヌフ
ロヌは、オヌバヌフロヌ頻床よりも倚く再初期化されるシステムでは、たず生じるこずがない。
ICS における異垞及びむンシデントの調査経隓が、それたで知られおおらず、予想・予期されお
いなかった創発特性の特定に結び぀いおいる。

466

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

actions (e.g., re-starting the system or application) are prudent but may not be acceptable for operational reasons in ICS.
SI-16 MEMORY PROTECTION
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-16

CONTROL BASELINES
LOW

Memory Protection

MOD

HIGH

Selected

Selected

No ICS Supplemental Guidance.
SI-17 FAIL-SAFE PROCEDURES
CONTROL NAME
Control Enhancement Name

CNTL NO.
SI-17

Fail-Safe Procedures

CONTROL BASELINES
LOW

MOD

HIGH

Added

Added

Added

ICS Supplemental Guidance: The selected failure conditions and corresponding procedures may vary among baselines. The same
failure event may trigger different response depending on the impact level. Mechanical and analog system can be used to provide
mechanisms to ensure fail-safe procedures. Fail-safe states should incorporate potential impacts to human safety, physical systems, and the
environment. Related controls: CP-6.
Rationale for adding SI-17 to all baselines: This control provides a structure for the organization to identify their policy and
procedures for dealing with failures and other incidents. Creating a written record of the decision process for selecting incidents and
appropriate response is part of risk management in light of changing environment of operations.

467

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

予防・回埩行動システムやアプリケヌションの再起動等は良識的な方法ではあるが、ICS の
運甚䞊の理由から受け入れられない。
SI-16

メモリ保護
管理名

管理番号

管理ベヌスラむン

管理拡匵名
䜎
メモリ保護

SI-16

äž­

高

遞定

遞定

ICS 補足ガむダンスなし
SI-17

フェヌルセヌフ手順
管理名

管理番号

SI-17

管理ベヌスラむン

管理拡匵名
フェヌルセヌフ手順

䜎

äž­

高

远加

远加

远加

ICS 補足ガむダンス遞定した故障条件ず察応手順は、ベヌスラむンに応じお異なる。同じ
故障事象でも、圱響床によっお別の察応ずなる。機械匏・アナログシステムを䜿甚しお、フェヌ
ルセヌフ手順メカニズムを備えるこずができる。フェヌルセヌフ状態は、人員の安党、物理シス
テム及び環境に圱響を及がしかねない。関連する管理CP-6
SI-17 を党おのベヌスラむンに远加する理由組織はこの管理により、故障その他のむンシ
デント凊理のポリシヌ・手順を明らかにできる。むンシデントず適切な察応を遞ぶ際の決定プロ
セスを文曞にするこずは、運甚環境の倉化ずいう芳点から、リスク管理の䞀郚ずなる

468

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

ORGANIZATION-WIDE INFORMATION SECURITY PROGRAM MANAGEMENT CONTROLS - PM
Characteristics of Organization-Wide Information Security Program Management Control Family
Organization-Wide Information Security Program Management Controls are deployed organization-wide supporting the information
security program. They are not associated with security control baselines and are independent of any system impact level.
Supplemental Guidance
Supplemental Guidance for all Controls and Control Enhancements in NIST SP 800-53 Rev. 4, Appendix F, should be used in
conjunction with the ICS Supplemental Guidance in this overlay, if any.
PM-1 INFORMATION SECURITY PROGRAM PLAN
CONTROL NAME
Control Enhancement Name

CNTL NO.
PM-1

Information Security Program Plan Policy and Procedures

ICS Supplemental Guidance: The policy specifically addresses the unique properties and requirements of ICS, the relationship to
non-ICS systems, and the relationship to other programs concerned with operational characteristics of ICS (e.g., safety, efficiency, reliability,
resilience).
PM-2 SENIOR INFORMATION SECURITY OFFICER
CONTROL NAME
Control Enhancement Name

CNTL NO.
PM-2

Senior Information Security Officer

No ICS Supplemental Guidance.
PM-3 INFORMATION SECURITY RESOURCES

CNTL NO.
PM-3

CONTROL NAME
Control Enhancement Name
Information Security Resources

ICS Supplemental Guidance: Capital planning and investment decisions address all of the relevant technologies and all phases of
the life cycle and needs to be informed by ICS experts as well as other subject matter experts (e.g., information security). Marshaling
interdisciplinary working teams to advise capital planning and investment decisions can help tradeoff and balance among conflicting equities,
objectives, and responsibilities such as capability, adaptability, resilience, safety, security, usability, and efficiency.
PM-4 PLAN OF ACTION AND MILESTONES PROCESS

CNTL NO.
PM-4

CONTROL NAME
Control Enhancement Name
Plan of Action and Milestones Process

ICS Supplemental Guidance: The plan of action and milestones includes both computational and physical ICS components.
Records of observed shortcomings and appropriate remedial action may be maintained in a single document or in multiple coordinated
documents (e.g., future engineering plans).

469

SP800-82 第 2 版

産業甚制埡システムICSセキュリティガむド

党組織的情報セキュリティプログラム管理察策 - PM
党組織的情報セキュリティプログラム管理察策ファミリの特城
党組織的情報セキュリティプログラム管理察策は、党組織に展開され、情報セキュリティプログ
ラムを支える。セキュリティ察策ベヌスラむンは付随しおおらず、いかなるシステム圱響レベル
ずも無関係である。
補足ガむダンス
利甚できる堎合には、NIST SP 800-53 第 4 版付録 F にある党おの管理・管理拡匵甚補足ガむダン
スを、このオヌバヌレむにおいお、ICS 補足ガむダンスず䜵甚すべきである。
PM-1

情報セキュリティプログラム蚈画曞
管理名

管理番号

管理拡匵名
情報セキュリティプログラム蚈画曞ポリシヌ・手順

PM-1

ICS 補足ガむダンス特にポリシヌは、ICS 独特の特性及び芁件、ICS 以倖のシステムずの
関係及び ICS の運甚特性に関係する他のプログラムずの関係安党性、効率、信頌性、匟力性
等を取り䞊げる。
PM-2

䞊玚情報セキュリティ担圓官
管理名

管理番号

管理拡匵名
䞊玚情報セキュリティ担圓官

PM-2

ICS 補足ガむダンスなし
PL-3

情報セキュリティリ゜ヌス
管理名

管理番号

管理拡匵名
情報セキュリティリ゜ヌス

PM-3

ICS 補足ガむダンス䞻芁プランニング及び投資決定は、関係する党技術、党ラむフサむク
ル段階及び ICS 専門家その他の専門家情報セキュリティ等からの情報を必芁ずする分野に぀
いお取り䞊げる。䞻芁プランニング及び投資決定に぀いお助蚀する分野暪断的な䜜業チヌムを結
集すれば、胜力・適応性・匟力性・安党性・セキュリティ・ナヌザビリティ・効率等の公正、目
的及び責任の競合に぀いお比范考量し、バランスを取る䞊で支揎を差し䌞べるこずができる。
PM-4

行動・マむルストヌンプロセス蚈画曞

管理番号

PM-4

管理名

管理拡匵名
行動・マむルストヌンプロセス蚈画曞

ICS 補足ガむダンス行動・マむルストヌン蚈画曞には、コンピュヌタ関係ず物理䞡面での
ICS コンポヌネントが含たれる。芳察された欠点及び適切な修正凊眮は、1 冊の文曞又は耇数の
連携文曞将来の゚ンゞニアリング蚈画曞等ずしお維持する。

470

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PM-5 INFORMATION SYSTEM INVENTORY
CONTROL NAME
CNTL NO.
PM-5

Control Enhancement Name
Information System Inventory

No ICS Supplemental Guidance.
PM-6 INFORMATION SECURITY MEASURES OF PERFORMANCE
CONTROL NAME
CNTL NO.
PM-6

Control Enhancement Name
Information Security Measures of Performance

No ICS Supplemental Guidance.
PM-7 ENTERPRISE ARCHITECTURE
CONTROL NAME
CNTL NO.
PM-7

Control Enhancement Name
Enterprise Architecture

No ICS Supplemental Guidance.
PM-8 CRITICAL INFRASTRUCTURE PLAN
CONTROL NAME
CNTL NO.
PM-8

Control Enhancement Name
Critical Infrastructure Plan

No ICS Supplemental Guidance.
References: Executive Order 13636– Improving Critical Infrastructure Cybersecurity, February 12, 2013
PM-9 RISK MANAGEMENT STRATEGY
CONTROL NAME
CNTL NO.
PM-9

Control Enhancement Name
Risk Management Strategy

ICS Supplemental Guidance: Risk management of ICS is considered along with other organizational risks affecting
mission/business success from an organization-wide perspective. Organization-wide risk management strategy includes sector-specific
guidance as appropriate.
PM-10 SECURITY AUTHORIZATION PROCESS
CONTROL NAME
CNTL NO.
PM-10

Control Enhancement Name
Security Authorization Process

ICS Supplemental Guidance: The authorization to operate processes for ICS involves multiple disciplines that have existing
approval and risk management process (e.g., physical security, safety). Organization-wide risk management requires harmonization among
these disciplines.

471

SP800-82 第 2 版

PM-5

産業甚制埡システムICSセキュリティガむド

情報システム目録
管理名

管理番号

管理拡匵名
情報システム目録

PM-5

ICS 補足ガむダンスなし
PM-6

情報セキュリティに関するパフォヌマンス蚈枬
管理名

管理番号

管理拡匵名
情報セキュリティに関するパフォヌマンス蚈枬

PM-6

ICS 補足ガむダンスなし
PM-7

䌁業アヌキテクチャ
管理名

管理番号

管理拡匵名
䌁業アヌキテクチャ

PM-7

ICS 補足ガむダンスなし
PM-8

重芁むンフラ蚈画曞
管理名

管理番号

管理拡匵名
重芁むンフラ蚈画曞

PM-8

ICS 補足ガむダンスなし
参考文献倧統領呜什 13636「重芁むンフラストラクチャのサむバヌセキュリティ改善」
2013 幎 2 月 12 日
PM-9

リスク管理戊略
管理名

管理番号

管理拡匵名
リスク管理戊略

PM-9

ICS 補足ガむダンスICS のリスク管理は、党組織的芳点に立ち、任務・事業の成吊に圱響
する組織の他のリスクず合わせお怜蚎する。党組織的管理戊略には、必芁に応じお郚門固有のガ
むダンスが含たれる。
PM-10

セキュリティ暩限プロセス
管理名

管理番号

PM-10

管理拡匵名
セキュリティ暩限プロセス

ICS 補足ガむダンスICS のプロセスを操䜜する暩限には、倚数の領域が関係しおおり、既
存の承認・リスク管理プロセスがある物理的セキュリティ、安党性等。党組織的リスク管理
には、これら領域間での芏制が必芁ずなる。

472

SPECIAL PUBLICATION 800-82 REVISION 2

GUIDE TO INDUSTRIAL CONTROL SYSTEMS (ICS) SECURITY

PM-11 MISSION/BUSINESS PROCESS DEFINITION
CONTROL NAME
CNTL NO.
PM-11

Control Enhancement Name
Mission/Business Process Definition

ICS Supplemental Guidance: Mission/business processes refinement requires protection of physical assets from damage originating
in the cyber domain. These needs are derived from the mission/business needs defined by the organization, the mission/business processes
selected to meet the stated needs, and the organizational risk management strategy.
PM-12 INSIDER THREAT PROGRAM
CONTROL NAME
CNTL NO.
PM-13

Control Enhancement Name
Information Security Workforce

No ICS Supplemental Guidance.
PM-13 INFORMATION SECURITY WORKFORCE
ICS Supplemental Guidance: All aspects of information security workforce development and improvement programs include
knowledge and skill levels in both computational and physical ICS components.
PM-14 TESTING, TRAINING, AND MONITORING
CONTROL NAME
CNTL NO.
PM-14

Control Enhancement Name
Testing, Training, and Monitoring

No ICS Supplemental Guidance.
PM-15 CONTACTS WITH SECURITY GROUPS AND ASSOCIATIONS
CONTROL NAME
CNTL NO.
PM-15

Control Enhancement Name
Contacts with Security Groups and Associations

No ICS Supplemental Guidance.
PM-16 THREAT AWARENESS PROGRAM
CONTROL NAME
CNTL NO.
PM-16

Control Enhancement Name
Threat Awareness Program

ICS Supplemental Guidance: The organization should collaborate and share information about potential incidents on a timely basis.
The DHS National Cybersecurity & Communications Integration Center (NCCIC), http://www.dhs.gov/about-national-cybersecuritycommunications-integration-center serves as a centralized location where operational elements involved in cybersecurity and
communications reliance are coordinated and integrated. The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)
http://ics-cert.us-cert.gov/ics-cert/ collaborates with international and private sector Computer Emergency Response Teams (CERTs) to share
control systems-related security incidents and mitigation measures. Organizations should consider having both an unclassified and classified
information sharing capability.

473

SP800-82 第 2 版

PM-11

産業甚制埡システムICSセキュリティガむド

任務・事業プロセス定矩
管理名

管理番号

管理拡匵名
任務・事業プロセス定矩

PM-11

ICS 補足ガむダンス任務・事業プロセスを掗緎させるには、物理的資産をサむバヌ領域に
起因する損害から保護しなければならない。このような需芁は、組織が明らかにした任務・事業
䞊の需芁、需芁を満たすために遞んだ任務・事業プロセス及び組織のリスク管理戊略から生じる。
PM-12

むンサむダヌ脅嚁プログラム
管理名

管理番号

管理拡匵名
むンサむダヌ脅嚁プログラム

PM-12

ICS 補足ガむダンスなし
PL-3

情報セキュリティワヌクフォヌス
管理名

管理番号

管理拡匵名
情報セキュリティワヌクフォヌス

PM-13

ICS 補足ガむダンス情報セキュリティワヌクフォヌス開発改善プログラムのあらゆる面には、
コンピュヌタ関係ず物理䞡面での ICS コンポヌネントに関する知識・技量レベルが含たれる。
PM-14

詊隓・蚓緎・監芖
管理名

管理番号

管理拡匵名
詊隓・蚓緎・監芖

PM-14

ICS 補足ガむダンスなし
PM-15

セキュリティグルヌプ・協䌚ずの連絡
管理名

管理番号

管理拡匵名
セキュリティグルヌプ・協䌚ずの連絡

PM-15

ICS 補足ガむダンスなし
PM-16

脅嚁意識プログラム
管理名

管理番号

PM-16

管理拡匵名
脅嚁意識プログラム

ICS 補足ガむダンス組織は、生じ埗るむンシデントに関しお連携し情報を適時に共有すべ
きである。䞋蚘 DHS 囜家サむバヌセキュリティ通信統合センタヌ(NCCIC)は集䞭所圚地ずしお機
胜し、サむバヌセキュリティず通信の信頌性に関わる運甚芁玠はそこで調敎され、統合化されお
いる。http://www.dhs.gov/about-national-cybersecurity-communications-integration-center 䞋蚘産業甚
制埡システムサむバヌ緊急察応チヌム(ICS-CERT)は、海倖及び民間のコンピュヌタ緊急察応チヌ
ム(CERT)ず連携しお、制埡システム関連セキュリティむンシデント情報ず緩和察策を共有しお
いる。http://ics-cert.us-cert.gov/ics-cert/
組織は、秘密情報ず普通情報の共有化に぀いお怜蚎すべきである。

474
Source Exif Data: 
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.7
Linearized                      : Yes
Author                          : NIST,JPCERT/CC
Comments                        : 
Company                         : 
Create Date                     : 2016:04:05 13:42:33+09:00
Modify Date                     : 2016:04:12 09:20:04+09:00
Source Modified                 : D:20160405044107
Subject                         : 産業甚制埡システム(ICS)セキュリティガむド
Has XFA                         : No
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03
Metadata Date                   : 2016:04:12 09:20:04+09:00
Creator Tool                    : Word 甹 Acrobat PDFMaker 11
Document ID                     : uuid:c4256d42-c7e6-4928-aedb-ebc1596eca74
Instance ID                     : uuid:f273de0f-5f70-4976-8ee3-cc6575384009
Format                          : application/pdf
Title                           : Guide to Industrial Control System (ICS) Security
Description                     : 産業甚制埡システム(ICS)セキュリティガむド
Creator                         : NIST,JPCERT/CC
Producer                        : Adobe PDF Library 11.0
Page Layout                     : OneColumn
Page Count                      : 490
Signing Date                    : 2016:04:12 09:20:04+09:00
Signing Authority               : Japan Computer Emergency Response Team Coordination Center
Modification Permissions        : No changes permitted
EXIF Metadata provided by EXIF.tools

Navigation menu