IEC62443标准：工业物联网的网络安全防护

下载需积分: 10 | PDF格式 | 1.81MB | 更新于2024-07-09 | 17 浏览量 | 举报

"ISA-d62443-2-3.pdf" 是一份与工业物联网（IIoT）网络安全相关的标准草案，源自ISA99委员会的工作成果，旨在加强工业自动化控制系统的安全防护。正文: 随着工业物联网的发展，工业网络的安全问题日益凸显。传统上，工业网络是封闭的，与公共互联网隔离，以确保生产和运营过程的安全。然而，IIoT的兴起推动了这些封闭系统与互联网的连接，以实现更高效的数据交换和远程监控。这一变化虽带来了诸多益处，如提升生产效率、优化资源分配，但也引入了新的网络安全风险。 IEC62443标准是应对这一挑战的重要工具。该标准由国际电工委员会（IEC）制定，它提供了一套全面的网络安全指南和最佳实践，覆盖了从设备到系统的各个层面。标准的目的是保护工业控制系统免受已知和未知的网络攻击，确保工业自动化环境的安全。 IEC62443标准分为多个部分，其中2-3部分可能涉及了特定的安全管理和技术措施。这些措施可能包括： 1. **风险管理**：标准要求对工业控制系统进行全面的风险评估，识别关键资产和潜在威胁，以便制定相应的防护策略。 2. **安全生命周期管理**：强调了产品和系统的安全生命周期，从设计、开发、实施、运行到退役，每个阶段都需要考虑网络安全。 3. **访问控制**：规定了用户认证、授权和审计机制，限制未经授权的访问，防止内部或外部攻击者侵入系统。 4. **安全配置**：指导如何正确配置硬件和软件，避免默认密码、未更新的固件和开放的服务成为攻击入口。 5. **安全更新与补丁管理**：要求定期更新系统，及时应用安全补丁，以修复已知漏洞。 6. **事件响应与恢复计划**：建立有效的应急响应机制，确保在发生安全事件时能迅速恢复业务。 7. **监控与日志记录**：通过实时监控网络流量和异常行为，以及详细的日志记录，可以及早发现并追踪潜在的攻击。 8. **培训与意识**：强调员工网络安全培训的重要性，提升全员的安全意识，减少因人为错误导致的安全漏洞。这份标准草案尚未经过正式审查，可能存在不完整之处，并可能会有进一步修改。尽管如此，它仍然是当前IIoT安全领域的重要参考，为企业和政府提供了构建更安全工业环境的框架。遵循IEC62443标准，可以显著提高工业网络的防御能力，降低由IIoT带来的潜在安全损害。

ISA-TR62443-2-3, D1E11, November 28, 2012– 12 – ISA99, WG06, TG02

[8] ISO 8601:2004 – Data elements and interchange formats -- Information interchange --

Representation of dates and times

[9] ECE/TRADE/C/CEFACT/2009/24 – Codes for Units of Measure used in International Trade

[10] ECE/TRADE/C/CEFACT/2009/25 – Codes for Passengers, Types of Cargo, Packages and

Packaging Materials (with Complementary Codes for Package Names)

3 Terms, definitions, abbreviated terms, acronyms, and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in ISA‑62443‑1‑1 (99.01.01)

―Terminology, Concepts, Models‖, ISA‑TR62443‑1‑2 (TR99.01.02) ―Master Glossary of Terms

and Abreviations‖, and the following apply.

3.1.1

bug

in the context of patch management, a flaw in the original development of software which causes

in to perform or behave in an unintended manner.

3.1.2

patch

an incremental software change in order to address a security vulnerability, reliability or

operability issue, or new feature.

NOTE: Patches may also be called also called software updates, software upgrades, firmware upgrades, service

packs, hotfixes, BIOS updates, and other digital electronic program updates.

3.1.3

patch lifecycle

the point in time that a patch is required/created. In the context of

ISA‑TR62443‑2‑3 (TR99.02.03), this lifecycle begins when the patch is created by the software

developer.

NOTE: Some feel that the patching lifecycle begins when the vulnerability has been disclosed. However, it is not

possible for this technical report to provide all possible guidance for the mitigation of vulnerabilities for the period

between disclosure of a vulnerability, and the availability of a patch. It is also to the discretion of the software

developer (i.e. product supplier) to determine if they shall develop a patch.

NOTE 2: The topic of vulnerability disclosure remains a concern to both asset owners and product suppliers. It is

considered to be an important topic to be revisited in the future.

3.1.4

patch management

the process of using a strategy and plan of what patches should be applied to which systems at a

specified time.

