ISA TR62443-2-3-2015 Security for industrial automation and control systems Part 2-3 Patch management in the IACS environment.pdf

1、 ISA-TR62443-2-3-2015 Security for industrial automation and control systems Part 2-3: Patch management in the IACS environment Approved 1 July 2015 ANSI/ISA-TR62443-2-3-2015 2 ISA99 ISA-TR62443-2-3-2015 Security for industrial automation and control systems Part 2-3: Patch management in the IACS en

2、vironment ISBN: 978-1-941546-64-2 Copyright 2015 by ISA. All rights reserved. Not for resale. ISA 67 Alexander Drive P. O. Box 12277 Research Triangle Park, NC 27709 USA ISA99 3 ANSI/ISA-TR62443-2-3-2015 PREFACE This preface, as well as all footnotes and annexes, is included for information purposes

3、 and is not part of ISA-TR62443-2-3-2015. This technical report has been prepared as part of the service of ISA, the International Society of Automation, toward a goal of uniformity in the fields of industrial automation and instrumentation. To be of real value, this technical report should not be s

4、tatic but should be subject to periodic review. Toward this end, the Society welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards and Practices Board; ISA; 67 Alexander Drive; P. O. Box 12277; Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax

5、 (919) 549-8288; E-mail: standardsisa.org. The ISA Standards and Practices Department is aware of the growing need for attention to the metric system of units in general and the International System of Units (SI) in particular, in the preparation of instrumentation standards. The Department is furth

6、er aware of the benefits to USA users of ISA standards of incorporating suitable references to the SI (and the metric system) in their business and professional dealings with other countries. Toward this end, this Department will endeavor to introduce SI-acceptable metric units in all new and revise

7、d standards, recommended practices and technical reports to the greatest extent possible. Standard for Use of the International System of Units (SI): The Modern Metric System, published by the American Society for Testing and Materials as IEEE/ASTM SI 10-97, and future revisions, will be the referen

8、ce guide for definitions, symbols, abbreviations, and conversion factors. It is the policy of ISA to encourage and welcome the participation of all concerned individuals and interests in the development of ISA standards, recommended practices and technical reports. Participation in the ISA standards

9、-making process by an individual in no way constitutes endorsement by the employer of that individual, of ISA or of any of the standards, recommended practices and technical reports that ISA develops. CAUTION ISA adheres to the policy of the American National Standards Institute with regard to paten

10、ts. If ISA is informed of an existing patent that is recommended for use of the standard, it will require the owner of the patent to either grant a royalty-free license for use of the patent by users complying with the standard or a license on reasonable terms and conditions that are free from unfai

11、r discrimination. Even if ISA is unaware of any patent covering this Standard, the user is cautioned that implementation of the standard may require use of techniques, processes or materials covered by patent rights. ISA takes no position on the existence or validity of any patent rights that may be

12、 involved in implementing the standard. ISA is not responsible for identifying all patents that may require a license before implementation of the standard or for investigating the validity or scope of any patents brought to its attention. The user should carefully investigate relevant patents befor

13、e using the standard for the users intended application. However, ISA asks that anyone reviewing this standard who is aware of any patents that may impact implementation of the standard notify the ISA Standards and Practices Department of the patent and its owner. Additionally, the use of this stand

14、ard may involve hazardous materials, operations or equipment. The standard cannot anticipate all possible applications or address all possible safety issues associated with use in hazardous conditions. The user of this standard must exercise sound professional judgment concerning its use and applica

15、bility under the users particular circumstances. The user must also consider the applicability of any governmental regulatory limitations and established safety and health practices before implementing this standard. ANSI/ISA-TR62443-2-3-2015 4 ISA99 The following people served as active members of

16、ISA99 Working Group 06 since 2011 for the preparation of this technical report and the patch reporting format: Name Company Contributor Reviewer William “Bill” Cotter WG/TG co-Chair 3M X Florian Ott WG/TG co-Chair Siemens AG X Donovan Tindill WG/TG co-Chair, Editor Honeywell / Matrikon X Michael Cod

