API STD 1164-2009 Pipeline SCADA Security (Second Edition)《油管SCADA的安全性.第2版》.pdf

1、Pipeline SCADA SecurityAPI STANDARD 1164SECOND EDITION, JUNE 2009Pipeline SCADA SecurityPipeline SegmentAPI STANDARD 1164SECOND EDITION, JUNE 2009Special NotesAPI publications necessarily address problems of a general nature. With respect to particular circumstances, local, state, and federal laws a

2、nd regulations should be reviewed.Neither API nor any of APIs employees, subcontractors, consultants, committees, or other assignees make any warranty or representation, either express or implied, with respect to the accuracy, completeness, or usefulness of the information contained herein, or assum

3、e any liability or responsibility for any use, or the results of such use, of any information or process disclosed in this publication. Neither API nor any of APIs employees, subcontractors, consultants, or other assignees represent that use of this publication would not infringe upon privately owne

4、d rights.Classified areas may vary depending on the location, conditions, equipment, and substances involved in any given situation. Users of this standard should consult with the appropriate authorities having jurisdiction.Users of this standard should not rely exclusively on the information contai

5、ned in this document. Sound business, sci-entific, engineering, and safety judgment should be used in employing the information contained herein.API publications may be used by anyone desiring to do so. Every effort has been made by the Institute to assure the accuracy and reliability of the data co

6、ntained in them; however, the Institute makes no representation, warranty, or guarantee in connection with this publication and hereby expressly disclaims any liability or responsibility for loss or damage resulting from its use or for the violation of any authorities having jurisdiction with which

7、this publication may conflict.API publications are published to facilitate the broad availability of proven, sound engineering and operating practices. These publications are not intended to obviate the need for applying sound engineering judgment regarding when and where these publications should b

8、e utilized. The formulation and publication of API publications is not intended in any way to inhibit anyone from using any other practices.Any manufacturer marking equipment or materials in conformance with the marking requirements of an API standard is solely responsible for complying with all the

9、 applicable requirements of that standard. API does not represent, warrant, or guarantee that such products do in fact conform to the applicable API standard.All rights reserved. No part of this work may be reproduced, translated, stored in a retrieval system, or transmitted by any means, electronic

10、, mechanical, photocopying, recording, or otherwise, without prior written permission from the publisher. Contact the Publisher, API Publishing Services, 1220 L Street, NW, Washington, DC 20005.Copyright 2009 American Petroleum InstituteForewordThis standard on SCADA security provides guidance to th

11、e operators of oil and gas liquids pipeline systems for managing SCADA system integrity and security. The use of this document is not limited to pipelines regulated under Title 49 CFR 195.1, but should be viewed as a listing of best practices to be employed when reviewing and developing standards fo

12、r a SCADA system. This document embodies the APIs Security Guidelines for the Petroleum Industry. This guideline is specifically designed to provide the operators with a description of industry practices in SCADA security, and to provide the framework needed to develop sound security practices withi

13、n the operators individual companies. It is important that operators understand system vulnerability and risks when reviewing the SCADA system for possible system improvements.Nothing contained in any API publication is to be construed as granting any right, by implication or otherwise, for the manu

14、facture, sale, or use of any method, apparatus, or product covered by letters patent. Neither should anything contained in the publication be construed as insuring anyone against liability for infringement of letters patent.Shall: The term “shall” is used in this standard to indicate those practices

15、 that are mandatory.Should: The term “should” is used in this standard to indicate: those practices for which engineering judgment is required; those practices which are preferred, but for which operators may determine that alternative practices are equally or more effective.This document was produc

16、ed under API standardization procedures that ensure appropriate notification and participation in the developmental process and is designated as an API standard. Questions concerning the interpretation of the content of this publication or comments and questions concerning the procedures under which

17、 this publication was developed should be directed in writing to the Director of Standards, American Petroleum Institute, 1220 L Street, NW, Washington, DC 20005. Requests for permission to reproduce or translate all or any part of the material published herein should also be addressed to the direct

18、or.Generally, API standards are reviewed and revised, reaffirmed, or withdrawn at least every five years. A one-time extension of up to two years may be added to this review cycle. Status of the publication can be ascertained from the API Standards Department, telephone (202) 682-8000. A catalog of

19、API publications and materials is published annually by API, 1220 L Street, NW, Washington, DC 20005.Suggested revisions are invited and should be submitted to the Standards Department, API, 1220 L Street, NW, Washington, DC 20005, standardsapi.org.iiiContentsPage1 Scope . . . . . . . . . . . . . .

20、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Purpose and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

21、.2 Roles and Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22、 . . . . . . . . 12.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Risk and Vulnerability Assessment.

25、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Business Continuity Plan (BCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Incident Response Plan (IRP

26、) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.7 Operating

27、System and Application Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.8 Application and Software Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Physical Securi

28、ty. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 System Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29、. . 155.1 Restricted Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30、. . . . . . . . . . . . . . . . . . . 155.3 Operating System Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.4 SCADA Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.5 Password Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.6 Biometrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.7 Disabled Non-required Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.8 Operating System Tools . . . . . . . . . . . .

33、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.9 Device Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.10 Personnel Admini

34、stration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Information Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

35、86.1 Confidential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Restricted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36、 . . . . . . . . . . . . . . . . . . . . . 196.3 Public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Network Design and Data Interchange . . . . . . . . . . . . . . . . . . . . .

37、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.1 Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.2 Network Management . . . . . . . . . . . . . . . . . . . . .

38、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.3 Data Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Field Communication . . . . . . . .

39、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.1 Field Device Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.2 System Acces

40、s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27vPageAnnex A (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41、 . . . . . . . . . . . 28Annex B (Example) SCADA/Control System Security Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42、. . . . . . . . . . . . . . . 64Figures1 General SCADA Systems Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Typical Non-isolated ImplementationNot Recommended. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43、 . . . . . . . 203 Typical Firewall Isolation ImplementationMinimal Isolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Typical DMZ ImplementationRecommended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Typical Dual-

44、homed Computer Bridge ImplementationNot Recommended. . . . . . . . . . . . . . . . . . . . . . 22vi1Pipeline SCADA Security1 ScopeThis document is structured so that the main body provides the high-level view of holistic security practices. The annexes provide further details and technical guidance.

45、 Reviewing the main body of this document and following the guidance set forth in the annexes assists in creating inherently secure operations. Implementation of this standard, to advance supervisory control and data acquisition (SCADA) cyber security, is not a simple process or one time event, but

46、a continuous process. The overall process could take years to implement correctly depending on the complexity of the SCADA system. Additionally, the process would optimally be started as part of a SCADA upgrade project and use this standard to “design in” security as a element of the new system.1.1

47、Purpose and ObjectivesThe goal of an operator is to control the pipeline in such a way that there are no adverse effects on employees, the environment, the public, or the customers as a result of actions by the operator, or by other parties. This SCADA security program provides a means to improve th

48、e security of the pipeline SCADA operation by: analyzing vulnerabilities of the SCADA system that can be exploited by unauthorized entities, listing the processes used to identify and analyze the SCADA system vulnerabilities to unauthorized attacks, providing a comprehensive list of practices to har

49、den the core architecture, providing examples of industry best practices.1.2 Roles and ResponsibilitiesThe operators senior management shall implement a program of SCADA security for their organization to identify accountability for all aspects of SCADA security at every organizational level. The SCADA security program scope should include the operators organization, business partners, vendors, and external suppliers of SCADA products and services for the SCADA system. The SCADA security program should document the SCADA security plan, identify the roles and responsibilities