[Source: Wikipedia, http://wikipedia.org. cited 16 November 2012.]

NOTE: In the context of this technical report, this applies to IACS. Patch management refers to the complete

lifecycle of the update which may begin with the disclosure of a vulnerability or functionality issue, through creation of

the patch, testing, deployment, and verification.

3.1.5

new term

word replacement definition phrase

NOTE 1 Any extra text necessary to fully define or explain the term in its current context. This can include full

sentences and other things.

NOTE 2 Another note discussing the term.

EXAMPLE Don‘t include examples of the term in the definition, include them separately.

[International Standard Reference for Definition]

This copy of a draft work product of the ISA99 committee is provided solely for the purpose of supporting the further development of committee work products.

The content has not been formally approved by the committee or ISA. It may not be complete and is subject to change.

This document may not be copied, distributed to others or offered for further reproduction or for sale.

ISA99, WG06, TG02 – 13 –ISA-TR62443-2-3, D1E11, November 28, 2012

SKELETON NOTE Only add in the reference at the end of the term if it relates directly to something from an

international standard. IEC seems to dislike referencing national standards documents (ISA, NIST, NERC, NEMA, etc.).

Only include these references if there is an ISO/IEC, NATO, etc. reference. Also, if the reference is not exactly from the

reference, indicate something like ―Adapted from … ‖.

3.2 Abbreviated terms and acronyms

This subclause defines the abbreviated terms and acronyms used in this document.

ANSI

American National Standards Institute

CPNI

Centre for Protection of National Infrastructure (United Kingdom)

CSSWG

Control Systems Security Working Group (part of NERC)

DHS

Department of Homeland Security (United States)

ICS-CERT

Industrial Control Systems Cyber Emergency Response Team (part of DHS)

IACS

Industrial Automation and Control System

IEC

International Electrotechnical Commission

ISA

International Society of Automation

ISO

International Organization for Standardization

MSMUG

Microsoft Manufacturing Users Group

NERC

North American Electric Reliability Corporation

NISCC

National Infrastructure Security Co-ordination Centre (United Kingdom)

Technical report

3.3 Conventions

SKELETON NOTE This sub-clause is where specific conventions used in the document, like specific clause/sub-

clause formatting, special text conventions, or any other things that the reader should know in order to read the

document. The reader may still need some introduction to conventions used throughout the document, but this sub-

clause allows for a greater explanation in one place.

Editor‘s Note: Throughout this draft for comment are 8 pt. blue italicized notes from the Working

Group 6 contributors to themselves, and also to any reviewers. They are used to guide the

various contributors to ensure they are fulfilling the original objective and plan for each section.

They are also used to communicate information planned that is currently missing from the

respective section. An example is shown below.

WORKING GROUP NOTES: This section shall discuss XYZ. This section is missing information on ABC.

This copy of a draft work product of the ISA99 committee is provided solely for the purpose of supporting the further development of committee work products.

The content has not been formally approved by the committee or ISA. It may not be complete and is subject to change.

This document may not be copied, distributed to others or offered for further reproduction or for sale.

ISA-TR62443-2-3, D1E11, November 28, 2012– 14 – ISA99, WG06, TG02

4 The Situation [Informative]

4.1 Patching Problems Faced by IACS

WORKING GROUP NOTES: Section in progress.

There are many challenges that asset owner‘s face when attempting to implement a patch

management program for their IACS. Patching an IACS means changing the IACS, and changes

can negatively affect its operability or reliability if not performed correctly. Preparing an IACS to

be patched can require a tremendous amount of work and asset owners may struggle for the

necessary resources to address the added work load. For each patch and for each product they

own, an asset owner will have to gather and analyze patch information for each device they own,

install and verify on a test system, ensure backups are created before and after, ensure testing

again before turning the system back over to operations, and finally tracking all the necessary

documentation of the changes.

Due to the resources and efforts required to patch an IACS most organizations schedule patch

roll outs during other normal routine maintenance outages. Sometimes these outage windows are

quarterly, yearly or even longer. Some extremely critical systems may have no allowed outage

windows available, and can therefore not be patched.

Applying patches is a risk management issue. If the cost of shutdown to apply patches is greater

than the risk evaluated cost, then the patch may be delayed, especially if there are other security

controls in place that mitigate the risk (such as no internet access from the system).

The unintended consequences of a poor patch management program can include:

 Interference with software license information

 Incompatibility between patches and control system software

 Virus and anti-malware false positives

 Degradation of system performance, reliability, and operability with insufficient testing.

WORKING GROUP NOTES: I would keep the concepts that you have covered, but I would continue to describe the

challenges faced by the Asset Owner. For example, many control systems in use today were engineered with a 20-30

year lifespan before replacement. In the last 15 years, the technology platform has moved towards open systems such

as TCP-IP, Ethernet, and Windows; bringing with it a huge list of vulnerabilities. There are control systems installed in

the last 10 years, now obsolete in Microsoft terms. But, are extremely vulnerable and the Asset Owner has no plans to

replace them any time soon. Or, the product supplier has chosen to stop testing patches, or the product supplier has

obsoleted the platform/product as well. That is the intent behind the timeline illustration, to help visualize this problem

and all the different scenarios.

Compounding this problem are downtime and operational impacts required to install patches, because total outages

may be required to update the software. Even if an Asset Owner wanted to patch, they cannot afford to shutdown to do

it. This is partly a byproduct of how control systems components have been designed, in that nobody expected security

vulnerabilities to be found, or a need to update the software code. There are a lot of Asset Owners who are nervous of

the idea patching their standby node, and crossing their fingers that when the system is failed over it will work

correctly.

I also refer you to Eric Byres presentation at DigitalBond‟s S4-2012 conference called “Why Johnny Can‟t Patch”.

There are additional concepts in there which could fit into section 4.2.2.

Ultimately, the objective of this section is to describe why IACS patching is tough, and different from IT

patching. The reader should be fully aware of all the gotchas, issues, and challenges they are going to face by

proceeding with an IACS Patch Management program.

WORKING GROUP NOTES: < A difficult concept to explain, perhaps it is not important for us to put in our document.

But in short the problem faced by IACS is they are often never patched since installation date, the vendor stopped

support several years ago, the platform/OS they run on is end-of-line, and there likely known vulnerabilities that cannot

be patched for these reasons.

If we are successful in explaining this problem, we can state this document helps provide guidance where patching is

possible, and that other ISA resources, or DHS, or NIPC should be considered for establishing protective

countermeasures for the unpatchable system, until the legacy IACS is retired/replaced.

This copy of a draft work product of the ISA99 committee is provided solely for the purpose of supporting the further development of committee work products.

The content has not been formally approved by the committee or ISA. It may not be complete and is subject to change.

This document may not be copied, distributed to others or offered for further reproduction or for sale.

ISA99, WG06, TG02 – 15 –ISA-TR62443-2-3, D1E11, November 28, 2012

Maybe the various stages of patch supportability we provide labels for, and can be used for classifying the ability to

install patches on the IACS.>

<Suggestion: Leverage color coding to imply good/bad state and the suggested target state or maintenance mode we

should be in. A consistent criteria that can be used to measure our patching „state‟ for groups of devices.>

Figure 1: Patch Availability and Support Timeline

Timeline

Vuln Scan, Missed

Patches Report

Total Missing Security Patches that present Vulnerabilities

Total Vendor Approved/Compatible Patches Patches not Vendor Approved

Patches that can be Installed

Patches Requiring EvaluationPatches Requiring Evaluation (optional)

Vendor

Approved /

Compatible

Legacy Platform Available Patches

Up to 15 years ago Now

Not Officially Supported, but required Evaluation & Testing

Platform End-of-Line

(eg. Win NT4, Cisco 2950,

SunOS 5.6 etc.)

System Install

Date

WORKING GROUP NOTES: The figure is mock-up illustration only. It has not yet been adopted into this report. It is

attempting to illustrate the gaps at various points in time, as product suppliers stop creating patches, operating system

suppliers stop creating patches, but vulnerabilities still exist, and gaps remain.

4.2 Impacts of Poor Patch Management

WORKING GROUP NOTES: Section in progress.

Adversaries will always have an advantage over their targets given the challenges asset owners

face in keep their systems up to date on security vulnerabilities. Though it may never be possible

to eliminate all software vulnerabilities, there should be no excuse for not evaluating the risk of

the vulnerability and determining when and how patches should be applied.

The primary impact for poor IACS patch management is an increased risk of loss or compromise

of an IACS system. Unlike non real-time systems, compromise of an IACS may have

consequences beyond the loss of data or downtime of the system. A compromise of an IACS

may impact the safety of the system, the physical safety of operational personnel, the quality of

produced products, the safety of the produced products, and usability of produced products.

For additional information, refer to B.2.2 ―Developing the Business Case‖.

NOTE 1 If critical documentation on the production of a product is lost, the product may have to be scrapped, even if

there was no physical damage done to the product.

NOTE 2 Directed attacks of unpatched IACS systems may even result in the destruction of equipment, such as seen in

the Stuxnet attacks. Undirected attacks of unpatched IACS systems, where the IACS system is not a primary target,

may still cause the loss of control with resultant risks to safety and product quality, such as SQL injection worms which

consume all CPU and network resource.

This copy of a draft work product of the ISA99 committee is provided solely for the purpose of supporting the further development of committee work products.

The content has not been formally approved by the committee or ISA. It may not be complete and is subject to change.

This document may not be copied, distributed to others or offered for further reproduction or for sale.

剩余82页未读，继续阅读