17、en Editor NextNine Inc, and MIT-(IC)3 X Marc Ayala aeSolutions X Bruce Billedeaux Maverick Technologies X Eric Boice Honeywell X Dennis Brandl BR however, it may also be applicable for non-security related patches or updates. The Technical Report does not differentiate between patches made available

18、 for the operating systems (OSs), applications or devices. It does not differentiate between the product suppliers that supply the infrastructure components or the IACS applications; it provides guidance for all patches applicable to the IACS. Additionally, the type of patch can be for the resolutio

19、n of bugs, reliability issues, operability issues or security vulnerabilities. Note 1 This Technical Report does not provide guidance on the ethics and approaches for the discovery and disclosure of security vulnerabilities affecting IACS. This is a general issue outside the scope of this report. No

20、te 2 This Technical Report does not provide guidance on the mitigation of vulnerabilities in the period between when the vulnerability is discovered and the date that the patch resolving the vulnerability is created. For guidance on multiple countermeasures to mitigate security risks as part of an I

21、ACS security management system (IACS-SMS), refer to Annexes B.4.5, B.4.6 and B.8.5 in this Technical Report and other documents in the ISA-62443 series. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the ed

22、ition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ANSI/ISA-6244311 (99.00.01) Security for industrial automation and control systems Part 1-1: Terminology, concepts and models 1 ISATR6244312 Security for industrial automati

23、on and control systems, Part 1-2: Master glossary of terms and abbreviations 2 ANSI/ISA-6244321 (99.02.01) Security for industrial automation and control systems Part 2-1: Establishing an Industrial Automation and Control Systems Security Program 1 3 Terms, definitions, abbreviated terms, acronyms a

24、nd conventions 3.1 Terms and definitions For the purposes of this document, the terms and definitions given in the normative references specified in clause 2 apply, in addition to the following. bug flaw in the original development of software (such as a security vulnerability), which causes it to p

25、erform or behave in an unintended manner (such as cause reliability or operability issues) patch incremental software change in order to address a security vulnerability, a bug, reliability or operability issue (update) or add a new feature (upgrade) ANSI/ISA-TR62443-2-3-2015 12 ISA99 Note to entry:

26、 Patches may also be called software updates, software upgrades, firmware upgrades, service packs , hotfixes, basic input output system (BIOS) updates, security advisories and other digital electronic program updates. patch lifecycle period in time that a patch is recommended or created until the pa

27、tch is installed Note 1 to entry: In the context of this technical report, this lifecycle begins when the patch is created and made available. Note 2 to entry: Some feel that the patching lifecycle begins when the vulnerability has been disclosed. However, it is not possible for this technical repor

28、t to provide all possible guidance for the mitigation of vulnerabilities for the period between disclosure of a vulnerability, the decision to create a patch and the availability of a patch. It is also to the discretion of the software developer or product supplier to determine if they develop a pat

29、ch. patch management set of processes used to monitor patch releases, decide which patches should be installed to which system under consideration (SuC), if the patch should be tested prior to installation on a production SuC, at which specified time the patch should be installed and of tracking the

30、 successful installation 3.2 Abbreviated terms and acronyms ANSI American National Standards Institute BCP Business continuity planning BIA Business impact assessment BIOS Basic input output system CCTS Core Components Technical Specification CERT Cyber Emergency Response Team, Computer Emergency Re

31、adiness Team or other regional/industry variant CD Compact disc COTS Commercial-off-the-shelf CPNI UK Centre for Protection of National Infrastructure CPU Central processing unit DCS Distributed control system DHS US Department of Homeland Security DRP Disaster recovery planning DVD Digital versatil

32、e disc EULA End user license agreement FAT Factory acceptance testing HSE Health, safety and environmental HTML Hypertext Markup Language HTTP Hypertext transfer protocol ICS-CERT US DHS Industrial Control Systems Cyber Emergency Response Team IACS Industrial automation and control system(s) IACS-SM

33、S IACS security management system IDS Intrusion detection system ISA99 13 ANSI/ISA-TR62443-2-3-2015 IEC International Electrotechnical Commission IP Internet protocol IPS Intrusion prevention system ISA International Society of Automation ISMS Information security management system ISO International

34、 Organization for Standardization IT Information technology KPI Key performance indicator MD5 Message digest 5 MES Manufacturing execution system MESA Manufacturing Enterprise Solutions Association International MSMUG Microsoft Manufacturing Users Group NERC North American Electric Reliability Corpo

35、ration NISCC US National Infrastructure Security Co-ordination Centre NSA US National Security Agency OAGIS Open Applications Group Integration Specification OEM Original equipment manufacturer OS Operating system PLC Programmable logic controller RACI Responsible, accountable, consulted, informed R

36、AID Redundant array of independent disks RASCI Responsible, accountable, supportive, consulted and informed RTU Remote terminal unit SAT Site acceptance testing SHA Secure hash algorithm SIS Safety instrumented system SMTP Simple Mail Transfer Protocol SPX Sequenced packet exchange SQL Structured qu

37、ery language SuC System under consideration TC Technical committee UN United Nations UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business URI Uniform resource identifier USB Universal serial bus US-CERT United States Computer Emergency Readiness Team ANSI/ISA-TR62443-2-3-20

38、15 14 ISA99 VPC Vendor patch compatibility WAN Wide area network XML eXtensible Markup Language XSD XML schema definition 4 Industrial automation and control system patching 4.1 Patching problems faced in industrial automation and control systems There are many challenges that asset owners face when

39、 attempting to implement a patch management program for their IACS. Patching an IACS means changing the IACS and changes can negatively affect its safety, operability or reliability if not performed correctly. Preparing an IACS to be patched can require a tremendous amount of work and asset owners m

40、ay struggle for the necessary resources to address the added workload. For each patch and for each product they own, an asset owner will have to gather and analyze patch information for each device, install and verify on a test system, ensure backups are created before and after, ensure testing agai

41、n before turning the system back over to operations and finally track all the necessary documentation of the changes. Due to the resources and efforts recommended to patch an IACS most organizations schedule patch installations during other normal routine maintenance outages. Sometimes these outage

42、windows are quarterly, yearly or even less frequently. Some extremely critical systems may not have outage windows available and can therefore not be patched if a system outage is required to do so. Applying patches is a risk management decision. If the cost of applying patches is greater than the r

43、isk evaluated cost, then the patch may be delayed, especially if there are other security controls in place that mitigate the risk (such as disable or remove features). The unintended consequences of a poor patch management program can include: incompatibility between patches and control system soft

44、ware; false positives due to antivirus and anti-malware; and degradation of system performance, reliability and operability with insufficient testing. For additional information, see B.4.2. 4.2 Impacts of poor patch management Adversaries (for example, malicious threat actors) will always have an ad

45、vantage over their targets given the challenges product suppliers and asset owners face in keeping their systems up to date to minimize security risk caused by vulnerabilities. The moment a vulnerability is disclosed, whether by well-intentioned or malicious intent, the problem is then transferred p

46、rimarily to the asset owner to apply the patch as quickly as possible. The asset owner may or may not be able to apply the patch and it becomes a risk-based decision on how to mitigate the vulnerability risk. Though it may never be possible to eliminate all software vulnerabilities, there should be

47、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 for example office or enterprise systems, compromise of an IACS ma

48、y have consequences beyond the loss of data or downtime of the system. A compromise of an IACS may impact system safety, the physical safety of operational personnel, the quality of produced products, the safety of produced products and the usability of produced products. ISA99 15 ANSI/ISA-TR62443-2

49、-3-2015 For additional information, see B.4.2. 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 (such as pharmaceutical development, food production, etc.) NOTE 2 Directed attacks of unpatched IACS systems may even result in the destruction of equipment. 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