FOR REVIEW PURPOSES ONLY!

Transcription

1 FOR REVIEW PURPOSES ONLY! THIS DOCUMENT IS A WORKING DRAFT OF AN ISA99 COMMITTEE WORK PRODUCT. IT MAY NOT BE ACCURATE OF COMPLETE AND IS SUBJECT TO CHANGE WITHOUT NOTICE. IT IS PROVIDED SOLELY FOR THE PURPOSE OF REVIEW IN SUPPORT OF FURTHER DEVELOPMENT OF COMMITTEE WORK PRODUCTS. THIS DOCUMENT MAY NOT BE COPIED, DISTRIBUTED TO OTHERS, OR OFFERED FOR FURTHER REPRODUCTION OR FOR SALE. Copyright by the International Society of Automation. All rights reserved. Not for resale. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without the prior written permission of the Publisher. ISA 67 Alexander Drive P. O. Box Research Triangle Park, North Carolina USA

2 This page intentionally left blank

3 1 2 ISA ( ) Security for industrial automation and control systems Part 2-1: Industrial automation and control system security management system Draft 7, Edit 5 November 9, 2015

4 ISA , D7E5 2 ISA99, WG ISA Security for industrial automation and control systems Part 2-1: Industrial automation and control system security management system ISBN: -to-be-assigned- Copyright 20xx by ISA. All rights reserved. Not for resale. Printed in the United States of America. ISA 67 Alexander Drive P. O. Box Research Triangle Park, NC USA

5 ISA99, WG02 3 ISA , D7E PREFACE This preface, as well as all footnotes and annexes, is included for information purposes and is not part of ISA This document has been prepared as part of the service of ISA, the International Society of Automation, toward a goal of uniformity in the field of instrumentation. To be of real value, this document should not be static 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) ; Fax (919) ; [email protected]. 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 further 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 revised 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 reference 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-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 patents. If ISA is informed of an existing patent that is required 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 unfair 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 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 before using the standard for the user s 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 standard 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 applicability under the user s particular circumstances. The user must also consider the applicability of any governmental regulatory limitations and established safety and health practices before implementing this standard.

6 ISA , D7E5 4 ISA99, WG The following people served as active members of ISA99, Working Group 02 for the preparation of this document: Name Company Contributor Reviewer Tom Good, WG Co-Chair DuPont X Jim Gilsinn, WG Co-Chair Kenexis X Meredith Allen Rockwell Automation X Soloman Almadi Aramco X Ken Anderson X Subodh Belgi X Rahul Bhojani Bayer X Dennis Brandl BRL Consulting X Tanya Brewer NIST X Riemer Brouwer Booz, Allen, Hamilton X Eric Byres Byres Security X Antony Capel Comgate X Piotr Ciepiela Ernst & Young X Richard Clark Wonderware X Eric Cosman, ISA99 Co-Chair The Dow Chemical Company X Jean-Pierre Dalzon Inforoutes Ardeche X Suzanne de Grooth Verlijsdonk Actemium X Ronald Derynck Verano X Gabriel Dimowo Shell X Robert Evans X Donna Guillen INL X Evan Hand Sara Lee X Ernie Hayden Securicon X Mark Heard Eastman Chemical X Marnix Haije Shell X Dave Mills Proctor and Gamble X Carol Muehrcke Cyber Defense Agency LLC X Mike Nash Gamma Secure Systems Ltd X Richard Oyen X Tom Phinney X Jeff Potter Emerson X Hector Puyosa Pina SABIC X Matt Rollinson Monsanto X Bryan Singer Kenexis Consulting X Martin Solum Cyber Defense Agency LLC X Leon Steinocher Flour Enterprises X Ivan Susanto Chevron X Brad Taylor The George Washington University X

7 ISA99, WG02 5 ISA , D7E5 Loren Uden Equistar X Jacek Walaszczyk Ernst & Young X Bob Webb Joe Weiss Applied Solutions, LLC X Ludwig Winkel Siemens X Jeanne Wood X Saber Zrelli Yokogawa X X 56 57

8 ISA , D7E5 6 ISA99, WG02 58 CONTENTS PREFACE... 3 FORWARD INTRODUCTION Scope Normative references Terms, definitions, abbreviated terms, acronyms, and conventions Terms and definitions Abbreviated terms and acronyms Conventions Description and requirements for an IACS security management system Structure of this guideline MORE OVERVIEW TEXT GOES HERE Refinements and additions to ISO/IEC 27001: Overview Subclause 5.1, Leadership and commitment Subclause 6.1.2, Information security risk assessment Subclause 6.1.3, Information security risk treatment Subclause 8.1, Operational planning and control Subclause 9.3, Management review Information security policies Management direction for information security Policies for information security Review of the policies for information security Organization of information security Internal organization Information security roles and responsibilities Segregation of duties Contact with authorities Contact with special interest groups Information security in project management Mobile devices and teleworking Mobile device policy Teleworking Human resource security Prior to employment Screening Terms and conditions of employment During employment Management responsibilities Information security awareness, education and training... 30

9 ISA99, WG02 7 ISA , D7E Disciplinary process Termination and change of employment Termination or change of employment responsibilities Asset management Responsibility for assets Inventory of assets Ownership of assets Acceptable use of assets Return of assets Information classification Classification of information Labelling of information Handling of assets Media handling Management of removable media Disposal of media Physical media transfer Access control Business requirements of access control Access control policy Access to networks and network services User access management User registration and de-registration User access provisioning Management of privileged access rights Management of secret authentication information of users Review of user access rights Removal or adjustment of access rights User responsibilities Use of secret authentication information System and application access control Information access restriction Secure log-on procedures Password management system Use of privileged utility programs Access control to program source code Cryptography Cryptographic controls Policy on the use of cryptographic controls Key management Physical and environmental security Secure areas Physical security perimeter Physical entry controls... 57

10 ISA , D7E5 8 ISA99, WG Securing offices, rooms and facilities Protecting against external and environmental threats Working in secure areas Delivery and loading areas Equipment Equipment siting and protection Supporting utilities Cabling security Equipment maintenance Removal of assets Security of equipment and assets off premises Secure disposal or reuse of equipment Unattended user equipment Clear desk and clear screen policy Operations security Operational procedures and responsibilities Documented operating procedures Change management Capacity management Separation of development, testing and operational environments Protection from malware s against malware Backup Information backup Logging and monitoring Event logging Protection of log information Administrator and operator logs Clock synchronization of operational software Installation of software on operational systems Technical Vulnerability Management Management of technical vulnerabilities Restrictions on software installation Information systems audit considerations Communication Security Network security management Network controls Security of network services Segregation in networks Information transfer Information transfer policies and procedures Agreements on information transfer Electronic messaging... 83

11 ISA99, WG02 9 ISA , D7E Confidentiality or non-disclosure agreements System acquisition, development and maintenance Security requirements of information systems Information security requirements analysis and specification Securing application services on public networks Protecting application services transactions Security in development and support processes Secure development policy System change control procedures Technical review of applications after operating platform changes Restrictions on changes to software packages Secure system engineering principles Secure development environment Outsourced development System security testing System acceptance testing Test data Protection of test data Supplier relationships Information security in supplier relationships Information security policy for supplier relationships Addressing security within supplier agreements Information and communication technology supply chain Supplier service delivery management Monitoring and review of supplier services Managing changes to supplier services Information security incident management Management of information security incidents and improvement Responsibilities and procedures Reporting information security events Reporting information security weaknesses Assessment of and decision on information security events Response to information security incidents Learning from information security incidents Collection of evidence Information security aspects of business continuity management Information security continuity Planning information security continuity Implementing information security continuity Verify, review and evaluate information security continuity Redundancies and Availability Availability of information processing facilities and the IACS Compliance Compliance with legal and contractual requirements

12 ISA , D7E5 10 ISA99, WG Identification of applicable legislation and contractual requirements Intellectual property rights Protection of records Privacy and protection of personally identifiable information Regulation of cryptographic controls Information security review Independent review of information security Compliance with security policies and standards Technical compliance review Annex A (informative) Information related to applying ISO/IEC 27001:2013 in the IACS environment Annex B (normative) Industrial automation and control systems extended control set B.1 Document Requirements B.2 of documents B.3 Internal IACS-SMS audits B.4 System and Information Integrity Policy and Procedures B.5 Centralized management of technical vulnerabilities (Relates to 12.6 Technical Vulnerability Management) B.6 Remote Access (Relates to 6.2 Mobile devices and teleworking) B.7 Mobile Code B.8 Access for Display Medium B.9 Monitoring Physical Access B.10 Access Records B.11 Security Alerts and Advisories B.12 Media Access B.13 Media Storage B.14 Emergency Shutoff B.15 Incident Response Testing and Exercises B.16 IACS Monitoring Tools and Techniques B.17 Software and Information Integrity B.18 Information Input Restrictions B.19 Error Handling B.20 Information Output Handling and Retention B.21 System Maintenance Policy and Procedures B.22 led Maintenance B.23 Maintenance Tools B.24 Remote Maintenance B.25 Maintenance Personnel B.26 Timely Maintenance Annex C (informative) Additional IACS Implementation Guidance C.1 IACS Assets C.1.1 Element: Staff training and security awareness C.1.2 Element: Personnel security C.2 Overview

13 ISA99, WG02 11 ISA , D7E C.3 Category: Risk analysis C.3.1 Description of category C.3.2 Element: Business rationale C.3.3 Element: Risk identification, classification and assessment C.4 Category: Addressing risk with the CSMS C.4.1 Description of category C.4.2 Element group: Security policy, organization and awareness C.4.3 Element group: Selected security countermeasures C.4.4 Element group: Implementation C.5 Category: Monitoring and improving the CSMS C.5.1 Description of category C.5.2 Element: Conformance C.5.3 Element: Review, improve and maintain the CSMS BIBLIOGRAPHY Figure B.2 Graphical view of category: Risk analysis Figure B.3 Reported attacks on computer systems through 2004 (source: CERT) Figure B.4 Sample logical IACS data collection sheet Figure B.5 Example of a graphically rich logical network diagram Figure B.6 Graphical view of element group: Security policy, organization, and awareness Figure B.7 Graphical view of element group: Selected security countermeasures Figure B.8 Reference architecture alignment with an example segmented architecture Figure B.9 Reference SCADA architecture alignment with an example segmented architecture Figure A.10 Access control: Account administration Figure A.11 Access control: Authentication Figure A.12 Access control: Authorization Figure B.13 Graphical view of element group: Implementation Figure B.14 Security level lifecycle model: Assess phase Figure B.15 Corporate security zone template architecture Figure B.16 Security zones for an example IACS Figure B.17 Security level lifecycle model: Develop and implement phase Figure B.18 Security level lifecycle model: Maintain phase Figure B.19 Graphical view of category: Monitoring and improving the CSMS Table B.1 Typical likelihood scale Table B.2 Typical consequence scale Table B.3 Typical risk level matrix Table B.4 Example countermeasures and practices based on IACS risk levels Table B.5 Example IACS asset table with assessment results

14 ISA , D7E5 12 ISA99, WG Table B.6 Example IACS asset table with assessment results and risk levels Table B.7 Target security levels for an example IACS

15 ISA99, WG02 13 ISA , D7E FORWARD This standard is part of a multipart standard that addresses the issue of security for industrial automation and control systems. It has been developed by Working Group 02 of the ISA99 committee in collaboration with IEC TC65/WG10 and ISO/IEC JTC1/SC27. This standard describes the controls contained by an industrial automation and control system security management system and provides guidance on how to meet the requirements described for each control Edition Year Changes Original Document Reformatted and revised document to create a modification to the 2013 editions of the ISO/IEC 2700x series of standards.

16 ISA , D7E5 14 ISA99, WG INTRODUCTION NOTE The format of this document follows the ISO/IEC requirements discussed in ISO/IEC Directives, Part 2. [13]1 The ISO/IEC Directives specify the format of this document as well as the use of terms like shall, should, and may. The use of those terms for the requirements specified in Clauses 4 through 15 of this document use the conventions discussed in the ISO/IEC Directives, Appendix H. Cyber security is an increasingly important topic in modern organizations. The term cyber security is generally used to describe the set of countermeasures or practices taken to protect a computer or computer system against unauthorized access or attack. In industrial automation and control systems (IACS), the concern is not as much about unwanted access as that the access may result in the IACS not performing the critical operational function in the required timefra me. Many organizations involved in information technology (IT) and business have been concerned with cyber security for many years and have well established information security management systems (ISMS) in place as defined by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) (see ISO/IEC [16] and ISO/IEC [17]). These management systems provide an organization with a well-established method for protecting its assets from cyber attacks and unintended cyber incidents. Industrial automation and control system (IACS) organizations have begun using commercial -offthe-shelf (COTS) technology developed for business systems in their everyday processes, which has introduced multiple vulnerabilities and threats to IACS equipment. When these technologies are used in the IACS environment, they are often adjusted to meet different functional needs and operational constraints of IACS. Typical error handling practices to deal with unwanted cyber actions are often eliminated to improve performance. As a result, these IACS using COTS are usually not as robust as the business systems for which the technology was designed. This resulting weakness may lead to health, safety and environmental (HSE) consequences. Organizations may try to use the pre-existing IT and business cyber security solutions to address security for IACS without understanding the consequences. While many of these solutions can be applied to IACS, they need to be applied in the correct way to eliminate inadvertent consequences. This document describes the implementation, management and operation of an IACS security management system (IACS-SMS) based on ISO/IEC 27001:2013 and ISO/IEC 27002:2013. This document builds on the guidance in these ISO/IEC standards. It addresses some of the important differences between IACS and general business/information technology systems. It introduces the important concept that cyber security risks with IACS may have HSE implications and should be integrated with other existing risk management practices addressing these risks. Management systems typically provide guidance on what should be included in a management system, but do not provide guidance on how to go about developing the management system. This document addresses the aspects of the elements included in an IACS-SMS and also provides guidance on how to go about developing the IACS-SMS. A very common engineering approach when faced with a challenging problem is to break the problem into smaller pieces and address each piece in a disciplined manner. This approach is a sound one for addressing cyber security risks with IACS. However, a frequent mistake made in addressing cyber security is to deal with cyber security one system at a time. Cyber security is a much larger challenge that needs to address the entire set of IACS as well as the policies, procedures, practices and personnel that surround and utilize those IACS. Implementing such a wide-ranging management system may require a cultural change within the organization. Addressing cyber security on an organization-wide basis can seem like a daunting task. Unfortunately there is no simple cookbook for security. There is good reason for this. There is not a one-size-fits-all set of security practices. Absolute security may be achievable, but is probably 1 Numbers in square brackets refer to the Bibliography.

17 ISA99, WG02 15 ISA , D7E undesirable because of the loss of functionality that would be necessary to achieve this near perfect state. Security is really a balance of risk versus cost. All situations will be different. In some situations the risk may be related to HSE factors rather than purely economic impact. The risk may have an unrecoverable consequence rather than a temporary financial setback. Therefore a cookbook set of mandatory security practices will either be overly restrictive and likely quite costly to follow, or be insufficient to address the risk. 383

18 ISA , D7E5 16 ISA99, WG Scope[TB1][JDG2] This part of the ISA/IEC series defines the requirements to develop an industrial automation and control system (IACS) security management system (IACS-SMS) and provides guidance on how to develop the management system. This document uses the broad definition and scope of what constitutes an IACS described in ISA [1] The elements of an IACS-SMS described in this standard are mostly policy, procedure, practice and personnel related, describing what shall or should be included in the final IACS-SMS for the organization. NOTE 1 Other documents in the ISA/IEC series and in the Bibliography discuss specific technologies and/or solutions for cyber security in more detail. The guidance provided on how to develop a IACS-SMS is an example. It represents the author s opinion on how an organization could go about developing the management system and may not work in all situations. The users of this standard will have to read the requirements carefully and apply the guidance appropriately in order to develop a fully functioning IACS-SMS for an organization. The policies and procedures discussed in this standard should be tailored to fit within the organization. NOTE 2 There may be cases where a pre-existing information security management system (ISMS) is in place and the IACS portion is being added or there may be some organizations that have never formally created a n ISMS or IACS-SMS at all. The authors of this standard cannot anticipate all cases where an organization will be establishing an IACS-SMS, so this standard does not attempt to create a solution for all cases. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISA Security for industrial automation and control systems: Terminology, concepts and models [1] ISO/IEC Information technology Security techniques Information security management systems Requirements [16] ISO/IEC Information technology Security techniques Code of practice for information security management [17] 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 the normative references specified in Clause 2 and the following apply Industrial Automation and System Security Management System management system to achieve and maintain the security of an industrial automation and control system Note to Entry In the context of an IACS, all references in ISO/IEC to information security management system refer to the IACS-SMS.

19 ISA99, WG02 17 ISA , D7E Industrial Automation and System (IACS) collection of personnel, hardware, and software that can affect or influence the safe, secure, and reliable operation of an industrial process [ANSI/ISA ] Note to Entry In the context of an IACS, all references in ISO/IEC to information refer to the IACS Management System set of interrelated or interacting elements of an organization to establish policies and objectives and processes to achieve those objectives [ISO/IEC 27000:2014] cyber security DEFINITION GOES HERE Note to Entry In the context of an IACS, all references in ISO/IEC to an information security system refer to cyber security asset any physical, logical and informational object that have value to the organization and are associated with the IACS Note to Entry IACS assets are generally part of the systems used to manufacture, inspect, manage and ship a product. [ANSI/ISA ][JDG3] 3.2 Abbreviated terms and acronyms This subclause defines the abbreviated terms and acronyms used in this document. ANSI American National Standards Institute IACS Industrial automation and control system(s) IACS-SMS IACS Security management system IEC International Electrotechnical Commission ISA International Society of Automation ISO International Organization for Standardization TR Technical report 3.3 Conventions[JDG4] MORE TEXT GOES HERE. 4 Description and requirements for an IACS security management system 4.1 Structure of this guideline This document has been structured in a format similar to both ISO/IEC and ISO/IEC Clause 4 relates to the information and requirements from ISO/IEC 27001:2013. This document refines and adds to the requirements in ISO/IEC 27001:2013. Clauses 5 through 15 relate to the information and requirements from ISO/IEC 27002:2013. In cases where controls need additional guidance specific to IACS, the ISO/IEC control and

20 ISA , D7E5 18 ISA99, WG implementation guidance is repeated without modification, followed by the specific IACS guidance related to this control. In cases where objectives, information, requirements and controls2 specified in ISO/IEC or ISO/IEC are applicable without a need for any additional information, only a reference is provided to ISO/IEC or ISO/IEC An extended set of IACS sector-specific controls and implementation guidance is described in Annex B. 4.2 MORE OVERVIEW TEXT GOES HERE MORE OVERVIEW TEXT GOES HERE. Maybe add in some discussion of the use of the term cyber security in this document instead of using IACS security. This is generally due to the fact that IACS security involved a variety of aspects, cyber, physical, personnel, etc. We are trying to limit the scope of this document to only really deal with the IACS cyber security issues. We will touch on other issues like physical security and personnel security when they are appropriate, but there are many more legal and regulatory aspects of those parts that we don t want to get into in this document. Probably should contain some generic language about IACS, indicating health, safety and environmental (HSE) and real-world consequences. 4.3 Refinements and additions to ISO/IEC 27001: Overview As a general rule, all of the requirements contained within ISO/IEC 27001:2013 apply to an IACS- SMS. The following sections contain additions to and refinements of the requirements contained within the ISO/IEC 27001:2013 where the authors felt that the requirements defined for IT systems were incomplete for IACS Subclause 5.1, Leadership and commitment Add an additional item to the list: a) establishing complementary physical security policies. ADD SOME INFORMATIVE AND/OR JUSTIFICATION TEXT HERE Subclause 6.1.2, Information security risk assessment Add the following items to the list: c) 3) identify risks associated with a reduction of IACS reliability during different phases of the IACS lifecycle; f) includes selection and implementation of IACS devices and countermeasures to manage risk to an acceptable level over the lifecycle of the IACS. g) is consistent with or an extension of the identified business cyber security, HSE, legal and regulatory requirements and risk management systems. h) involves individuals knowledgeable with the IACS. ADD SOME INFORMATIVE AND/OR JUSTIFICATION TEXT HERE 2 In this context, the term control refers to a cyber security countermeasure applied to the system instead of in reference to an IACS. ISO/IEC 2700x, as well as other information technology (IT) related cyber security documents often use the term control in this manner. Throughout this document, the acronym IACS or the term con trol system will be used instead of control to avoid as much confusion as possible.

21 ISA99, WG02 19 ISA , D7E Subclause 6.1.3, Information security risk treatment Modify the following items in the list: a) Select appropriate information security risk treatment options, including physical and cyber security countermeasures and compensating countermeasures, taking account of the risk assessment results; Subclause 8.1, Operational planning and control Add the following text to the requirement:[jdg5] Processes, procedures, countermeasures and compensating countermeasures shall be implemented in such a way to detect and respond to cyber security incidents in order to minimize the consequences to the IACS. ADD SOME INFORMATIVE AND/OR JUSTIFICATION TEXT HERE Subclause 9.3, Management review Add the following item to the list: g) business continuity plans, including restoring essential services for the IACS and other recovery point objectives (RPOs). ADD SOME INFORMATIVE AND/OR JUSTIFICATION TEXT HERE 5 Information security policies 5.1 Management direction for information security Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations Policies for information security A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties. At the highest level, organizations should define an "information security policy" which is approved by management and which sets out the organization s approach to managing its information security objectives. Information security policies should address requirements created by: a) business strategy; b) regulations, legislation and contracts; c) the current and projected information security threat environment. The information security policy should contain statements concerning: a) definition of information security, objectives and principles to guide all activities relating to information security; b) assignment of general and specific responsibilities for information security management to defined roles; c) processes for handling deviations and exceptions.

22 ISA , D7E5 20 ISA99, WG At a lower level, the information security policy should be supported by topic-specific policies, which further mandate the implementation of information security controls and are typically structured to address the needs of certain target groups within an organization or to cover certain topics. Examples of such detailed policy topics include: a) access control (see 9); b) information classification (and handling) (see 8.2); c) physical and environmental security (see 11); d) end user oriented topics such as: 1) acceptable use of assets (see 8.1.3); 2) clear desk and clear screen (see ); 3) information transfer (see ); 4) mobile devices and teleworking (see 6.2); 5) restrictions on software installations and use (see ); e) backup (see 12.3); f) information transfer (see 13.2); g) protection from malware (see 12.2); h) management of technical vulnerabilities (see ); i) cryptographic controls (see 10); j) communications security (see 13); k) privacy and protection of personally identifiable information (see ); l) supplier relationships (see 15). These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an information security awareness, education and training programme (see 7.2.2). Other information The need for internal policies for information security varies across organizations. Internal policies are especially useful in larger and more complex organizations where those defining and approving the expected levels of control are segregated from those implementing the controls or in situations where a policy applies to many different people or functions in the organization. Policies for information security can be issued in a single "information security policy" document or as a set of individual but related documents. If any of the information security policies are distributed outside the organization, care should be taken not to disclose confidential information. Some organizations use other terms for these policy documents, such as Standards, Directives or Rules Review of the policies for information security The policies for information security should be reviewed at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness.

23 ISA99, WG02 21 ISA , D7E Each policy should have an owner who has approved management responsibility for the development, review and evaluation of the policies. The review should include assessing opportunities for improvement of the organization s policies and approach to managing information security in response to changes to the organizational environment, business circumstances, legal conditions or technical environment. The review of policies for information security should take account of the results of management reviews. Management approval for a revised policy should be obtained. 6 Organization of information security 6.1 Internal organization Objective: To establish a management framework to initiate and control the implementation and operation of information security within the organization Information security roles and responsibilities All information security responsibilities should be defined and allocated. Allocation of information security responsibilities should be done in accordance with the information security policies (see 5.1.1). Responsibilities for the protection of individual assets and for carrying out specific information security processes should be identified. Responsibilities for information security risk management activities and in particular for acceptance of residual risks should be defined. These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Local responsibilities for the protection of assets and for carrying out specific security processes should be defined. Individuals with allocated information security responsibilities may delegate security tasks to others. Nevertheless they remain accountable and should determine that any delegated tasks have been correctly performed. Areas for which individuals are responsible should be stated. In particular the following should take place: a) the assets and information security processes should be identified and defined; b) the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented (see 8.1.2); c) authorization levels should be defined and documented; d) to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments; e) coordination and oversight of information security aspects of supplier relationships s hould be identified and documented. Other information Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls.

24 ISA , D7E5 22 ISA99, WG However, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection Segregation of duties Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization s assets. When assigning permissions and/or roles to users, the organization shall obey the separation of duties as outlined in their security policy. Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls. Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered. The organization establishes appropriate divisions of responsibility and separates duties as needed to eliminate conflicts of interest in the responsibilities and duties of individuals. Examples of separation of duties include: a) mission functions and distinct IACS support functions are divided among different individuals/roles b) different individuals perform IACS support functions (e.g., system management, systems programming, quality assurance/testing, configuration management, and network security) c) security personnel who administer access control functions do not administer audit functions Other Information Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization's assets Contact with authorities Appropriate contacts with relevant authorities should be maintained. Organizations should have procedures in place that specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner (e.g. if it is suspected that laws may have been broken). Other information Organizations under attack from the Internet may need authorities to take action against the attack source. Maintaining such contacts may be a requirement to support information security incident management (see 16) or the business continuity and contingency planning process (see 17). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in

25 ISA99, WG02 23 ISA , D7E laws or regulations, which have to be implemented by the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety, e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment) Contact with special interest groups Appropriate contacts with special interest groups or other specialist security forums and professional associations should be maintained. Membership in special interest groups or forums should be considered as a means to: a) improve knowledge about best practices and stay up to date with relevant security information; b) ensure the understanding of the information security environment is current and complete; c) receive early warnings of alerts, advisories and patches pertaining to attacks and vulnerabilities; d) gain access to specialist information security advice; e) share and exchange information about new technologies, products, threats or vulnerabilities; f) provide suitable liaison points when dealing with information security incidents (see 16). Other Information Information sharing agreements can be established to improve cooperation and coordination of security issues. Such agreements should identify requirements for the protection of confidential information Information security in project management Information security should be addressed in project management, regardless of the type of the project. Information security should be integrated into the organization's project management method(s) to ensure that information security risks are identified and addressed as part of a project. This applies generally to any project regardless of its character, e.g. a project for a core business process, IT, facility management and other supporting processes. The project management methods in use should require that: a) information security objectives are included in project objectives; b) an information security risk assessment is conducted at an early stage of the project to identify necessary controls; c) information security is part of all phases of the applied project methodology. Information security implications should be addressed and reviewed regularly in all projects. Responsibilities for information security should be defined and allocated to specified roles defined in the project management methods.

26 ISA , D7E5 24 ISA99, WG Mobile devices and teleworking Objective: To ensure the security of teleworking and use of mobile devices Mobile device policy A policy and supporting security measures should be adopted to manage the risks introduced by using mobile devices. The organization shall produce implementation guidance for organization-controlled portable and mobile devices. When using mobile devices, special care should be taken to ensure that business information is not compromised. The mobile device policy should take into account the risks of working with mobile devices in unprotected environments. The mobile device policy should consider: a) registration of mobile devices; b) requirements for physical protection; c) restriction of software installation; d) requirements for mobile device software versions and for applying patches; e) restriction of connection to information services; f) access controls; g) cryptographic techniques; h) malware protection; i) remote disabling, erasure or lockout; j) backups; k) usage of web services and web apps. Care should be taken when using mobile devices in public places, meeting rooms and other unprotected areas. Protection should be in place to avoid the unauthorized access to or disclosure of the information stored and processed by these devices, e.g. using cryptographic techniques (see 10) and enforcing use of secret authentication information (see 9.2.3). Mobile devices should also be physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centres and meeting places. A specific procedure taking into account legal, insurance and other security requirements of the organization should be established for cases of theft or loss of mobile devices. Devices carrying important, sensitive or critical business information should not be left unattended and, where possible, should be physically locked away, or special locks should be used to secure the devices. Training should be arranged for personnel using mobile devices to raise their awareness of the additional risks resulting from this way of working and the controls that should be implemented. Where the mobile device policy allows the use of privately owned mobile devices, the policy and related security measures should also consider: a) separation of private and business use of the devices, including using software to s upport such separation and protect business data on a private device;

27 ISA99, WG02 25 ISA , D7E b) providing access to business information only after users have signed an end user agreement acknowledging their duties (physical protection, software updating, etc.), waiving ownership of business data, allowing remote wiping of data by the organization in case of theft or loss of the device or when no longer authorized to use the service. This policy needs to take account of privacy legislation. Other information Mobile device wireless connections are similar to other types of network connection, but have important differences that should be considered when identifying controls. Typical differences are: a) some wireless security protocols are immature and have known weaknesses; b) information stored on mobile devices may not be backed-up because of limited network bandwidth or because mobile devices may not be connected at the times when backups are scheduled. Mobile devices generally share common functions, e.g., networking, internet access, e -mail and file handling, with fixed-use devices. Information security controls for the mobile devices generally consist of those adopted in the fixed-use devices and those to address threats raised by their usage outside the organization's premises. Portable and mobile devices may introduce undesired network traffic, malware and/or information exposure, and thus there should be specific control associated with their usage in the typical IACS environment. Portable and mobile devices (e.g., notebook computers, personal digital assistants, cellular telephones, and other computing and communications devices with network connectivity are only allowed access to the IACS in accordance with organizational security policies and procedures. Security policies and procedures include device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), configuration management, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared) Teleworking A policy and supporting security measures should be implemented to protect information accessed, processed or stored at teleworking sites. The organization shall establish terms and conditions for authorized individuals to: (i) access the IACS from an external information system; and (ii) process, store, and/or transmit organizationcontrolled information using an external information system. (1) The organization prohibits authorized individuals from using an external information system to access the IACS or to process, store, or transmit organization-controlled information except in situations where the organization: (i) can verify the employment of required security controls on the external system as specified in the organization s information security policy and system security plan; or (ii) has approved IACS connection or processing agreements with the organizational entity hosting the external information system. (2) The organization provides a domain of filtered control for access by external IACS users, and limits access only to this domain. (3) The organization provides a separate domain of information for read-only or download-only access by external IACS users and limits access only to this domain.

28 ISA , D7E5 26 ISA99, WG Organizations allowing teleworking activities should issue a policy that defines the conditions and restrictions for using teleworking. Where deemed applicable and allowed by law, the following matters should be considered: a) the existing physical security of the teleworking site, taking into account the physical security of the building and the local environment; b) the proposed physical teleworking environment; c) the communications security requirements, taking into account the need for remote access to the organization s internal systems, the sensitivity of the information that will be accessed and passed over the communication link and the sensitivity of the internal system; d) the provision of virtual desktop access that prevents processing and storage of information on privately owned equipment; e) the threat of unauthorized access to information or resources from other persons using the accommodation, e.g. family and friends; f) the use of home networks and requirements or restrictions on the configuration of wireless network services; g) policies and procedures to prevent disputes concerning rights to intellectual property developed on privately owned equipment; h) access to privately owned equipment (to verify the security of the machine or during an investigation), which may be prevented by legislation; i) software licensing agreements that are such that organizations may become liable for licensing for client software on workstations owned privately by employees or external party users; j) anti-virus protection and firewall requirements. The guidelines and arrangements to be considered should include: a) the provision of suitable equipment and storage furniture for the teleworking activities, where the use of privately owned equipment that is not under the control of the organization is not allowed; b) a definition of the work permitted, the hours of work, the classification of information that may be held and the internal systems and services that the teleworker is authorized to access; c) the provision of suitable communication equipment, including methods for securing remote access; d) physical security; e) rules and guidance on family and visitor access to equipment and information; f) the provision of hardware and software support and maintenance; g) the provision of insurance; h) the procedures for backup and business continuity; i) audit and security monitoring; j) revocation of authority and access rights, and the return of equipment when the teleworking activities are terminated. Other information Teleworking refers to all forms of work outside of the office, including non-traditional work environments, such as those referred to as telecommuting, flexible workplace, remote work and virtual work environments.

29 ISA99, WG02 27 ISA , D7E External information systems are information systems or components of information systems that are outside of the accreditation boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness. External information systems include, but are not limited to, personally owned information systems (e.g., computers, cellular telephones, or personal digital assistants); privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, convention centers, or airports). Authorized individuals include organizational personnel, contractors, or any other individuals with authorized access to the organizational IACS. The organization establishes terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. The terms and conditions address as a minimum; (i) the types of applications that can be accessed on the organizational IACS from the external information system; and (ii) the maximum S capable system category of information that can be transmitted to or processed and stored on the external information system. 7 Human resource security There shall be a personnel security policy established, clearly stating the organization s commitment to security and the security responsibilities of personnel. (Personnel includes employees, prospective employees, contract employees, vendors, and contractors.) The personnel security policy should address security responsibilities from recruitment through the end of employment, especially for sensitive positions 7.1 Prior to employment Objective: To ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered and that their security responsibilities are addressed Screening Background verification checks on all candidates for employment should be carried out in accordance with relevant laws, regulations and ethics and should be proportional to the business requirements, the classification of the information to be accessed and the perceived risks. Additionally, validation of identity on all candidates for employment, (prospective employees, employees, contract employees, vendors and contractors) who will have access to the IACS (both physical and cyber) or information shall be carried out in accordance with relevant laws, regulations and ethics and should be proportional to the business requirements, the classification of the information or the IACS and the perceived risks. This includes persons that have proposed access privileges or persons that may have access to systems that can have a high consequence or need rapid response and hence may have fewer logical controls. Verification should take into account all relevant privacy, protection of personally identifiable information and employment based legislation, and should, where permitted, include the following: a) availability of satisfactory character references, e.g. one business and one personal; b) a verification (for completeness and accuracy) of the applicant s curriculum vitae; c) confirmation of claimed academic and professional qualifications;

30 ISA , D7E5 28 ISA99, WG d) independent identity verification (passport or similar document); e) more detailed verification, such as credit review or review of criminal records. When an individual is hired for a specific information security role, organizations should make sure the candidate: a) has the necessary competence to perform the security role; b) can be trusted to take on the role, especially if the role is critical for the organization Where a job, either on initial appointment or on promotion, involves the person having access to information processing facilities, and, in particular, if these are handling confidential information, e.g. financial information or highly confidential information, the organization should also consider further, more detailed verifications. Additionally, if the person has access to critical IACS assets, critical processes, critical systems, processing hazardous materials or processes of high risk that require a higher security clearance then the organization should consider more detailed verifications. Procedures should define criteria and limitations for verification reviews, e.g. who is eligible to screen people and how, when and why verification reviews are carried out. A screening process should also be ensured for contractors. In these cases, the agreement between the organization and the contractor should specify responsibilities for conducting the screening and the notification procedures that need to be followed if screening has not been completed or if the results give cause for doubt or concern. Information on all candidates being considered for positions within the organization should be collected and handled in accordance with any appropriate legislation existing in the relevant jurisdiction. Depending on applicable legislation, the candidates should be informed beforehand about the screening activities Terms and conditions of employment The contractual agreements with employees, vendors, or contractors, shall state their and the organization s responsibilities for information security. The contractual obligations for employees, vendors or contractors shall reflect the organization s policies for information security in addition to clarifying and stating: a) that all employees, contract employees, vendors and contractors who are given access to confidential information should sign a confidentiality or non-disclosure agreement prior to being given access to information processing facilities (see ); b) the employee s, contract employee s, vendor s, or contractor s legal responsibilities and rights, e.g. regarding copyright laws or data protection legislation or IACS assets (see ); c) responsibilities for the classification of information and management of organizational assets associated with information, information processing facilities and information services handled by the employee, contract employee, vendor, or contractor (see 8); d) responsibilities of the employee, contract employee, vendor, or contractor for the handling of information received from other companies or external parties. This information would include critical information or critical IACS assets[enh6]. e) actions to be taken if the employee, contract employee, vendor, or contractor disregards the organization s security requirements (see 7.2.3).

31 ISA99, WG02 29 ISA , D7E Information security roles and responsibilities should be communicated to job candidates during the pre-employment process. The organization should ensure that employees, contract employees, vendors, and contractors agree to terms and conditions concerning information security appropriate to the nature and extent of access they will have to the organization s assets associated with information systems and services. Where appropriate, responsibilities contained within the terms and conditions of employment should continue for a defined period after the end of the employment (see 7.3). Other information A code of conduct may be used to state the employee s, contract employee s, vendor s, or contractor s information security responsibilities regarding confidentiality, data protection, ethics, appropriate use of the organization s equipment and facilities, as well as reputable practices expected by the organization. The external party, with which a contractor is associated, can be required to enter into contractual arrangements on behalf of the contracted individual. 7.2 During employment Objective: To ensure that employees, contract employees, vendors, and contractors are aware of and fulfil their information security responsibilities Management responsibilities Management should require all employees, contract employees, vendors and contractors to apply information security in accordance with the established policies and procedures and processes of the organization. Management responsibilities should include ensuring that employees and contractors: a) are properly briefed on their information security roles and responsibilities prior to being granted access to confidential information or information systems; b) are informed on their responsibilities for maintaining IACS availability, plant protection, plant operations (even if in a degraded mode), and time-critical system responses and responsibilities should be clarified and stated; c) are provided with guidelines to state information security expectations of their role within the organization; d) are motivated to fulfil the information security policies of the organization; e) achieve a level of awareness on information security relevant to their roles and responsibilities within the organization (see 7.2.2); f) conform to the terms and conditions of employment, which includes the organization s information security policy and appropriate methods of working; g) continue to have the appropriate skills and qualifications and are educated on a regular basis; h) are provided with an anonymous reporting channel to report violations of information security policies or procedures ( whistle blowing ). i) are subjected to ongoing scrutiny for changes that might indicate a conflict of interest or concern for performing the job in an appropriate manner;

32 ISA , D7E5 30 ISA99, WG Security expecations and responsibilities are clearly documented and regularly communicated to personnel. Duties and responsibilities are segregated among personnel to maintain appropriate checks and balances, so that no single individual has total (unsupervised) control over actions that change the functional operation of the IACS. Management should demonstrate support of information security policies, procedures and controls, and act as a role model. Other Information If employees, contract employees, vendors and contractors are not made aware of their information security responsibilities, they can cause considerable damage to an organization. Motivated personnel are likely to be more reliable and cause fewer information security incidents. Poor management can cause personnel to feel undervalued resulting in a negative information security impact on the organization. For example, poor management can lead to information security being neglected or potential misuse of the organization s assets Information security awareness, education and training All employees of the organization and, where relevant, vendors and contractors shall receive appropriate awareness education and training and regular updates in organizational policies and procedures, as relevant for their job function. This should include the information necessary to identify, review, address and where appropriate remediate vulnerabilities and threats to IACS and to help ensure work practices are using effective countermeasures. The organization shall train personnel in their contingency roles and responsibilities with respect to the IACS and provides refresher training [Assignment: organization-defined frequency, at least annually]. (1) The organization incorporates simulated events into contingency training to facilitate effective response by personnel in crisis situations. (2) The organization employs automated mechanisms to provide a more thorough and realistic training environment. The organization shall train personnel in their incident response roles and responsibilities with respect to the IACS and provides refresher training [Assignment: organization-defined frequency, at least annually]. (1) The organization incorporates simulated events into incident response training to facilitate effective response by personnel in crisis situations. (2) The organization employs automated mechanisms to provide a more thorough and realistic training environment. An information security awareness programme should aim to make employees and, where relevant,vendors and contractors aware of their responsibilities for information security and the means by which those responsibilities are discharged. An information security awareness programme should be established in line with the organization s information security policies and relevant procedures, taking into consideration the organization s information to be protected and the controls that have been implemented to protect the information. The awareness programme should include a number of awareness-raising activities such as campaigns (e.g. an information security day ) and issuing booklets or newsletters. All personnel

33 ISA99, WG02 31 ISA , D7E should receive adequate technical training associated with the known threats and vulnerabilities of hardware, software and social engineering. The awareness programme should be planned taking into consideration the employees roles in the organization, and, where relevant, the organisation s expectation of the awareness of vendors and contractors. The activities in the awareness programme should be scheduled over time, preferably regularly, so that the activities are repeated and cover new employees and contractors. The awareness programme should also be updated regularly so it stays in line with organizational policies and procedures, and should be built on lessons learnt from information security incidents. Awareness training should be performed as required by the organization s information security awareness programme. Awareness training can use different delivery media including classroombased, distance learning, web-based, self-paced and others. The security awareness program should consider the following: a) Establishing the cybersecurity awareness program as a component of the company s overall training organization for all employees; b) Tailoring the cybersecurity training curriculum with a progression of material for a given role in the organization; c) Maintaining and reviewing records of employee training and schedules for training updates on a regular basis depending on their position/role; d) Leveraging cyber security training provided by vendors; e) Establishing the timing, frequency and content of the security awareness communication program in a document to enhance the organization s understanding of cyber security controls; f) Including an overview of the security awareness communication program for all personnel to ensure they are aware of the security practices on their first day; and, g) Reviewing the training and the security awareness program annually for its effectiveness, applicability, content and consistency with tools currently used and corporate policies. Information security education and training should also cover general aspects such as: a) stating management s commitment to information security throughout the organization; b) the need to become familiar with and comply with applicable information security rules and obligations, as defined in policies, standards, laws, regulations, contracts and agreements; c) personal accountability for one s own actions and inactions, and general responsibilities towards securing or protecting information belonging to the organization and external parties; d) basic information security procedures (such as information security incident reporting) and baseline controls (such as password security, malware controls and clear desks); e) contact points and resources for additional information and advice on information security matters, including further information security education and training materials. Information security education and training should take place periodically. Initial education and training applies to those who transfer to new positions or roles with substantially different information security requirements, not just to new starters and should take place before the role becomes active. The organization should develop the education and training program in order to conduct the education and training effectively. The program should be in line with the organization s information security policies and relevant procedures, taking into consideration the organization s informat ion

34 ISA , D7E5 32 ISA99, WG to be protected and the controls that have been implemented to protect the information. The program should consider different forms of education and training, e.g. lectures or self-studies. Other Information When composing an awareness program, it is important not only to focus on the what and how, but also the why. It is important that employees understand the aim of information security and the potential impact, positive and negative, on the organization of their own behavior. Awareness, education and training can be part of, or conducted in collaboration with, other training activities, for example general IT or general security training. Awareness, education and training activities should be suitable and relevant to the individual s roles, responsibilities and skills (see 7.2.2). An assessment of the employees understanding could be conducted at the end of an awareness, education and training course to test knowledge transfer. The training program should be validated on an on-going basis to ensure that personnel understand the security program and that they are receiving the proper training. This validation is to determine if the training program is meeting the needs of the organization, not just ve rifying that personnel are being trained. The training program should be reviewed on a regular basis and updated as necessary to ensure that changes to the IACS and changing threats to the IACS are addressed in the training. The training program should be updated whenever there are changes to the IACS or when threats change Disciplinary process There should be a formal and communicated disciplinary process in place to take action against employees who have committed an information security breach. The disciplinary process should not be commenced without prior verification that an information security breach has occurred (see ). The formal disciplinary process should ensure correct and fair treatment for employees, contract employees, vendors and contractors who are suspected of committing breaches of information security. The formal disciplinary process should provide for a graduated response that takes into consideration factors such as the nature and gravity of the breach and its impact on business, whether or not this is a first or repeat offence, whether or not the violator was properly trained, relevant legislation, business contracts and other factors as required. The disciplinary process should also be used as a deterrent to prevent employees from violating the organization s information security policies and procedures and any other information security breaches. Deliberate breaches may require immediate actions. Other information The disciplinary process can also become a motivation or an incentive if positive sanctions are defined for remarkable behavior with regards to information security. 7.3 Termination and change of employment Objective: To protect the organization s interests as part of the process of changing or terminating employment.

35 ISA99, WG02 33 ISA , D7E Termination or change of employment responsibilities Information security responsibilities and duties that remain valid after termination or change of employment shall be defined, communicated to the employee or contractor and enforced. All employees, contract employees, vendors and contractors shall return all of the organization s assets in their possession upon termination of their employment, contract or agreement as is clarified in Section 8.0 The access rights of all employees, contract employees, vendors and contractors for IACS assets and facilities shall be removed upon termination of their employment, contract agreement, or adjusted upon change as is clarified in Section 9.0. The communication of termination responsibilities should include on-going information security requirements and legal responsibilities and, where appropriate, responsibilities contained within any confidentiality agreement (see ) and the terms and conditions of employment (see 7.1.2) continuing for a defined period after the end of the employee s or contractor s employment. Responsibilities and duties still valid after termination of employment should be contained in the employee s or contractor s terms and conditions of employment (see 7.1.2). Changes of responsibility or employment should be managed and the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment. Other Information The human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person leaving to manage the information security aspects of the relevant procedures. In the case of a contractor provided through an external party, this termination process is undertaken by the external party in accordance with the contract between the organization and the external party. It may be necessary to inform employees, customers, vendorsor contractors of changes to personnel and operating arrangements. 8 Asset management 8.1 Responsibility for assets Objective: To identify organizational assets and the IACS assets associated with the automation and control system(s) and define appropriate protection responsibilities Inventory of assets Assets associated with information and information processing facilities should be identified and an inventory of these assets should be drawn up and maintained. The organization shall develop, document, and maintain a current inventory of the components of the IACS and relevant ownership information. (1) The organization updates the inventory of IACS components as an integral part of component installations. (2) The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of IACS components.

36 ISA , D7E5 34 ISA99, WG An organization should identify assets relevant in the lifecycle of information and document their importance. The lifecycle of information should include creation, processing, storage, transmission, deletion and destruction. Documentation should be maintained in dedicated or existing inventories as appropriate. The asset inventory should include all IACS assets necessary in order to recover from a disaster, including type of asset, format, location, backup information, license information, and a business value. The inventory should not duplicate other inventories unnecessarily, but it should be ensured that the content is aligned. Based on the importance of the asset, its business value and its security classification, levels of protection commensurate with the importance of the assets should be identified. The asset inventory should be accurate, up to date, consistent and aligned with other inventorie s. For each of the identified assets, ownership of the asset needs to be assigned (see 8.1.2) and the classification needs to be identified (see 8.2). In addition, ownership and information classification should be agreed and documented for each of the assets. The organization determines the appropriate level of granularity for the IACS components included in the inventory that are subject to management control (i.e., tracking, and reporting). The inventory of IACS components includes any information determined to be necessary by the organization to achieve effective property accountability (e.g., manufacturer, model number, serial number, software license information, system/component owner). The component inventory is consistent with the accreditation boundary of the IACS. Other Information Inventories of assets help to ensure that effective protection takes place, and may also be required for other purposes, such as health and safety, insurance or financial (asset management) reasons. ISO/IEC provides examples of assets that might need to be considered by the organization when identifying assets. The process of compiling an inventory of assets is an important prerequisite of risk management (see also ISO/IEC and ISO/IEC 27005). Additionally, there are many types of IACS assets, including: a) information: databases and data files, contracts and agreements, system documentation, research information, user manuals, training material, operational or support procedures, business continuity plans, fallback arrangements, audit trails, and archived information; b) software assets: application software, system software, development tools, and utilities; c) physical assets: computer equipment, communications equipment, removable media, and other equipment; d) services: computing and communications services, general utilities, e.g. heating, lighting, power, and air-conditioning; e) people, and their qualifications, skills, and experience; f) intangibles, such as reputation and image of the organization Ownership of assets Assets maintained in the inventory should be owned.

37 ISA99, WG02 35 ISA , D7E Individuals as well as other entities having approved management responsibility for the asset lifecycle qualify to be assigned as asset owners. A process to ensure timely assignment of asset ownership is usually implemented. Ownership should be assigned when assets are created or when assets are transferred to the organization. The asset owner should be responsible for the proper management of an asset over the whole asset lifecycle. The asset owner should: a) ensure that assets are inventoried; b) ensure that assets are appropriately classified and protected; c) define and periodically review access restrictions and classifications to important assets, taking into account applicable access control policies; d) ensure proper handling when the asset is deleted or destroyed. Other Information The identified owner can be either an individual or an entity who has approved management responsibility for controlling the whole lifecycle of an asset. The identified owner does not necessarily have any property rights to the asset. Routine tasks may be delegated, e.g. to a custodian looking after the assets on a daily basis, but the responsibility remains with the owner. In complex information systems, it may be useful to designate groups of assets which act together to provide a particular service. In this case the owner of this service is accountable for the delivery of the service, including the operation of its assets Acceptable use of assets Rules for the acceptable use of information and of assets associated with information and information processing facilities should be identified, documented and implemented. Employees and external party users using or having access to the organization s assets should be made aware of the information security requirements of the organization s assets associated with information and information processing facilities and resources. They should be responsible for their use of any information processing resources and of any such use carried out under their responsibility. Employees and external party users using or having access to the organization s assets associated with the IACS shall be made aware of the IACS requirements. They shall be responsible for their use of any IACS resources and of any such use carried out under their responsibility. All employees, contract employees, vendors, and contractors shall follow rules for the acceptable use of assets associated with IACS, including: a) a) rules for electronic mail and Internet usages. b) b)guidelines for the use of mobile devices, especially for the use outside the premises of the organization.

38 ISA , D7E5 36 ISA99, WG Specific rules or guidance shall be provided by the relevant management. Employees, contract employees, vendors and contractors using or having access to the organization s assets shall be aware of the limits existing for their use of organization s assets associated with IACS, and resources. They should be responsible for their use of any IACS, and of any such use carried out under their responsibility Return of assets All employees and external party users should return all of the organizational assets in their possession upon termination of their employment, contract or agreement. The termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization. In cases where an employee or external party user purchases the organization s equipment or uses their own personal equipment, procedures should be followed to ensure that all relevant information is transferred to the organization and securely erased from the equipment (see ). In cases where an employee or external party user has knowledge that is important to ongoing operations, that information should be documented and transferred to the organization. During the notice period of termination, the organization should control unauthorized copying of relevant information (e.g. intellectual property) by terminated employees and contractors. 8.2 Information classification Objective: To ensure that information receives an appropriate level of protection in accordance with its importance to the organization Classification of information Information should be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification. Classifications and associated protective controls for information should take account of business needs for sharing or restricting information, as well as legal requirements. Assets other than information can also be classified in conformance with classification of information which is stored in, processed by or otherwise handled or protected by the asset. Owners of information assets should be accountable for their classification. The classification scheme should include conventions for classification and criteria for review of the classification over time. The level of protection in the scheme should be assessed by analyzing confidentiality, integrity and availability and any other requirements for the information considered. The scheme should be aligned to the access control policy (see 9.1.1). Each level should be given a name that makes sense in the context of the classification scheme s application. The scheme should be consistent across the whole organization so that everyone will classify information and related assets in the same way, have a common understanding of protection requirements and apply the appropriate protection.

39 ISA99, WG02 37 ISA , D7E Classification should be included in the organization's processes, and be consistent and coherent across the organization. Results of classification should indicate value of assets depending on their sensitivity and criticality to the organization, e.g. in terms of confidentiality, integrity and availability. Results of classification should be updated in accordance with changes of their value, sensitivity and criticality through their life-cycle. Other Information Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls. Information can cease to be sensitive or critical after a certain period of time, for example, when the information has been made public. These aspects should be taken into account, as over - classification can lead to the implementation of unnecessary controls resulting in additional expense or on the contrary under-classification can endanger the achievement of business objectives. An example of an information confidentiality classification scheme could be based on four levels as follows: a) disclosure causes no harm; b) disclosure causes minor embarrassment or minor operational inconvenience; c) disclosure has a significant short term impact on operations or tactical objectives; d) disclosure has a serious impact on long term strategic objectives or puts the survival of the organization at risk Labelling of information An appropriate set of procedures for information labelling should be developed and implemented in accordance with the information classification scheme adopted by the organization. Procedures for information labelling need to cover information and its related assets in physical and electronic formats. The labelling should reflect the classification scheme established in The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of media. The procedures can define cases where labelling is omitted, e.g. labelling of non-confidential information to reduce workloads. Employees and contractors should be made aware of labelling procedures. Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label in the output. Other Information Labelling of classified information is a key requirement for information sharing arrangements. Physical labels and Metadata are a common form of labelling. Labelling of information and its related assets can sometimes have negative effects. Classified assets are easier to identify and accordingly to steal by insiders or external attackers.

40 ISA , D7E5 38 ISA99, WG Handling of assets Procedures for handling assets should be developed and implemented in accordance with the information classification scheme adopted by the organization. Procedures should be drawn up for handling, processing, storing and communicating information consistent with its classification (see 8.2.1). The following items should be considered: a) access restrictions supporting the protection requirements for each level of classificatio n; b) maintenance of a formal record of the authorized recipients of assets; c) protection of temporary or permanent copies of information to a level consistent with the protection of the original information; d) storage of IT assets in accordance with manufacturers specifications; e) clear marking of all copies of media for the attention of the authorized recipient. The classification scheme used within the organization may not be equivalent to the schemes used by other organizations, even if the names for levels are similar; in addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification labels from other organizations. 8.3 Media handling Objective: To prevent unauthorized disclosure, modification, removal or destruction of information stored on media Management of removable media Procedures should be implemented for the management of removable media in accordance with the classification scheme adopted by the organization. The following guidelines for the management of removable media should be considered: a) if no longer required, the contents of any re-usable media that are to be removed from the organization should be made unrecoverable; b) where necessary and practical, authorization should be required for media removed from the organization and a record of such removals should be kept in order to maintain an audit trail; c) all media should be stored in a safe, secure environment, in accordance with manufacturers specifications; d) if data confidentiality or integrity are important considerations, cryptographic techniques should be used to protect data on removable media; e) to mitigate the risk of media degrading while stored data are still needed, the data should be transferred to fresh media before becoming unreadable;

41 ISA99, WG02 39 ISA , D7E f) multiple copies of valuable data should be stored on separate media to further reduce the risk of coincidental data damage or loss; g) registration of removable media should be considered to limit the opportunity for data loss; h) removable media drives should only be enabled if there is a business reason for doing so; i) where there is a need to use removable media the transfer of information to such media should be monitored. Procedures and authorization levels should be documented. The media protection policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The media protection policy can be included as part of the general information security policy for the organization. Media protection procedures can be developed for the security program in general, and for a particular IACS, when required Disposal of media Media should be disposed of securely when no longer required, using formal procedures. Formal procedures for the secure disposal of media should be established to minimize the risk of confidential information leakage to unauthorized persons. The procedures for secure disposal of media containing confidential information should be proportional to the sensitivity of that information. The following items should be considered: a) media containing confidential information should be stored and disposed of securely, e.g. by incineration or shredding, or erasure of data for use by another application within the organization; b) procedures should be in place to identify the items that might require secure disposal; c) it may be easier to arrange for all media items to be collected and disposed of securely, rather than attempting to separate out the sensitive items; d) many organizations offer collection and disposal services for media; care should be taken in selecting a suitable external party with adequate controls and experience; e) disposal of sensitive items should be logged in order to maintain an audit trail. When accumulating media for disposal, consideration should be given to the aggregation effect, which can cause a large quantity of non-sensitive information to become sensitive. Other Information Damaged devices containing sensitive data may require a risk assessment to determine whether the items should be physically destroyed rather than sent for repair or discarded (see ) Physical media transfer Media containing information should be protected against unauthorized access, misuse or corruption during transportation. The following guidelines should be considered to protect media containing information being transported: a) reliable transport or couriers should be used; b) a list of authorized couriers should be agreed with management;

42 ISA , D7E5 40 ISA99, WG c) procedures to verify the identification of couriers should be developed; d) packaging should be sufficient to protect the contents from any physical damage likely to arise during transit and in accordance with any manufacturers specifications, for example protecting against any environmental factors that may reduce the media s restoration effectiveness such as exposure to heat, moisture or electromagnetic fields; Physical and technical security measures for the protection of digital and non-digital media are approved target by the organization, commensurate with the S system categorization of the information residing on the media, and consistent with applicable laws, directives, policies, regulations, standards, and guidance. Cryptographic mechanisms can provide confidentiality and/or integrity protections depending upon the mechanisms used. e) logs should be kept, identifying the content of the media, the protection applied as well as recording the times of transfer to the transit custodians and receipt at the destination. f) The organization employs an identified custodian at all times to transport IACS media. Organizations establish documentation requirements for activities associated with the transport of IACS media in accordance with the organizational assessment of risk. IACS media includes both digital media (e.g., diskettes, tapes, removable hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). A controlled area is any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information and/or IACS. This requirement also applies to portable and mobile computing and communications devices with information storage capability (e.g., notebook computers, personal digital assistants, cellular telephones) that are transported outside of controlled areas. Telephone systems are also considered IACS and may have the capability to store information on internal media (e.g., on voic systems). Since tele phone systems do not have, in most cases, the identification, authentication, and access control mechanisms typically employed in other IACS, organizational personnel exercise extreme caution in the types of information stored on telephone voic systems that are transported outside of controlled areas. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring protection during transport. Organizations document in policy and procedures, the media requiring protection during transport and the specific measures taken to protect such transported media. The rigor with which this requirement is applied is target commensurate with the S system categorization of the information contained on the media. An organizational assessment of risk also guides the selection and use of appropriate storage containers for transporting non-digital media. Other Information Information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending media via the postal service or via courier. In this control, media include paper documents. When confidential information on media is not encrypted, additional physical protection of the media should be considered. 9 Access control[jdg7] 9.1 Business requirements of access control Objective: To limit access to information and information processing facilities.

43 ISA99, WG02 41 ISA , D7E Access control policy[jdg8] An access control policy shall be established, documented and periodically reviewed/updated based on business, information, and IACS security requirements. The access control policy shall be: (i) a formal, documented, access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the access control policy and associated access controls. The access control policy, processes, and procedures shall be consistent with applicable laws, directives, policies, regulations, standards, and guidance and in alignment with the security requirements of the IACS(s). The access control policy can be included as part of the general information security policy for the organization. Access control procedures can be developed for the security program in general, and for a particular IACS, when required. Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks. Access controls are both logical and physical (see 11) and these should be considered together. Users and service providers should be given a clear statement of the business requirements to be met by access controls. Access control is the method of controlling who or what resources can access premises and systems and what type of access is permitted. There are three key aspects associated with access control: account management & administration, identification & authentication and use control & authorization. All three aspects must work together to establish a sound and secure access contr ol strategy. a) Account management & administration Account management and administration is the method associated with establishing, granting and revoking access accounts and maintaining the permissions and privileges provided under these accounts to access specific resources and functions on the physical premises, network or system. Access accounts should be function or role-based and may be defined for individuals, groups of individuals functioning as a crew or for devices providing a function. b) Identification & authentication Identification and authentication positively identifies network users, hosts, applications, services and resources for computerized transaction so that they can be given the rights and responsibilities associated with the accounts they have been granted under account administration. There are several types of authentication strategies and each has varying degrees of strength. Strong authentication methods are ones that are quite accurate in positively identifying the user. Weak authentication methods are ones that can be easily defeated to provide unwanted access to information. Physical location of the user may have a significant impact on the risk of accessing the IACS c) Use control & authorization Use control and authorization grants access privileges to resources upon successful identification and authentication of a user s access account. The privileges granted are determined by the account configuration set up during the account management and administration step in the business process. Permission to access systems or areas utilizing these three aspects of access control is based on specific needs as determined by management policies. Access to sensitive systems and IACS devices can be controlled by logical means (rules that grant or deny access to known users based on their roles), physical devices (locks, cameras, and other controls that restrict access to the IACS), or both. The policy should take account of the following:

44 ISA , D7E5 42 ISA99, WG a) security requirements of business and IACS applications; b) policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information and the IACS (see 8.2); c) consistency between the access rights and information and IACS classification policies of different systems and networks; d) relevant legislation and any contractual obligations regarding limitation of access to data or services or the IACS (see 18.1); e) management of access rights in a distributed and networked environment which recognizes all systems and types of connections available; f) segregation of access control roles, e.g. access request, access authorization, access administration; g) requirements for formal authorization of access requests (see 9.2.1); h) requirements for periodic review of access rights (see 9.2.5); i) removal of access rights (see 9.2.6); j) archiving of records of all significant events concerning the use and management of user identities and secret authentication information; k) roles with privileged access (see 9.2.3). l) permission to access IACS devices can be logical (rules that grant or deny access to known users based on their roles), physical (locks, cameras, and other controls that restrict access to the IACS), or both. m) In critical environments, multiple authorization methods should be employed to limit access to the IACS; Other information Care should be taken when specifying access control rules to consider: a) establishing rules based on the premise Everything is generally forbidden unless expressly permitted rather than the weaker rule Everything is generally permitted unless expressly forbidden ; b) changes in information labels (see 8.2.2) that are initiated automatically by information processing facilities and those initiated at the discretion of a user; c) changes in user permissions that are initiated automatically by the information system and those initiated by an administrator; d) rules which require specific approval before enactment and those which do not. Access control rules should be supported by formal procedures (see 9.2, 9.3, 9.4) and defined responsibilities (see 6.1.1, 9.2, 15.1). Role based access control is an approach used successfully by many organizations to link access rights with business roles. Two of the frequent principles directing the access control policy are: a) Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile); b) Need to use: you are only granted access to the information processing facilities and IACS (IT equipment, IACS equipment, processes, systems, applications, procedures, rooms) you need to perform your task/job/role.

45 ISA99, WG02 43 ISA , D7E Access to networks and network services Users shall only be provided with access to the network and network services and IACS networks that they have been specifically authorized to use. A policy should be formulated concerning the use of networks and network services which is a subset of the access control policy. This policy should cover: a) the networks and network services which are allowed to be accessed; b) authorization procedures for determining who is allowed to access which networks and networked services; c) management controls and procedures to protect access to network connections and network services; d) the means used to access networks and network services (e.g. use of VPN or wireless network); e) user authentication requirements for accessing various network services; f) monitoring use of network services, including wireless technologies. g) design requirements of IACS networks for critical IACS assets. The policy on the use of network services should be consistent with the organization s access control policy (see 9.1.1). Other Information Unauthorized and insecure connections to network services can affect the whole organization. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization s information security management and control. 9.2 User access management Objective: To ensure authorized user access and to prevent unauthorized access to systems and services User registration and de-registration A formal user registration and de-registration process shall be implemented to enable assignment of access rights and as part of the account management and administration process for granting and revoking access to the IACS. The process for managing user IDs should include: a) using unique user IDs to enable users to be linked to and held responsible for their actions; the use of shared or group IDs should only be permitted where they are necessary for business or operational reasons and should be approved and documented. IACS group IDs should be function or role-based and may be defined for groups of individuals functioning as a crew or for deviceds providing functionality for business or operational reasons ; b) immediately disabling or removing user IDs of users who have left the organization (see 9.2.5); c) periodically identifying and removing or disabling redundant user IDs;

46 ISA , D7E5 44 ISA99, WG d) ensuring that redundant user IDs are not issued to other users. Other information Providing or revoking access to information or information processing facilities is usually a two-step procedure: a) assigning and enabling, or revoking, a user ID (this control); b) providing, or revoking, access rights to such user ID (see 9.2.2). The organization shall develop and keeps current a list of personnel with authorized access to the facility where the IACS resides (except for those areas within the facility officially designated as publicly accessible) and issues assigns appropriate authorization credentials. Designated officials within the organization review and approve the access list and authorization credentials [Assignment: organization-defined frequency]. Appropriate authorization credentials include, for example, badges, identification cards, smart cards, key pads codes or biometric attributes User access provisioning A formal user access provisioning process should be implemented to assign or revoke access rights for all user types to all systems and services. The provisioning process for assigning or revoking access rights granted to user IDs should include: a) obtaining authorization from the owner of the information system or IACS or service for the use of the information system or IACS or service (see control 8.1.2); separate approval for access rights from management may also be appropriate; b) verifying that the level of access granted is appropriate to the access policies (see 9.1) and is consistent with other requirements such as segregation of duties (see 6.1.5); c) ensuring that access rights are not activated (e.g. by service providers) before authorization procedures are completed; d) maintaining a central record of access rights granted to a user ID to access information systems and services; e) adapting access rights of users who have changed roles or jobs and immediately removing or blocking access rights of users who have left the organization; f) periodically reviewing access rights with owners of the information systems or IACS or services (see 9.2.4). g) giving users a written statement of their access rights and requiring users to sign statements indicating that they understand the conditions of access. Other information Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews (see 9.2.4) are easier managed at the level of such roles than at the level of particular rights. Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel or contractors (see 7.1.2, 7.2.3, , ).

47 ISA99, WG02 45 ISA , D7E Management of privileged access rights The allocation and use of privileged access rights should be restricted and controlled.. The allocation of privileged access rights shall be controlled through a formal authorization process in accordance with the relevant access control policy (see control 9.1.1). The following steps should be considered: a) the privileged access rights associated with each system or process, e.g. operating system, database management system and each application and the users to whom they need to be allocated should be identified; b) privileged access rights should be allocated to users on a need-to-use basis and on an eventby-event basis in line with the access control policy (see 9.1.1), i.e. based on the minimum requirement for their functional roles; c) an authorization process and a record of all privileges allocated should be maintained. Privileged access rights should not be granted until the authorization process is complete; d) requirements for expiry of privileged access rights should be defined; e) privileged access rights should be assigned to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged accounts; f) the competences of users with privileged access rights should be reviewed regularly in order to verify if they are in line with their duties; g) specific procedures[enh9] should be established and maintained in order to avoid the unauthorized use of generic administration user IDs, according to systems configuration capabilities; h) for generic administration user IDs, the confidentiality of secret authentication information should be maintained when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms); and i) rights/privileges or accesses needed by an asset owner (or processes acting on behalf of asset owners) for the performance of specified tasks. The organization shall: (i) approve individual access privileges and enforces physical and logical access restrictions associated with changes to the IACS; and (ii) generate, retain, and review records reflecting all such changes. (1) The organization employs automated mechanisms to enforce access restrictions and support auditing of the enforcement actions. Planned or unplanned changes to the hardware, software, and/or firmware components of the IACS can have significant effects on the overall security of the system. Accordingly, only qualif ied and authorized individuals obtain access to IACS components for purposes of initiating changes, including upgrades and modifications. Other information Inappropriate use of system administration privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems.

48 ISA , D7E5 46 ISA99, WG The organization should employ the concept of least privilege for specific duties and IACS (zones and conduits) in accordance with risk assessments as necessary to adequately mitigate risk to organizational operations, organizational assets and individuals Management of secret authentication information of users The allocation of secret authentication information should be controlled through a formal management process. The process should include the following requirements: a) users should be required to sign a statement to keep personal secret authentication information confidential and to keep group information (i.e. shared) secret authentication information solely within the members of the group; this signed statement may be included in the terms and conditions of employment (see 7.1.2); b) when users are required to maintain their own secret authentication information they should be provided initially with secure temporary secret authentication information`, which they are forced to change on first use; c) procedures should be established to verify the identity of a user prior to providing new, replacement or temporary secret authentication information; d) temporary secret authentication information should be given to users in a secure manner; the use of external parties or unprotected (clear text) electronic mail messages should be avoided; e) temporary secret authentication information should be unique to an individual and should not be guessable; f) users should acknowledge receipt of secret authentication information; g) default vendor secret authentication information should be altered following installation of systems or software. Identifiers are distinguished from the privileges which they permit an entity to perform within a specific IACS control domain/zone (see also 2.6, Authenticator Management). Where users function as a single group (e.g., control room operators), user identification may be role -based, group-based, or device-based. For some IACS, the capability for immediate operator interaction is critical. Local emergency actions for the IACS must not be hampered by identification requirements. Access to these systems may be restricted by appropriate compensating security mechanisms. Identifiers may be required on portions of the IACS but not necessarily the entire system. For very high SAL level IACS the requirement for maximum control is increased, not decreased. Security measures that have the potential to cause loss of control in process operations are not acceptable. In these cases, to maintain the higher SAL levels, compensating measures external to the IACS (e.g. additional physical security measures and/or enhanced personnel background checks) will be needed. In these cases, it may be possible to see a normally high SAL level IACS at a lower SAL 1 or 2 rating, depending upon the compensating controls. Lockout or loss of control due to security measures is not acceptable in high availability IACS. IACS authenticators include, for example, tokens, Public Key certificates, biometrics, passwords, physical keys, and key cards. IACS users should take reasonable measures to safeguard authenticators including maintaining possession of their individual authenticators, not loaning or sharing authenticators with others, and reporting lost or compromised authenticato rs immediately. In the case of a process or device, such users should also take measures to protect their IACS authenticators.

49 ISA99, WG02 47 ISA , D7E If the IACS is required to have a high level of availability, measures must be taken to maintain this high level of availability (e.g. compensating physical controls, duplicate keys, supervisory override). Lockout or loss of control due to security measures is not acceptable Other information Passwords are a commonly used type of secret authentication information and are a common means of verifying a user s identity. Other types of secret authentication information are cryptographic keys and other data stored on hardware tokens (e.g. smart cards) that produce authentication codes Review of user access rights Asset owners should review users access rights at regular intervals. The organization reviews accounts [Assignment: organization-defined frequency, at least annually]. A history of account changes shall be maintained if only manually. (1) The organization has policies and procedures to terminate guest or temporary accounts after [Assignment: organization-defined time period for each type of account]. (2) The organization has policies and procedures to disable inactive accounts after [Assignment: organization-defined time period]. (3) The organization employs mechanisms to audit account creation, Modification, disabling, and termination actions and to notify, as required, appropriate individuals. The review of access rights should consider the following: a) users access rights should be reviewed at regular intervals and after any changes, such as promotion, demotion or termination of employment (see 7); b) user access rights should be reviewed and re-allocated when moving from one role to another within the same organization; c) authorizations for privileged access rights should be reviewed at more frequent intervals; d) privilege allocations should be checked at regular intervals to ensure that unauthorized privileges have not been obtained; e) changes to privileged accounts should be logged for periodic review. Account management might include (i.e., individual, role, and system, device-based, and system), establishment of conditions for group membership, and assignment of associated authorizations. In certain IACS instances, where the organization has determined that individual accounts are unnecessary from a risk-analysis and/or regulatory aspect, shared accounts are acceptable as long as adequate compensating controls (such as limited physical access) are in place and documented. Non-user accounts (sometimes termed service accounts) that are utilized for process-to-process communication (for example, an HMI connecting to a database) typically require different security policies from human user accounts. The organization identifies authorized users of the IACS and specifies access rights/privileges. The organization grants access to the IACS based on: a) a valid need-to-know/need-to-share that is determined by assigned official duties and satisfying all functional and security criteria; and

50 ISA , D7E5 48 ISA99, WG b) Intended system usage. The organization requires proper identification for requests to establish accounts and approves all such requests. c) The organization specifically authorizes and monitors the use of guest/anonymous accounts and removes, disables, or otherwise secures unnecessary accounts. Account managers are notified when IACS users are terminated or transferred and associated accounts are removed, disabled, or otherwise secured. d) Account managers are also notified when users IACS usage or need-to-know/need-toshare changes. In cases where accounts are role-based, i.e., the workstation, hardware, and/or field devices define a user role, access to the IACS includes physical security policies and procedures based on organization risk assessment. e) In cases where physical access to the workstation, hardware, and/or field devices predefine privileges, the organization implements physical security policies, and procedures based on organization risk assessment. Account management may include additional account types (e.g., role-based, device-based, attribute-based). The organization removes, changes, disables, or otherwise secures default accounts. Other information This control compensates for possible weaknesses in the execution of controls 9.2.1, and Removal or adjustment of access rights The access rights of all employees and external party users to information and information processing facilities shall be removed upon termination of their employment, contract or agreement, or adjusted upon change. Upon termination, the access rights of an individual to information and assets associated with information processing facilities and services should be removed or suspended. This will determine whether it is necessary to remove access rights. Changes of employment should be reflected in removal of all access rights that were not approved for the new employment. The access rights that should be removed or adjusted include those of physical and logical access. Removal or adjustment can be done by removal, revocation or replacement of keys, identification cards, information processing facilities or subscriptions. Any documentation that identifies access rights of employees and contractors should reflect the removal or adjustment of access rights. If a departing employee or external party user has known passwords for user IDs remaining active, these should be changed upon termination or change of employment, contract or agreement. Access rights for information and assets associated with information processing facilities should be reduced or removed before the employment terminates or changes, depending on the evaluation of risk factors such as: a) whether the termination or change is initiated by the employee, the external party user or by management, and the reason for termination; b) the current responsibilities of the employee, external party user or any other user; c) the value of the assets currently accessible. d) other risk factors to be considered when reducing or removing access rights should include risk associated with disruption to IACS availability, plant protection, and plant opoerations. Other information In certain circumstances access rights may be allocated on the basis of being available to more people than the departing employee or external party user, e.g. group IDs. In such circumstances, departing individuals should be removed from any group access lists and arrangements should be made

51 ISA99, WG02 49 ISA , D7E to advise all other employees and external party users involved to no longer share this information with the person departing. In cases of management-initiated termination, disgruntled employees or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they may be tempted to collect information for future use. The organization promptly removes from the access list personnel no longer requiring access to the facility where the IACS resides. Authorized access shall be adjusted for assignments in restricted areas or for personnel dismissal. 9.3 User responsibilities Objective: To make users accountable for safeguarding their authentication information Use of secret authentication information Users should be required to follow the organization s practices in the use of secret authentication information. All users should be advised to: a) keep secret authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority; b) avoid keeping a record (e.g. on paper, software file or hand-held device) of secret authentication information, unless this can be stored securely and the method of storing has been approved (e.g. password vault); c) change secret authentication information whenever there is any indication of its possible compromise; d) when passwords are used as secret authentication information, select quality passwords with sufficient minimum length which are: 1) easy to remember; 2) not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers and dates of birth etc.; 3) not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries); 4) free of consecutive identical, all-numeric or all-alphabetic characters; 5) if temporary, changed at the first log-on; Other information Provision of Single Sign On (SSO) or other secret authentication information management tools reduces the amount of secret authentication information that users are required to protect and thus can increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of secret authentication information. 9.4 System and application access control Objective: To prevent unauthorized access to systems and applications.

52 ISA , D7E5 50 ISA99, WG Information access restriction Access to information and application system functions should be restricted in accordance with the access control policy. Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy. The following should be considered in order to support access restriction requirements: a) providing menus to control access to application system functions; b) controlling which data can be accessed by a particular user; c) controlling the access rights of users, e.g. read, write, delete and execute; d) controlling the access rights of other applications; e) limiting the information contained in outputs; f) providing physical or logical access controls for the isolation of sensitive applications, application data, or systems Secure log-on procedures Where required by the access control policy, access to systems and applications should be controlled by a secure log-on procedure. A suitable authentication technique should be chosen to substantiate the claimed identity of a user. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used. The procedure for logging into a system or application should be designed to minimize the opportunity for unauthorized access. The log-on procedure should therefore disclose the minimum of information about the system or application, in order to avoid providing an unauthorized user with any unnecessary assistance. A good log-on procedure should: a) not display system or application identifiers until the log-on process has been successfully completed; b) display a general notice warning that the computer should only be accessed by authorized users; c) not provide help messages during the log-on procedure that would aid an unauthorized user; d) validate the log-on information only on completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect; e) protect against brute force log-on attempts; f) log unsuccessful and successful attempts; g) raise a security event if a potential attempted or successful breach of log-on controls is detected; h) display the following information on completion of a successful log-on: 1) date and time of the previous successful log-on; 2) details of any unsuccessful log-on attempts since the last successful log-on;

53 ISA99, WG02 51 ISA , D7E i) not display a password being entered; j) not transmit passwords in clear text over a network; k) terminate inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization's security management or on mobile devices; l) restrict connection times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access. Other information Passwords are a common way to provide identification and authentication based on a secret that only the user knows. The same can also be achieved with cryptographic means and authentication protocols. The strength of user authentication should be appropriate for the classification of the information to be accessed. If passwords are transmitted in clear text during the log-on session over a network, they can be captured by a network sniffer program Password management system Password management systems shall be interactive and shall ensure quality passwords. A password management system should: a) enforce the use of individual user IDs and passwords to maintain accountability; b) allow users to select and change their own passwords and include a confirmation procedure to allow for input errors; c) enforce a choice of quality passwords; d) force users to change their passwords at the first log-on; e) enforce regular password changes and as needed; f) maintain a record of previously used passwords and prevent re-use; g) not display passwords on the screen when being entered; h) store password files separately from application system data; i) store and transmit passwords in protected form. Other information Some applications require user passwords to be assigned by an independent authority; in such cases, points b), d) and e) of the above guidance do not apply. In most cases the passwords are selected and maintained by users Use of privileged utility programs The use of utility programs that might be capable of overriding system and application controls should be restricted and tightly controlled. The following guidelines for the use of utility programs that might be capable of overriding system and application controls should be considered: a) use of identification, authentication and authorization procedures for utility programs;

54 ISA , D7E5 52 ISA99, WG b) segregation of utility programs from applications software; c) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see 9.2.2); d) authorization for ad hoc use of utility programs; e) limitation of the availability of utility programs, e.g. for the duration of an authorized change; f) logging of all use of utility programs; g) defining and documenting of authorization levels for utility programs; h) removal or disabling of all unnecessary utility programs; i) not making utility programs available to users who have access to applications on systems where segregation of duties is required. Other information Most computer installations have one or more utility programs that might be capable of overriding system and application controls Access control to program source code Access to program source code shall be restricted. [JDG10] Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled, in order to prevent the introduction of unauthorized functionality and to avoid unintentional changes as well as to maintain the confidentiality of valuable intellectual property. For program source code, this can be achieved by controlled central storage of such code, preferably in program source libraries. The following guidelines should then be considered to control access to such program source libraries in order to reduce the potential for corruption of computer programs: a) where possible, program source libraries should not be held in operational systems; b) the program source code and the program source libraries should be managed according to established procedures; c) support personnel should not have unrestricted access to program source libraries; d) the updating of program source libraries and associated items and the issuing of program sources to programmers should only be performed after appropriate authorization has been received; e) program listings should be held in a secure environment; f) an audit log should be maintained of all accesses to program source libraries; g) maintenance and copying of program source libraries should be subject to strict change control procedures (see ). If the program source code is intended to be published, additional controls to help getting assurance on its integrity (e.g. digital signature) should be considered. 10 Cryptography 10.1 Cryptographic controls Objective: To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information.

55 ISA99, WG02 53 ISA , D7E Policy on the use of cryptographic controls A policy on the use of cryptographic controls for protection of information should be developed and implemented. If cryptography is required, the IACS shall employ validated cryptographic modules that applicable laws, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module may require. When developing a cryptographic policy the following should be considered: a) the management approach towards the use of cryptographic controls across the organization, including the general principles under which business information should be protected; b) based on a risk assessment, the required level of protection should be identified taking into account the type, strength and quality of the encryption algorithm required; c) the use of encryption for protection of information transported by mobile or removable media devices or across communication lines; d) the approach to key management, including methods to deal with the protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys; e) roles and responsibilities, e.g. who is responsible for: 1) the implementation of the policy; 2) the key management, including key generation (see ); f) the standards to be adopted for effective implementation throughout the organization (which solution is used for which business processes); g) the impact of using encrypted information on controls that rely upon content inspection (e.g. malware detection). When implementing the organization s cryptographic policy, consideration should be given to the regulations and national and/or legal restrictions that might apply to the use of cryptographic techniques in different parts of the world and to the issues of trans-border flow of encrypted information (see ). Cryptographic controls can be used to achieve different information security objectives, e.g.: a) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted; b) integrity/authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information; c) non-repudiation: using cryptographic techniques to provide evidence of the occurrence or nonoccurrence of an event or action; d) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources. The use of cryptography is determined after careful consideration of the security needs and the potential ramifications on system performance. The procurement process most effective safeguard is to use a cryptographic module validated by a recognized 3rd party authority, e.g. the Cryptographic Module Validation Program.

56 ISA , D7E5 54 ISA99, WG Other information Making a decision as to whether a cryptographic solution is appropriate should be seen as part of the wider process of risk assessment and selection of controls. This assessment can then be used to determine whether a cryptographic control is appropriate, what type of control should be applied and for what purpose and business processes. A policy on the use of cryptographic controls is necessary to maximize the benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use. Specialist advice should be sought in selecting appropriate cryptographic controls to meet the information security policy objectives Key management A policy on the use, protection and lifetime of cryptographic keys should be developed and implemented through their whole lifecycle. Where public key cryptography is utilized, the organization shall determine what appropriate interfaces are required with existing public key infrastructure under an appropriate certificate policy or obtains public key certificates under an appropriate certificate policy from an approved service provider. The policy should include requirements for managing cryptographic keys though their whole lifecycle including generating, storing, archiving, retrieving, distributing, retiring and destroying keys. Cryptographic algorithms, key lengths and usage practices should be selected according to best practice. Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys. All cryptographic keys should be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys should be physically protected. A key management system should be based on an agreed set of standards, procedures and secure methods for: a) generating keys for different cryptographic systems and different applications; b) issuing and obtaining public key certificates; c) distributing keys to intended entities, including how keys should be activated when received; d) storing keys, including how authorized users obtain access to keys; e) changing or updating keys including rules on when keys should be changed and how this will be done; f) dealing with compromised keys; g) revoking keys including how keys should be withdrawn or deactivated, e.g. when keys have been compromised or when a user leaves an organization (in which case keys should also be archived); h) recovering keys that are lost or corrupted; i) backing up or archiving keys; j) destroying keys;

57 ISA99, WG02 55 ISA , D7E k) logging and auditing of key management related activities. In order to reduce the likelihood of improper use, activation and deactivation dates for keys should be defined so that the keys can only be used for the period of time defined in the associated key management policy. In addition to securely managing secret and private keys, the authenticity of public keys should also be considered. This authentication process can be done using public key certificates, which are normally issued by a certification authority, which should be a recognized organization with suitable controls and procedures in place to provide the required degree of trust. The contents of service level agreements or contracts with external suppliers of cryptographic services, e.g. with a certification authority, should cover issues of liability, reliability of services and response times for the provision of services (see 15.2). Registration to receive a public key certificate needs to include authorization by a supervisor or a responsible official and needs to be accomplished using a secure process that verifies the identity of the certificate holder and ensures that the certificate is issued to the intended party. Other information The management of cryptographic keys is essential to the effective use of cryptographic techniques. ISO/IEC provides further information on key management. Cryptographic techniques can also be used to protect cryptographic keys. Procedures may need to be considered for handling legal requests for access to cryptographic keys, e.g. encrypted information can be required to be made available in an unencrypted form as evidence in a court case. 11 Physical and environmental security 11.1 Secure areas Objective: To prevent unauthorized physical access, damage and interference to the organization s information and information processing facilities Physical security perimeter Security perimeters shall be defined and used to protect areas that contain either sensitive or critical information and information processing facilities. The organization shall control all physical access points (including designated entry/exit points) to the facility where the IACS resides (except for those areas within the facility officially designated as publicly accessible) and verifies individual access authorizations before granting access to the facility. The organization controls access to areas officially designated as publicly accessible, as appropriate, in accordance with the organization s assessment of risk. The organization controls physical access to the IACS independent of the physical access controls for the facility. Identity verification is required for entry to the most secured IACS spaces. The following guidelines should [ENH11]be considered and implemented where appropriate for physical security perimeters: a) security perimeters should be defined, and the siting and strength of each of the perimeters should depend on the security requirements of the assets within the perimeter and the results of a risk assessment;

58 ISA , D7E5 56 ISA99, WG b) perimeters of a building or site containing information processing facilities should be physically sound (i.e. there should be no gaps in the perimeter or areas where a break-in could easily occur); the exterior roof, walls and flooring of the site should be of solid construction and all external doors should be suitably protected against unauthorized access with control mechanisms, (e.g. bars, alarms, locks etc.); doors and windows should be locked when unattended and external protection should be considered for windows, particularly at ground level; The organization uses physical access devices (e.g., keys, locks, combinations, card readers) and/or guards to control entry to facilities containing IACS. c) a manned reception area or other means to control physical access to the site or building should be in place; access to sites and buildings should be restricted to authorized personnel only; d) physical barriers should, where applicable, be built to prevent unauthorized physical access and environmental contamination; e) all fire doors on a security perimeter should be alarmed, monitored and tested in conjunction with the walls to establish the required level of resistance in accordance with suitable regional, national and international standards; they should operate in accordance with the local fire code in a failsafe manner; f) suitable intruder detection systems should be installed to national, regional or international standards and regularly tested to cover all external doors and accessible windows; unoccupied areas should be alarmed at all times; cover should also be provided for other areas, e.g. computer room or communications rooms; g) information processing facilities managed by the organization should be physically separated from those managed by external parties. h) The organization secures keys, combinations, and other access devices and inventories those devices regularly. The organization changes combinations and keys: (i) periodically; and (ii) when keys are lost, combinations are compromised, or individuals are transferred or terminated. Workstations and associated peripherals connected to (and part of) an organizational IACS may be located in areas designated as publicly accessible with access to such devices being appropriately controlled. The organization considers IACS safety and security interdependencies. The organization considers access requirements in emergency situations. During an emergency-related event, the organization may restrict access to IACS facilities and assets to authorized individuals only. i) This requirement enhancement, in general, applies to server rooms, communications centers, telecommunication spaces, control rooms, instrument rack rooms, remote control rooms or any other areas within a facility containing large concentrations of IACS components or components with a higher impact level than that of the majority of the facility. The intent is to provide an additional layer of physical security for those areas where the organization may be more vulnerable due to the concentration of IACS components or the impact level of the components. The requirement enhancement is not intended to apply to workstations or peripheral devices that are typically dispersed throughout the facility and used routinely by organizational personnel. Other information Physical protection can be achieved by creating one or more physical barriers around the organization s premises and information processing facilities. The use of multiple barriers gives additional protection, where the failure of a single barrier does not mean that security is immediately compromised. A secure area may be a lockable office or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access may be needed between areas with different security requirements inside the security perimeter. Special attention to physical access security should be given in the case of buildings holding assets for multiple organizations.

59 ISA99, WG02 57 ISA , D7E The application of physical controls, especially for the secure areas, should be adapted to the technical and economic circumstances of the organization, as set forth in the risk assessment. Especially in energy transmission and distribution systems, and in the area of distributed generation, the components are distributed across decentralized sites. Equipment is situated in control and technical rooms within the organization s building and in peripheral sites. Sometimes the equipment is situated on third-party premises or in public environments. It is not normally possible to achieve a comprehensive level of physical protection for peripheral and potential unmanned sites, therefore the residual risk must be assessed and mitigated where necessary, by means of supplementary measures.[jdg12] Physical entry controls Secure areas shall be protected by appropriate entry controls to ensure that only authorized personnel are allowed access to the IACS. The organization escorts visitors and monitors visitor activity. The following guidelines should be considered: a) the date and time of entry and departure of visitors should be recorded, and all visitors should be supervised unless their access has been previously approved; they should only be granted access for specific, authorized purposes and should be issued with instructions on the security requirements of the area and on emergency procedures. The identity of visitors should be authenticated by an appropriate means; b) access to areas where confidential information is processed or stored should be restricted to authorized individuals only by implementing appropriate access controls, e.g. by implementing a two-factor authentication mechanism such as an access card and secret PIN; c) a physical log book or electronic audit trail of all access should be securely maintained and monitored; d) all employees, contractors and external parties should be required to wear some form of visible identification and should immediately notify security personnel if they encounter unescorted visitors and anyone not wearing visible identification; e) external party support service personnel should be granted restricted access to secure areas or confidential information processing facilities only when required; this access should be authorized and monitored; f) access rights to secure areas should be regularly reviewed and updated, and revoked when necessary (see and 9.2.5). g) Personnel without permanent authorization or permanent duties, including physical access to an IACS, are considered a visitor Securing offices, rooms and facilities Physical security for offices, rooms and facilities shall be designed and applied. The following guidelines should be considered to secure offices, rooms and facilities: a) key facilities should be sited to avoid access by the public; b) where applicable, buildings should be unobtrusive and give minimum indication of their purpose, with no obvious signs, outside or inside the building, identifying the presence of information processing activities;

60 ISA , D7E5 58 ISA99, WG c) facilities should be configured to prevent confidential information or activities from being visible and audible from the outside. Electromagnetic shielding should also be considered as appropriate; d) directories and internal telephone books identifying locations of confidential information processing facilities should not be readily accessible to anyone unauthorized Protecting against external and environmental threats Physical protection against natural disasters, malicious attack or accidents should be designed and applied. Specialist advice should be obtained and followed on how to avoid damage from fire, flood, earthquake, explosion, hazardous events, civil unrest and other forms of natural or man-made disaster occurring onsite or at neighboring premises. a) hazardous[gtd13] or combustible materials should be stored at a safe distance from a secure area. Bulk supplies such as stationery should not be stored within the same secure area as the IACS.; b) fallback equipment and back-up media should be sited at a safe distance to avoid damage from a disaster affecting the main site; c) appropriate firefighting equipment should be provided and suitably placed; d) site location should be selected or appropriate countermeasures should be employed to minimize impact due to internal or external explosion or fire; e) appropriate electric design should be developed to minimize impact of electromagnetic radiation, lightning and provide backup power supply (see for uninterruptible power supply); and f) appropriate environment control to minimize impact of dust, humidity, corrosion and entry of rodents Working in secure areas Procedures for working in secure areas shall be designed and applied. The following guidelines should be considered: a) personnel should only be aware of the existence of, or activities within, a secure area on a need-to-know basis; b) unsupervised working in secure areas should be avoided both for safety reasons and to prevent opportunities for malicious activities; c) vacant secure areas should be physically locked and periodically reviewed; d) photographic, video, audio or other recording equipment, such as cameras in mobile devices, should not be allowed, unless authorized. The arrangements for working in secure areas include controls for the employees and external party users working in the secure area and they cover all activities taking place in the secure area.

61 ISA99, WG02 59 ISA , D7E Delivery and loading areas Access points such as delivery and loading areas and other points where unauthorized persons could enter the premises shall be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access. The following guidelines should be considered: a) access to a delivery and loading area from outside of the building should be restricted to identified and authorized personnel; b) the delivery and loading area should be designed so that supplies can be loaded and unloaded without delivery personnel gaining access to other parts of the building; c) the external doors of a delivery and loading area should be secured when the internal doors are opened; d) incoming material should be inspected and examined for explosives, chemicals or other hazardous materials, before it is moved from a delivery and loading area; e) incoming material should be registered in accordance with asset management procedures(see 8) on entry to the site; f) incoming and outgoing shipments should be physically segregated, where possible; g) incoming material should be inspected for evidence of tampering enroute. If such tampering is discovered it should be immediately reported to security personnel Equipment Objective: To prevent loss, damage, theft or compromise of assets and interruption to the organization s operations Equipment siting and protection Equipment shall be sited and protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access. The organization shall employ and maintain fire suppression and detection devices/systems that can be activated in the event of a fire. (1) The organization employs fire detection devices/systems that activate automatically and notify the organization and emergency responders in the event of a fire. (2) The organization employs fire suppression devices/systems that provide automatic notification of any activation to the organization and emergency responders. (3) The organization employs an automatic fire suppression capability in facilities that ar e not staffed on a continuous basis. The organization shall regularly maintain, within acceptable levels, and monitor the temperature and humidity within the facility where the IACS resides. The organization shall protect the IACS from water damage resulting from broken plumbing lines or other sources of water leakage by providing master shutoff valves that are accessible, working properly, and known to key personnel. (1) The organization employs mechanisms that, without the need for manual intervention, protect the IACS from water damage in the event of a significant water leak.

62 ISA , D7E5 60 ISA99, WG The following guidelines should be considered to protect equipment: a) equipment should be sited to minimize unnecessary access into work areas; b) information processing facilities handling sensitive data should be positioned carefully to reduce the risk of information being viewed by unauthorized persons during their use; c) storage facilities should be secured to avoid unauthorized access; d) items requiring special protection should be safeguarded to reduce the general level of protection required; e) controls should be adopted to minimize the risk of potential physical and environmental threats, e.g. theft, fire, explosives, smoke, water (or water supply failure), dust, vibration, chemical effects, electrical supply interference, communications interference, electromagnetic radiation and vandalism; f) guidelines for eating, drinking and smoking in proximity to information processing facilities should be established; g) environmental conditions, such as temperature and humidity, should be monitored and alarmed for conditions which could adversely affect the operation of information processing facilities; h) lightning protection should be applied to all buildings and lightning protection filters should be fitted to all incoming power and communications lines; i) the use of special protection methods, such as keyboard membranes, should be considered for equipment in industrial environments; j) equipment processing confidential information should be protected to minimize the risk of information leakage due to electromagnetic emanation. Fire suppression and detection devices/systems include, but are not limited to, sprinkler systems, handheld fire extinguishers, fixed fire hoses, and smoke detectors Supporting utilities Equipment shall be protected from power failures and other disruptions caused by failures in supporting utilities. The organization shall identify primary and alternate telecommunications services to support the IACS and initiates necessary agreements to permit the resumption of system operations for critical mission/business functions within [Assignment: organization-defined time period] when the primary telecommunications capabilities are unavailable. (1) The organization develops primary and alternate telecommunications service agreements that contain priority-of-service provisions in accordance with the organization s availability requirements. (2) The organization obtains alternate telecommunications services that do not share a single point of failure with primary telecommunications services. (3) The organization obtains alternate telecommunications service providers that are sufficiently separated from primary service providers so as not to be susceptible to the same hazards. (4) The organization requires primary and alternate telecommunications service providers to have adequate contingency plans. The organization shall provide a short-term uninterruptible power supply to facilitate an orderly shutdown of the IACS in the event of a primary power source loss.

63 ISA99, WG02 61 ISA , D7E (1) The organization provides a long-term alternate power supply for the IACS that is capable of maintaining minimally required operational capability in the event of an extended loss of the primary power source. (2) The organization provides a long-term alternate power supply for the IACS that is selfcontained and not reliant on external power generation. The organization shall employ and maintains automatic emergency lighting that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes. Supporting utilities (e.g., electricity, telecommunications, water supply, gas, sewage, ventilation and air conditioning) should: a) conform to equipment manufacturer's specifications and local legal requirements; b) be appraised regularly for their capacity to meet business growth and interactions with other supporting utilities; c) be inspected and tested regularly to ensure their proper functioning; d) if necessary, be alarmed to detect malfunctions; e) if necessary, have multiple feeds with diverse physical routing. Emergency lighting and communications should be provided. Emergency switches and valves to cut off power, water, gas or other utilities should be located near emergency exits or equipment rooms. In the event that the primary and/or alternate telecommunications services are provided by a common carrier, the organization requests Telecommunications Service Priority (TSP) for all telecommunications services used for national security emergency preparedness (see for a full explanation of the TSP program). Other information Additional redundancy for network connectivity can be obtained by means of multiple routes from more than one utility provider Cabling security Power and telecommunications cabling carrying data or supporting information services shall be protected from interception, interference or damage. Additional redundancy for network connectivity can be obtained by means of multiple routes from more than one utility provider.[enh14] The organization shall protect power equipment and power cabling for the IACS from damage and destruction. (1) The organization employs redundant and parallel power cabling paths. The following guidelines for cabling security should be considered: a) power and telecommunications lines into information processing facilities should be underground, where possible, or subject to adequate alternative protection; b) power cables should be segregated from communications cables to prevent interference; c) for sensitive or critical systems further controls to consider include:

64 ISA , D7E5 62 ISA99, WG ) installation of armored conduit and locked rooms or boxes at inspection and termination points; 2) use of electromagnetic shielding to protect the cables; 3) initiation of technical sweeps and physical inspections for unauthorized devices being attached to the cables; 4) controlled access to patch panels and cable rooms. Physical protections applied to IACS distribution and communication lines help prevent accidental damage, disruption, and physical tampering. Additionally, physical protections are necessary to help prevent eavesdropping or in transit modification of unencrypted communications. Protective measures to control physical access to IACS distribution and communication lines include: (i) including endpoints or any access point contained in locked wiring closets; (ii) disconnected or locked spare jacks; and/or (iii) protection of cabling by conduit or cable trays Equipment maintenance Equipment shall be correctly maintained to ensure its continued availability and integrity. The following guidelines for equipment maintenance should be considered: a) equipment should be maintained in accordance with the supplier s recommended service intervals and specifications; b) only authorized maintenance personnel should carry out repairs and service equipment; c) records should be kept of all suspected or actual faults, and of all preventive and corrective maintenance; d) appropriate controls should be implemented when equipment is scheduled for maintenance, taking into account whether this maintenance is performed by personnel on site or external to the organization; where necessary, confidential information should be cleared from the equipment or the maintenance personnel should be sufficiently cleared; e) all maintenance requirements imposed by insurance policies should be complied with; f) before putting equipment back into operation after its maintenance, it should be inspected to ensure that the equipment has not been tampered with and does not malfunction Removal of assets Equipment, information or software should not be taken off-site without prior authorization. The following guidelines should be considered: a) employees and external party users who have authority to permit off-site removal of assets should be identified; b) time limits for asset removal should be set and returns verified for compliance; c) where necessary and appropriate, assets should be recorded as being removed off-site and recorded when returned; d) the identity, role and affiliation of anyone who handles or uses assets should be documented and this documentation returned with the equipment, information or software.

65 ISA99, WG02 63 ISA , D7E e) Other information Spot checks, undertaken to detect unauthorized removal of assets, can also be performed to detect unauthorized recording devices, weapons, etc., and to prevent their entry into and exit from, the site. Such spot checks should be carried out in accordance with relevant legislation and regulations. Individuals should be made aware that spot checks are carried out, and the verifications should only be performed with authorization appropriate for the legal and regulatory requirements Security of equipment and assets off premises Security shall be applied to off-site assets taking into account the different risks of working outside the organization s premises. The use of any information storing and processing equipment outside the organization s premises should be authorized by management. This applies to equipment owned by the organization and that equipment owned privately and used on behalf of the organization. The following guidelines should be considered for the protection of off-site equipment: a) equipment and media taken off premises should not be left unattended in public places; b) manufacturers instructions for protecting equipment should be observed at all times, e.g. protection against exposure to strong electromagnetic fields; c) controls for off-premises locations, such as home-working, teleworking and temporary sites should be determined by a risk assessment and suitable controls applied as appropriate, e.g. lockable filing cabinets, clear desk policy, access controls for computers and secure communication with the office (see also ISO/IEC Network Security); d) when off-premises equipment is transferred among different individuals or external parties, a log should be maintained that defines the chain of custody for the equipment including at least names and organizations of those who are responsible for the equipment. Risks, e.g. of damage, theft or eavesdropping, may vary considerably between locations and should be taken into account in determining the most appropriate controls. Other information Information storing and processing equipment includes all forms of personal computers, organizers, mobile phones, smart cards, paper or other form, which is held for home working or being transported away from the normal work location. More information about other aspects of protecting mobile equipment can be found in 6.2. It may be appropriate to avoid the risk by discouraging certain employees from working off-site or by restricting their use of portable IT equipment; Secure disposal or reuse of equipment All items of equipment containing storage media shall be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.

66 ISA , D7E5 64 ISA99, WG Procedures should be established and audited with respect to the addition, removal and disposal of all assets; and equipment should be verified to ensure whether or not storage media is contained prior to disposal or re-use. Storage media containing confidential or copyrighted information should be physically destroyed or the information should be destroyed, deleted or overwritten using techniques to make the original information non-retrievable rather than using the standard delete or format function. Other information Damaged equipment containing storage media may require a risk assessment to determine whether the items should be physically destroyed rather than sent for repair or discarded. Information can be compromised through careless disposal or re-use of equipment. In addition to secure disk erasure, whole-disk encryption reduces the risk of disclosure of confidential information when equipment is disposed of or redeployed, provided that: a) the encryption process is sufficiently strong and covers the entire disk (including slack space, swap files etc.); b) the encryption keys are long enough to resist brute force attacks; c) the encryption keys are themselves kept confidential (e.g. never stored on the same disk). For further advice on encryption, see 10. Techniques for securely overwriting storage media differ according to the storage media technology. Overwriting tools should be reviewed to make sure that they are applicable to the technology of the storage media Unattended user equipment Users shall ensure that unattended equipment has appropriate protection. All users should be made aware of the security requirements and procedures for protecting unattended equipment, as well as their responsibilities for implementing such protection. Users should be advised to: a) terminate active sessions when finished, unless they can be secured by an appropriate locking mechanism, e.g. a password protected screen saver; b) log-off from applications or network services when no longer needed; c) secure computers or mobile devices from unauthorized use by a key lock or an equivalent control, e.g. password access, when not in use Clear desk and clear screen policy A clear desk policy for papers and removable storage media and a clear screen policy for information processing facilities shall be adopted. The clear desk and clear screen policy should take into account the information classifications (see8.2), legal and contractual requirements (see 18.1) and the corresponding risks and cultural aspects of the organization. The following guidelines should be considered:

67 ISA99, WG02 65 ISA , D7E a) sensitive or critical business information, e.g. on paper or on electronic storage media, should be locked away (ideally in a safe or cabinet or other forms of security furniture) when not required, especially when the office is vacated. b) computers and terminals should be left logged off or protected with a screen and keyboard locking mechanism controlled by a password, token or similar user authentication mechanism when unattended and should be protected by key locks, passwords or other controls when not in use; c) unauthorized use of photocopiers and other reproduction technology (e.g., scanners, digital cameras) should be prevented; d) media containing sensitive or classified information should be removed from printers immediately. Other information A clear desk/clear screen policy reduces the risks of unauthorized access, loss of and damage to information during and outside normal working hours. Safes or other forms of secure storage facilities might also protect information stored therein against disasters such as a fire, earthquake, flood or explosion. Consider the use of printers with pin code function, so the originators are the only ones who can get their print-outs and only when standing next to the printer. 12 Operations security 12.1 Operational procedures and responsibilities Objective: To ensure correct and secure operations of information processing facilities Documented operating procedures Operating procedures shall be documented and made available to all users who need them. Documented procedures should be prepared for operational activities associated with information processing and communication facilities, such as computer start-up and close-down procedures, backup, equipment maintenance, media handling, computer room, control roomand network management, system updates, system migration, mail handling management and safety. The operating procedures should specify the operational instructions, including: a) the installation and configuration of systems; b) processing and handling of information both automated and manual; c) backup (see 12.3); d) scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times; e) instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities (see 9.4.4); f) support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties; g) special output and media handling instructions, such as the use of special stationery or the management of confidential output including procedures for secure disposal of output from failed jobs (see 8.3 and );

68 ISA , D7E5 66 ISA99, WG h) system restart and recovery procedures for use in the event of system failure; i) the management of audit-trail and system log information (see 12.4); j) monitoring procedures (see 12.4). k) under which conditions the incident, emergency or crisis handling procedures are to be invoked (see section ) Operating procedures and the documented procedures for system activities should be treated as formal documents and changes authorized by management. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities. disabled or the proposed control structure should be reviewed to determine if advantage can be taken of the enhanced functionality available Change management Changes to the organization, business processes, information processing facilities and systems that affect information security shall be controlled. A change management system for the IACS environment shall be developed and implemented. The change management process shall follow separation of duty principles to avoid conflict of interest. The adequacy and effectiveness of the change management policies and procedures shall be reviewed at planned intervals to ensure their continuing suitability for managing changes to IACS systems. The change management procedures shall include provisions to conduct safety and security reviews when significant changes are proposed or made to the IACS to ensure that the changes do not increase risks to HSE or business continuity. The organization shall develop, disseminate, and periodically review/update: (i) a formal, documented, configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the configuration management policy and associated configuration management controls. The organization shall develop, document, and maintain a current baseline configuration of the IACS. (1) The organization updates the baseline configuration of the IACS as an integral part of IACS component installations. (2) The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the IACS. The organization employs automated mechanisms to: (i) document proposed changes to the IACS; (ii) notify appropriate approval authorities; (iii) highlight approvals that have not been received in a timely manner; (iv) inhibit change until necessary approvals are received; and (v) document completed changes to the IACS. The organization tests, validates, and documents changes (e.g., patches and updates) before implementing the changes on the operational IACS. The organization shall conduct security impact analyses to determine the effects of configuration changes. The IACS vendor shall provide guidelines for recommended network and security configurations. The organization shall, based upon guidelines provided by the vendor: (i) establish mandatory network and security configuration settings for IACS components (ii) configure these settings to

69 ISA99, WG02 67 ISA , D7E the most restrictive mode consistent with operational requirements; (iii) document these settings; and (iv) enforce these settings in all components of the IACS. (1) The organization shall employ automated mechanisms to centrally manage, apply, and verify configuration settings. In particular, the following items should be considered: a) identification and recording of significant changes; b) planning and testing of changes; c) assessment of the potential impacts, including information security impacts, of such changes; d) formal approval procedure for proposed changes; e) verification that information security requirements have been met; f) communication of change details to all relevant persons; g) fallback procedures, including procedures and responsibilities for aborting and recovering from unsuccessful changes and unforeseen events; h) provision of an emergency change process to enable quick and controlled implementation of changes needed to resolve an incident (see 16.1). i) using clearly defined criteria, proposed changes to the IACS should be reviewed for their potential impact to HSE risks and cyber security risks by individuals technically knowledgeable about the industrial operation and the IACS system; j) the security requirements of a new system being installed in the IACS environment in an existing zone should meet the security policies and procedures required for that zone/environment; (See ISA for more information about zones and conduits.) k) maintenance upgrades or changes should meet the security requirements for the zone; l) cyber security change management procedures should be integrated with existing process safety management (PSM) procedures Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes. When changes are made, an audit log containing all relevant information should be retained. The risk of proposed changes to the IACS should be reviewed by individuals technically knowledgeable about the industrial operations and IACS. The configuration management policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The configuration management policy can be included as part of the general information security policy for the organization. Configuration management procedures can be developed for the security program in general, and for a particular IACS, when required. This requirement establishes a baseline configuration for the IACS. The baseline configuration provides information about a particular component s makeup (e.g., the standard software load for a workstation or notebook computer including updated patch information) and the component s logical placement within the IACS architecture. The baseline configuration also provides the organization with a well-defined and documented specification to which the IACS is built and deviations, if required, are documented in support of mission needs/ objectives. The organization manages configuration changes to the IACS using an organizationally approved process. Configuration change control involves the systematic proposal, justification, implementation, test/evaluation, review, and disposition of changes to the IACS, including upgrades and modifications. Configuration change control includes changes to the configurati on settings for information technology products (e.g., operating systems, firewalls, routers). The

70 ISA , D7E5 68 ISA99, WG organization includes emergency changes in the configuration change control process, including changes resulting from the remediation of flaws. The approvals to implement a change to the IACS include successful results from the security analysis of the change. The organization audits activities associated with configuration changes to the IACS. The organization ensures that testing does not interfere with IACS functions. The individual/group conducting the tests fully understands the organizational information security policies and procedures, the IACS security policies and procedures, and the specific health, safety, and environmental risks associated with a particular facility and/or process. A production IACS may need to be taken off-line, or replicated to the extent feasible, before testing can be conducted. If an IACS must be taken off-line for testing, the tests are scheduled to occur during planned IACS outages whenever possible. In situations where the organization cannot, for operational reasons, conduct live testing of a production IACS, the organization employs compensating controls (e.g., providing a replicated system to conduct testing). Prior to change implementation, and as part of the change approval process, the organization analyzes changes to the IACS for potential adverse security consequences. After the IACS is changed (including upgrades and modifications), the organization checks the securit y features to verify that the features are still functioning properly. The organization audits activities associated with configuration changes to the IACS. Monitoring configuration changes and conducting security impact analyses are important elements with regard to the ongoing assessment of security controls in the IACS. Other information Inadequate control of changes to information processing facilities and systems is a common cause of system or security failures. Changes to the operational environment, especially when transferring a system from development to operational stage, can impact on the reliability of applications (see14.2.2) Capacity management The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure the required system performance. Capacity requirements should be identified, taking into account the business criticality of the concerned system. System tuning and monitoring should be applied to ensure and, where necessary, improve the availability and efficiency of systems. Detective controls should be put in place to indicate problems in due time. Projections of future capacity requirements should take account of new business and system requirements and current and projected trends in the organization's information processing capabilities. Particular attention needs to be paid to any resources with long procurement lead times or high costs; therefore managers should monitor the utilization of key system resources. They should identify trends in usage, particularly in relation to business applications or information systems management tools. Managers should use this information to identify and avoid potential bottlenecks and dependence on key personnel that might present a threat to system security or services, and plan appropriate action. Providing sufficient capacity can be achieved by increasing capacity or by reducing demand. Examples of managing capacity demand include: a) deletion of obsolete data (disk space); b) decommissioning of applications, systems, databases or environments;

71 ISA99, WG02 69 ISA , D7E c) optimizing batch processes and schedules; d) optimizing application logic or database queries; e) denying or restricting bandwidth for resource-hungry services if these are not business critical (e.g. video streaming). A documented capacity management plan should be considered for mission critical systems. Other information This control also addresses the capacity of the human resources, as well as offices and facilities Separation of development, testing and operational environments Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment. The level of separation between operational, testing, and development environments that is necessary to prevent operational problems should be identified and implemented. The following items should be considered: a) rules for the transfer of software from development to operational status should be defined and documented; b) development and operational software should run on different systems or computer processors and in different domains or directories; c) changes to operational systems and applications should be tested in a testing or staging environment prior to being applied to operational systems; d) other than in exceptional circumstances, testing should not be done on operational systems; e) compilers, editors and other development tools or system utilities should not be accessible from operational systems when not required; f) users should use different user profiles for operational and testing systems, and menus should display appropriate identification messages to reduce the risk of error; g) sensitive data should not be copied into the testing system environment unless equivalent controls are provided for the testing system (see 14.3). Other information Development and testing activities can cause serious problems, e.g. unwanted modification of files or system environment or system failure. There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the operational environment. Where development and testing personnel have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. On some systems this capability could be misused to commit fraud or introduce untested or malicious code, which can cause serious operational problems. Developers and testers also pose a threat to the confidentiality of operational information. Development and testing activities may cause unintended changes to software or information if they share the same computing environment. Separating development, testing and operational environments is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business data (see 14.3 for the protection of test data).

72 ISA , D7E5 70 ISA99, WG If the separation of development, test, and operational systems cannot be implemented, then, depending upon the criticality of the system in question, specially adapted change management, incident, emergency and crisis handling procedures should be established that will allow a rapid and appropriate reaction to interferences and problems in the operational system. Moreover it should be ensured that development and test systems are also secured using the state-of-the-art technology. According to their criticality it should be ensured that the tes t and development systems are sufficiently isolated from other system and networks (e.g. operation in a separate network environment, no direct Internet access, etc.) and that they are exclusively used for development and testing Protection from malware Objective: To ensure that information and information processing facilities are protected against malware s against malware Detection, prevention and recovery controls to protect against malware shall be implemented, combined with appropriate user awareness. Protection against malware should be based on malware detection and repair software, information security awareness and appropriate system access and change management controls. The following guidance should be considered: a) establishing a formal policy prohibiting the use of unauthorized software (see and 14.2.); b) implementing controls that prevent or detect the use of unauthorized software (e.g. application whitelisting); c) implementing controls that prevent or detect the use of known or suspected malicious websites (e.g. blacklisting); d) establishing a formal policy to protect against risks associated with obtaining files and software either from or via external networks or on any other medium, indicating what protective measures should be taken; e) reducing vulnerabilities that could be exploited by malware, e.g. through technical vulnerability management (see 12.6); f) conducting regular reviews of the software and data content of systems supporting critical business processes; the presence of any unapproved files or unauthorized amendments should be formally investigated; g) installation and regular update of malware detection and repair software to scan computers and media as a precautionary control, or on a routine basis; the scan carried out should include: 1) scan any files received over networks or via any form of storage medium, for malware before use; 2) scan electronic mail attachments and downloads for malware before use; this scan should be carried out at different places, e.g. at electronic mail servers, desk top computers and when entering the network of the organization; 3) scan web pages for malware; h) defining procedures and responsibilities to deal with malware protection on systems, training in their use, reporting and recovering from malware attacks;

73 ISA99, WG02 71 ISA , D7E i) preparing appropriate business continuity plans for recovering from malware attacks, including all necessary data and software backup and recovery arrangements (see 12.3); j) implementing procedures to regularly collect information, such as subscribing to mailing lists or verifying web sites giving information about new malware; k) implementing procedures to verify information relating to malware, and ensure that warning bulletins are accurate and informative; managers should ensure that qualified sources, e.g. reputable journals, reliable Internet sites or suppliers producing software protecting against malware, are used to differentiate between hoaxes and real malware; all users should be made aware of the problem of hoaxes and what to do on receipt of them; l) isolating environments where catastrophic impacts may result. m) The organization also considers the receipt of false positives during malicious code detection and eradication and the resulting potential effect on the availability of the IACS. Updates are scheduled to occur during planned IACS outages. The organization considers IACS vendor recommendations for malicious code protection. Other information The use of two or more software products protecting against malware across the information processing environment from different vendors and technology can improve the effectiveness of malware protection. The use of one malware product on a set of devices in the IACS environment and a different malware product from a different vendor on a different set of devices can improve effectiveness. Care should be taken to protect against the introduction of malware during maintenance and emergency procedures, which may bypass normal malware protection controls. Under certain conditions, malware protection might cause disturbance within operations. Use of malware detection and repair software alone as a malware control is not usually adequate and commonly needs to be accompanied by operating procedures that prevent introduction of malware. IACS devices should not be directly connected to the Internet to obtain updated malicious code definition files. For smaller systems, manual distribution and installation of updated malicious code definition files may be used. For larger systems, a centralized, dedicated distribution server for IACS devices is recommended. Malicious code definition updates shall first be deployed on a test system or single computer to ensure compatibility prior to full deployment.[jdg15] If the software that protects against malicious code cannot be deployed for technical reasons (e.g. as a result of a lack of vendor support or vendor approval or the impossibility of installing timely updates), the resulting risks should be identified and other types of countermeasu res should be implemented that provide at least an equal degree of protection. Supplementary controls against malicious code include, among others: n) securing of all physical and logical data interfaces; o) network isolation and implementation of segmented network security zones that limit the impact of a malware incident; p) comprehensive system hardening measures to minimize the risk of malware incidents; q) the use of vendor qualified whitelisting solutions, which restrict the execution of non - approved software and code. r) The use of Host Intrusion Prevention System (HIPS) [JDG16]in monitoring mode (protection mode is not recommended). HIPS helps identifying network-based malwares and helps for early alerting about threats.

74 ISA , D7E5 72 ISA99, WG s) Use of Network Anomaly Detection System (NADS) [JDG17]to identify anomalies in the network traffic especially when a workstation is compromised and tries to spread the infection to others. NADS can be configured to block the traffic that is not allowed to run between the systems themselves when integrated with the host antimalware agent.[jdg18] In particular, the possible effects of malware incidents on equipment used for real -time process control and associated communications (e.g., through overload and disruption) should be taken into consideration and mitigated by implementing the appropriate controls Backup Objective: To protect against loss of data Information backup Backup copies of information, software and system images should [ENH19]be taken and tested regularly in accordance with an agreed backup policy. The organization shall identify an alternate storage site and initiates necessary agreements to permit the storage of IACS backup information. (1) The organization identifies an alternate storage site that is geographically separated from the primary storage site so as not to be susceptible to the same hazards. (2) The organization configures the alternate storage site to facilitate timely and effective recovery operations. (3) The organization identifies potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions. The frequency of IACS backups and the transfer rate of backup information to alternate storage sites (if so designated) shall be consistent with the organization s recovery time objectives and recovery point objectives. (1) The organization selectively uses backup information in the restoration of IACS functions as part of contingency plan testing. (2) The organization stores backup copies of the operating system and other critical IACS software in a separate facility or in a fire-rated container that is not collocated with the operational software. A backup policy should be established to define the organization's requirements for backup of information, software and systems. The backup policy should define the retention and protection requirements. Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following a disaster or media failure. When designing a backup plan, the following items should be taken into consideration: a) accurate and complete records of the backup copies and documented restoration procedures should be produced;

75 ISA99, WG02 73 ISA , D7E b) the extent (e.g. full or differential backup) and frequency of backups should reflect the business requirements of the organization, the security requirements of the information involved and the criticality of the information to the continued operation of the organization; c) the backups should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site; d) backup information should be given an appropriate level of physical and environmental protection (see 11) consistent with the standards applied at the main site; e) backup media should be regularly tested to ensure that they can be relied upon for emergency use when necessary; this should be combined with a test of the restoration procedures and checked against the restoration time required. Testing the ability to restore backed-up data should be performed onto dedicated test media, not by overwriting the original media in case the backup or restoration process fails and causes irreparable data damage or loss; f) in situations where confidentiality is of importance, backups should be protected by means of encryption. Operational procedures should monitor the execution of backups and address failures of scheduled backups to ensure completeness of backups according to the backup policy. Backup arrangements for individual systems and services should be regularly tested to ensure that they meet the requirements of business continuity plans. In the case of critical systems and services, backup arrangements should cover all systems information, applications and data necessary to recover the complete system in the event of a disaster. The retention period for essential business information should be determined, taking into account any requirement for archive copies to be permanently retained. The frequency of IACS backups and the transfer rate of backup information to the alternate storage site (if so designated) are consistent with the organization s recovery time objectives and recovery point objectives. Availability of up-to-date backups is essential for recovery from IACS failure and mis-configuration. Automating this function ensures that all required files are captured, reducing operator overhead. An organizational assessment of risk guides the use of encryption for backup information. While integrity and availability are the primary concerns for system backup information, protecting backup information from unauthorized disclosure is also an important consideration depending on the type of information residing on the backup media and the S target system level Logging and monitoring Objective: To record events and generate evidence Event logging Event logs recording user activities, exceptions, faults and information security events should [ENH20]be produced, kept and regularly reviewed. Event logs should include, when relevant: a) user IDs; b) system activities; c) dates, times and details of key events, e.g. log-on and log-off;

76 ISA , D7E5 74 ISA99, WG d) device identity or location if possible and system identifier; e) records of successful and rejected system access attempts; f) records of successful and rejected data and other resource access attempts; g) changes to system configuration; h) use of privileges; i) use of system utilities and applications; j) files accessed and the kind of access; k) network addresses and protocols; l) alarms raised by the access control system; m) activation and de-activation of protection systems, such as anti-virus systems and intrusion detection systems; n) records of transactions executed by users in applications. Event logging sets the foundation for automated monitoring systems which are capable of generating consolidated reports and alerts on system security. The organization should develop a baseline of normal IACS user behavior with allowable variances. The organization should also employ automated mechanisms to facilitate the review of user activities. Care must be exercised to ensure that the system load associated with logging does not interfere with the operational performance of the control system. Selective use of logging may be necessary on older control system devices to balance the benefits of event tracking with the necessity of reliable system performance. Other information Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken (see ). The acquisition, processing and management of audit protocols and data should be implemented in accordance with all applicable business, statutory, regulatory and internal requirements Where possible, system administrators should not have permission to erase or de-activate logs of their own activities (see ) Protection of log information Logging facilities and log information should be protected against tampering and unauthorized access. s should aim to protect against unauthorized changes to log information and operational problems with the logging facility including: a) alterations to the message types that are recorded; b) log files being edited or deleted; c) storage capacity of the log file media being exceeded, resulting in either the failure to record events or over-writing of past recorded events. Some audit logs may be required to be archived as part of the record retention policy or because of requirements to collect and retain evidence (see ).

77 ISA99, WG02 75 ISA , D7E Other information System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the copying of appropriate message types automatically to a second log, or the use of suitable system utilities or audit tools to perform file interrogation and rationalization should be considered. System logs need to be protected, because if the data can be modified or data in them deleted, their existence may create a false sense of security. Real-time copying of logs to a system outside the control of a system administrator or operator can be used to safeguard logs Administrator and operator logs System administrator and system operator activities should be logged and the logs protected and regularly reviewed. Privileged user account holders may be able to manipulate the logs on information processing facilities under their direct control, therefore it is necessary to protect and review the logs to maintain accountability for the privileged users. Other information An intrusion detection system managed outside of the control of system and network administrators can be used to monitor system and network administration activities for compliance Clock synchronization The clocks of all relevant information processing systems within an organization or security domain should be synchronized to a single reference time source. External and internal requirements for time representation, synchronization and accuracy should be documented. Such requirements can be legal, regulatory, contractual requirements, standards compliance or requirements for internal monitoring. A standard reference time for use within the organization should be defined. The organization's approach to obtaining a reference time from external source(s) and how to synchronize internal clocks reliably should be documented and implemented. Other information The correct setting of computer clocks is important to ensure the accuracy of audit logs, which may be required for investigations or as evidence in legal or disciplinary cases. Inaccurate audit logs may hinder such investigations and damage the credibility of such evidence. A clock linked to a radio time broadcast from a national atomic clock can be used as the master clock for logging systems. A network time protocol can be used to keep all of the servers in synchronization with the master clock. Depending upon the criticality of the process control system in question, the use of dedicated, non - internet synchronized NTP servers or of digitally signed NTP time messages should be considered in order to lower the risks associated with accessing external system devices.

78 ISA , D7E5 76 ISA99, WG of operational software Objective: To ensure the integrity of operational systems Installation of software on operational systems Procedures shall be implemented to control the installation of software on operational systems. The following guidelines should be considered to control changes of software on operational systems: a) the updating of the operational software, applications and program libraries should only be performed by trained administrators upon appropriate management authorization (see 9.4.5); b) operational systems should only hold approved executable code and not development code or compilers; c) applications and operating system software should only be implemented after extensive and successful testing; the tests should cover usability, security, effects on other systems and userfriendliness and should be carried out on separate systems (see ); it should be ensured that all corresponding program source libraries have been updated; d) a configuration control system should be used to keep control of all implemented software as well as the system documentation; e) a rollback strategy should be in place before changes are implemented; f) an audit log should be maintained of all updates to operational program libraries; g) previous versions of application software should be retained as a contingency measure; h) old versions of software should be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data is retained in archive. Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Over time, software vendors will cease to support older versions of software. The organization should consider the risks of relying on unsupported software. Any decision to upgrade to a new release should take into account the business requirements for the change and the security of the release, e.g. the introduction of new information security functionality or the number and severity of information security problems affecting this version. Software patches should be applied when they can help to remove or reduce information security weaknesses (see 12.6). Physical or logical access should only be given to suppliers for support purposes when necessary and only with management approval. The supplier s activities should be monitored (see ). Computer software may rely on externally supplied software and modules, which should be monitored and controlled to avoid unauthorized changes, which could introduce security weaknesses Technical Vulnerability Management Objective: To prevent exploitation of technical vulnerabilities.

79 ISA99, WG02 77 ISA , D7E Management of technical vulnerabilities Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. A current and complete inventory of assets (see 8) is a prerequisite for effective technical vulnerability management. Specific information needed to support technical vulnerability management includes the software vendor, version numbers, current state of deployment (e.g. what software is installed on what systems), and the person(s) within the organization responsible for the software. Appropriate, timely action should be taken in response to the identification of potential technical vulnerabilities. The following guidance should be followed to establish an effective management process for technical vulnerabilities: a) the organization should define and establish the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, patching, asset tracking, and any coordination responsibilities required; b) information resources that will be used to identify relevant technical vulnerabilities and to maintain awareness about them should be identified for software and other technology (based on the asset inventory list, see 8.1.1); these information resources should be updated based on changes in the inventory, or when other new or useful resources are found; c) a timeline should be defined to react to notifications of potentially relevant technical vulnerabilities; d) once a potential technical vulnerability has been identified, the organization should identify the associated risks and the actions to be taken; such action could involve patching of vulnerable systems and/or applying other controls; e) depending on how urgently a technical vulnerability needs to be addressed, the action taken should be carried out according to the controls related to change management (see ) or by following information security incident response procedures (see ); f) follow the patch management procedures: 1) if a patch is available from a legitimate source, the risks associated with inst alling the patch should be assessed (the risks posed by the vulnerability should be compared with the risk of installing the patch); 2) only approved patches from the IACS vendor that have been tested and/or evaluated should be installed in the production environment to ensure they are effective and do not result in side effects that cannot be tolerated; if no patch is available, other controls should be considered, such as: i) turning off services or capabilities related to the vulnerability; ii) adapting or adding access controls, e.g. firewalls, at network borders (see 13.1 ); iii) increased monitoring to detect actual attacks; iv) raising awareness of the vulnerability; g) an audit log should be kept for all procedures undertaken; h) the technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency; i) systems at high risk should be addressed first.

80 ISA , D7E5 78 ISA99, WG j) an effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out should an incident occur; k) define a procedure to address the situation where vulnerability has been identified but there is no suitable countermeasure. In this situation, the organization should evaluate risks relating to the known vulnerability and define appropriate detective and corrective actions. Other information Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures (see and ). Vendors are often under significant pressure to release patches as soon as possible. Therefore, there is a possibility that a patch does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling a patch cannot be easily achieved once the patch has been applied. If adequate testing of the patches is not possible, e.g. because of costs or lack of resources, a delay in patching can be considered to evaluate the associated risks, based on the experience reported by other users. The use of ISO/IEC can be beneficial Restrictions on software installation Rules governing the installation of software by users shall be established and implemented. The organization should define and enforce strict policy on which types of software users may install. The principle of least privilege should be applied. If granted certain privileges, users may have the ability to install software. The organization should identify what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted having regard to the roles of the users concerned. Software installation on IACS devices must be carefully managed because a new application or an update of an existing application may interfere with the system performing its intended task. Only system administrators and lead IACS support engineers should have the privileges to install software. Operators and other end users should not be given the privileges to perform this task. Other information Uncontrolled installation of software on computing devices can lead to introducing vulnerabilities and then to information leakage, loss of integrity or other information security incidents, or to violation of intellectual property rights Information systems audit considerations Objective: To minimize the impact of audit activities on operational systems Information systems audit controls Audit requirements and activities involving verification of operational systems should be carefully planned and agreed to minimize disruptions to business processes.

81 ISA99, WG02 79 ISA , D7E The following guidelines should be observed: a) audit requirements for access to systems and data should be agreed with appropriate management; b) the scope of technical audit tests should be agreed and controlled; c) audit tests should be limited to read-only access to software and data; d) access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed, or given appropriate protection if there is an obligation to keep such files under audit documentation requirements; e) requirements for special or additional processing should be identified and agreed; audit tests that could affect system availability should be run outside business hours; f) resources for performing the checks should be explicitly identified and made available; g) all access should be monitored and logged to produce a reference trail. 13 Communication Security 13.1 Network security management Objective: To ensure the protection IACS, business process and information in networks and its supporting information processing facilities Network controls Networks should be managed and controlled to protect IACS, business process and information in systems and applications. The organization shall produce implementation guidance for wireless technologies. (1) The organization shall deploy continuous passive monitoring for unauthorized wireless access points and takes appropriate action if such access points are discovered. s should be implemented to ensure the security of information in networks and the protection of connected services from unauthorized access. In particular, the following items should be considered: a) responsibilities and procedures for the management of networking equipment should be established; b) operational responsibility for networks should be separated from computer operations where appropriate (see 6.1.5); c) special controls should be established to safeguard the availability, confidentiality and integrity of data passing over public networks or over wireless networks and to protect the connected systems and applications (see 10 and 13.2 ); special controls may also be required to maintain the availability of the network services and computers connected; d) appropriate logging and monitoring should be applied to enable recording and detection of actions that may affect, or are relevant to, IACS and information security; e) management activities should be closely coordinated both to optimize the service to the organization and to ensure that controls are consistently applied across the IACS and information processing infrastructure;

82 ISA , D7E5 80 ISA99, WG f) systems on the network should be authenticated; g) systems connection to the network should be restricted. h) High-risk IACS shall be isolated from or employ a network segmentation barrier to separate it from the other zones with different security levels or risk; and i) Barrier devices shall block all non-essential communications in and out of the security zone containing critical control equipment. Other Information Additional information on network security can be found in ISO/IEC Network Security. Wireless technologies include, but are not limited to, microwave, satellite, packet radio [UHF/VHF], x, (ZigBee, WirelessHART, ISA100.11a), and Bluetooth. At the time of publication of this document, these access points are typically based on x technology. In the future, this will change and thus other wireless technologies will need to be monitored as well. Regardless, organizations should conduct a thorough scan for unauthorized wireless access points in facilities containing high-impact IACS. The scan should involve the entire facility, not just areas containing a high-impact IACS.[JDG21] Security of network services Security mechanisms, service levels and management requirements of all network services should be identified and included in network services agreements, whether these services are provided in-house or outsourced. The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored, and the right to audit should be agreed. The security arrangements necessary for particular services, such as security features, service levels and management requirements, should be identified. The organization should ensure that network service providers implement these measures. Other Information Network services include the provision of connections, private network services and value added networks and managed network security solutions such as firewalls and intrusion detection systems. These services can range from simple unmanaged bandwidth to complex value-added offerings. Security features of network services could be: a) technology applied for security of network services, such as authentication, encryption and network connection controls; b) technical parameters required for secured connection with the network services in accordance with the security and network connection rules; c) procedures for the network service usage to restrict access to network services or applications, where necessary Segregation in networks It shall include network segmentation countermeasure strategies like:

83 ISA99, WG02 81 ISA , D7E a) Groups of information services, users and information systems shall be segregated on networks b) Additionally, network segmentation countermeasure strategies employing security zones shall be developed for IACS based upon the risk level. The organization carefully considers the intrinsically shared nature of commercial telecommunications services in the implementation of security controls associated with the use of such services. (1) The organization implements a managed interface (boundary protection devices in an effective security architecture) with any external telecommunication service, implementing controls appropriate to the required protection of the confidentiality and integrity of the information being transmitted. One method of managing the security of large networks is to divide them into separate network domains. The domains can be chosen based on trust levels (e.g., public access domain, desktop domain, server domain), along organizational units (e.g., human resources, finance, marketing) or some combination (e.g., server domain connecting to multiple organizational units). The segregation can be done using either physically different networks or by using different logical networks (e.g. virtual private networking). The perimeter of each domain should be well defined. Access between network domains is allowed, but should be controlled at the perimeter using a gateway (e.g., firewall, filtering router). For high risk IACS, the use of a DMZ in conjunction with a Zone offers additional risk reduction opportunities between the low-security-level Business Zone and the high-security-level Zone. The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the access control policy (see 9.1.1), access requirements, value and classification of information processed and also take account of the relative cost and performance impact of incorporating suitable gateway technology. Wireless networks require special treatment due to the poorly defined network perimeter. For sensitive environments, consideration should be made to treat all wireless access as external connections (see 9.4.2) and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls policy (see ) before granting access to internal systems. The authentication, encryption and user level network access control technologies of modern, standards based wireless networks may be sufficient for direct connection to the organization s internal network when properly implemented. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers, and may include third party provided access lines and other service elements. Consequently, such interconnecting communication services may represent sources of increased risk despite contract security provisions. Therefore, when this situation occurs, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. Other information Networks often extend beyond organizational boundaries, as business partnerships are formed that require the interconnection or sharing of information processing and networking facilities. Such extensions can increase the risk of unauthorized access to the organization s information systems that use the network, some of which require protection from other network users because of their sensitivity or criticality.

84 ISA , D7E5 82 ISA99, WG Information transfer Objective: To maintain the security of information transferred within an organization and with any external entity Information transfer policies and procedures Formal transfer policies, procedures and controls should be in place to protect the transfer of information through the use of all types of communication facilities. The procedures and controls to be followed when using communication facilities for information transfer should consider the following items: a) procedures designed to protect transferred information from interception, copying, modification, mis-routing and destruction; b) procedures for the detection of and protection against malware that may be transmitted through the use of electronic communications (see ); c) procedures for protecting communicated sensitive electronic information that is in the form of an attachment; d) policy or guidelines outlining acceptable use of communication facilities (see 8.1.3); e) personnel, external party and any other user s responsibilities not to compromise the organization, e.g. through defamation, harassment, impersonation, forwarding of chain letters, unauthorized purchasing, etc.; f) use of cryptographic techniques e.g. to protect the confidentiality, integrity and authenticity of information (see 10); g) retention and disposal guidelines for all business correspondence, including messages, in accordance with relevant national and local legislation and regulations; h) controls and restrictions associated with using communication facilities, e.g. automatic forwarding of electronic mail to external mail addresses; i) advising personnel to take appropriate precautions not to reveal confidential information; j) not leaving messages containing confidential information on answering machines since these may be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialling; k) advising personnel about the problems of using facsimile machines or services, namely: 1) unauthorized access to built-in message stores to retrieve messages; 2) deliberate or accidental programming of machines to send messages to specific numbers; 3) sending documents and messages to the wrong number either by misdialling or using the wrong stored number. In addition, personnel should be reminded that they should not have confidential conversations in public places or over insecure communication channels, open offices and meeting places. Information transfer services should comply with any relevant legal requirements (see 18.1). Other information Information transfer may occur through the use of a number of different types of communication facilities, including electronic mail, voice, facsimile and video.

85 ISA99, WG02 83 ISA , D7E Software transfer may occur through a number of different mediums, including downloading from the Internet and acquisition from vendors selling off-the-shelf products. The business, legal and security implications associated with electronic data interchange, electronic commerce and electronic communications and the requirements for controls should be considered Agreements on information transfer Agreements should address the secure transfer of business information between the organization and external parties. Information transfer agreements should incorporate the following: a) management responsibilities for controlling and notifying transmission, dispatch and receipt; b) procedures to ensure traceability and non-repudiation; c) minimum technical standards for packaging and transmission; d) escrow agreements; e) courier identification standards; f) responsibilities and liabilities in the event of IACS security incidents, such as loss of data, control or visualization; g) use of an agreed labelling system for sensitive or critical information, ensuring that the meaning of the labels is immediately understood and that the information is appropriately protected (see 8.2); h) technical standards for recording and reading information and software; i) any special controls that are required to protect sensitive items, such as cryptography (see 10); j) maintaining a chain of custody for information while in transit; k) acceptable levels of access control. Policies, procedures and standards should be established and maintained to protect information and physical media in transit (see 8.3.3), and should be referenced in such transfer agreements. The information security content of any agreement should reflect the sensitivity of the business information involved. Other information Agreements may be electronic or manual, and may take the form of formal contracts. For confidential information, the specific mechanisms used for the transfer of such information should be consistent for all organizations and types of agreements Electronic messaging Information involved in electronic messaging should be appropriately protected. Information security considerations for electronic messaging should include the following: a) protecting messages from unauthorized access, modification or denial of service commensurate with the classification scheme adopted by the organization;

86 ISA , D7E5 84 ISA99, WG b) ensuring correct addressing and transportation of the message; c) reliability and availability of the service; d) legal considerations, for example requirements for electronic signatures; e) obtaining approval prior to using external public services such as instant messaging, social networking or file sharing; f) stronger levels of authentication controlling access from publicly accessible networks. Other information There are many types of electronic messaging such as , electronic data interchange and social networking which play a role in business communications Confidentiality or non-disclosure agreements Requirements for confidentiality or non-disclosure agreements reflecting the organization s needs for the protection of information should be identified, regularly reviewed and documented. Confidentiality or non-disclosure agreements should address the requirement to protect confidential information using legally enforceable terms. Confidentiality or non-disclosure agreements are applicable to external parties or employees of the organization. Elements should be selected or added in consideration of the type of the other party and its permissible access or handling of confidential information. To identify requirements for confidentiality or non-disclosure agreements, the following elements should be considered: a) a definition of the information to be protected (e.g. confidential information); b) expected duration of an agreement, including cases where confidentiality might need to be maintained indefinitely; c) required actions when an agreement is terminated; d) responsibilities and actions of signatories to avoid unauthorized information disclosure; e) ownership of information, trade secrets and intellectual property, and how this relates to the protection of confidential information; f) the permitted use of confidential information and rights of the signatory to use information; g) the right to audit and monitor activities that involve confidential information; h) process for notification and reporting of unauthorized disclosure or confidential information leakage; i) terms for information to be returned or destroyed at agreement cessation; j) expected actions to be taken in case of a breach of the agreement. Based on an organization s information security requirements, other elements may be needed in a confidentiality or non-disclosure agreement. Confidentiality and non-disclosure agreements should comply with all applicable laws and regulations for the jurisdiction to which they apply (see 18.1). Requirements for confidentiality and non-disclosure agreements should be reviewed periodically and when changes occur that influence these requirements.

87 ISA99, WG02 85 ISA , D7E Other information Confidentiality and non-disclosure agreements protect organizational information and inform signatories of their responsibility to protect, use and disclose information in a responsible and authorized manner. There may be a need for an organization to use different forms of confidentiality or non-disclosure agreements in different circumstances. 14 System acquisition, development and maintenance 14.1 Security requirements of information systems Objective: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks Information security requirements analysis and specification The information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems. The security functions and capabilities of each new component of the IACS shall be defined up front, developed or achieved via procurement, and tested together with other components so that the entire system meets the desired security profile. Information security requirements should be identified using various methods such as deriving compliance requirements from policies and regulations, threat modelling, incident reviews, or use of vulnerability thresholds. Results of the identification should be documented and reviewed by all stakeholders. Information security requirements and controls should reflect the business value of the information involved (see 8.2) and the potential negative business impact which might result from lack of adequate security. Identification and management of information security requirements and associated processes should be integrated in early stages of information systems projects. Early consideration of information security requirements, e.g. at the design stage can lead to more effective and cost efficient solutions. Information security requirements should also consider: a) the level of confidence required towards the claimed identity of users, in order to derive user authentication requirements; b) access provisioning and authorization processes, for business users as well as for privileged or technical users; c) informing users and operators of their duties and responsibilities; d) the required protection needs of the assets involved, in particular regarding availability, confidentiality, integrity; e) requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements; f) requirements mandated by other security controls, e.g. interfaces to logging and monitoring or data leakage detection systems.

88 ISA , D7E5 86 ISA99, WG For applications that provide services over public networks or which implement transactions, the dedicated controls and should be considered. If products are acquired, a formal testing and acquisition process should be followed. Contracts with the supplier should address the identified security requirements. Where the security functionality in a proposed product does not satisfy the specified requirement, the risk introduced and associated controls should be reconsidered prior to purchasing the product. Available guidance for security configuration of the product aligned with the final software / service stack of that system should be evaluated and implemented. Criteria for accepting products should be defined e.g., in terms of their functionality, which will give assurance that the identified security requirements are met. Products should be evaluated against these criteria before acquisition. Additional functionality should be reviewed to ensure it does not introduce unacceptable additional risks. Other information ISO/IEC and ISO provide guidance on the use of risk management processes to identify controls to meet information security requirements Securing application services on public networks Information involved in application services passing over public networks should be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. Information security considerations for application services passing over public networks should include the following: a) the level of confidence each party requires in each other s claimed identity, e.g. through authentication; b) authorization processes associated with who may approve contents of, issue or sign key transactional documents; c) ensuring that communicating partners are fully informed of their authorizations for provision or use of the service; d) determining and meeting requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation of contracts, e.g. associated with tendering and contract processes; e) the level of trust required in the integrity of key documents; f) the protection requirements of any confidential information; g) the confidentiality and integrity of any order transactions, payment information, delivery address details and confirmation of receipts; h) the degree of verification appropriate to verify payment information supplied by a customer; i) selecting the most appropriate settlement form of payment to guard against fraud; j) the level of protection required to maintain the confidentiality and integrity of order information; k) avoidance of loss or duplication of transaction information; l) liability associated with any fraudulent transactions; m) insurance requirements.

89 ISA99, WG02 87 ISA , D7E Many of the above considerations can be addressed by the application of cryptographic controls (see 10), taking into account compliance with legal requirements (see 18, especially see for cryptography legislation). Application service arrangements between partners should be supported by a documented agreement which commits both parties to the agreed terms of services, including details of authorization (see b) above). Resilience requirements against attacks should be considered, which can include requirements for protecting the involved application servers or ensuring the availability of network interconnections required to deliver the service. Other information Applications accessible via public networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public. Therefore, detailed risk assessments and proper selection of controls are indispensable. s required often include cryptographic methods for authentication and securing data transfer. Application services can make use of secure authentication methods, e.g. using public key cryptography and digital signatures (see 10) to reduce the risks. Also, trusted third parties can be used, where such services are needed Protecting application services transactions Information involved in application service transactions should be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay. Information security considerations for application service transactions should include the following: a) the use of electronic signatures by each of the parties involved in the transaction; b) all aspects of the transaction, i.e. ensuring that: 1) user s secret authentication information of all parties are valid and verified; 2) the transaction remains confidential; 3) privacy associated with all parties involved is retained; c) communications path between all involved parties is encrypted; d) protocols used to communicate between all involved parties are secured; e) ensuring that the storage of the transaction details is located outside of any publicly accessible environment, e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on a storage medium directly accessible from the Internet; f) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate/signature management process. Other information The extent of the controls adopted needs to be commensurate with the level of the risk associated with each form of application service transaction. Transactions may need to comply with legal and regulatory requirements in the jurisdiction which the transaction is generated from, processed via, completed at or stored in.

90 ISA , D7E5 88 ISA99, WG Security in development and support processes Objective: To ensure that information security is designed and implemented within the development lifecycle of information systems Secure development policy Rules for the development of software and systems should be established and applied to developments within the organization. Secure development is a requirement to build up a secure service, architecture, software and system. Within a secure development policy, the following aspects should be put under consideration: a) security of the development environment; b) guidance on the security in the software development lifecycle: 1) security in the software development methodology; 2) secure coding guidelines for each programming language used; c) security requirements in the design phase; d) security checkpoints within the project milestones; e) secure repositories; f) security in the version control; g) required application security knowledge; h) developers' capability of avoiding, finding and fixing vulnerabilities. Secure programming techniques should be used both for new developments and in code reuse scenarios where the standards applied to development may not be known or were not consistent with current best practices. Secure coding standards should be considered and where relevant mandated for use. Developers should be trained in their use and testing and code review should verify their use. If development is outsourced, the organization should obtain assurance that the external party complies with these rules for secure development (see ). Other information Development may also take place inside applications, such as office applications, scripting, browsers and databases System change control procedures Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures. A change management system for the IACS environment shall be developed and implemented. The change management process shall follow separation of duty principles to avoid conflicts of interest. Formal change control procedures should be documented and enforced to ensure the integrity of system, applications and products, from the early design stages through all subsequent maintenance efforts. Introduction of new systems and major changes to existing systems should follow a formal process of documentation, specification, testing, quality control and managed implementation.

91 ISA99, WG02 89 ISA , D7E This process should include a risk assessment, analysis of the impacts of changes and specification of security controls needed. This process should also ensure that existing security and control procedures are not compromised, that support programmers are given access only to those parts of the system necessary for their work and that formal agreement and approval for any change is obtained. Wherever practicable, application and operational change control procedures should be integrated (see ). The change control procedures should include but not be limited to: a) maintaining a record of agreed authorization levels; b) ensuring changes are submitted by authorized users; c) reviewing controls and integrity procedures to ensure that they will not be compromised by the changes; d) identifying all software, information, database entities and hardware that require amendment; e) identifying and checking security critical code to minimize the likelihood of known security weaknesses; f) obtaining formal approval for detailed proposals before work commences; g) ensuring authorized users accept changes prior to implementation; h) ensuring that the system documentation set is updated on the completion of each change and that old documentation is archived or disposed of; i) maintaining a version control for all software updates; j) maintaining an audit trail of all change requests; k) ensuring that operating documentation (see ) and user procedures are changed as necessary to remain appropriate; l) ensuring that the implementation of changes takes place at the right time and does not disturb the business processes involved. m) ensuring that HSE and cyber security risks are assessed by indivudals technically knowledgeable about the industrial operations and the IACS; n) ensuring that the security requirements of a new system meet the security policies and procedures required for the existing zones, conduits and environment; and o) ensuring that maintenance upgrades or changes meet the security requriements for the zones, conduits and environment. Other information Changing software can impact the operational environment and vice versa. Good practice includes the testing of new software in an environment segregated from both the production and development environments (see ). This provides a means of having control over new software and allowing additional protection of operational information that is used for testing purposes. This should include patches, service packs and other updates. Where automatic updates are considered, the risk to the integrity and availability of the system should be weighed against the benefit of speedy deployment of updates. Automated updates should not be used on critical systems as some updates can cause critical applications to fail Technical review of applications after operating platform changes When operating platforms are changed (including upgrades, updates and patches) business critical applications should be reviewed and tested to ensure there are no adverse impacts on organizational operations or security.

92 ISA , D7E5 90 ISA99, WG This process should cover: a) review of application control and integrity procedures to ensure that they have not been compromised by the operating platform changes; b) ensuring that notification of operating platform changes is provided in time to allow appropriate tests and reviews to take place before implementation; c) ensuring that appropriate changes are made to the business continuity plans (see 17). Other information Operating platforms include operating systems, databases and middleware platforms. The control should also be applied for changes of applications Restrictions on changes to software packages Modifications to software packages should be discouraged, limited to necessary changes and all changes should be strictly controlled. As far as possible and practicable, vendor-supplied software packages should be used without modification. Where a software package needs to be modified the following points should be considered: a) the risk of built-in controls and integrity processes being compromised; b) whether the consent of the vendor should be obtained; c) the possibility of obtaining the required changes from the vendor as standard program updates; d) the impact if the organization becomes responsible for the future maintenance of the software as a result of changes; e) compatibility with other software in use. If changes are necessary the original software should be retained and the changes applied to a designated copy. A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software (see ). All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body Secure system engineering principles Principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation efforts. Secure information system engineering procedures based on security engineering principles should be established, documented and applied to in-house information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology) balancing the need for information security with the need for accessibility. New technology should be analyzed for security risks and the design should be reviewed against known attack patterns. These principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to-date in terms of combating

93 ISA99, WG02 91 ISA , D7E any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. The established security engineering principles should be applied, where applicable, to outsourced information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should confirm that the rigor of suppliers' security engineering principles is comparable with its own. Other information Application development procedures should apply secure engineering techniques in the development of applications that have input and output interfaces. Secure engineering techniques provide guidance on user authentication techniques, secure session control and data validation, sanitization and elimination of debugging codes Secure development environment Organizations should establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. A secure development environment includes people, processes and technology associated with system development and integration. Organizations should assess risks associated with individual system development efforts and establish secure development environments for specific system development efforts, considering: a) sensitivity of data to be processed, stored and transmitted by the system; b) applicable external and internal requirements, e.g. from regulations or policies; c) security controls already implemented by the organization that support system development; d) trustworthiness of personnel working in the environment (see 7.1.1); e) the degree of outsourcing associated with system development; f) the need for segregation between different development environments; g) control of access to the development environment; h) monitoring of change to the environment and code stored therein; i) backups are stored at secure offsite locations; j) control over movement of data from and to the environment. Once the level of protection is determined for a specific development environment, organizations should document corresponding processes in secure development procedures and provide these to all individuals who need them Outsourced development The organization should supervise and monitor the activity of outsourced system development. Where system development is outsourced, the following points should be considered across the organization s entire external supply chain: a) licensing arrangements, code ownership and intellectual property rights related to the outsourced content (see );

94 ISA , D7E5 92 ISA99, WG b) contractual requirements for secure design, coding and testing practices (see ); c) provision of the approved threat model to the external developer; d) acceptance testing for the quality and accuracy of the deliverables; e) provision of evidence that security thresholds were used to establish minimum acceptable levels of security and privacy quality; f) provision of evidence that sufficient testing has been applied to guard against the absence of both intentional and unintentional malicious content upon delivery; g) provision of evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities; h) escrow arrangements, e.g. if source code is no longer available; i) contractual right to audit development processes and controls; j) effective documentation of the build environment used to create deliverables; k) the organization remains responsible for compliance with applicable laws and control efficiency verification. Other information Further information on supplier relationships can be found in ISO/IEC System security testing Testing of security functionality should be carried out during development. New and updated systems require thorough testing and verification during the development processes, including the preparation of a detailed schedule of activities and test inputs and expected outputs under a range of conditions. As for in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken (both for inhouse and for outsourced developments) to ensure that the system works as expected and only as expected (see and ). The extent of testing should be in proportion to the importance and nature of the system System acceptance testing Acceptance testing programs and related criteria should be established for new information systems, upgrades and new versions. System acceptance testing should include testing of information security requirements (see and ) and adherence to secure system development practices (see ). The testing should also be conducted on received components and integrated systems. Organizations can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security-related defects. Testing should be performed in a realistic test environment to ensure that the system will not introduce vulnerabilities to the organization s environment and that the tests are reliable Test data Objective: To ensure the protection of data used for testing.

95 ISA99, WG02 93 ISA , D7E Protection of test data Test data should be selected carefully, protected and controlled. The use of operational data containing personally identifiable information or any other confidential information for testing purposes should be avoided. If personally identifiable information or otherwise confidential information is used for testing purposes, all sensitive details and content should be protected by removal or modification (see ISO/IEC 29101). The following guidelines should be applied to protect operational data, when used for testing purposes: a) the access control procedures, which apply to operational application systems, should also apply to test application systems; b) there should be separate authorization each time operational information is copied to a test environment; c) operational information should be erased from a test environment immediately after the testing is complete; d) the copying and use of operational information should be logged to provide an audit trail. Other information System and acceptance testing usually requires substantial volumes of test data that are as close as possible to operational data. 15 Supplier relationships 15.1 Information security in supplier relationships Objective: To ensure protection of the organization s assets that is accessible by suppliers Information security policy for supplier relationships Information security requirements for mitigating the risks associated with supplier s access to the organization s assets should be agreed with the supplier and documented. The organizations should identify and mandate information security controls to specifically address supplier access to the organization s information in a policy. These controls should address processes and procedures to be implemented by the organization, as well as those processes and procedures that the organization should require the supplier to implement, including: a) identifying and documenting the types of suppliers, e.g. IT services, logistics utilities, financial services, IT infrastructure components, whom the organization will allow to access its information; b) a standardized process and lifecycle for managing supplier relationships; c) defining the types of information access that different types of suppliers will be allowed, and monitoring and controlling the access; d) minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the organization s business needs and requirements and its risk profile;

96 ISA , D7E5 94 ISA99, WG e) processes and procedures for monitoring adherence to established information security requirements for each type of supplier and type of access, including third party review and product validation; f) accuracy and completeness controls to ensure the integrity of the information or information processing provided by either party; g) types of obligations applicable to suppliers to protect the organization s information; h) handling incidents and contingencies associated with supplier access including responsibilities of both the organization and suppliers; i) resilience and, if necessary, recovery and contingency arrangements to ensure the availability of the information or information processing provided by either party; j) awareness training for the organization s personnel involved in acquisitions regarding applicable policies, processes and procedures; k) awareness training for the organization s personnel interacting with supplier personnel regarding appropriate rules of engagement and behavior based on the type of supplier and the level of supplier access to the organization s systems and information; l) conditions under which information security requirements and controls will be documented in an agreement signed by both parties; m) managing the necessary transitions of information, information processing facilities and anything else that needs to be moved, and ensuring that information security is maintained throughout the transition period. Other information Information can be put at risk by suppliers with inadequate information security management. s should be identified and applied to administer supplier access to information processing facilities. For example, if there is a special need for confidentiality of the information, non-disclosure agreements can be used. Another example is data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization Addressing security within supplier agreements All relevant information security requirements should be established and agreed with each supplier that may access, process, store, communicate, or provide IT infrastructure components for, the organization s information. Supplier agreements should be established and documented to ensure that there is no misunderstanding between the organization and the supplier regarding both parties obligations to fulfil relevant information security requirements. The following terms should be considered for inclusion in the agreements in order to satisfy the identified information security requirements: a) description of the information to be provided/accessed and methods of providing/accessing the information; b) classification of information according to the organization's classification scheme (see 8.2); if necessary also mapping between the organization's own classification scheme and the classification scheme of the supplier; c) legal and regulatory requirements, including data protection, intellectual property rights and copyright, and a description of how it will be ensured that they are met;

97 ISA99, WG02 95 ISA , D7E d) obligation of each contractual party to implement an agreed set of controls including access control, performance review, monitoring, reporting and auditing; e) rule of acceptable use of information, including unacceptable use if necessary; f) either explicit list of supplier personnel authorized to access or receive the organization's information or procedures or conditions for authorization, and removal of the authorization, for access to or receipt of the organization's information by supplier personnel; g) information security policies relevant to the specific contract; h) incident management requirements and procedures (especially notification and collaboration during incident remediation); i) training and awareness requirements for specific procedures and information security requirements, e.g. for incident response, authorization procedures; j) relevant regulations for sub-contracting, including the controls that need to be implemented; k) relevant agreement partners, including a contact person for information security issues; l) screening requirements, if any, for supplier s personnel including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern; m) right to audit the supplier processes and controls related to the agreement; n) defect resolution and conflict resolution processes; o) supplier s obligation to periodically deliver an independent report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report; p) supplier s obligations to comply with the organization s security requirements. Other information The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant information security risks and requirements. Supplier agreements may also involve other parties (e.g., sub-suppliers). The procedures for continuing processing in the event that the supplier becomes unable to supply its products or services need to be considered in the agreement to avoid any delay in arranging replacement products or services Information and communication technology supply chain Agreements with suppliers should include requirements to address the information security risks associated with information and communications technology services and product supply chain. The following topics should be considered for inclusion in supplier agreements concerning supply chain security: a) defining information security requirements to apply to information and communication technology product or service acquisition in addition to the general information security requirements for supplier relationships; b) for information and communication technology services, requiring that suppliers propagate the organization s security requirements throughout the supply chain if suppliers subcontract for parts of information and communication technology service provided to the organization; c) for information and communication technology products, requiring that suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased from other suppliers;

98 ISA , D7E5 96 ISA99, WG d) implementing a monitoring process and acceptable methods for validating that delivered information and communication technology products and services are adhering to stated security requirements; e) implementing a process for identifying product or service components that are critical for maintaining functionality and therefore require increased attention and scrutiny when built outside of the organization especially if the top tier supplier outsources aspects of product or service components to other suppliers; f) obtaining assurance that critical components and their origin can be traced throughout the supply chain; g) obtaining assurance that the delivered information and communication technology products are functioning as expected without any unexpected or unwanted features; h) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers; i) implementing specific processes for managing information and communication technology component lifecycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Other information The specific information and communication technology supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. Organizations are advised to work with suppliers to understand the information and communication technology supply chain and any matters that have an important impact on the products and services being provided. Organizations can influence information and communication technology supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the information and communication technology supply chain. Information and communication technology supply chain as addressed here includes cloud computing services Supplier service delivery management Objective: To maintain an agreed level of information security and service delivery in line with supplier agreements Monitoring and review of supplier services Organizations should regularly monitor, review and audit supplier service delivery. Monitoring and review of supplier services should ensure that the information security terms and conditions of the agreements are being adhered to and that information security incidents and problems are managed properly. This should involve a service management relationship process between the organization and the supplier to: a) monitor service performance levels to verify adherence to the agreements; b) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements;

99 ISA99, WG02 97 ISA , D7E c) conduct audits of suppliers, in conjunction with review of independent auditor s reports, if available, and follow-up on issues identified; d) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures; e) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered; f) resolve and manage any identified problems; g) review information security aspects of the supplier s relationships with its own suppliers; h) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see 17). The responsibility for managing supplier relationships should be assigned to a designated individual or service management team. In addition, the organization should ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate action should be taken when deficiencies in the service delivery are observed. The organization should retain sufficient overall control and visibility into all security aspects for sensitive or critical information or information processing facilities accessed, processed or managed by a supplier. The organization should retain visibility into security activities such as change management, identification of vulnerabilities and information security incident reporting and response through a defined reporting process Managing changes to supplier services Changes to the provision of services by suppliers, including maintaining and improving existing information security policies, procedures and controls, should be managed, taking account of the criticality of business information, systems and processes involved and re-assessment of risks. The following aspects should be taken into consideration: a) changes to supplier agreements; b) changes made by the organization to implement: 1) enhancements to the current services offered; 2) development of any new applications and systems; 3) modifications or updates of the organization s policies and procedures; 4) new or changed controls to resolve information security incidents and to improve security;. c) changes in supplier services to implement: 1) changes and enhancement to networks; 2) use of new technologies; 3) adoption of new products or newer versions/releases; 4) new development tools and environments; 5) changes to physical location of service facilities; 6) change of suppliers;

100 ISA , D7E5 98 ISA99, WG ) sub-contracting to another supplier. 16 Information security incident management 16.1 Management of information security incidents and improvement Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses of the IACS Responsibilities and procedures Management responsibilities and procedures shall be established to ensure a quick, effective and orderly response to information security incidents in accordance with the established procedures. A methodology should be in place to address issues discovered and to ensure they are corrected The organization shall develop, disseminate, and periodically review/update: (i) a formal, documented, incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the incident response polic y and associated incident response controls. The organization shall provide an incident response support resource that offers advice and assistance to users of the IACS for the handling and reporting of security incidents. The support resource is an integral part of the organization s incident response capability. (1) The organization employs automated mechanisms to increase the availability of incident response-related information and support. The following guidelines for management responsibilities and procedures with regard to information security incident management should be considered: a) management responsibilities should be established to ensure that the following procedures are developed and communicated adequately within the organization: 1) procedures for incident response planning and preparation; 2) procedures for monitoring, detecting, analyzing and reporting of information security events and incidents; 3) procedures for logging incident management activities; 4) procedures for handling of forensic evidence; 5) procedures for assessment of and decision on information security events and assessment of information security weaknesses; 6) procedures for response including those for escalation, controlled recovery from an incident and communication to internal and external relevant people or organizations, testing the incident response procedure, and training for all appropriate parties. b) procedures established should ensure that: 1) competent personnel handle the issues related to information security incidents within the organization; 2) a point of contact for security incidents detection and reporting is implemented; 3) appropriate contacts with authorities, external interest groups or forums that handle the issues related to information security incidents are maintained;

101 ISA99, WG02 99 ISA , D7E c) reporting procedures should include the details of an identified incident are documented to record the incident, the response, the lessons learned, and any actions taken to modify the IACS in light of this incident and detail the following: 1) preparing information security event reporting forms to support the reporting action and to help the person reporting to remember all necessary actions in case of an information security event; 2) the procedure to be undertaken in case of an information security event, e.g. noting all details (e.g. type of non-compliance or breach, occurring malfunction, messages on the screen, strange behavior) immediately; and not carrying out any action alone, but immediately reporting to the point of contact and taking only coordinated actions; 3) reference to an established formal disciplinary process for dealing with employees who commit security breaches; 4) suitable feedback processes to ensure that those persons reporting information security events are notified of results after the issue has been dealt with and closed. 5) documented details of an incident to be communicated to all appropriate organizations (such as management, IT, process safety, automation and control, engineering, security, and manufacturing) in a timely manner. 6) the report shall be prepared as soon as possible after the incident to ensure that no information is lost. As more information becomes available after an incident, the report may be added to or modified accordingly. d) Actions to recover from security breaches and correct system failures should be car efully and formally controlled. The procedures should ensure that: 1) only clearly identified and authorized personnel are allowed access to live systems and data (see also 6.2 for external access); 2) all emergency actions taken are documented in detail; 3) emergency actions are reported to management and reviewed in an orderly manner; 4) the integrity of the IACS and the business systems and controls are confirmed with minimal delay The objectives for information security incident management should be agreed with management, and it should be ensured that those responsible for information security incident management understand the organization s priorities for handling information security incidents. The incident response policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The incident response policy can be included as part of the general information security policy for the organization. Incident response procedures can be developed for the security program in general, and for a particular IACS, when required. Possible implementations of incident response support resources in an organization include a help desk or an assistance group and access to forensics services, when required. Other information Information security incidents might transcend organizational and national boundaries. To respond to such incidents there is an increasing need to coordinate response and share information about these incidents with external organizations as appropriate. Detailed guidance on information security incident management is provided in ISO/IEC

102 ISA , D7E5 100 ISA99, WG Reporting information security events Information security events shall be reported through appropriate management channels as quickly as possible. The organization shall promptly reports incident information to appropriate authorities. (1) The organization employs automated mechanisms to assist in the reporting of security incidents. All employees and contractors should be made aware of their responsibility to report information security events as quickly as possible. They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported. Situations to be considered for information security event reporting include: a) ineffective security control; b) breach of information integrity, confidentiality or availability expectations; c) human errors; d) non-compliances with policies or guidelines; e) breaches of physical security arrangements; f) uncontrolled system changes; g) system overloads or malfunctions of software or hardware; h) access violations. i) Loss of service, equipment or facilities j) detection of malware on the system k) social engineering attempts The types of incident information reported, the content and timeliness of the reports, and the list of designated reporting authorities or organizations are consistent with applicable laws, directives, policies, regulations, standards, and guidance. Most countries maintain a Computer Emergency Readiness Team (CERT). One example is the United States CERT (US-CERT), which maintains the IACS Security Center at In addition to incident information, weaknesses and vulnerabilities in the IACS are reported to appropriate organizational officials in a timely manner to prevent security incidents. Other information Malfunctions or other anomalous system behavior may be an indicator of a security attack or actual security breach and should therefore always be reported as an information security event Reporting information security weaknesses Employees and contractors using the organization s information systems and services should be required to note and report any observed or suspected information security weaknesses in systems or services. All employees and contractors should report these matters to the point of contact as quickly as possible in order to prevent information security incidents. The reporting mechanism should be as easy, accessible and available as possible.

103 ISA99, WG ISA , D7E Other information Employees and contractors should be advised not to attempt to prove suspected security weaknesses. Testing weaknesses might be interpreted as a potential misuse of the system and could also cause damage to the information system or service and result in legal liability for the individual performing the testing Assessment of and decision on information security events Information security events should be assessed and it should be decided if they are to be classified as information security incidents. The point of contact should assess each information security event using the agreed information security event and incident classification scale and decide whether the event should be classified as an information security incident. Classification and prioritization of incidents can help to identify the impact and extent of an incident. In cases where the organization has an information security incident response team (ISIRT), the assessment and decision can be forwarded to the ISIRT for confirmation or reassessment. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification Response to information security incidents Information security incidents shall be responded to in accordance with the documented procedures. The information security incident response procedure shall include training of personnel in their incident response roles and responsibilities with respect to the IACS and provide refresher training; testing of the incident response capability for the IACS; incident handling; incident reporting; and incident response assistance. The organization shall implement an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery. (1) The organization employs automated mechanisms to support the incident handling process. The organization shall track and document IACS security incidents on an ongoing basis. (1) The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information. Information security incidents should be responded to by a nominated point of contact and other relevant persons of the organization or external parties (see ). The organization should implement an incident response plan that identifies responsible personnel and defined actions to be performed by designated individuals. Responsibilities and procedures should be in place to handle cyber security events and weaknesses effectively once they have been reported. A process of continual improvement should be applied to the response for testing, monitoring, evaluating, overall management of security incidents, and IACS Monitoring Tools and Techniques. The organization shall test and/or exercise the incident response capability for the IACS. The following should be considered in the development of the Information Security response planning.:

104 ISA , D7E5 102 ISA99, WG a) The organization incorporates simulated events into incident response training to facilitate effective response by personnel in crisis situations. b) The organization employs automated mechanisms to provide a more thorough and realistic training environment. c) The organization employs automated mechanisms to more thoroughly and effectively test/exercise the incident response capability. d) Incident-related information can be obtained from a variety of sources including, but not limited to, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. The organization incorporates the lessons learned from ongoing incident handling activities into the incident response procedures and implements the procedures accordingly. e) The types of incident information reported, the content and timeliness of the reports, an d the list of designated reporting authorities or organizations are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The United States Computer Emergency Readiness Team (US-CERT) maintains the IACS Security Center at In addition to incident information, weaknesses and vulnerabilities in the IACS are reported to appropriate organizational officials in a timely manner to prevent security incidents. f) Possible implementations of incident response support resources in an organization include a help desk or an assistance group and access to forensics services, when required. g) The organization interconnects and configures individual intrusion detection tools into a system wide intrusion detection system using common protocols. However, organizations consult appropriate legal counsel with regard to all IACS monitoring activities. Organizations heighten the level of IACS monitoring activity whenever there is an indication of increased risk to organizational operations, organizational assets, or individuals based on law enforcement information, intelligence information, or other credible sources of information. The response should include the following: a) collecting evidence as soon as possible after the occurrence; b) conducting information security forensics analysis, as required (see ); c) escalation, as required; d) ensuring that all involved response activities are properly logged for later analysis; e) communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know; f) dealing with information security weakness(es) found to cause or contribute to the incident; g) once the incident has been successfully dealt with, formally closing and recording it. Post-incident analysis should take place, as necessary, to identify the source of the incident. Incident-related information can be obtained from a variety of sources including, but not limited to, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. The organization incorporates the lessons learned from ongoing incident handling activities into the incident response procedures and implements the procedures accordingly. Other information The first goal of incident response is to resume normal security level and then initiate the necessary recovery.

105 ISA99, WG ISA , D7E Learning from information security incidents Knowledge gained from analyzing and resolving information security incidents should be used to reduce the likelihood or impact of future incidents. There should be mechanisms in place to enable the types, volumes and costs of information security incidents to be quantified and monitored. The information gained from the evaluation of information security incidents should be used to identify recurring or high impact incidents. Other information The evaluation of information security incidents may indicate the need for enhanced or additional controls to limit the frequency, damage and cost of future occurrences, or to be taken into account in the security policy review process (see 5.1.2). With due care of confidentiality aspects, anecdotes from actual information security incidents can be used in user awareness training (see 7.2.2) as examples of what could happen, how to respond to such incidents and how to avoid them in the future Collection of evidence The organization shall define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve as evidence. Internal procedures should be developed and followed when dealing with evidence for the purposes of disciplinary and legal action. In general, these procedures for evidence should provide processes of identification, collection, acquisition and preservation of evidence in accordance with different types of media, devices and status of devices, e.g., powered on or off. The procedures should take account of: a) chain of custody; b) safety of evidence; c) safety of personnel; d) roles and responsibilities of personnel involved; e) competency of personnel; f) documentation; g) briefing. Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. Forensic evidence may transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as forensic evidence. The requirements of different jurisdictions should also be considered to maximize chances of admission across the relevant jurisdictions. Other information Identification is the process involving the search for, recognition and documentation of potential evidence. Collection is the process of gathering the physical items that can contain potential evidence.

106 ISA , D7E5 104 ISA99, WG Acquisition is the process of creating a copy of data within a defined set. Preservation is the process to maintain and safeguard the integrity and original condition of the potential evidence. When an information security event is first detected, it may not be obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve a lawyer or the police early in any contemplated legal action and take advice on the evidence required. ISO/IEC provides guidelines for identification, collection, acquisition and preservation of digital evidence. 17 Information security aspects of business continuity management 17.1 Information security continuity Objective: Information security continuity should be embedded in the organization s business continuity management systems Planning information security continuity The organization should determine its requirements for information security and the continuity of information security management in adverse situations, e.g. during a crisis or disaster. An organization should determine whether the continuity of information security is captured within the business continuity management process or within the disaster recovery management process. Information security requirements should be determined when planning for business continuity and disaster recovery. In the absence of formal business continuity and disaster recovery planning, information security management should assume that information security requirements remain the same in adverse situations, compared to normal operational conditions. Alternatively, an organization could perform a business impact analysis for information security aspects to determine the information security requirements applicable to adverse situations. Other information In order to reduce the time and effort of an additional business impact analysis for information security, it is recommended to capture information security aspects within the normal business continuity management or disaster recovery management business impact analysis. This implies that the information security continuity requirements are explicitly formulated in the business continuity management or disaster recovery management processes. Information on business continuity management can be found in ISO/IEC 27031, ISO/IEC and ISO/IEC Implementing information security continuity The organization should establish, document, implement and maintain processes, procedures controls, and contingency plans to ensure the required level of continuity for information security during an adverse situation and ensure availability of the IACS for business processes are at the required level and in the required time scales following interruption to, or failure of, critical business processes. The organization shall develop and implement a contingency plan for the IACS addressing contingency roles, responsibilities, assigned individuals with contact information, and activities associated with restoring the system after a disruption or failure. Designated officials

107 ISA99, WG ISA , D7E within the organization review and approve the contingency plan and distribute copies of the plan to key contingency personnel. The contingency plan shall include training, testing, and updates to the contingency plan as required by the organization. In order to assure business continuity, the organization shall identify an alte rnate storage site and implement the necessary agreements as required by the organization and all contractual parties to permit the storage of IACS backup information. The organization shall develop and implement a contingency plan for the IACS addressing contingency roles, responsibilities, assigned individuals with contact information, and activities associated with restoring the system after a disruption or failure. Designated officials within the organization review and approve the contingency plan and distribute copies of the plan to key contingency personnel. (1) The organization coordinates contingency plan development with organizational elements responsible for related plans. Foundational Requirement: Rationale/Supplemental Guidance: Examples of related plans include Business Continuity Plan, Disaster Recovery Plan, Continuity of Operations Plan, Business Recovery Plan, Incident Response Plan, and Emergency Action Plan. (2) The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during crisis situations. (1) The organization shall include a full recovery and reconstitution of the IACS as part of contingency plan testing. An organization should ensure that: a) an adequate management structure is in place to prepare for, mitigate and respond to a disruptive event using personnel with the necessary authority, experience and competence; b) incident response personnel with the necessary responsibility, authority and competence to manage an incident and maintain information security are nominated; c) documented plans, response and recovery procedures are developed and approved, detailing how the organization will manage a disruptive event and will maintain its information security to a predetermined level and determine the priority of critical business and IACS in order to reestablish operationsbased on management-approved information security continuity objectives (see ). According to the information security continuity requirements, the organization should establish, document, implement and maintain: a) information security controls within business continuity or disaster recovery processes, procedures and supporting systems and tools; b) processes, procedures and implementation changes to maintain existing information security controls during an adverse situation; c) compensating controls for information security controls that cannot be maintained during an adverse situation. In the event of a significant disruption, the organization should determine the priority of critical business and IACS to re-establish operations.

108 ISA , D7E5 106 ISA99, WG Other information Within the context of business continuity or disaster recovery, specific processes and procedures may have been defined. Information that is handled within these processes and procedures or within dedicated information systems to support them should be protected. Therefore an organization should involve information security specialists when establishing, implementing and maintaining business continuity or disaster recovery processes and procedures. Information security controls that have been implemented should continue to operate during an adverse situation. If security controls are not able to continue to secure information, other controls should be established, implemented and maintained to maintain an acceptable level of information security. The contingency planning policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The contingency planning policy can be included as part of the general information security policy for the organization. Contingency planning procedures can be developed for the security program in general, and for a particular IACS, when required. The organization defines contingency plans for categories of disruptions or failures. In the event of a loss of processing within the IACS or communication with operational facilities, the IACS 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). These examples are not exhaustive. IACS recovery and reconstitution to a known secure state means that all system parameters (either default or organization-established) are set to secure values, security-critical patches are reinstalled, security-related configuration settings are reestablished, system documentation and operating procedures are available, application and system software is reinstalled and configured with secure settings, information from the most recent, known secure backups is loaded, and the system is fully tested and functional Verify, review and evaluate information security continuity The organization should verify the established and implemented information security continuity controls at regular intervals in order to ensure that they are valid and effective during adverse situations. The organization shall: (i) test and/or exercise the contingency plan for the IACS [Assignment: organization-defined frequency, at least annually] using [Assignment: organization-defined tests and/or exercises] to determine the plan s effectiveness and the organization s readiness to execute the plan; and (ii) review the contingency plan test/exercise results and initiates corrective actions. (1) The organization coordinates contingency plan testing and/or exercises with organizational elements responsible for related plans. (2) The organization tests/exercises the contingency plan at the alternate processing site to familiarize contingency personnel with the facility and available resources and to evaluate the site s capabilities to support contingency operations. (3) The organization employs automated mechanisms to more thoroughly and effectively test/exercise the contingency plan by providing more complete coverage of contingency issues, selecting more realistic test/exercise scenarios and environments, and more effectively stressing the IACS and supported missions. The organization shall review the contingency plan for the IACS [Assignment: organization -defined frequency, at least annually] and revises the plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing.

109 ISA99, WG ISA , D7E Organizational, technical, procedural and process changes, whether in an operational or continuity context, can lead to changes in information security continuity requirements. In such cases, the continuity of processes, procedures and controls for information security should be reviewed against these changed requirements. Organizations should verify their information security management continuity by: a) exercising and testing the functionality of information security continuity processes, procedures and controls to ensure that they are consistent with the information security continuity objectives; b) exercising and testing the knowledge and routine to operate information security continuity processes, procedures and controls to ensure that their performance is consistent with the information security continuity objectives; c) reviewing the validity and effectiveness of information security continuity measures when information systems, information security processes, procedures and controls or business continuity management/disaster recovery management processes and solutions change. There are several methods for testing and/or exercising contingency plans to identify potential weaknesses (e.g., full-scale contingency plan testing, functional/tabletop exercises). The depth and rigor of contingency plan testing and/or exercises increases with the S target system level of the IACS. Contingency plan testing and/or exercises also include a determination of the effects on organizational operations and assets (e.g., reduction in mission capability) and individuals arising due to contingency operations in accordance with the plan. Organizational changes include changes in mission, functions, or business processes supported by the IACS. The organization communicates changes to appropriate organizational elements responsible for related plans (e.g., Business Continuity Plan, Disaster Recovery Plan, Continuity of Operations Plan, Business Recovery Plan, Incident Response Plan, Emergency Action Plan). Other information The verification of information security continuity controls is different from general information security testing and verification and should be performed outside the testing of changes. If possible, it is preferable to integrate verification of information security continuity controls with the organization s business continuity or disaster recovery tests. Examples of related plans include Business Continuity Plan, Disaster Recovery Plan, Continuity of Operations Plan, Business Recovery Plan, Incident Response Plan, and Emergency Action Plan Redundancies and Availability Objective: To ensure availability of information processing facilities and the IACS Availability of information processing facilities and the IACS Information processing facilities and the IACS shall be implemented with redundancy and proper safety systems and equipment sufficient to meet availability requirements required by the organization for business continuity. In order to assure information processing facilities and the IACS have sufficient availability and meet the organization s safety objectives emergency lighting shall be properly implemented that activates in the event of a power outage or disruption and that covers emergency exits and evacuation. Additionally, the organization shall employ and maintain fire suppression and detection devices/systems that can be activated in the event of a fire.

110 ISA , D7E5 108 ISA99, WG In order to assure IACS availability, the IACS shall include the following within its software and/or hardware configuration: a) Assure software backup and an alternate site for the IACS per the organization s needs; b) Adequate power to the IACS c) Proper networking and network redundancy for the IACS and the organization; d) Emergency shutoff for all IACS components that assures safe shutdown e) Emergency short-term uninterruptible power supply to facilitate an orderly shutdown of the IACS in the event of a primary power source loss; f) Maintain, within acceptable levels, and monitor the required environmental requirements and water damage possibilities within the facility where the IACS resides. The organization shall identify an alternate control site and initiates necessary agreements to permit the resumption of IACS operations for critical mission/business functions within [Assignment: organization-defined time period] when the primary processing capabilities are unavailable. (1) The organization identifies an alternate processing site that is geographically separated from the primary processing site so as not to be susceptible to the same hazards. (2) The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions. (3) The organization develops alternate processing site agreements that contain priority-ofservice provisions in accordance with the organization s availability requirements. (4) The organization fully configures the alternate processing site so that it is ready to be used as the operational site supporting a minimum required operational capability. Organizations should identify business requirements for the availability of information systems. Where the availability cannot be guaranteed using the existing systems architecture, redundant components or architectures should be considered. Where applicable, redundant information systems and IACS should be tested to ensure the failover from one component to another component works as intended. Equipment and supplies required to resume operations within the organization-defined time period are either available at the alternate site or contracts are in place to support delivery to the site. Timeframes to resume IACS operations are consistent with organization-established recovery time objectives. Other information The implementation of redundancies can introduce risks to the integrity or confidentiality of information and information systems, which need to be considered when designing information systems. 18 Compliance 18.1 Compliance with legal and contractual requirements Objective: To avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements.

111 ISA99, WG ISA , D7E Identification of applicable legislation and contractual requirements All relevant legislative statutory, regulatory, contractual requirements and the organization s approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and the organization. The specific controls and individual responsibilities to meet these requirements should also be defined and documented. Managers should identify all legislation applicable to their organization in order to meet the requirements for their type of business. If the organization conducts business in other countries, managers should consider compliance in all relevant countries Intellectual property rights Appropriate procedures should be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products. The following guidelines should be considered to protect any material that may be considered intellectual property: a) publishing an intellectual property rights compliance policy which defines the legal use of the IACS; b) acquiring software only through known and reputable sources, to ensure that copyright is not violated; c) maintaining awareness of policies to protect intellectual property rights and giving notice of the intent to take disciplinary action against personnel breaching them; d) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights; e) maintaining proof and evidence of ownership of licenses, master disks, manuals, etc.; f) implementing controls to ensure that any maximum number of users permitted within the license is not exceeded; g) carrying out reviews that only authorized software and licensed products are installed; h) providing a policy for maintaining appropriate license conditions; i) providing a policy for disposing of or transferring software to others; j) complying with terms and conditions for software and information obtained from public networks; k) not duplicating, converting to another format or extracting from commercial recordings (film, audio) other than permitted by copyright law; l) not copying in full or in part, books, articles, reports or other documents, other than permitted by copyright law. Other information Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licenses.

112 ISA , D7E5 110 ISA99, WG Proprietary software products are usually supplied under a license agreement that specifies license terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. The importance and awareness of intellectual property rights should be communicated to staff for software developed by the organization. Legislative, regulatory and contractual requirements may place restrictions on the copying of proprietary material. In particular, they may require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which may involve fines and criminal proceedings Protection of records Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release, in accordance with legilated, regulatory, contractual and business requirements. When deciding upon protection of specific organizational records, their corresponding classification based on the organization s classification scheme, should be considered. I A C S r ecords o r c l a s s i f i e d i n f o r m a t i o n should be categorized into record types, e.g. critical and/or classified records,accounting records, database records, transaction logs, audit logs and operational procedures, each with details of retention periods and type of allowable storage media, e.g. paper, microfiche, magnetic, optical. Any related cryptographic keys and programs associated with encrypted archives or digital signatures (see 10), should also be stored to enable decryption of the records for the length of time the records are retained. Consideration should be given to the possibility of deterioration of media used for storage of records. Storage and handling procedures should be implemented in accordance with manufacturer s recommendations. Where electronic storage media are chosen, procedures to ensure the ability to access data (both media and format readability) throughout the retention period should be established to safeguard against loss due to future technology change. Data storage systems should be chosen such that required data can be retrieved in an acceptable timeframe and format, depending on the requirements to be fulfilled. The system of storage and handling should ensure identification of records and of their retention period as defined by national or regional legislation or regulations, if applicable. This system should permit appropriate destruction of records after that period if they are not needed by the organization. To meet these record safeguarding objectives, the following steps should be taken within an organization: a) guidelines should be issued on the retention, storage, handling and disposal of records and information; b) a retention schedule should be drawn up based on the type of record and/or information and the period of time for which they should be retained; c) an inventory of these records and/or information should be maintained. Other information Some records may need to be securely retained to meet statutory, regulatory or contractual requirements, as well as to support essential business activities. Examples include records that may be required as evidence that an organization operates within statutory or regulatory rules, to ensure defense against potential civil or criminal action or to confirm the financial status of an organization

113 ISA99, WG ISA , D7E to shareholders, external parties and auditors. National law or regulation may set the time period and data content for information retention. Further information about managing organizational records can be found in ISO Privacy and protection of personally identifiable information Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation where applicable. An organization s data policy for privacy and protection of personally identifiable information should be developed and implemented. This policy should be communicated to all persons involved in the processing of personally identifiable information. Compliance with this policy and all relevant legislation and regulations concerning the protection of the privacy of people and the protection of personally identifiable information requires appropriate management structure and control. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to managers, users and service providers on their individual responsibilities and the specific procedures that should be followed. Responsibility for handling personally identifiable information and ensuring awareness of the privacy principles should be dealt with in accordance with relevant legislation and regulations. Appropriate technical and organizational measures to protect personally identifiable information should be implemented. Other information ISO/IEC provides a high-level framework for the protection of personally identifiable information within information and communication technology systems. A number of countries have introduced legislation placing controls on the collection, processing and transmission of personally identifiable information (generally information on living individuals who can be identified from that information). Depending on the respective national legislation, such controls may impose duties on those collecting, processing and disseminating personally identifiable information, and may also restrict the ability to transfer personally identifiable information to other countries Regulation of cryptographic controls Cryptographic controls should be used in compliance with all relevant agreements, legislation and regulations. The following items should be considered for compliance with the relevant agreements, laws and regulations: a) restrictions on import or export of computer hardware and software for performing cryptographic functions; b) restrictions on import or export of computer hardware and software which is designed to have cryptographic functions added to it; c) restrictions on the usage of encryption; d) mandatory or discretionary methods of access by the countries authorities to information encrypted by hardware or software to provide confidentiality of content.

114 ISA , D7E5 112 ISA99, WG Legal advice should be sought to ensure compliance with relevant legislation and regulations. Before encrypted information or cryptographic controls are moved across jurisdictional borders, legal advice should also be taken Information security review Objective: To ensure that information security is implemented and operated in accordance with the organizational policies and procedures Independent review of information security The organization s approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes and procedures for information security) should be reviewed independently at planned intervals or when significant changes occur. The organization shall develop, disseminate, and periodically reviews/updates: (i) a formal, documented, audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. The organization shall regularly review/analyze IACS audit records for indications of inappropriate or unusual activity, investigates suspicious activity or suspected violations, reports findings to appropriate officials, and takes necessary actions. (1) The organization employs automated mechanisms to integrate audit monitoring, analysis, and reporting into an overall process for investigation and response to suspicious activities. (2) The organization employs automated mechanisms to alert security personnel of the following inappropriate or unusual activities with security implications: [Assignment: organization-defined list of inappropriate or unusual activities that are to result in alerts]. The organization shall retain audit records for [Assignment: organization-defined time period] to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements. Management should initiate the independent review. Such an independent review is necessary to ensure the continuing suitability, adequacy and effectiveness of the organization's approach to managing information security. The review should include assessing opportunities for improvement and the need for changes to the approach to security, including the policy and control objectives. Such a review should be carried out by individuals independent of the area under review, e.g. the internal audit function, an independent manager or an external party organization specializing in such reviews. Individuals carrying out these reviews should have the appropriate skills and experience. The results of the independent review should be recorded and reported to the management who initiated the review. These records should be maintained. If the independent review identifies that the organization s approach and implementation to managing information security is inadequate, e.g. documented objectives and requirements are not met or not compliant with the direction for information security stated in the information security policies (see 5.1.1), management should consider corrective actions. The audit and accountability policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The audit and accountability policy can be included

115 ISA99, WG ISA , D7E as part of the general information security policy for the organization. Audit and accountability procedures can be developed for the security program in general, and for a particular IACS, when required. The parameters to be monitored are a local matter. Of those parameters it is strongly recommended to consider false-positives (e.g. how many times did an authorized entity get hindered or prevented from performing its function). Organizations increase the level of audit monitoring and analysis activity within the IACS whenever there is an indication of increased risk to organizational operations, organizational assets, or individuals based on law enforcement information, intelligence information, or other credible sources of information. The organization retains audit records until it is determined that they are no longer needed for administrative, legal, audit, or other operational purposes. Other information ISO/IEC 27007, "Guidelines for information security management systems auditing" and ISO/IEC TR 27008, "Guidelines for auditors on information security controls" also provide guidance for carrying out the independent review Compliance with security policies and standards Managers should regularly review the compliance of information processing and procedures within their area of responsibility with the appropriate security policies, standards and any other security requirements. The organization periodically reviews and updates the list of organization-defined auditable events. Managers shall identify how to review that information security requirements defined in policies, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review. If any non-compliance is found as a result of the review, managers should: a) identify the causes of the non-compliance; b) evaluate the need for actions to achieve compliance; c) implement appropriate corrective action; d) review the corrective action taken to verify its effectiveness and identify any deficiencies or weaknesses. Results of reviews and corrective actions carried out by managers should be recorded and these records should be maintained. Managers should report the results to the persons carrying out independent reviews (see ) when an independent review takes place in the area of their responsibility. The purpose of this requirement is to identify important events which need to be audited as significant and relevant to the security of the IACS. The security audit function is usually coordinated with the network health and status monitoring function which may be in a different zone. Commonly recognized and accepted checklists and configuration guides should be considered when compiling a list of auditable events. The organization defines auditable events that are adequate to support after-the-fact investigations of security incidents. Other information Operational monitoring of system use is covered in 12.4.

116 ISA , D7E5 114 ISA99, WG Technical compliance review Information systems should be regularly reviewed for compliance with the organization s information security policies and standards. Technical compliance should be reviewed preferably with the assistance of automated tools, which generate technical reports for subsequent interpretation by a technical specialist. Alternatively, manual reviews (supported by appropriate software tools, if necessary) by an experienced system engineer could be performed. If penetration tests or vulnerability assessments are used, caution should be exercised as such activities could lead to a compromise of the security of the system. Such tests should be planned, documented and repeatable. Any technical compliance review should only be carried out by competent, authorized persons or under the supervision of such persons. Other information Technical compliance reviews involve the examination of operational systems to ensure that hardware and software controls have been correctly implemented. This type of compliance review requires specialist technical expertise. Compliance reviews also cover, for example, penetration testing and vulnerability assessments, which might be carried out by independent experts specifically contracted for this purpose. This can be useful in detecting vulnerabilities in the system and for inspecting how effective the controls are in preventing unauthorized access due to these vulnerabilities. Penetration testing and vulnerability assessments provide a snapshot of a system in a specific state at a specific time. The snapshot is limited to those portions of the system actually tested during the penetration attempt(s). Penetration testing and vulnerability assessments are not a substitute for risk assessment. ISO/IEC TR provides specific guidance regarding technical compliance reviews.

117 ISA99, WG ISA , D7E Annex A (informative) Information related to applying ISO/IEC 27001:2013 in the IACS environment NOTE This annex provides information that will help the reader understand how they can apply the ISO/IEC 27001:2013 standard in their IACS environment :2013 is intentionally vague in places to allow for a generic management system to be applied in a multitude of different areas. This section provides guidance on what additional material may be needed in order to properly apply and meet the letter and the spirit of what appears in the requirements

118 ISA , D7E5 116 ISA99, WG Annex B (normative) Industrial automation and control systems extended control set NOTE This annex provides definitions for new objectives, new controls and new implementation guidance, as an industrial automation and control systems extended control set. ISO/IEC control objectives related to the new controls are repeated without any modifications. It is recommended that any organization implementing these controls in the context of an IACS-SMS which is intended to be conformant to ISO/IEC extend their SOA by the inclusion of the controls stated in this annex. B.1 Document Requirements Periodic reviews of compliance to the information and document management policy should be performed. (ISA Audit the information and document management process) B.2 of documents Information that requires special control or handling should be reviewed on a periodic basis to validate that special handling is still required. Periodic reviews of compliance to the information and document management policy should be performed. Additionally, appropriate measures should be employed to ensure long-term records can be retrieved (that is, converting the data to a newer format or retaining older equipment that can read the data). B.3 Internal IACS-SMS audits The required competency for auditing the specific systems that are in scope should be specified. The level of independence required should be determined as part of the governance. ISA Ensure auditors competence MMA B.4 System and Information Integrity Policy and Procedures The organization shall develop, disseminate, and periodically reviews/updates: (i) a formal, documented, system and information integrity policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the system and information integrity policy and associated system and information integrity requirements. Implementation Guidance The system and information integrity policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The system and information integrity policy can be included as part of the general information security policy for the organization. System and information integrity procedures can be developed for the security program in general, and for a particular IACS, when required.

119 ISA99, WG ISA , D7E B.5 Centralized management of technical vulnerabilities (Relates to 12.6 Technical Vulnerability Management) The organization should centrally manage information about technical vulnerabilities and the process to remediate those vulnerabilities. Implementation Guidance By centrally managing information about technical vulnerabilities in system components, common remediation techniques can be employed throughout an organization. After assessing the risk to the system from the fix, the organization can promptly install newly released security relevant patches, service packs, and hot fixes. These fixes should be managed from a centralized server that can be accessed in a secure way throughout the IACS. For some systems, it may be better to have IACS components pull their updates from the centralized server. For other systems, it may be better to push the updates to the IACS components. Either of these methods can be used either periodically or on demand. The flaw remediation process should be consistent with any appropriate certification, safety and regulatory testing requirements. B.6 Remote Access (Relates to 6.2 Mobile devices and teleworking) The organization shall authorize all methods of remote access to the IACS. The organization should control all remote access to the IACS through a limited number of conduits. Implementation Guidance Remote access is access to an IACS by any user (human, software process or device) communicating from outside the perimeter of the zone being addressed. Examples of remote access methods include dial-up, broadband, and wireless. Remote access to IACS zones and components should only be enabled when approved by the organization. Also, the organization should only permit remote access to privileged functions for compelling operational needs. These rationale for remote access to these functions and operational needs should be documented and reviewed regularly. B.7 Mobile Code The organization shall produce implementation guidance regarding the use of mobile code technologies based on the potential to cause damage to the IACS. Implementation Guidance Mobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. procedures prevent the development, acquisition, or introduction of unacceptable mobile code within the IACS. For example, mobile code exchanges might be disallowed directly with the IACS, but rather in a controlled adjacent information environment maintained by IACS personnel. B.8 Access for Display Medium The organization shall control physical access to IACS devices that display information to prevent unauthorized individuals from observing the display output. Access displays shall be placed in such a manner to prevent others from viewing the display of clear text access information.

120 ISA , D7E5 118 ISA99, WG <ADD SOME TEXT HERE> B.9 Monitoring Physical Access The organization shall monitor physical access to the IACS to detect and respond to physical security incidents. The organization reviews physical access logs periodically and investigates apparent security violations or suspicious physical access activities. Response to detected physical security incidents is part of the organization s incident response capability. Requirement Enhancements: (1) The organization monitors real-time physical intrusion alarms and surveillance equipment. (2) The organization employs automated mechanisms to recognize potential intrusions and initiate appropriate response actions. B.10 Access Records The organization shall maintain visitor access records to the facility where the IACS resides (except for those areas within the facility officially designated as publicly accessible).the detailed contents of these records are to be defined by the asset owner and their respective security policy. Designated officials within the organization review the visitor access records [Assignment: organization-defined frequency] and maintain those records for [Assignment: organization-defined periodicity].. These logs are intended to support forensic investigation. Useful attributes would include: (i) name and organization of the person visiting; (ii) signature of the visitor; (iii) form of identification; (iv) date of access; (v) time of entry and departure; (vi) purpose of visit; and (vii) name and organization of person visited.. Requirement Enhancements: (1) The organization employs automated mechanisms to facilitate the maintenance and review of access records. B.11 Security Alerts and Advisories The organization shall receive IACS security alerts/advisories on a regular basis, issues alerts/advisories to appropriate personnel, and takes appropriate actions in response. The organization documents the types of actions to be taken in response to security alerts/advisories.

121 ISA99, WG ISA , D7E B.12 Media Access The organization shall restrict access to IACS media to authorized individuals. The organization employs automated mechanisms to restrict access to media storage ar eas and to audit access attempts and access granted. IACS media includes both digital media (e.g., diskettes, magnetic tapes, external/removable hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). This requirement also applies to portable and mobile computing and communications devices with information storage capability (e.g., notebook computers, personal digital assistants, cellular telephones). An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. The rigor with which this requirement is applied is target commensurate with the S system categorization of the information contained on the media. For example, fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact on the organization or individuals if accessed by other than authorized personnel. In these situations, it is assumed that the physical access requirements where the media resides provide adequate protection. This requirement enhancement is primarily applicable to designated media storage areas within an organization where a significant volume of media is stored and is not intended to apply to every location where some media is stored (e.g., in individual offices). B.13 Media Storage Comtrol The organization shall physically control and securely store IACS media within controlled areas. IACS media includes both digital media (e.g., diskettes, magnetic tapes, external/removable hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). A controlled area is any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information and/or IACS. This requirement applies to portable and mobile computing and communications devices with information storage capability (e.g., notebook computers, personal digital assistants, cellular telephones, telephone systems (voic only)). Organizations document in policy and procedures, the media requiring physical protection an d the specific measures taken to afford such protection. The rigor with which this requirement is applied is commensurate with the S target system categorization of the information contained on the media. For example, fewer protection measures are needed for media containing information determined by the organization to have limited or no adverse impact on the organization or individuals if accessed by non-authorized personnel. The assumption is that the physical access controls to the facility where the media resides provide adequate protection. The organization protects IACS media identified by the organization until the media are destroyed or sanitized using approved equipment, techniques, and procedures.

122 ISA , D7E5 120 ISA99, WG As part of a defense-in-depth protection strategy, the organization considers routinely encrypting data at rest on selected secondary storage devices. The organization implements effective cryptographic key management in support of secondary storage encryption and provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by IACS users. B.14 Emergency Shutoff The IACS shall provide, for specific locations within a facility containing concentrations of IACS resources, the capability of shutting off power to any IACS component that may be malfunctioning or threatened without endangering personnel by requiring them to approach the equipment. (1) The IACS shall protect the emergency power-off capability from accidental or unauthorized activation. : Facilities containing concentrations of IACS resources may include, for example, data centers, server rooms, and mainframe rooms. Emergency shutoff capabilities are typically integrated with SIS systems, if present (e.g. automated fail-safe shutdown sequences). B.15 Incident Response Testing and Exercises The organization shall test and/or exercise the incident response capability for the IACS [Assignment: organization-defined frequency, at least annually] using [Assignment: organizationdefined tests and/or exercises] to determine the incident response effectiveness and documents the results. (1) The organization employs automated mechanisms to more thoroughly and effectively test/exercise the incident response capability. Automated mechanisms can provide the ability to more thoroughly and effectively test or exercise the incident response capability by providing more complete coverage of incident response issues, selecting more realistic test/exercise scenarios and environments, and more effectively stressing the response capability. B.16 IACS Monitoring Tools and Techniques The organization shall determine the required granularity of the information collected based upon its monitoring objectives and the capability of the IACS to support such activities. This includes monitoring inbound and outbound communications for unusual or unauthorized activities or conditions. (1) The organization interconnects and configures individual intrusion detection tools into a system wide intrusion detection system using common protocols. Organizations consult appropriate legal counsel with regard to all IACS monitoring activities. Organizations heighten the level of IACS monitoring activity whenever there is an indication of increased risk to organizational operations, organizational assets, or individuals based on law enforcement information, intelligence information, or other credible sources of information.

123 ISA99, WG ISA , D7E B.17 Software and Information Integrity The organization reassesses the integrity of software and information by performing [Assignment: organization-defined frequency] integrity scans of the system. This requirement complements related Access requirements. Access involves enforcing the roles, permissions, and use patterns as designed. Integrity verification methods are employed to detect, record, report, and protect against the effects of software and information tampering that may occur if other protection mechanisms (e.g. Access ) have been circumvented. B.18 Information Input Restrictions Restrictions on entities authorized to input information to the IACS may extend beyond the typical access controls employed by the system and include limitations based on specific operational/project responsibilities. B.19 Error Handling The extent to which the IACS identifies and handles error conditions shall be guided by organizational policy and operational requirements. B.20 Information Output Handling and Retention The organization shall handle and retain output from the IACS in accordance with applicable laws, directives, policies, regulations, standards, and operational requirements. B.21 System Maintenance Policy and Procedures The organization shall develop, disseminate, and periodically review/update: (i) a formal, documented, IACS maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii ) formal, documented procedures to facilitate the implementation of the IACS maintenance policy and associated system maintenance controls. The IACS maintenance policy and procedures are consistent with applicable laws, directives, policies, regulations, standards, and guidance. The IACS maintenance policy can be included as part of the general information security policy for the organization. System maintenance procedures can be developed for the security program in general, and for a particular IACS, when required.

124 ISA , D7E5 122 ISA99, WG B.22 led Maintenance The organization shall schedule, perform, document, and review records of routine preventative and regular maintenance (including repairs) on the components of the IACS in accordance with vendor, system integrator, and/or organizational specifications and requirements. (1) The organization maintains maintenance records for the IACS that include: (i) the date and time of maintenance; (ii) name of the individual performing the maintenance; (iii) na me of escort, if necessary; (iv) a description of the maintenance performed; and (v) a list of equipment removed or replaced (including identification numbers, if applicable). (2) The organization employs automated mechanisms to schedule and conduct maintenance as required, and to create up-to date, accurate, complete, and available records of all maintenance actions, both needed and completed. All maintenance activities to include routine, scheduled maintenance and repairs are controlled; whether performed on site or remotely and whether the equipment is serviced on site or removed to another location. Organizational officials approve the removal of the IACS or IACS components from the facility when repairs are necessary. If the IACS or component of the system requires offsite repair, the organization removes all information from associated media using approved procedures. After maintenance is performed on the IACS, the organization checks all potentially affected security controls to verify that the controls are still functioning properly. B.23 Maintenance Tools The organization shall approve, control, and monitor the use of IACS maintenance tools and maintains the tools on an ongoing basis. (1) The organization inspects all maintenance tools carried into a facility by maintenance personnel for obvious improper modifications. The intent of this requirement is to address hardware and software brought into the IACS specifically for diagnostic/repair actions (e.g., a hardware or software packet sniffer that is introduced for the purpose of a particular maintenance activity). Hardware and/or software components that may support IACS maintenance, yet are a part of the system (e.g., the software implementing ping, ls, ipconfig or the hardware and software implementing the monitoring port of an Ethernet switch) are not covered by this requirement. Maintenance tools include, for example, diagnostic and test equipment used to conduct maintenance on the IACS. (1) The organization checks all media containing diagnostic and test programs for malicious code before the media are used in the IACS. (2) The organization checks all maintenance equipment with the capability of retaining information so that no organizational information is written on the equipment or the equipment is appropriately sanitized before release; if the equipment cannot be sanitized, the equipment remains within the facility or is destroyed, unless an appropriate organization official explicitly authorizes an exception. (3) The organization employs automated mechanisms to restrict the use of maintenance tools to authorized personnel only.

125 ISA99, WG ISA , D7E B.24 Remote Maintenance The organization shall authorize, monitor, and control any remotely executed maintenance and diagnostic activities, if employed. (1) The organization audits all remote maintenance and diagnostic sessions and appropriate organizational personnel review the maintenance records of the remote sessions. (2) The organization addresses the installation and use of remote maintenance and diagnostic links in the security plan for the IACS. Remote maintenance and diagnostic activities are conducted by individuals communicating through an external, non-organization-controlled network (e.g., the Internet). The use of remote maintenance and diagnostic tools is consistent with organizational policy and documented in the security plan for the IACS. The organization maintains records for all remote maintenance and diagnostic activities. Other techniques and/or controls to consider for improving the security of remote maintenance include: (i) encryption and decryption of communications; (ii) strong identification and authentication techniques; and (iii) remote disconnect verification. When remote maintenance is completed, the organization (or IACS in certain cases) terminates all sessions and remote connections invoked in the performance of that activity. If password-based authentication is used to accomplish remote maintenance, the organization changes the passwords following each remote maintenance service. The National Security Agency provides a listing of approved media sanitization products at B.25 Maintenance Personnel The organization shall allow only authorized personnel to perform maintenance on the IACS. Maintenance personnel (whether performing maintenance locally or remotely) have appropriate access authorizations to the IACS when maintenance activities allow access to organizational information or could result in a future compromise of confidentiality, integrity, or availability. When maintenance personnel do not have needed access authorizations, organizational personnel with appropriate access authorizations supervise maintenance personnel during the performance of maintenance activities on the IACS. B.26 Timely Maintenance The organization shall obtain maintenance support and spare parts for [Assignment: organization - defined list of key IACS components] within [Assignment: organization-defined time period] of failure.

126 ISA , D7E5 124 ISA99, WG

127 ISA99, WG ISA , D7E Annex C (informative) Additional IACS Implementation Guidance NOTE This Annex should contain any additional material that we want to include from the previous ISA document. It is a placeholder and dumping ground right now. We will try to organize and consolidate the material in this Annex later. C.1 IACS Assets Need to indicate the clear boundaries between IACS and other components. Below is some idea of how we define physical, logical and information IACS assets. This will definitely need to be refined. Physical IACS assets are objects that have processors and/or network interfaces and are responsible for performing some function in the IACS. We aren t talking about the thermocouples or limit switches (Level 0), but we are talking about the I/O blocks and controllers necessary to perform the control loops. The Physical IACS asset list may also not contain large-scale items like generators or pumps, depending on their control mechanism. If they have a separate controller, then the controller is part of the physical IACS assets, while the generator or pumps aren t. Logical IACS assets are objects like 3rd party software applications, computer operating systems, operational programs (ladder-logic, scripts, recipes, etc.), and other objects where generally a monetary amount can be associated with their loss or damage. Informational IACS assets are objects that are likely operational in nature, including things like disaster recovery plans, operational procedures, incident handling plans, data historian databases, etc. These are, many times, the outputs of different stages of the IACS-SMS that need to be managed and stored for future purposes (including certification, regulation, inspection, and review), but may be difficult to associate a monetary figure since they are policy, procedure, or planning related objects. C.1.1 Element: Staff training and security awareness C Description of the element Security awareness for all personnel is an essential tool for reducing cyber security risks. Knowledgeable and vigilant staff is one of the most important lines of defense in securing any system. In the area of IACS, the same emphasis shall be placed on cyber security as on safety and operational integrity, because the consequences can be just as severe. It is therefore important for all personnel (employee, contract or third-party) to understand the importance of security in maintaining the operation of the system. Staff training and security awareness programs provide all personnel (employees, contractors, and the like) with the information necessary to identify, review, address and where appropriate, remediate vulnerabilities and threats to IACS and to help ensure their own work practices include effective countermeasures. All personnel should receive adequate technical training associated with the known threats and vulnerabilities of hardware, software and social engineering. Cyber security training and security awareness programs are most effective if they are tailored to the audience, consistent with company policy and communicated regularly. Training provides a means to communicate key messages to personnel in a timely fashion. An effective training program can help employees understand why new or updated security controls are required and generate ideas they can use to reduce risks and the impact on the organization if control methods are not incorporated.

128 ISA , D7E5 126 ISA99, WG C Developing a staff training program and building security awareness Training of one sort or another is an activity that spans almost the entire period during which a CSMS is developed and implemented. It begins after the scope of the effort is clarified and the team of stakeholders is identified. The objective of the training program is to provide all personnel with the information they need so that they will be aware of any possible threats to the system and their responsibilities for the safe and secure operation of the production facilities. The organization should design and develop a cyber security training program in conjunction with the organization s overall training program. Training should be in two phases: 1) general training for all personnel and 2) role-based training aimed at specific duties and responsibilities. Before beginning the development of the training program it is important to identify the scope and boundaries for the training and to identify and define the various roles within the organization. The general training program should be developed for all personnel. Users should be trained in the correct security procedures, the correct use of IACS facilities and the correct handling of information in order to minimize risks. Training should also include legal responsibilities, business controls and individual security responsibilities. Role-based training should focus on the security risks and responsibilities associated with the specific role a person fills within the organization. These individuals will need more specific and intensive training. Subject matter experts should be employed to cont ribute to this training. Rolebased training may be conducted in the classroom, may be web-based or hands-on. This training may also leverage training provided by vendors for in-depth discussion of tools and associated exposures. The program should include a means to review and revise the program, as required and a means to evaluate the effectiveness of the program. Also, there should be a time defined for periodic retraining. Management s commitment to training and ensuring adequate cyber security awarenes s is critical to providing a stable and secure computing environment for both IT and IACS. In particular for the IACS environment, a stable and secure computing environment aids in maintaining the safe operation of the equipment under control and reducing HSE incidents. This should be in the form of resources for developing and organizing the training and making staff available to attend. Following the development of a cyber security training program, the organization should provide the appropriate training for all personnel. Training programs should be provided in a place and at times that allow personnel to be trained without adversely affecting their other responsibilities. General training should be provided as part of a new employee s orientation and as a part of the orientation for contract, temporary or third-party personnel. The training required should be appropriate for the level of contact which they will have with the organization. Specialized training may be provided as follows: a) Training for stakeholders Training is appropriate for the team of stakeholders as well as the community of individuals in the IACS community who will ultimately be impacted. The team of stakeholders will need specific training on the type of risks that are being considered, the scope and charter of work that management has approved, any background information on incidents that have occurred to these systems either within the organization or within the industry in general and on the types of architectures and systems that are in use within the organization. Formal classroom training is not necessary to share this information. Presentations at business meetings, communication sessions and announcements are examples of ways to share the information. Training employees preparing for new roles

129 ISA99, WG ISA , D7E Training will be needed for employees as they prepare to assume new roles either within the direct risk management system or within the risk management related projects. Virtually all members of the IACS community will receive a certain amount of training during this phase. Some of the direct risk management roles will include responsibilities for self-assessments or internal audits. Training of auditors Training will be needed for auditors to help them understand the nature of the sys tems and networks they will be auditing as well as the specific policies that have been created. Ongoing training There will be an ongoing need for training at all levels due to the addition of new employees and third-party personnel, the need to provide updates as policies and services are modified over time and to provide refresher training to ensure that personnel remain competent in their roles and responsibilities. It is important to validate that personnel are aware of their roles and responsibilities as part of the training program. Validation of security awareness provides two functions: 1) it helps identify how well the personnel understand the organization s cyber security program and 2) it helps to evaluate the effectiveness of the training program. Validation can come through several means including written testing on the content of the training, course evaluations, monitored job performance or documented changes in security behavior. A method of validation should be agreed upon during the development of the training program and communicated to the personnel. Records of employee training and schedules for training updates should be maintained and reviewed on a regular basis. Documenting training can assist the organization to ensure that all personnel have the required training for their particular roles and responsibilities. It can also help identify if additional training is needed and when periodic retraining is required. Over time, the vulnerabilities, threats and associated security measures will change. These changes will necessitate changes to the content of the training program. The training program should be reviewed periodically (for example, annually) for its effectiveness, applicability, content and consistency with tools currently used and corporate practices and laws and revised as needed. Subscriptions to security alert services may help ensure up-to-date knowledge of recently identified vulnerabilities and exposures. C Supporting practices C Baseline practices The following seven actions are baseline practices: b) Addressing the various roles associated with maintaining a secure systems environment within the cyber security training curriculums. Having classroom courses or on-the-job training to address the requirements for each role. Validating a user s understanding via course evaluations and/or examinations. Having subject matter experts for each course who can provide additional information and consulting. Reviewing and validating the training curriculum periodically and evaluating its eff ectiveness. Communicating key messages to all personnel in a timely fashion via a security awareness communication program. Training all personnel initially and periodically thereafter (for example, annually). While none of these baseline practices are specific to IACS security training, the emphasis and content for the training programs needs to show the relationship between IACS security and HSE consequences. C Additional practices The following seven actions are additional practices:

130 ISA , D7E5 128 ISA99, WG c) Establishing cyber security training as a component of the company s overall training organization for all employees. Tailoring the cyber security training curriculums with a progression of material for a given role in the organization. Maintaining and reviewing records of employee training and schedules for training updates on a regular basis depending on their position/role. Leveraging cyber security training provided by vendors. Establishing the timing, frequency and content of the security awareness communication program in a document to enhance the organizations understanding of cyber security controls. Including an overview of the security awareness communication program for all personnel to ensure they are aware of the security practices on their first day. Reviewing the training and the security awareness program annually for its effectiveness, applicability, content and consistency with tools currently used and corporate practices. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., [16], Error! Reference source not found.. C.1.2 Element: Personnel security C Description of element Personnel security involves looking at potential and current personnel to determine if they will carry out their responsibilities for IACS security in the organization and establishing and communicating their responsibilities to do so. Employees, contractors or temporary personnel that have access to industrial operation sensitive information or the IACS networks, hardware and software create a potential exposure if sensitive information is revealed, modified or if unauthorized access to IT systems or IACS is granted. C Requirements for personnel security In many organizations, the personnel security requirements have been driven by concerns about insider threats and the possibility of accidents caused by inattention to detail or by personnel unfit for a job due to lack of proper background or use of substances that might cloud judgment. By implementing personnel security policies it may be possible to reduce these types of problems. When developing a program for personnel security, it is important to include personnel that can access all systems in scope and not just limit the effort to personnel using traditional computer room facilities. Computers in IACS operations are tools used to operate the facility productively and safely. It is the personnel that operate the systems that are the heart of the operations and every care should be taken to ensure that these people are qualified and fit for these positions. This process begins at the recruitment phase and continues through termination. It requires constant attention by management and co-workers to ensure that the system is operated in a secure manner. A personnel security policy should clearly state the organization s commitment to security and the security responsibilities of personnel. It should address security responsibilities of all personnel (both individual employees and the organization) from recruitment through the end of employment, especially for sensitive positions. (This includes employees, prospective employees, contract employees, third-party contractors and company organizations such as human relations.) All personnel, including new hires and internal transfers to sensitive positions (for example, those requiring privileged access) should be screened during the job application process. This screening

131 ISA99, WG ISA , D7E should include identity, personal and employment references and academic credentials. Background screenings may also include credit history, criminal activity and drug screening as this information may be useful in determining the applicants suitability (subject to local Privacy Laws). Third-parties, contractors, and the like are subject to background screening at least as rigorous as employees in comparable positions. Employees and contractors may also be subject to ongoing scrutiny, such as for financial, criminal and drug activities. Due to the amount of industrial operation sensitive data and potential HSE risks in some IACS environments, it may be necessary to screen a wide group of employees who have access to the IACS. Plant-floor employees may need the same level of background checks and scrutiny as a typical IT system administrator. The terms screening and background checks are left intentionally vague so that the organization can determine the level of screening to be performed on personnel. Sensitive positions is also left to be defined by the organization because it is realized that some positions can have little or no effect on the security of the system. During the hiring process, the terms and conditions of employment should clearly state the employees responsibility for cyber security. These responsibilities should extend for a reasonable period of time after employment ceases. While hiring contractors or working with third -party personnel, their security responsibilities should be documented and included in any agreements. Where possible, the responsibilities should be specific and measurable. Personnel should be made aware of the organization s security expectations and their responsibilities through clearly documented and communicated statements by the organization. Personnel need to accept their mutual responsibility to ensure safe and secure operation of the organization. Organizations may consider having all personnel of IACS facilities sign a confidentiality or nondisclosure agreement. Any confidentiality agreements should be reviewed with and signed by employees as part of the initial employment process. Third -party contractors, casual staff or temporary employees not covered by a formal nondisclosure agreement should also sign a confidentiality agreement prior to beginning work. Organizations should create job roles based on the segregation of duties to assure that access to information is on a need-to-know basis and high-risk operating steps require more than one person to complete. These duties should be segregated amongst personnel to maintain the appropriate checks and balances, so that no single individual has total control over actions that change the functional operation of the IACS. The security roles and responsibilities for a given job should be periodically reviewed and revised to meet the changing needs of the company. All personnel should be expected to remain vigilant for situations that may lead to safety or security incidents. Companies need to train managers to observe personnel behavior that may lead to theft, fraud, error or other security implications. A disciplinary process for cyber security violations should be established and communicated to personnel. This should be tied to the legal and punitive measures against such crimes in the country. C Supporting practices C Baseline practices The following eight actions are baseline practices: d) Screening personnel during the recruitment phase, such as background checks prior to hiring or movement to sensitive jobs, especially for sensitive positions. Scrutinizing personnel, especially those in sensitive positions, on a regular basis to look for financial problems, criminal activity or drug problems. Communicating the terms and conditions of employment or contract to all personnel stating the individual s responsibility for cyber security. Documenting and communicating the organization s security expectations and personnel responsibilities on a regular basis. Requiring personnel to accept their mutual responsibility to ensure safe and secure operation of the organization.

132 ISA , D7E5 130 ISA99, WG Segregating duties amongst personnel to maintain the appropriate checks and balances. Requiring all personnel to sign a confidentiality or nondisclosure agreement. Establishing a disciplinary process for personnel who have violated the security policies of the organization. C Additional practices The following two actions are additional practices: e) Creating job roles based on the segregation of duties to assure that access to information is on a need-to-know basis and high-risk processing steps require more than one person to complete. Documenting the security responsibilities and including them in job descriptions, contracts or other third party agreements. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. DRAFT 5, EDIT 3 ANNEX A Guidance for developing the elements of a CSMS C.2 Overview This annex provides informative guidance to the reader on how to develop a CSMS that meets the requirements specified in Clause Error! Reference source not found.. The guidance presented here provides an overall management system framework that allows organizations adopting the CSMS to tailor it to their own specific needs. It should be thought of as a starting point or baseline for a CSMS. Not all guidance may be applicable and depending on the application, the organization may require more security than what is presented. It is also not meant to be a step-by-step process, as was previously stated in Error! Reference source not found.. This Annex is organized with the same categories, element groups, and elements as those listed in Clause Error! Reference source not found. (see Figure B.1). Each element in this annex uses the following organization: Description of element a basic description of the topic; Element-specific information one or more subclauses providing detailed guidance regarding this element. Their structure and content is element-specific; Supporting practices: Baseline practices recommendations for organizations to achieve a baseline level of cyber security. These practices become the building blocks of the requirements for each element. Additional practices innovative security practices used by some organizations to further enhance cyber security; Resources used sources for additional information as well as documents referenced (in addition to the current document).

133 ISA99, WG ISA , D7E5 Business rationale Risk analysis Risk identification, classification and assessment Security policy, organization and awareness Addressing risk with the CSMS Selected security countermeasures Implementation Figure B.1 Graphical view of elements of a cyber security management system C.3 Category: Risk analysis C.3.1 CSMS scope Organize for security Staff training and security awareness Business continuity plan Security policies and procedures Conformance Description of category Personnel security Physical and environmental security Network segmentation Access control - Account administration Access control - Authentication Access control - Authorization Monitoring and improving the CSMS Review, improve and maintain the CSMS Risk management and implementation System development and maintenance Information and document management Incident planning and response The first main category of the CSMS is risk analysis. This category discusses much of the background information that feeds into many of the other elements in the CSMS. Figure B.2 shows the two elements that are part of the category: Business rationale and Risk identification, classification and assessment.

134 ISA , D7E5 132 ISA99, WG02 Business rationale Risk analysis Risk identification, classification and assessment Figure B.2 Graphical view of category: Risk analysis C.3.2 Element: Business rationale C Description of element This element establishes that the organization is aware of and understands the importance of cyber security for information technology as used in IACS. This understanding is based upon an understanding of the roles that information technology plays in the mission of th e organization, associated risks to this mission and the cost and other business impacts of mitigating this risk. C Cyber security risk, business rationale and business case The first step to implementing a cyber security program for IACS is to develop a compelling business rationale for the unique needs of the organization to address cyber risk. An organization may derive the rationale for its IACS CSMS and related individual projects from existing policies related to safety, general risk management or compliance with regulatory requirements. Other organizations may require that the business rationale take the form of a formal or informal business case for cyber security management activities in order to establish that the cost of mitigating cyber risk is justified by its financial benefit. A business rationale or business case for taking the first steps to build a CSMS will depend upon an assessment of risk, generally at a high level. Once risk is acknowledged, an organization is ready to take appropriate steps to mitigate it. An effort to perform more systematic and detailed risk assessment (as described later in this document) and individual decisions about countermeasures, may themselves require a business rationale, possibly in the form of a business case. A business rationale captures the business concerns of senior management while being founded in the experience of those already dealing with many of the same risks. This subclause deals with the key components of the resulting business rationale and key resources to help identify those components. A business rationale may have as its scope the justification of a high-level or detailed risk assessment, other specific aspects of a full CSMS as described herein, or implementation of a single countermeasure. Experience has shown that embarking on a cyber security program without an agreed business rationale often results in eventual loss of program resources in favor of other business requirements. Typically these other business requirements have a more direct business benefit and easily understood rationale. C Key components of business rationale There are four key components of a business rationale: prioritized business consequences, prioritized threats, estimated annual business impact and cost of countermeasures. a) Prioritized business consequences The list of potential business consequences needs to be distilled to the particular business consequences that senior management will find the most compelling. For instance, a food and beverage company that handles no toxic or flammable materials and typically processes its product at relatively low temperatures and pressures might not be concerned about equipment damage or environmental impact but might be more concerned about loss of production availability and degradation of product quality. The insight here is based on histories of past incidents as well as knowledge of how IACS are actually used in the business and the potential

135 ISA99, WG ISA , D7E business impact that unauthorized technical changes could cause. Regulatory compliance might also be a concern. b) Prioritized threats The list of potential threats needs to be refined, if possible, to those threats that are deemed credible. For instance, a food and beverage company might not find terrorism a credible threat but might be more concerned with viruses and worms and disgruntled employees. The insight here is primarily based on histories of past incidents. c) Estimated annual business impact The highest priority items shown in the list of prioritized business consequences should be scrutinized to obtain an estimate of the annual business impact preferably, but not necessarily, in financial terms. For the food and beverage company example, it may have experienced a virus incident within its internal network that the information security or ganization estimated as resulting in a specific financial cost. Because the internal network and the controls network are interconnected, it is conceivable that a virus originating from the controls network could cause the same amount of business impact. The insight here is primarily based on histories of past incidents. Regulatory compliance may entail specific financial or business penalties for non - compliance. d) Cost The estimated cost of the human effort and technical countermeasures that this business rationale intends to justify. NOTE A business impact estimate in financial terms and cost estimates for countermeasures are required to create a business case, but a successful business rationale may not always include this information. There are a number of resources for information to help form this business rationale: external resources in trade organizations and internal resources in related risk management programs or engineering and operations. External resources in trade organizations often provide useful tips about factors that most strongly influenced their 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. Internal resources associated with related risk management efforts (that is, information security, HSE risk, physical security, and 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 prove the most appropriate or receptive to serving as a champion. Internal resources associated with control systems engineering and operations can provide insight into the details of how control systems are actually used within the organization. How are networks typically segregated? How are high-risk combustion systems or safety instrumented systems (SIS) typically designed? What security countermeasures are already commonly used? Keeping in mind the organization s history with mergers and acquisitions, it is also important to understand how representative any particular site might be of the entire business unit, region or overall organization. Remember that in the early stages of the industrial operation, the primary focus will be on identifying one or two high-priority issues that justify continued effort. As the IACS cyber security program develops further, other items may appear on the list and priorities may shift, as the organization applies a more rigorous risk analysis methodology. However, these changes should not detract from the result of this original effort to justify initiating the program.

136 ISA , D7E5 134 ISA99, WG C Content suggestions for IACS business rationale Within each organization, the journey to develop an effective cyber security program for IACS starts with individuals who recognize the risks the organization is taking and begin to articulate these risks internally, not just in technical terms, but in business terms that resonate with upper management. A business rationale is not a detailed risk assessment; it is rather a high-level description of risks sufficient to justify the next planned steps in building a CSMS. It may be as brief or detailed as required to support the decision processes in the particular organization. The negative business consequences of cyber attacks against IACS can include the following: 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; 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; economic loss. In prioritizing the risk of these consequences occurring, it is also important to consider the potential source or threat that initiates a cyber attack and the likelihood that such an event would occur. Cyber threats could arise from sources inside or outside an organization; threats could be the result of either intentional or unintentional actions; and threats could either be directed at a specific target or undirected. Cyber security incidents can result from many different types of threat agents such as the following: Thrill-seeking, hobbyist, or alienated individuals who gain a sense of power, control, selfimportance and pleasure through successful penetration of computer systems either via undirected attacks (viruses and worms) or directed attacks (hacking) to steal or destroy information or disrupt an organization s activities. Disgruntled employees or contractors who damage systems or steal information for revenge or profit. Well-intentioned employees who inadvertently make changes to the wrong controller or operating equipment. Employees who break quality, safety or security policies or procedures to meet other urgent needs (for example, production goals). Terrorists typically motivated by political beliefs for which cyber attacks offer the potential for low-cost, low-risk, but high-gain attacks especially when linked with coordinated physical attacks. Professional thieves (including organized crime) who steal information for sale. Adversary nations or groups who use the Internet as a military weapon for cyber warfare to disrupt the command, control and communication capabilities of a foe. Documented cases provide insight into how and how often one of these threat agents succeeds in inflicting negative business consequences. The rapid adoption of new network technologi es has led to the development of new tools to enable cyber attacks. With the lack of a recognized publicly

137 ISA99, WG ISA , D7E accessible incident reporting system, it will be extremely difficult in the near future to determine a quantitative likelihood of any specific type of event occurring. Likelihood will need to be evaluated qualitatively based on an organization s own internal incident history and on the few cases that have been publicly documented. Several examples of these cases are: EXAMPLE 1 In January, 2003, the SQL Slammer Worm rapidly spread from one computer to another across the Internet and within private networks. It penetrated a computer network at Ohio s Davis -Besse nuclear power plant and disabled a monitoring system for nearly five hours, despite a belief by plant personnel that the network was protected by a firewall. It occurred due to an unprotected interconnection between plant and corporate networks. The SQL Slammer Worm downed one utility s critical SCADA network after moving from a corporate network t o the control center local area network (LAN). Another utility lost its Frame Relay Network used for communications and some petrochemical plants lost human-machine interfaces (HMIs) and data historians. A 911 call center was taken offline, airline flights were delayed and canceled and bank ATMs were disabled. EXAMPLE 2 Over several months in 2001, a series of cyber attacks were conducted on a computerized waste water treatment system by a disgruntled contractor in Queensland, Australia. One of these attack s caused the diversion of millions of gallons of raw sewage into a local river and park. There were 46 intrusions before the perpetrator was arrested. EXAMPLE 3 In September, 2001, a teenager allegedly hacked into a computer server at the Port of Houston to target a female chat room user following an argument. It was claimed that the teenager intended to take the woman s computer offline by bombarding it with a huge amount of useless data and he needed to use a number of other servers to be able to do so. The attack bombarded scheduling computer systems at the world s eighth largest port with thousands of electronic messages. The port s web service, which contained crucial data for shipping pilots, mooring companies and support firms responsible for helping ships navigate in and out of the harbor, was left inaccessible. The CERT organization has been monitoring and tracking the number of attacks occurring on Internet-connected systems since None of the reported incidents were for control systems. As of 2004, they have stopped tracking the number of attacks, because the prevalence of automated attack tools has led to attacks becoming so commonplace that the number of incidents reported provides little information with regard to assessing the scope and im pact of attacks. A graph of their incident data is shown in Figure B.3 to demonstrate the dramatic increase that has occurred over the last 15 years. Number Reported to CERT (Thousands) In 2004, CERT stopped reporting data since attacks were too frequent Figure B.3 Reported attacks on computer systems through 2004 (source: CERT) Year

138 ISA , D7E5 136 ISA99, WG C Supporting practices C Baseline practices The following six actions are baseline practices: a) Identifying and documenting the business objectives, critical business processes and critical information technology processes. Include IACS and interfaces with value chain partners where sensitive information is transferred, stored, or processed. b) Identifying the dependence of the business on information technology systems. Categorize the business dependence low, medium, high, or an alternate ranking system. c) Identifying various damage scenarios by the loss of confidentiality, integrity or availability of information. Include the manipulation of IACS and the consequences of such actions for those businesses, which use these systems. Include HSE and operational integrity and reliability for drivers of IACS. Capture risks associated with value chain and other third-party business partners. These risks often include the loss or alteration of sensitive information. An example is the interception of information associated with manufacturing products shipments, including types of materials, quantities, shipping routes, mode of transportation, and the like. d) Developing business impact analyses for IACS security. e) Developing business impact analyses for value chain or other third-party business partner. f) Determining the organization s risk tolerance profile defined in terms of: 1) Safety of personnel (serious injury or fatality); 2) Financial loss or impact including regulatory penalties; 3) Environmental/regulatory consequence; 4) Damage to company image; 5) Impact to investment community; 6) Loss of customer base or confidence; 7) Impact on infrastructure. NOTE Risk tolerance varies depending on the business. Simply put, the organization s risk tolerance is its threshold of pain. The risk tolerance may be very low (for example, a single serious injury may not be acceptable and must be addressed immediately) when it comes to safety in plant manufacturing or may be very high (for example, in terms of production loss) if the organization has multiple production sites of a commodity product. The financial impact for one business may not be appropriate for other businesses. Organizations with multiple businesses should look at the interdependencies of one business upon another when determining risk tolerance. IT security managers typically will be familiar with the organization s risk tolerance profile for some, but not all of these consequences. Other managers who are responsible for managing the risks associated with HSE consequences will be familiar with the organization s risk tolerance profile in these areas. The overall risk tolerance profile needs to be determined by integrating information from these sources as well as those from the IACS environment. C Additional practices The following three actions are additional practices: a) Identifying and documenting the business objectives, critical business processes, and critical IT processes. This process is best performed with a cross-section of the organization representing the functional areas, as well as the business units of the company. This group typically is chartered either by a senior executive who is responsible for the IT organization, or by a leadership team that includes other senior executives from throughout the organization. This charter specifically includes the risk associated with IACS. b) Developing a business impact analysis that describes the issues and consequences of inaction and benefits of action. Where practical, these actions are quantified in terms of financial impacts (that is, lost sales or fines), market impacts (that is, loss of confidence or public image),

139 ISA99, WG ISA , D7E as well as HSE impacts (that is, environmental release, equipment damage and loss of life). Especially when considering consequences like public image, it is important to understand that an incident due to one particular business unit can affect the organization as a whole. c) Documenting and approving (by the appropriate level of management) the risks outside the scope of the CSMS. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: [16], Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C.3.3 Element: Risk identification, classification and assessment C Description of element Organizations protect their ability to perform their mission by systematically identifying, prioritizing and analyzing potential security threats, vulnerabilities, and consequences using accepted methodologies. Risk is formally defined as an expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular consequence (see ISA ). As described under the related element Risk Management and Implementation (see C.4.4.2), an organization defines its risk tolerance in terms of the characteristics of threats, vulnerabilities and potential consequences it identifies. The organization then implements this risk tolerance decision by taking action where indicated to reduce the likelihood of a security threat occurring by mitigating vulnerabilities and/or reducing the consequences in case the security threat is realized. C Cyber risk for IACS The risk management approach outlined in C.3.2 applies in general for all types of cyber risks as well as other types of risks. This discussion is about the unique aspects of the analysis of cyber risk for IACS. Although various industries may find certain types of business impact of more conc ern and may feel that certain types of threats are more likely, all industries that use IACS should be concerned that they are entering a new risk environment. At the same time that IACS have adopted commercial IT operating systems and network technologies and users have interconnected their private networks with their IACS networks, the number of threats has also increased greatly. There are risks associated with traditional information (electronic or paper), classical IT systems and applications, IACS, business partners, joint ventures, outsourcing partners, and the like. Risks for traditional IT assets focus on the confidentiality, integrity, and availability of information. Risks in IACS are different as the drivers focus more on HSE factors and operatio nal reliability in addition to the traditional protection of information confidentiality, integrity and availability. In IACS the priorities are generally reversed with focus on availability, integrity and confidentiality in that order. This means that cyber risk assessment for IACS should be coordinated with physical security and HSE, wherever practical. Some organizations fully integrate risk assessment efforts related to all of these areas. Risks using outsourcing, third-party contractors or other partners in the manufacturing value chain include sensitive information transmitted, stored or processed. The integration of these business partners into an organization s operations potentially permits unintentional access into the company s systems. In virtually all of these cases, the security-related industrial operations and technologies developed for classical IT applications have not been deployed for IACS partly due to ignorance, but partly due to valid constraints that do not exist in classical IT applications. The objective of this standard is to address both issues.

140 ISA , D7E5 138 ISA99, WG C Risk assessment process C General An overview of risks is required to establish the business rationale for a CSMS. The more detailed priorities addressed by this system are determined based upon a methodology that systematically considers risk at a greater level of granularity than typically assessed to establish an initial business rationale. C Risk assessment and vulnerability assessment In the general literature, the terms vulnerability assessment and risk assessment are sometimes used interchangeably. These two kinds of analyses can be distinguished in accordance with the definitions of vulnerability and risk in this standard. Recall that vulnerability is defined as a flaw or weakness in a system's design, implementation or operation and management that could be exploited to violate the system's integrity or security policy (see ISA ). As an example, the observation that passwords in a control center are seldom changed is an example of a vulnerability that would be identified in a vulnerability assessment. There may be several risks associated with this vulnerability, for example: A low likelihood that the password becomes well known in the plant over time and that a legitimate employee not trained for control system operations uses the password while pitching in to solve a problem and causes a loss of production for several hours due to input errors. A low likelihood that a disgruntled former employee successfully breaks through corporate firewall defenses to access the control system network remotely, logs in to an HMI and deliberately takes actions that can cause a loss of production for several days. Thus as these terms are used in this standard, risk assessment has as its output a set of risks and a vulnerability assessment has as its output a set of vulnerabilities, which have not yet been analyzed in terms of the risks they create. In this way, a vulnerability assessment is an input to a risk assessment. Note some existing methodologies titled vulnerability assessment methods include risk concepts and others do not. Returning to the above example of the control room password, it is clear that there are also risks involved in changing the control system password periodically, for example, a low likelihood that an operator may not remember a new password in an emergency situation and will be unable to login to resolve the situation, resulting in serious collateral environmental damage. The tradeoff between the risk addressed by a countermeasure and the risk introduced by a countermeasure such as in this case, is discussed under the Risk Management and Implementation element of this standard (see C.4.4.2). C High-level and detailed risk assessment Risk assessment can be carried out at several levels. This standard requires risk assessment at two levels of detail, called high-level risk assessment and detailed risk assessment. High-level risk assessment examines what might be the impact of general types of cyber security vulnerabilities and the likelihood that a threat might exercise these vulnerabilities, but does not consider particular instances of these vulnerabilities or related countermeasures already in place. Thus examples of risks identified in a high-level risk assessment might be: A medium likelihood that a malware infestation occurs and causes control network co ngestion and thus a lack of visibility to the status of the industrial process in the control room, resulting in potential emergency shutdown and resulting costs. A low likelihood that a contractor with criminal connections and with physical access to the control system network media taps this media and successfully modifies control commands in a way that causes damage to the facility.

141 ISA99, WG ISA , D7E High-level assessment is required because experience has shown that if organizations start out by looking at detailed vulnerabilities, they miss the big picture of cyber risk and find it difficult to determine where to focus their cyber security efforts. Examination of risks at a high level can help to focus effort in detailed vulnerability assessments. The high-level assessment can typically cover all control networks owned by an organization, possibly by dividing them into groups that share common characteristics. Resources may not be available to cover all IACS at the detailed level. A detailed risk assessment, as defined for this standard, is supported by a detailed vulnerability assessment that includes examining details such as existing technical countermeasures, adherence to account management procedures, patch and open port status by individual host on a specific control system network and network connectivity characteristics such as firewall separation and configuration. Thus an example output from a detailed risk assessment might be: Direct connection of process engineering workstations to both the corporate network and the control system network in the South facility, bypassing the control network internal firewall, contribute to risk of malware infection on the control network. In combination with lack of antivirus protection on 50% of the hosts on the South facility control network, this results in a medium likelihood of a virus-triggered network congestion incident causing a lack of visibility to the status of the industrial operation in the control room and resulting in potential emergency shutdown and resulting costs. All control system network media (for example, addresses x) and connections to other networks are either physically protected by walls, ceilings or floors, or in locked rooms accessible to three authorized control system network administrators. Therefore the risk of a successful attempt at tapping this media is low. These detailed risk assessment results support related results from a high-level assessment according to the related examples above. However, the detailed risk assessment may in man y cases determine that risks are lower or higher than suspected in the high-level assessment. The detailed risk assessment may also uncover risks not considered in the high-level assessment. Finally, since the detailed assessment identifies specific vulnerabilities, it provides direction for how an organization might address risks deemed unacceptable. C Types of risk assessment methodologies C General There are a variety of risk assessment methods that have been developed and marketed by different organizations. In general, these can be classified according to two factors: how they characterize the individual risks (qualitatively versus quantitatively) and how they structure the risk identification exercise (scenario-based versus asset-based). C Qualitative versus quantitative Qualitative risk assessment typically relies on the input of experienced employees and/or experts to provide information regarding likelihood and severity of specific threats impacting specific assets. In addition, different levels of likelihood and severity are identified by general classes such as high, medium and low rather than specific probabilities or economic impacts. Qualitative risk assessment is preferred when there is a lack of reliable information regarding the likelihood of specific threats affecting specific assets or estimating the overall impact of damage to specific assets. Quantitative risk assessment typically relies on extensive data sets that document the rate at which damage occurs to assets based on exposure to defined combinations of threats and vulnerabilities. If this information is available, it can provide more precise risk estimates than qualitative risk assessment methods. Due to the recent exposure of IACS to cyber security threats, the relative infrequency at which incidents occur and the rapidly evolving nature of the threats, extensive data sets do not yet exist to aid in the assessment of cyber security threats to IACS. At this stage, qualitative risk assessment is the preferred method for evaluating these risks.

142 ISA , D7E5 140 ISA99, WG C Scenario-based versus asset-based In conducting a risk assessment, it is usually helpful to focus the participant s thoughts along one of two lines: the scenarios by which threats take advantage of vulnerabilities to impact assets or the assets themselves. The scenario-based approach tends to take advantage of experience with actual incidents or near-incidents. However, the approach may not penetrate to discover threats or vulnerabilities to sensitive assets that have not been previously threatened. The a sset-based approach tends to take advantage of knowledge of an organization s systems and work methods and particular assets whose compromise would lead to high economic impact. However, this approach may not penetrate to discover types of threats or vulnerabilities that would place these assets in jeopardy or scenarios that involve more than one asset. Whichever general approach is used, it is recommended that some aspect of the other approach be included to provide a more thorough risk assessment. EXAMPLE An organization that has identified assets as devices, applications and data is considered as an example that integrates scenario and asset-based methods. In the next step, the organization lists possible scenarios related to these assets and determines consequences as follows. Application scenarios are very similar to the device scenarios shown. a) Device scenarios 1) Scenario: Unauthorized user locally accessing an IACS device What is the consequence of someone walking up to the device and performing the tasks allowed at this device? 2) Scenario: Remote access of an IACS device by an unauthorized user What is the consequence of an unauthorized user gaining remote access to this device and performing any of the tasks allowed by this device? 3) Scenario: IACS device disabled or destroyed What is the consequence of a cyber incident that blocks the device from performing all or a subset of its normal functions? b) Data scenarios 1) Scenario: IACS data theft What is the consequence of someone stealing this data set? Does the data set have high intellectual property value? Is the data set of business value to a competitor? If publicly released, would the data set be an embarrassment to the organization? Is the data set required for regulatory compliance? Is the data set under a litigation hold order? 2) Scenario: IACS data corruption What is the potential consequence if: The data set was intercepted and changed between the source and destination? The data set was corrupted at the source? Is the data set required for regulatory compliance? Is the data set under a litigation hold order? 3) Scenario: IACS data denial of service What is the consequence if the user of the data was not able to access the IACS data set? NOTE A group might carry out scenario based risk assessment by starting from descriptions of incident scenarios and then determining consequences of the scenario, as shown in this example or start by creating a list of

143 ISA99, WG ISA , D7E undesirable consequences first, and then work backwards to develop possible incident scenarios that might create these consequences. A combination of these approaches may also be used. C Selecting the risk assessment methodology Selecting the right risk assessment methodology for an organization is very subjective, based upon a number of issues. Many of these methodologies are commercially available. Some of these are available at no charge; others require a license for use. Assessing these methodologies to find the one most useable for an organization can be a challenging task. Common to most methodologies is the premise that risk is a combination of the likelihood of an event occurring and consequences of that event. The complication is how to assign quantitative numbers to likelihood, which is typi cally expressed similar to a probability. Industry experience with process safety and accidents provides a large amount of historical quantitative data on which to base probability values. But, identifying the appropriate numbers for the likelihood of a specific cyber incident is not easy, not only because of a lack of historical data, but also because the past may not predict the future once vulnerability becomes known to potential attackers. Because of this complication, many companies and trade associations have chosen to develop their own methodology to address the threat and vulnerability concerns of specific importance to their company in a manner consistent with their corporate culture. Also for this reason, this standard uses the term likelihood, which has to do with estimations of human capabilities and intent, rather than the expected term probability, which has to do with the occurrence of natural events unbiased by human interference. Some methodologies support high-level risk assessment well. Some support detailed risk assessment well, by allowing input of vulnerability assessment results and they may also directly provide guidance for the associated detailed vulnerability assessment. An organization will find it effective to use a methodology that coherently supports both high-level and detailed risk assessment. EXAMPLE An example of a trade association helping with the task of selecting the right methodology, the American Chemistry Council s Chemical Information Technology Center (ChemITC) has pu blished a document titled Report on Cyber Security Vulnerability Assessment Methodologies Version 2.0. Error! Reference source not found. This document examines various elements of eleven different methodologies and compares them to a set of criteria important in a general-purpose cyber security risk methodology for assessing business IT systems, IACS and value chain systems. The report offers some sound advice for selecting a methodology. A portion of the guidance is included in the following with permission from CSCSP. a) Step 1 Filter The first step is to review the overview of the selected methodologies. The purpose of this step is to filter the methodologies of interest based on criteria such as ease of use, complexity, scope, resource requirements and type of methodology (see Error! Reference source not found., Appendix IV). b) Step 2 Select After identifying the methodologies, select the methodologies that fit the organization s needs (see Error! Reference source not found., Attachment II). Attachment II identifies the particular criteria that were used to assess the methodology. The criteria listed there address a much larger IT space beyond IACS. It may be that a methodology to address only a subset of the criteria used in the ChemITC study is necessary. Understanding the difference between the organization s needs and the evaluation criteria will be helpful when reviewing the synopses for the different methodologies. Then review the corresponding synopses to obtain more detailed information for assistance in making an informed methodology choice (see Error! Reference source not found., Appendix V). The synopsis for each methodology addresses the following topics: cyber security vulnerability assessment methodology, reviewers, date,

144 ISA , D7E5 142 ISA99, WG web address, general observations, strengths compared to the common evaluation criteria, gaps compared to the common evaluation criteria, how this methodology could be used, limitations on methodology use, and suggested revisions. c) Step 3 Validate (optional) If there is any uncertainty or difficulty choosing the methodology, review the technical criteria spreadsheets shown in the reference document for the methodology to validate the organization s choice(s) (see Error! Reference source not found. Attachment II). The technical criteria spreadsheet exists for each methodology. This step is optional because it simply provides even more specific evaluation data. d) Step 4 Acquire the selected methodology After narrowing down the methodology selection to one, obtain the methodology from the provider. The web addresses supplied in the bibliography are a good starting point. C High-level risk assessment Identifying risks Once a set of key stakeholders has been identified and provided with some training regarding the nature of IACS, they will perform a high-level risk assessment following the organization s selected methodology. This assessment process clarifies the nature of the individual risks to the organization that arise from the use of IACS. This clarity is needed to ultimately select the most cost-effective countermeasures to be designed or deployed and to help justify the costs of their deployment. While this task is the first step of a risk assessment, it is NOT a detailed vulnerability or threat assessment. It typically involves a risk analysis session to gather input from all stakeholders and takes advantage of high-level business consequences that may have been identified in the business rationale. The deliverable document from the risk analysis session is a list of scenarios that describe how a particular threat could take advantage of a particular type of vulnerability and damage particular assets resulting in identified negative business consequences. The same session may also address calibration of consequence level and prioritization by risk tolerance level. Stakeholders, who have experience with IACS applications in the business units and those responsible for the management of related risks, need to participate in the risk assessment effort to leverage their expertise and experience. In order to make the most efficient use of the participants time, it is normally necessary to schedule somewhere between a half and a full day to conduct the risk analysis session with all the stakeholder participants in attendance. There are two phases of this risk analysis session: background information and risk identification. Regardless of which risk assessment method is ultimately used, it is also important to provide the participants in the risk analysis session with appropriate background information before beginning to identify the risks. Typical background information includes an overview of the business ration ale and charter, an overview of IACS architectures and functions and an overview of specific types of incidents that occurred within the organization or publicized incidents that occurred in other organizations. For the session to be successful, it is also important that participants understand the working definitions for risks and vulnerabilities; otherwise, the session is likely to identify vulnerabilities but may not succeed in identifying risks. Examples are useful for this purpose. Thus, as an example,

145 ISA99, WG ISA , D7E vulnerability might be weak authentication on the control system HMI. The related threat might be that an employee with insufficient experience is able to operate the HMI without supervision and sets unsafe parameters. The consequence might be a stoppage of production due to safety controls being exercised. It is a common pitfall that an organization will list cyber vulnerabilities and then proceed to mitigate them. C High-level risk assessment Classifying risks C General The list of scenarios produced as an output of the risk analysis session describes a number of different risks posed to organizations by threats to IACS. One of the duties of corporate management is to manage all the risks to their organizations. To facilitate this effort risks need to be identified and prioritized. This subclause describes the three steps required to develop a framework to prioritize individual risks so the appropriate corrective actions can be justified. C The risk equation Before describing the framework for risk prioritization and calibration, it is important to understand a basic concept of risk analysis (for example, the risk equation). The likelihood of an event occurring takes into account both the likelihood that a threat that could cause an action will be realized and the likelihood that a vulnerability that allows the action will in fact be exploited by the threat. For example, for a virus to cripple a network, it needs to first reach the network and then needs to defeat antivirus controls on the network. If likelihood is expressed similar to a probability, then: LikelihoodEvent_Occurring = LikelihoodThreat_Realized LikelihoodVulnerability_Exploited (A.1) As discussed above, risk is made up of both likelihood and consequence, where consequence is the negative impact the organization experiences due to the specific harm to the organization s asset(s) by the specific threat or vulnerability. Risk = LikelihoodEvent_Occurring Consequence (A.2) C Calibrating likelihood and consequence scales Risk management systems have been developed within most organizations to deal with a wide variety of risks. In some cases the use of such systems has been mandated by regulatory requirements. These risk management systems make use of the same risk equation to prioritize the risks to the organization by the same type of threats to different assets (for example, information security) or by different threats to the same assets (that is, business continuity, industrial operation safety, environmental safety and physical security). In most org anizations, these risk management systems will already have developed scales for likelihood and consequence. A typical likelihood scale is shown in Table B.1. This scale is only an example; the organization will need to determine the actual values used in this scale for themselves. Table B.1 Typical likelihood scale Likelihood High Medium Category Description A threat/vulnerability whose occurrence is likely in the next year. A threat/vulnerability whose occurrence is likely in the next 10 years.

146 ISA , D7E5 144 ISA99, WG02 Low A threat/vulnerability for which there is no history of occurrence and for which the likelihood of occurrence is deemed unlikely Most organizations find it difficult to agree on likelihood, and little information is currently available to help. It is clear that differing opinions about this factor can radically change the investments made by the CSMS. Even though all may not agree with the final assessment on likelihood, the benefit of using it is that the assumptions being used to drive CSMS investment are clear for all to see. Since likelihood is the major factor of risk about which an organization has the least information and control, it is important to track improvements in industry data available to help make this factor more accurate. To address the issue of lack of agreement, some organizations use the following methods: Use a probability of 100% for likelihood and thus consider only consequences, or do this for certain types of consequences such as HSE Agree on a range of probabilities or likelihood categories and then work their prioritization process based on ranges Attempt more precision by consulting industry data that is available on attacks to IACS Attempt more precision by collecting internal incident data Separate likelihood into two factors the likelihood that an adversary will attempt an attack and the likelihood that they will succeed. Separating these factors can help to clarify the real source of disagreement. If it can be agreed by all that an attempt will succeed and the argument for low risk relies on hoping no attempt happens, that can change the tenor of the discussion. Consequence is usually measured in different terms for different types of risks. A typical consequence scale is shown in Table B.2Error! Reference source not found.. This example illustrates how cyber risk assessment can take process safety and other organizational risks into account. As above, this scale is only an example and will need to be calibrated for the organization. It is important to follow a high level of intellectual honesty when assessing the consequence s. During the assessment, identify assumptions that impact the level of consequence. For example, one might reasonably assume all the safety interlocks and shutdown systems are in place to minimize the impact of an event, since the likelihood of a cyber event in conjunction with an unrelated accident that disables safety systems is very small. However, in making this assumption, one also needs to consider whether there is a risk of an intentional cyber attack taking advantage of an accidental malfunction of safety systems or a coordinated physical or cyber attack causing such a malfunction. Other possible assumptions that may be called out are that operating practices are being followed to the extent typical of normal operation and fundamental lockout procedures are being followed. It is important for sites to honestly assess the risk, keeping in mind the sophistication and state of the control system and related operations and the dependency upon that system to operate the facility. Calibrating consequences is necessarily performed with respect to the interests and policies of the organization performing the risk assessment. Although the risk of the IACS may be very much impacted by the hazards associated with the industrial operations being controlled by the IACS, it is important to not confuse the risk to the organization with the risk to society. The industrial operations may not employ any hazardous materials but produce a very valuable in - demand product generating high revenues for the company. An IACS security incident resulting in an industrial operations upset, causing several days of off-specification product that cannot be sold, could have very high financial impact to the company. To this company, the IACS has a High-Risk level even though society may view this as a low-risk because there is no health, safety or environmental impact to the general public. Likewise, the same organization might also consider an industrial operation upset on a production facility using hazardous materials

147 ISA99, WG ISA , D7E as a high-risk consequence even if it did not impact production, due to internal policies and/or external regulations concerning public safety. Prior to convening a group to calibrate individual risks, clarify the likelihood and consequence scales to provide guidance to the team performing the risk assessment.

148 ISA , D7E5 146 ISA99, WG Table B.2 Typical consequence scale Consequence Risk area Business continuity planning Information security Industrial operation safety Environmental safety Manufacturing outage at one site Manufacturing outage at multiple sites Cost (million USD) Legal Public confidence People on-site People off-site Environment > 7 days > 1 day > 500 Felony criminal offense Loss of brand image Fatality Fatality or major community incident Citation by regional or national agency or long-term significant damage over large area > 2 days > 1 hour > 5 Misdemeano r criminal offense Loss of customer confidence Loss of workday or major injury Complaints or local community impact Citation by local agency < 1 day < 1 hour < 5 None None First aid or recordable injury No complaints Small, contained release below reportable limits National impact Infrastructure and services Impacts multiple business sectors or disrupts community services in a major way Potential to impact a business sector at a level beyond that of a single company. Potential to impact services of a community Little to no impact to business sectors beyond the individual company. Little to no impact on community services

149 ISA99, WG ISA , D7E5 Category A (high) B (medium) C (low) 5693

150 ISA , D7E5 148 ISA99, WG C Risk level The output of a qualitative risk assessment will consist of a list of assets or scenarios with an overall risk level ranking. This is typically developing in a matrix similar to the one shown in Table B.3, which defines three risk levels based upon three levels of likelihood and consequence. Thus each risk identified in the risk assessment is assigned a risk level. Again, this is meant as an example and will require further review by the organization. Table B.3 Typical risk level matrix Consequence category A B C High High-risk High-risk Medium-risk Likelihood Medium High-risk Medium-risk Low-risk Low Medium-risk Low-risk Low-risk The risk levels in each block (High, Medium and Low) each correspond to a particular combination of likelihood and consequence. An organization will define a risk tolerance policy related to each risk level, which will correspond to a particular level of corporate response. The actual approach to resolve the risk may be through the use of identified countermeasures. An initial version of this matrix should be prepared by responsible corporate management before the risk analysis process. This is the recommended method to insure that the risk assessment effort provides results that directly assist in decision making and are actionable by the organization. See C for further information about defining a risk tolerance policy and how the risk tolerance policy and risk assessment results are used to manage risks. C Detailed risk assessment C General A detailed risk assessment focuses on individual IACS networks and devices, and takes into account a detailed technical vulnerability assessment of these assets and the effectiveness of existing countermeasures. It may not be practical for all organizations to perform detailed risk assessment for all their IACS assets at once in this case an organization will gather enough information about their IACS to allow them to prioritize these systems to determine those to be analyzed first by the detailed vulnerability and risk assessment effort. A detailed risk assessment identifies risks and then prioritizes them. Risks should be identified for each IACS. After identifying the risks, an organization may choose to prioritize all the risks found across all of these systems, prioritize the risks individually for each system or prioritize risks found in subsets of the IACS studied, such as all IACS at a specific site. Since prioritization ultimately drives decisions on what actions will be taken and investments made to improve cyber security, the scope of the prioritization should align with the scope of the budget and the decision authority in place in the organization to make these investments. For example, if all IACS supporting a specific product line are managed and budgeted as a group, risks across those IACS would be prioritized together to support that manager s decision process. C Characterizing key IACS Identifying and prioritizing IACS risks requires that an organization locate and identify key IACS and their devices and the characteristics of these systems that drive risks. Without an inventory of the IACS devices and networks, it is difficult to assess and prioritize where security measures are required and where they will have the most impact.

151 ISA99, WG ISA , D7E The team shall meet with IACS personnel to identify the different IACS used throughout the site and that control remote sites. The focus should be on systems rather than just devices including but not limited to, control systems, measurement systems and monitoring systems that use a central HMI device. Include industrial operations areas, as well as utility areas such as powerhouses and waste-treatment facilities. As was noted above, the objective is to identify the major devices and kinds of devices that are in use and function collectively to operate the equipment under control. At this point in developing the security program it is not important to develop a comprehensive inventory of every device in the IACS, because the inventory will be used to make judgmental decisions about the relative risk the control devices introduce to the industrial operation. As examples, it is important to understand: Whether the field instrumentation and communication from the field transmitter to the controllers is analog-based or digital-based. Whether devices/systems are connected to each other and the types of networks used. Whether the devices are located within a secured area such as a building or fenced facility or whether the devices are located remotely. Whether the control devices are subject to regulatory control. Whether the loss or malfunction of the device/system is significant in terms of their impact on the equipment under control, both in business/financial and HSE terms. The resulting identification of devices/systems should show the scope of impact on the equ ipment under control if the devices lose control of the industrial operations they are applied to and their relative security vulnerability (from physical, network, or other factors). This kind of information can be used to understand the relative risk to the industrial operation. Conducting a comprehensive inventory to identify exact quantities of each kind of device is not necessary at this stage. C Grouping the devices and systems and developing an inventory As the team identifies the individual devices/systems, it may be helpful to put the items into a logical grouping of equipment. In modern IACS facilities, this collection of equipment functions as an integrated system to control the various activities of the industrial operation. The number of logical control systems in a company will vary widely. In a medium to large organization, there may be several hundred logical IACS comprised of thousands of individual devices and low-level systems. For medium to large organizations addressing cyber security on a company-wide basis, it may be very helpful to record the list of logical systems in a searchable database. DCS may be organized by line, unit, cell or vehicle within a local or remote geographical site. SCADA systems may be organized by control center, remote site and associated control equipment. The database will be more effective if the data are collected in a standard format to facilitate comparison of one system to another. Error! Reference source not found. is an example of a standard format that can be easily created in the form of a spreadsheet or database. It has been included to spur thinking about the kind of information that may be of use later in the system prioritization and detailed risk assessment activities.

152 ISA , D7E5 150 ISA99, WG02 Industrial automation and control system network characterization Business Site Operating unit Site IT contact Phone # Site process control contact Phone # Last updated PLEASE ANSWER THE FOLLOWING QUESTIONS : Are manufacturing and control systems currently interfaced to site or corporate LANs? Are manufacturing and control systems remotely accessed from outside the IACS domain? Process control domain Total number of IP addressable nodes Number of IP addressable nodes to be accessed from outside process control domain Number of concurrent users inside IACS domain Number of concurrent users inside IACS domain requiring access to external resources Number of total users outside IACS domain requiring access to process control resources Number of concurrent users outside IACS domain requiring access to process control resources IP addressing (check all that apply) DHCP Public addresses used (i.e. x.x.x.x) Static Private addresses used ( x.x) platforms Number of control platforms platform type (PLC, DCS, PC) platform vendor(s) platform model(s) Operator consoles and HMI devices Number of operator consoles Operator console vendor(s) Operator console model(s) Operator console operating system(s) Application nodes (check all that apply) Proccess management and control server SCADA OPC server Engineering workstation Batch server Other Network security barriers in-use Type (firewalls, routers, VLANS, etc.) Anticipated network security support (check all that apply) Site resources External (3rd party) Site network (answer yes / no) Current site network topology diagrams available and up-to-date? Are process control nodes on isolated LAN segment? Site information security policy in place? Security office audit completed (if yes, date completed ) Does site use two-factor authentication? Security office risk assessment completed (if yes, date completed ) Remote access requirements (check all that apply) Via site / corporate LAN Via dial-up modem Via internet Via local dial-up modem directly tied to manufacturing and control node(s) 5771 Local egress requirements (check all that apply) To site applications and resources (document management systems, quality systems, business systems) To corporate applications and resources (document management systems, quality systems, business systems) To internet sites

153 ISA99, WG ISA , D7E Figure B.4 Sample logical IACS data collection sheet Care should be taken when identifying industrial automation control devices/systems and focus attention beyond the devices that perform direct control. The system or network may be more than the PLC or DCS. In an integrated manufacturing or production facility, the IACS network is comprised of devices that are directly used to manufacture, inspect, manage and ship product and may include, in addition to others, the following components: DCSs and associated devices; SCADA systems and associated devices; PLCs and associated devices; HMI stations; SIS and associated devices; shop floor (special purpose) computers; process information management (PIM) systems and manufacturing execution systems (MES); industrial automation control modeling systems; expert systems; inspection systems; material handling and tracking systems; analyzers; gauging systems; batch systems; electrical power monitoring and/or management systems; remote telemetry systems; communication systems used for communication with remote devices; standard operating condition (SOC) and standard operating procedure (SOP) sys tems; document management systems; program development computers; HVAC control systems; network communication gateways (that is, switches, hubs and routers); network protection devices (that is, firewalls and intrusion detection systems). Consider including all CPU-based networked devices that are critical to sustaining production. The objective of this inventory step is to discover devices that are vulnerable to network -based attacks so they can be included in the detailed risk assessment. NOTE This time is not the decision point for deciding which devices should be isolated or separated from the LAN. Err on the side of including more devices rather than fewer. After performing the risk assessment and having a better understanding of the overall vulnerabilities, the assessment team should decide if risk mitigation solutions are truly necessary and where the various devices should be located. There are several enterprise-wide inventory tools commercially available that will work across networks to identify and document all hardware, systems and software resident on the network. Care shall be taken before using this type of application to identify IACS. Conduct an assessment of how these tools work and what impact they might have on the connected control equipm ent before using any of them.

154 ISA , D7E5 152 ISA99, WG Tool evaluation may include testing in similar, off-line, non-production control system environments to ensure the tool does not adversely affect the operation of the control system and interrupt production. While non-production devices may have no impact on production systems, they may send information that could (and has in the past) caused control systems failures or impairment. Impact could be due to the nature of the information and/or the system traffic and loading. Altho ugh this impact may be acceptable in IT systems, it is not acceptable in IACS. C Developing simple network diagrams A simple network diagram will be beneficial in grouping the various industrial automation and control devices and systems into an identifiable logical control system. It should include the devices identified with the Logical IACS Data Collection Sheet discussed in C The diagram should attempt to capture the basic logical network architecture, such as connectivity approaches, combined with some of the physical network architecture basics like location of devices. Before conducting prioritization of IACS or a detailed risk assessment, it is important that the team has a clear understanding of the scope/boundaries of the system to be assessed. A network diagram is a tool to help visualize the network and aid in performing the risk assessment. It can be a very simple block diagram showing devices, systems, and interface connections or more detailed like the one shown in Figure B.5. Either approach will be beneficial to meeting the objectives. If zones and conduits have been established, simple network diagrams should depict these elements. (More explanation on developing zones and conduits can be found in C ) Figure B.5 Example of a graphically rich logical network diagram Simple network diagrams are a starting point and represent a snapshot at one point in time. Experience in detailed vulnerability assessment shows that virtually every assessment turns up connections not identified in the initial diagramming process. Therefore these diagrams should not form the sole basis for assessing connectivity without more detailed physical validation. They are

155 ISA99, WG ISA , D7E valuable for scoping the risk assessment effort and for defining zones and conduits as described in ISA C Preliminary assessment of overall risk for each identified system Once the list of IACS devices, assets and networks has been completed, a preliminary assessment needs to be made as to the relative level of risk associated with the systems, so they can be prioritized for detailed risk assessment. If a detailed risk assessment is to be carried out on all IACS or if the high-level risk assessment has provided sufficient insight to prioritize individual IACS by risk, then this step will not be required. Each individual system shall be assessed to understand the financial and HSE consequences as identified in the high-level risk assessment, in the event that the availability, integrity or confidentiality of the system is compromised. Also, some measure of scale needs to be assigned to the assessment. Personnel familiar with the IACS shall conduct the screening assessment activity. IACS and IT personnel typically bring knowledge of the devices and systems in use, while the operations personnel typically bring an understanding of the consequences of a security incident. This team of resources shall work together to accomplish the screening assessment. The team will develop a high-level scale to quantitatively rate the overall risk associated with each system. The scale could be as simple as high, medium and low or 1 to 10 and shall establish the criteria for each gradation on the risk scale. The team will make a judgment decision on the level of risk associated with each system by examining the financial and HSE consequences in the event that the availability, integrity, or confidentiality of the system is compromised. The team should record the high-level risk assessment for the logical system in the inventory list developed earlier. Establishing risk tolerance levels helps to prioritize the actual assets in the IACS environment. The results of this preliminary assessment will be an important input to the decision to perform detailed vulnerability assessment for a particular IACS. A full vulnerability assessment shall be planned if: It is determined that the IACS is presently connected to the corporate network or to outside networks (for example, Internet, modems). A detailed risk assessment will help better understand the vulnerabilities and the appropriate mitigation strategy to reduce risk. It is determined that the system is currently supported remotely. It is anticipated that either of the two criteria above will be met in the near future. In that case, the vulnerability assessment should be performed before taking steps that result in thi s highrisk position. C Prioritizing the systems The previous subclause suggested assigning a vulnerability/risk rating to each logical IACS identified. This rating scale is a good place to start the prioritization process. However, there are several additional things to consider when deciding where to begin focusing detailed risk assessment efforts, such as: risk to the company (for example, HSE or financial); places where assessment process is likely to be most successful; cost of the potential countermeasures required; capital versus non-capital costs; skilled support staff available for the particular system;

156 ISA , D7E5 154 ISA99, WG geographic region; member trade association directives or sensitivities; country or local political requirements; outsourced or in-house support staff; site support to undertake the effort; history of known cyber security problems. There is no right or wrong approach. The values will be different for each company. What is important is to use the same prioritization principles across all the sites. Reco rd the prioritization decisions made and the basis for making them. C Identifying vulnerabilities and prioritizing risks The next step in the risk assessment process is actually conducting the detailed risk assessment on the prioritized systems. Most methodologies employ an approach to break the system down into smaller pieces and examine the risks associated with these smaller elements comprising the overall system. A detailed risk assessment should address physical and cyber security threats, internal and external threats and consider hardware, software, and information as sources for vulnerabilities. It is imperative that a team of people performs the assessment to bring a well-rounded perspective to the assessment. The team should be comprised of, at a minimum, a lead site operations person, site IACS person, site IT person and site network person. Others to be considered include experts in physical security, information system security, legal, business (operations, maintenance, engineering, etc.), human resources, HSE and hardware vendors. These people are in the best position to recognize vulnerabilities and the consequence of risk for their specific areas. Although the goal is to understand the threats and consequences associated with a particular system, it is quite likely that a key objective is to be able to compare the assessment results from one system/site to another across the organization. The ability to do this will depend on how consistently the methodology is applied. Some proven approaches include: using a key person to lead the assessment process at each site; using a small team of people to lead the assessments based upon geography, business unit, and the like, who have participated with each other in other assessments; using good training materials with procedure and exercises to level-set the team of individuals who will conduct the assessments at each site; using a common form or database to record assessment results; centrally reviewing all the assessment results to check if the results seem realistic and comparable to other similar systems. When conducting the assessment, consider all aspects of the IACS, including unintended changes in system configuration brought about by maintenance, temporary supplier connections to the system for support and even subtle changes in supplier design that could introduce new vulnerabilities through spare parts or upgrades, which should be considered and/or tested in the same manner as the original system components. The assessment needs to address systems that interface with the IACS as well to ensure that they cannot compromise the IACS security or vice versa. Examples include development systems that provide online development capabilities and environmental and power systems whose compromise could create unacceptable risks.

157 ISA99, WG ISA , D7E In some cases, the vulnerability may lie with the vendor. Vendor quality assurance and design control may require a vulnerability assessment. This step is particularly important when ordering spare parts or upgrades. At this point in the assessment process, a detailed examination of the network from a physical and operational viewpoint should be carried out in order to uncover any connections not shown in the initial simple network diagrams. Many assessments will find such connections. The following potential sources for vulnerabilities related to network connectivity have been previously identified as weaknesses in certain systems and should be identified and examined: wireless access points, particularly poorly secured technologies such as early versions of IEEE ; modem connections, particularly those that do not dial back and do not provide encryption; remote access software (for example, pcanywhere 3 and Timbuktu ) programs that are typically used for access by experts within or outside the entity to support systems or operations. These applications can provide significant control and configuration access to an unauthorized individual; remote windowing technologies such as X Windows ; Intranet connections; Internet connections; telemetry networks; any network connection to systems that are not a direct part of the IACS; any network connections used to couple parts of the SCADA or control system togethe r that are not part of a physically secure, dedicated IACS network. In other words, any network that extends beyond the boundary of a single security zone or across insecure zones or is used for both IACS and other functions at the same time. Equipment included in network connections includes radio telemetry and outsourced services such as frame relay used to communicate between geographically separated areas. A number of industry resources cover control system security and provide lists of typical vulnerabilities to look for in a detailed vulnerability assessment (see Error! Reference source not found. and Error! Reference source not found.). The team s ultimate output is a list of vulnerabilities prioritized by their impact on risk. After vulnerabilities have been identified, the team then associates these vulnerabilities with threats, consequences and associated likelihoods for realization of the threat and exercise of the vulnerability. This analysis takes into account potential mitigation due to physical security measures. Those vulnerabilities that contribute to the highest level risks are typically easy to agree upon. To complete the vulnerability assessment process, the team s methodology should include an agreed method to determine how to prioritize vulnerabilities that contribute to a lar ge number of medium and low-level risks. Detailed risk assessment results shall be documented and action taken on recommendations resulting from them (see C.4.4.2). Documentation of the detailed vulnerabilities found during the detailed risk assessment typically includes for each vulnerability found, the date of assessment, identification of assets involved, description of the vulnerability, name of an individual who observed the vulnerability and any tools 3 pcanywhere, Timbuktu and X Windows are examples of suitable products available commercially. This information is given for the convenience of users of this document and does not constitute an endorsement by ISA of these products.

158 ISA , D7E5 156 ISA99, WG or methods they used in order to do so. In addition to vulnerabilities found, the documentation of the detailed vulnerability assessment should include vulnerabilities checked for but not found to be present and how this was verified for each asset assessed. This may take the form of a simple checklist. Documentation of vulnerabilities provides great leverage when updating the risk assessment and when specific questions about assets are raised. Prior vulnerability checklists and results form a baseline from which to improve vulnerability assessments in the future and a basis for consistency across an organization. An organization should view them in this light and avoid viewing them as a static definition of the contents of such an assessment. Tasks and documentation related to the high-level and detailed risk assessment processes described in this subclause and the risk management process in C can be integrated for efficiency to suit the needs of a particular organization. The detailed risk assessment results should be updated and revalidated on a periodic basis. In addition, since a detailed risk assessment can become out of date due to changes in the environment of a control system, triggers for an updated risk assessment effort should be incorporated into the management of change program. This is a critical point, since most organizations find it easier to establish a cyber security baseline than to maintain it over time (see C.5.3). C Pitfalls to avoid During the assessment, common pitfalls that can derail the risk assessment process should be avoided through the following actions: a) Designing the solution during the assessment The purpose of the assessment is to learn what risks exist, not to design the solution as a team. A lot of time can be wasted by trying to solve the problem and debating one approach versus another while assessing one particular asset. The focus should be on understanding the risks and consequences that currently exist or may occur in the foreseeable future, su ch as a project currently underway to add a new model device with a network interface. b) Minimizing or overstating the consequence An honest assessment of the consequence of an incident affecting a particular hardware, software or information asset should be provided. Consequences should not be minimized for the purpose of avoiding taking proper security risk mitigation actions to reduce risk. What may be very important to one particular person because it directly impacts his or her job, may have a very different level of consequence to the organization as a whole. c) Failing to gain consensus on the risk assessment results Reaching agreement on the risks and consequences is extremely important. It will be much harder to reach agreement on the countermeasures if the team does not have a common understanding of the risk and agreement on the importance. d) Assessing the system without considering the assessment results from other similar systems It is important to validate that the results are appropriate and consisten t with those of similar assessment processes at other sites. The conclusions from previous similar system assessments and the vulnerabilities identified can be very beneficial to the assessment of the system at hand. C Interrelationship with physical security measures Cyber security and physical security may be closely related. In some situations they may function as independent layers of protection and in other situations they are highly dependent upon each other. The loss of one may represent a loss of both layers of protection. During the detailed risk assessment for a system, the potential interaction and how it may affect the consequences should be kept in mind.

159 ISA99, WG ISA , D7E In some industries, it is common practice to have a SIS in addition to the IACS. If the SIS is relay based, the likelihood of it being affected by a cyber event that impacts the IACS is small. The SIS can be counted upon to perform its safety function and the consequence of a cyber event may be contained and reduced. However, if the SIS is electronically based and tied to the same network as the IACS (some industries do not recommend this practice), the likelihood of a cyber incident impacting both systems is much higher and the consequence could be greater. Another example might be a badge access system to a locked control room. Under normal situations, the access control system provides additional security to the control systems. However, in the event of a denial of service (DoS) flood of the network, the door access control system could fail to function and impede the operator s ability to gain access to the control room operator console. The same DoS network overload could be affecting the operator console as well. In this situation, the single cyber incident serves as a double impediment to responding to the control device and could increase the consequence of the incident. Eventually, cyber security risk assessment methodologies should be incorporated into physical and site risk assessment methodologies. C Risk assessment and the IACS lifecycle The previous subclauses describe how the process of risk assessment can be carried out on existing IACS when first establishing a CSMS and applied periodically thereafter. Risk assessment is most effective and least disruptive when applied in a similar fashion during the various stages of the lifecycle of the IACS before it is running in production mode: a) During development of a new or updated IACS Cyber risk should be considered in advance before implementing a new or modified IACS, since experience has shown it will always be easier and less expensive to consider security during the design phase than to add it later. The process for high-level risk assessment proceeds in the same way for a future system as described above for an existing system. The assessment is ideally performed in parallel with high-level design and the results of the proposed design and risk assessment are reviewed together. A detailed risk assessment can also be carried out in parallel with detailed design, though vulnerabilities identified are hypothetical and will not in all cases be as specific as for an already implemented system. In this way, risk assessment during development can drive decisions about what countermeasures should be put in place along with the desired IACS improvements, to minimize surprises after implementation. b) During implementation of a new or updated IACS Even with attention to risk during the development phase, implementation details may introduce unexpected vulnerabilities. In the best case, part of the acceptance process for a new or updated IACS includes not only testing, but also a detailed vulnerability analysis as previously described. Thus, for example, an organization may need to determine whether to turn on a new or updated system before a patch to a recently discovered vulnerability is available for the underlying operating system. c) During retirement of an IACS The decision to retire or retain an IACS or components of an IACS is based upon many factors, including cost, desire for new functionality or capacity, ongoing reliability and availability of vendor support. Impact on cyber security is also a factor to be weighed in this decision. New components and architectures may improve security functionality and/or introduce new vulnerabilities that need to be addressed. Hence a cyber risk assessment that analyzes a retirement decision examines both the scenario in which the old system is replaced and the scenario in which the old system is retained for some period of time. High-level and detail risk assessments are updated upon the retirement of an IACS for two reasons: 1) the removal of the IACS may impact the vulnerability of some IACS that remain in place and 2) if the IACS is replaced by a new system, new vulnerabilities may be introduced

160 ISA , D7E5 158 ISA99, WG as discussed earlier. An example of this is that network connectivity to an IACS that remains in place may have always taken place through the IACS being removed. This means that a new connectivity design is put in place for the remaining IACS and this configuration should be assessed for vulnerabilities and associated risks. C Supporting practices C Baseline practices The following ten actions are baseline practices: a) Establishing the criteria for identifying which devices comprise the IACS. b) Identifying devices that support critical business processes and IACS operations including the IT systems that support these business processes and IACS operations. c) Classifying the logical assets and components based on availability, integrity, and confidentiality, as well as HSE impact. d) Prioritizing risk assessment activities based on consequence (for example, industrial operations with known high hazards are addressed with a high priority). e) Scoping the boundaries of the system to be assessed, identifying all assets and critical components. f) Developing a network diagram of the IACS (see C ). g) Understanding that risks, risk tolerance and acceptability of countermeasures may vary by geographic region or business organization. h) Maintaining an up-to-date record of all devices comprising the IACS for future assessments. i) Conducting a risk assessment through all stages of the technology lifecycle (development, implementation, updating and retirement). j) Identifying reassessment frequency or triggering criteria based on technology, organization or industrial operation changes. C Additional practices The following four actions are additional practices: a) Identifying and classifying assets to aid in defining the company s risk. Important focus areas should be people involved and technologies used. The creation of a checklist helps group the assets into categories (see C ). b) Classifying individual assets based on the safety implications of availability, integrity, and confidentiality. An asset could have different levels of classification for each of the categories. EXAMPLE Classification for a specific type of data: Availability: low the system does not require continuous operation. The system is not part of a hazardous operation. A delay of up to one or two days would be acceptable. Integrity: medium the data is verified at various stages and changes to it would be detected. Confidentiality: very high the business critical data should be maintained at the highest confidential level. c) Establishing the likelihood (that is, probability or estimated frequency) that a particular threat will be successful, in view of the current level of controls. It is important to look at other typical controls that may be in place in manufacturing/operations that would supplement cyber security controls to reduce the likelihood of the consequence occurring. These include independent SIS and other PSM techniques such as passive, auxiliary, independent back-up devices. The estimated frequency is directly related to the overall vulnerability and threats and could be expressed quantitatively as a percentage or more subjectively as high, medium or low.

161 ISA99, WG ISA , D7E d) Defining the consequences or impact of a successful threat attempt based on the business or IACS risk evaluation. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: [16], Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C.4 Category: Addressing risk with the CSMS C.4.1 Description of category The second main category of the CSMS is Addressing Risk with the CSMS. This category contains the bulk of the requirements and information contained in the CSMS. It is divided into three element groups: C.4.2 Security policy, organization and awareness, Selected security countermeasures and Implementation. C Element group: Security policy, organization and awareness Description of element group The first element group in this category discusses the development of the basic cyber security policies, the organizations responsible for cyber security and the awareness within the organization of cyber security issues. Figure B.6 shows a graphical representation of the five elements contained in the element group: CSMS scope, Organizing for security, Staff training and security awareness, Business continuity plan and Security policies and procedures. CSMS scope Addressing risk with the CSMS Security policy, organization and awareness Organize for security Security policies and procedures Staff training and security awareness Business continuity plan Figure B.6 Graphical view of element group: Security policy, organization, and awareness

162 ISA , D7E5 160 ISA99, WG C Element: CSMS scope C Description of the element With the business rationale established and management support obtained, the next step is to develop a formal scope or charter for the effort. This scope should explain what is to be accomplished (in business terms) and when. It defines the specific entity of focus. This scope statement should be owned by a senior executive program champion, or by a management team who will be responsible for guiding the team during program development. The champion will ultimately be responsible for making sure that the program is executed, including communications, funding, enforcement and auditing. Ultimately, the CSMS shall encompass all business units and all geographic parts of the organization. If leadership commitment cannot be obtained initially for this scope of work, define a smaller scope of work and use this as an opportunity to build credibility and demonstrate the value of the CSMS. C Developing the CSMS scope Management needs to understand the boundaries where the CSMS apply to the organization as well as establish a direction and focus for the CSMS. By developing a clearly defined scope, it is easier for management to convey its goals and purpose for the CSMS. The scope should include all aspects of the IACS, integration points with business partners, customers and suppliers. A management framework (for example, organization) should be established to initiate and control the implementation and ongoing operations of cyber security within the company. An organization responsible for determining and communicating corporate policies as they relate to cyber security is important to protect corporate assets from a cyber security perspective. Companies need to recognize that in today s Internet-driven business world, electronic information connectivity is an integral part of doing business and thus cyber security is essentia l. Business transactions are not only contained within the organization s Internet firewall, but are extended to customers, vendors, third-party contractors and outsourcing partners. The overall scope of work needs to be clarified from three different perspectives: business, architectural and functional. From a business perspective the scope of work needs to answer questions similar to: Which corporations are included? Which business units are included? Which geographical regions are included? Which specific sites are included? From an architectural standpoint, the scope of work needs to answer questions similar to: Which computer systems and networks will be addressed? Will SCADA and distribution monitoring systems be included? Will non production-related computer systems (both those supported and unsupported by the IT organization) in manufacturing be included? Will manufacturing execution systems (MES) be included? Will burner management systems and SIS be included? Will robotic systems be included?

163 ISA99, WG ISA , D7E Will connections to suppliers or customers be included? From the functional standpoint, the scope of work can be divided into the following two categories: a) Direct risk management activities These are activities that involve the evaluation, communication and prioritization of risk. Examples include designation of local cyber security owners, collecting and maintaining an asset inventory, developing and maintaining the network architecture, completing internal or external audits and reporting these results on a business unit or corporate basis. b) Risk management related projects These are activities funded on the basis of reducing the risks identified by the risk management activities. These indirect risk management solutions take the form of projects that are bounded in time and the development and deployment of ongoing services. In clarifying the functional scope, questions similar to the following should be considered: How does the scope of this work relate to existing risk management systems? How does the scope of this work relate to information security policies that already apply to these systems and organizations? How does the scope of this work relate to technical standards and procedures that already apply to specific architectural components (that is, basic process control systems, SCADA systems, SIS, burner management systems and robotic systems)? How does the scope of this work relate to projects that are already funded? How does the scope of this work relate to existing services? Leadership support provides the endorsement of the effort by managers who are responsible for assigning resources to manage and implement the tasks to reduce risks to the IACS. The scope should be owned by a senior executive program champion who will be responsible for guiding the team during program development. The champion will ultimately be responsible for making sure that the program is executed, including communications, funding, enforcement and auditing. With support and commitment from senior leadership, stakeholders should be identified and their time to work on improving security should be allocated. The stakeholders are responsible for moving the security initiative forward. With support from senior leadership the stakeholders initiate the next activities and engage the right resources to accomplish the tasks. Form an integrated team that involves traditional desktop and business computing systems, IACS and systems that interact with customers, suppliers and transportation providers. The charter and scope mentioned earlier bring focus on who needs to be involved to meet the objectives of the initiative. It is likely that senior leadership may identify a project leader whose job it is to round up the right people to work on the security effort. This person shall have a high-level understanding of the current state of cyber security procedures in the company. Assuming that the goal is to improve the cyber security policies and procedures for IACS, the project leader should look for the areas that could be affected by IACS cyber security incidents and identify the key people that are recognized as responsible/accountable for these areas. The focus should be on identifying people in the right role, independent of the organization to which they are assigned. It is important to note that different company organizational structures may have these people in different organizations. The goal is to develop a cost-effective CSMS that leverages existing business processes and organizations rather than create a whole new organization. People who are already in the right role and with the right experience should be selected when possible. Breaking down turf issues may be an important activity of this stakeholder team.

164 ISA , D7E5 162 ISA99, WG The core team of stakeholders should be cross-functional in nature and bring together skills not typically found in any single person. The team should include people with the following roles: IACS person(s) who may be implementing and supporting the IACS devices; operations person(s) responsible for making the product and meeting customer orders; process safety management person(s) whose job it is to ensure that no HSE incidents occur; IT person(s) who may be responsible for network design and operation, support of desktops and servers, and the like; security person(s) associated with physical and IT security at the site; additional resources which may be in the legal, human resources and customer support or order fulfillment roles. The set of stakeholders may change over time or specific individuals may take on higher -profile roles during different phases or activities while developing the CSMS. It is not important which organization leads the effort, but rather that the leader exhibits the right set of behaviors that foster working together as a team with a unified purpose. The parent organizations to which the above individuals are aligned each have something to offer and have a stake in decisions and outcome of the CSMS. C Suggested practices C Baseline practices The following three actions are baseline practices: a) Describing the organization(s) responsible for establishing, communicating, and monitoring cyber security within the company. b) Stating the scope of the CSMS, including: information systems including all operating systems, databases, applications, joint ventures and third-party business activities; IACS including all process control systems, SCADA systems, PLCs, DCSs, configuration workstations and plant or lab information systems for both real-time and historical data; networks, local area networks (LANs), wide area networks (WANs) including hardware, applications, firewalls, intrusion detection systems, and the like; integration points with support and service providers; user responsibilities including policies to address authentication and auditability; information protection including access requirements and individual accountability; risk management including processes to identify and mitigate risks and document residual risk; disaster recovery including identification of critical software/services; training requirements; conformance, compliance and audit; asset identification. c) Characterizing the organization responsible for the CSMS, including: organization structure; location; budget;

165 ISA99, WG ISA , D7E roles and responsibilities associated with the CSMS processes. C Additional practices The following five actions are additional practices: a) Having management endorse the scope and responsibilities of the CSMS. b) Having a clear understanding of the roles and responsibilities associated with the organization(s) responsible for some aspect of the CSMS. c) Documenting the scope of the CSMS with separate subclauses addressing specific components. d) Addressing business, legal (for example, Data Privacy), and regulatory requirements and responsibilities. e) Identifying and documenting the dependency of process safety on cyber security and physical security practices and procedures including a framework for organizational interaction. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: [16], Error! Reference source not found.. C Element: Organizing for security C Description of element Companies should establish an organization, structure, or network of people with responsibility for overall security recognizing there are physical as well as cyber components that should be addressed. It is important to establish accountability to provide direction and oversight to an organization s cyber security. Cyber security in the broadest sense covers not only data, but also the systems (hardware and software) that generate or store this information and includes elements of physical security as well. IACS, value-chain partners, third-party contractors, joint venture partners, outsourcing partners and physical security specialists should be considered by the organization as part of the overall security structure and hence included in the scope of responsibility. C Building an organizational framework for security The commitment to a security program begins at the top. Senior management shall demonstrate a clear commitment to cyber security. Cyber security is a business responsibility shared by all members of the enterprise and especially by leading members of the business, man ufacturing, IT and risk management teams. Cyber security programs with visible, top-level support and buy-in from organization leaders are more likely to gain conformance, function more effectively and have earlier success. A management framework should be established to initiate and control the implementation of an overall security program. The scope and responsibilities of cyber security for organizations should include physical security and cyber security for IT systems, IACS suppliers, third party contr actors, outsourcing partners and the value-chain components of the organization. An overall security program should be extended to include joint venture operations. Organizations should establish a framework with management leadership to approve the cyber security policy, assign security roles and coordinate the implementation of cyber security across the organization. The framework may face some interesting organizational challenges. Many companies are organized in a three-dimensional matrix where one dimension is by business line, a second dimension is by function or discipline and a third dimension is by geographical region. Individual managers typically have responsibilities for some part of this overall organization. Because a system is only as secure as its weakest link, a cyber security system will ultimately need to be developed that spans the entire geographical reach of the organization.

166 ISA , D7E5 164 ISA99, WG Cyber security deals with a number of different risks that can generally be classified into concerns about availability, integrity or confidentiality. Concerns about availability would typically be managed by a business continuity planning program or network security program. Concerns about integrity in a manufacturing context are typically managed by a process safety or quality assurance program. Concerns about confidentiality are typically managed by an information security program. Because cyber security affects so many different risk areas, it is likely that no one single manager will have the necessary scope of responsibility to authorize a cyber security program for all IACS. It will often be necessary to convene and convince a small group of senior managers who, quite possibly, have never had to work closely together before to make a consensual decision. Either an overall enterprise (for example, a corporation) or individual sub-organizations within the enterprise may work toward conformance with this standard. If the overall enterprise is to conform, risk is assessed across the total enterprise. In this case, for example, individual plants within the corporation may carry out risk assessments, but will use a common risk assessment methodology that allows compilation of these assessments at the corporate level. Thus if an overall enterprise has a goal to achieve conformance, it will find it necessary to set guidelines to support this, even if individual sub-organizations such as plants do much of the work. Other possibilities are that the overall enterprise is not attempting to meet the standard, but is requesting its sub-organizations at some level to do so individually or that some sub-organizations are attempting to meet the standard on their own initiative. In either of these cases the enterprise will still need to support these sub-organizations in meeting any specific requirements in the standard that are handled at the enterprise level, such as securing corporately provided architectures, employee screening and wording of contracts with service suppliers. Under these scenarios, for example, an individual plant site could have its own risk assessment methodology, determine its own mitigation priorities and have plant level senior management supporting the effort. And in these cases the enterprise is not evaluating its own overall conformance with the standard, although it potentially might evaluate conformance of individual plants. This strategy would make the most sense for a highly decentralized diverse corporation or other enterprise. C Getting started and gaining support For senior managers to effectively champion a cyber security program they must be convinced that the costs of the program they will pay out of their budgets will be less than the impact of the threat on their areas of responsibility. It may be necessary to develop a business rationale or a busin ess case for managing cyber security risks to convince leadership to support the program. Budgetary responsibilities and scopes of responsibility will need to be clarified amongst the senior leadership. Due to the constraints of time, many senior managers have trusted advisers they use to filter the important issues they need to address from the issues that others are more suited to address. These individuals are gatekeepers. In large organizations, there are frequently staff organizations that senior managers use to generate recommendations for technically complex issues. It may be necessary to work with these staff organizations initially to collect sufficient information to make the business case. These organizations may also be able to provide insight into which senior managers typically handle specific types of risks. It is likely that senior leadership may identify a project leader whose job it is to round up the right people to work on the security effort. This person shall have a high-level understanding of the current state of cyber security procedures in the company. It is important to recognize that a truly integrated CSMS involves traditional desktop and business computing systems, IACS and value chain systems that interact with customers, suppliers and transportation providers. The charter and scope mentioned earlier bring focus on who needs to be involved to meet the objectives of the initiative. The project leader should look for the areas that could be affected by IACS cyber security incidents and identify the key people that are recognized as responsible/accountable for these areas. The

167 ISA99, WG ISA , D7E focus should be on identifying people in the right role, independent of the organization to which they are assigned. It is important to note that different company organizational structures may have these people in different organizations. The goal is to develop a cost-effective CSMS that leverage existing business processes and organizations rather than create a whole new organization. People who are already in the right role and with the right experience should be selected where possible. Breaking down turf issues may be an important activity of this stakeholder team. The core team of stakeholders should be cross-functional in nature and bring together skills not typically found in any single person. The team should include people with the following roles: IACS person(s) who may be implementing and supporting the IACS devices; operations person(s) responsible for making the product and meeting customer orders; process safety management person(s) whose job it is to ensure that no health, safety and environmental incidents occur; IT person(s) who may be responsible for network design and operation, support of desktops and servers, and the like; security person(s) associated with physical and IT security at the site; additional resources which may be in the legal, human resources and customer support or order fulfillment roles. The set of stakeholders may change over time or specific individuals may take on higher prof ile roles during different phases or activities in the life of developing the CSMS. It is not important which company organization leads the effort, but rather that the leader exhibits the right set of behaviors that foster working together as a team with a unified purpose. The parent organizations to which the above individuals are aligned each have something to offer and have a stake in decisions and outcome of the CSMS. One common practice to convince senior manager is to test new programs in a small geographic region or at a particular site to prove that new procedures/programs work prior to devoting a large amount of resources. This can be another effective approach to either get access to senior managers or actually make the business case to senior managers. Once the appropriate senior managers have been identified, it is important to decide whether to present the CSMS to them all as a group or to approach them sequentially. It is more efficient to convince them all simultaneously, but they may not all be receptive to the discussion simultaneously. If there is a need to persuade a leadership team, it is helpful to identify an ally on the leadership team to review the presentation and offer input before making the presentation to the whole team. Due to the number of different risk areas that are affected by cyber security, it is not uncommon to require persuasion of more than one leadership team. If the costs of the cyber security program cannot be determined initially due to lack of a computer inventory or lack of standard countermeasures, a second round of presentations may be required once these costs are determined more precisely. The emphasis at this early stage needs to be on putting a system in place to balance the costs of the countermeasures with the costs of the risks. Usually there is inadequate information at this stage to request a specific budget for implementing countermeasures. C Supporting practices C Baseline practices The following five actions are baseline practices:

168 ISA , D7E5 166 ISA99, WG a) Obtaining executive management commitment for setting up an organizational framework to address security. b) Assigning responsibility for cyber and physical security to personnel with an appropriate level of funding to implement security policies. c) Initiating a company-wide security team (or organization) to provide clear direction, commitment and oversight. The team can be an informal network, organizational or hierarchical structure spanning different company departments or organizations. This team assigns responsibilities and confirms that business processes are in place to protect company assets and information. d) Establishing or modifying contracts to address cyber and physical security policies and procedures of business partners, third-party contractors, outsourcing partners, and the like, where the security policies and procedures of those external partners affect the security of the IACS. e) Coordinating or integrating the physical security organization where an overlap and/or synergy between physical and cyber security risks. C Additional practices The following four actions are additional practices: a) Establishing the responsibility for IACS cyber security: A single individual from any of several functions is responsible for cyber security for the entire organization. This individual chairs a cross-functional team representing the various business units and functional departments. The team demonstrates a commitment to cyber security and sets a clear direction for the organization. This includes asset and industrial operation ownership as well as providing the appropriate resources for addressing security issues. A separate team is responsible for the security of IACS under either a manufacturing or engineering organization. While this approach has the advantage of having leadership knowledgeable of the risks associated with IACS, the benefits of such an approach can be lost if this team does not coordinate closely with those responsible for traditional IT assets and physical security. An overall security team is responsible for both physical and logical assets. In this hierarchical structure, security is under a single organization with separate teams responsible for physical and information systems. This approach is useful in smaller organizations where resources may be limited. b) Coordinating efforts with law enforcement agencies, regulators, and Internet service providers along with other relevant organizations, as it relates to terrorist or other external threats. Organizations that have established relationships with local emergency response personnel expand these relationships to include information sharing as well as responding to cyber security incidents. c) Holding external suppliers that have an impact on the security of the organization to the same security policies and procedures to maintain the overall level of IACS security. Security policies and procedures of second and third-tier suppliers should also be in compliance with corporate cyber security policies and procedures if they will impact IACS security: companies should consider the increased security risk associated with outsourcing as part of the decision making process to determine what to outsource and outsourcing partner selection; contracts with external suppliers governing physical, as well as logical access; confidentiality or nondisclosure expectations and intellectual property rights should be clearly defined;

169 ISA99, WG ISA , D7E change management procedures should be clearly defined. d) Removing external supplier access at the conclusion/termination of the contract. The timeliness of this is critical and is clearly detailed in the contract. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C Element: Staff training and security awareness C Description of the element Security awareness for all personnel is an essential tool for reducing cyber security risks. Knowledgeable and vigilant staff is one of the most important lines of defense in securing any system. In the area of IACS, the same emphasis shall be placed on cyber security as on safety and operational integrity, because the consequences can be just as severe. It is therefore important for all personnel (employee, contract or third-party) to understand the importance of security in maintaining the operation of the system. Staff training and security awareness programs provide all personnel (employees, contractors, and the like) with the information necessary to identify, review, address and where appropriate, remediate vulnerabilities and threats to IACS and to help ensure their own work practices include effective countermeasures. All personnel should receive adequate technical training associated with the known threats and vulnerabilities of hardware, software and social engineering. Cyber security training and security awareness programs are most effective if they are tailored to the audience, consistent with company policy and communicated regularly. Training provides a means to communicate key messages to personnel in a timely fashion. An effective training program can help employees understand why new or updated security controls are required and generate ideas they can use to reduce risks and the impact on the organization if control methods are not incorporated. C Developing a staff training program and building security awareness Training of one sort or another is an activity that spans almost the entire period during which a CSMS is developed and implemented. It begins after the scope of the effort is clarified and the team of stakeholders is identified. The objective of the training program is to provide all personnel with the information they need so that they will be aware of any possible threats to the system and their responsibilities for the safe and secure operation of the production facilities. The organization should design and develop a cyber security training program in conjunction with the organization s overall training program. Training should be in two phases: 1) general training for all personnel and 2) role-based training aimed at specific duties and responsibilities. Before beginning the development of the training program it is important to identify the scope and boundaries for the training and to identify and define the various roles within the organization. The general training program should be developed for all personnel. Users should be trained in the correct security procedures, the correct use of information processing facilities and the correct handling of information in order to minimize risks. Training should also include legal responsibilities, business controls and individual security responsibilities. Role-based training should focus on the security risks and responsibilities associated with the specific role a person fills within the organization. These individuals will need more specific and intensive training. Subject matter experts should be employed to contribu te to this training. Rolebased training may be conducted in the classroom, may be web-based or hands-on. This training may also leverage training provided by vendors for in-depth discussion of tools and associated exposures.

170 ISA , D7E5 168 ISA99, WG The program should include a means to review and revise the program, as required and a means to evaluate the effectiveness of the program. Also, there should be a time defined for periodic retraining. Management s commitment to training and ensuring adequate cyber security awareness is critical to providing a stable and secure computing environment for both IT and IACS. In particular for the IACS environment, a stable and secure computing environment aids in maintaining the safe operation of the equipment under control and reducing HSE incidents. This should be in the form of resources for developing and organizing the training and making staff available to attend. Following the development of a cyber security training program, the organization should provide the appropriate training for all personnel. Training programs should be provided in a place and at times that allow personnel to be trained without adversely affecting their other responsibilities. General training should be provided as part of a new employee s orientation and as a p art of the orientation for contract, temporary or third-party personnel. The training required should be appropriate for the level of contact which they will have with the organization. Specialized training may be provided as follows: a) Training for stakeholders Training is appropriate for the team of stakeholders as well as the community of individuals in the IACS community who will ultimately be impacted. The team of stakeholders will need specific training on the type of risks that are being considered, the scope and charter of work that management has approved, any background information on incidents that have occurred to these systems either within the organization or within the industry in general and on the types of architectures and systems that are in use within the organization. Formal classroom training is not necessary to share this information. Presentations at business meetings, communication sessions and announcements are examples of ways to share the information. b) Training employees preparing for new roles Training will be needed for employees as they prepare to assume new roles either within the direct risk management system or within the risk management related projects. Virtually all members of the IACS community will receive a certain amount of training during this phase. Some of the direct risk management roles will include responsibilities for self-assessments or internal audits. c) Training of auditors Training will be needed for auditors to help them understand the nature of the systems and networks they will be auditing as well as the specific policies that have been created. d) Ongoing training There will be an ongoing need for training at all levels due to the addition of new employees and third-party personnel, the need to provide updates as policies and services are modified over time and to provide refresher training to ensure that personnel remain competent in their roles and responsibilities. It is important to validate that personnel are aware of their roles and responsibilities as part of the training program. Validation of security awareness provides two functions: 1) it helps identify how well the personnel understand the organization s cyber security program and 2) it helps to evaluate the effectiveness of the training program. Validation can come through several means including written testing on the content of the training, course evaluations, monitored job performance or documented changes in security behavior. A method of validation should be agreed upon during the development of the training program and communicated to the personnel. Records of employee training and schedules for training updates should be maintained and reviewed on a regular basis. Documenting training can assist the organization to ensure that all

171 ISA99, WG ISA , D7E personnel have the required training for their particular roles and responsibilities. It can also help identify if additional training is needed and when periodic retraining is required. Over time, the vulnerabilities, threats and associated security measures will change. These changes will necessitate changes to the content of the training program. The training program should be reviewed periodically (for example, annually) for its effectiveness, applicability, content and consistency with tools currently used and corporate practices and laws and revised as needed. Subscriptions to security alert services may help ensure up-to-date knowledge of recently identified vulnerabilities and exposures. C Supporting practices C Baseline practices The following seven actions are baseline practices: a) Addressing the various roles associated with maintaining a secure systems environment within the cyber security training curriculums. b) Having classroom courses or on-the-job training to address the requirements for each role. c) Validating a user s understanding via course evaluations and/or examinations. d) Having subject matter experts for each course who can provide additional information and consulting. e) Reviewing and validating the training curriculum periodically and evaluating its effectiv eness. f) Communicating key messages to all personnel in a timely fashion via a security awareness communication program. g) Training all personnel initially and periodically thereafter (for example, annually). While none of these baseline practices are specific to IACS security training, the emphasis and content for the training programs needs to show the relationship between IACS security and HSE consequences. C Additional practices The following seven actions are additional practices: a) Establishing cyber security training as a component of the company s overall training organization for all employees. b) Tailoring the cyber security training curriculums with a progression of material for a given role in the organization. c) Maintaining and reviewing records of employee training and schedules for training updates on a regular basis depending on their position/role. d) Leveraging cyber security training provided by vendors. e) Establishing the timing, frequency and content of the security awareness communication program in a document to enhance the organizations understanding of cyber security controls. f) Including an overview of the security awareness communication program for all personnel to ensure they are aware of the security practices on their first day. g) Reviewing the training and the security awareness program annually for its effectiveness, applicability, content and consistency with tools currently used and corporate practices. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., [16], Error! Reference source not found..

172 ISA , D7E5 170 ISA99, WG C Element: Business continuity plan C Description of the element A business continuity plan identifies procedures for maintaining or re-establishing essential business operations while recovering from a significant disruption. The purpose of the business continuity plan is to provide a course of action to respond to the consequences of disasters, security failures and loss of service to a business. A detailed business continuity plan ensures that business critical IACS systems can be restored and utilized as soon as possible after the occurrence of a significant disruption. C Scope of the business continuity plan Before developing the business continuity plan, it is important to understand when the plan should be used and what kinds of situations apply. Unplanned interruptions may take the form of a natural disaster (that is, hurricane, tornado, earthquake or flood), an unintentional man -made event (that is, accidental equipment damage, fire or explosion or operator error), an intentional man-made event (that is, attack by bomb, firearm, vandalism, hacker or virus) or an equipment failure. From a potential outage perspective, this may involve typical time spans of minutes or hours to recov er from many mechanical failures to days, weeks or months to recover from a natural disaster. 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. Since 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 IACS cyber security, it is recommended that neither of these constraints be made. Long-term outages (disaster recovery) and short-term outages (operational recovery) should both be considered. The plan also includes other aspects of disaster recovery, such as emergency management, human resources, and media or press relations. 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 in place to prevent them. It is also important for the physical security organization to understand which areas of a production site house IACS that might pose higher-level risks. C The business continuity planning process Prior to creating a plan 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. System recovery involves the recovery of all communication links and IACS capabilities and is usually specified in terms of a recovery time objective or the time to recover these links and 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 or 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 documented. For most of the smaller scale interruptions, repair and replace activities based on a critical-spares inventory may prove adequate to meet the recovery objectives. In other cases, contingency plans need to be developed. Due to the potential cost of these contingency plans, these should be reviewed with the managers responsible for business continuity planning to verify they are justified. The requirements for a business continuity team should be identified and a team should be formed. The team should include IACS and other industrial operations owners. In the event of a significant disruption, this team should determine the priority of critical business and IACS systems to re - establish operations.

173 ISA99, WG ISA , D7E A schedule to test all or part of the recovery procedures should be developed. Often the procedures for a specific subsystem are tested annually and the specific subsystem is rotated so the overall system procedures are eventually tested over a 5-10 year period. These frequencies are only examples and shall be determined by the organization as part of the planning process. Particular attention should be given to verifying backups for system configuration data and product or production data. Not only should these be tested when they are produced, the procedures followed for their storage should also be reviewed on some frequency to verify that the backups and the supporting data are usable and accurate. These backups should be kept under environmental conditions that will not render them unusable and in a secure location where they can be quickly obtained by authorized individuals when needed. In the event that an incident occurs, the organization may be required to provide forensic data about the incident to investigators, whether inside or outside the organization. Over time, the business continuity plan will need to be reviewed and revised to reflect changes in the management structure, organization, business model, industry, and the like. C Supporting practices C Baseline practices The following nineteen actions are baseline practices: a) Forming a business continuity team involving the key stakeholders in the organization (that is, business owners, IT personnel and IACS personnel) to develop the plan. b) Determining the priority of critical business and IACS based on the nature of the system and the time required for restoration. This depends on the organization s risk tolerance and recovery objectives. c) Determining the amount of time/resources required for system restoration, location of backup files, hardware, frequency of backups, need for hot spares, and the like, to ensure critical systems can be restored in the event of a disaster situation. d) Requiring that the records related to the document management and backup/recovery procedures be readily available in multiple ways from multiple locations (that is, electronic copies stored in a vault and paper copies on-site and in a protected facility) so that there is no single point of failure. e) Considering the possible impact on third parties such as joint ventures and supply chains. f) Determining the need for additional business insurance. g) Defining the specific roles and responsibilities for each part of the plan. Some organizations divide the team into sub-teams reporting to a coordinating committee. Examples of sub-teams include damage assessment, restoration and recovery, communications (internal and external) and emergency response. h) Assigning the responsibility for initiating the business continuity plan and clearly define the circumstances under which to activate the plan. i) Detailing under what circumstances to take specific emergency measures. The choice of measures varies according to the specific scenario. Consider the consequences of an IT or IACS disaster having physical impact to production facilities. j) Defining the type, number and identity of the resources needed and their assignments. k) Detailing the communications methods for the team members along with contingencies for loss of , phone disruption, and the like in the event of a large-scale disaster.

174 ISA , D7E5 172 ISA99, WG l) Defining the frequency and method to test, validate and assess the continuity plan and using these results to improve and update the plan for increased effectiveness. m) Detailing the risks associated with operating under the continuity plan and how they are going to be addressed and/or mitigated. n) Identifying data that requires special handling and protection, as well as the information that is critical to continued operation. o) Establishing interim procedures to continue minimum business operations. A reduced product slate may be appropriate during this interim period. p) Identifying and storing backup systems (hardware, software and documentation) in a safe location. q) Testing backup systems on a predefined schedule for proper operation of the system and correct restoration of the data. r) Identifying and/or storing supplies to support the emergency response team and aid in restoring business operations (for example, bottled water, detoxification showers and emergency a ir packs or respirators). s) Defining the process for resuming normal operations. C Additional practices The following nine actions are additional practices: a) Prioritizing IT systems and IACS by their consequence to the business or operation based on the organization s risk tolerance. The IACS may have impact on the business IT systems that might be overlooked without collectively examining and prioritizing the systems as a whole. Disaster planning and recovery plans should address the interrelationship of these systems. b) Locating critical system backups in different geographic areas. If this is not feasible, storing backup data and equipment in an area not subject to the same physical disaster as the primary system (that is, high ground for floods or concrete bunker for tornadoes). c) Testing and updating business continuity plans periodically or as needed. d) Tying business continuity plans to a management of change system ensuring an update to the business continuity plan in the event of significant changes in system or business consequence. e) Testing communications plans periodically or as needed and assigning responsibility to keep call lists up-to-date. f) Providing critical contact information to the core team (a card carried by each team member). g) Having each person of the team keep written copies of the plan at home. h) Having procedures and/or contracts in place to purchase additional hardware, software and supplies if needed. It is important that the continuity plan balances the replacement times for IACS with the replacement times for the equipment being controlled. In some cases, this equipment may have long lead times for repair/replacement that greatly exceed the replacement time of the control systems. i) Establishing advance service level agreements with providers of a disaster recovery service. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found..

175 ISA99, WG ISA , D7E C Element: Security policies and procedures C Description of element Within each management system, there are sets of overall requirements to be met by the system and lists of the organizations that are subject to these requirements. In this standard, those requirements are referred to as policies. There are also descriptions of how individuals and organizations meet the requirements in the management system. In this standard, these descriptions are referred to as procedures. For a CSMS, policies provide high-level guidance on requirements for cyber security within the organization. They contain directives that address how an organization defines cyber security, operates its cyber security program and addresses its tolerance for risk. The policies for the CSMS are created from higher-level corporate policies from which they derive their authority. Policies carry with them negative consequences for lack of compliance, possibly including termination of employment or even criminal prosecution. Procedures provide the detail on how the CSMS policies are implemented within the organization. They may not be as strict as policies and may include provisions to obtain exception s since it is very difficult to craft procedures to deal appropriately with every possible situation or contingency. The CSMS policies and procedures written by the organization should give personnel a clear understanding of their roles and responsibilities in securing the organization s assets. C Developing security policies Developing security policies for the organization should not be approached as a linear task. After the initial stages of policy development have been completed, it is necessary for the o rganization to review and analyze the effectiveness of those policies, then refine them as necessary. These policies should not be developed in isolation from other risk management systems in the organization. Developing and implementing security policies involves senior leadership commitment from all areas of the organization with responsibility for these types of systems. By defining and endorsing a security policy, senior leadership can demonstrate a commitment to continuous improvement. Leadership commitment relating to security policies involves organization leadership recognizing security policy as a business responsibility shared by all members of the management team and as a policy that includes physical and cyber components. The security procedures need to be incorporated into the overall business strategies and have management support. Many IACS organizations have existing policies in place for systems such as safety, physical security, IT and employee behavior. When beginning the process of developing a CSMS, it is important to try and integrate the cyber security policies in that system with existing policies and procedures. This may and often does, require the modification of policies within those other risk management systems. For example, existing risk management systems may have already characterized the risks or established risk tolerance levels that need to be understood when developing the new CSMS. An explanation of combining policies and risk management systems can be found in ISA , 5.6. Error! Reference source not found. Security policies that deal with IACS risks will also deal with a wide range of issues from organizational leadership requirements to technically detailed system configuration requirements. It is recommended that these policies be separated into appropriate subgroups to make them more accessible to readers who may only be interested in specific topics. In many circumstances the security policies and procedures can be thought of as countermeasures to address risk. These can take several forms from administrative procedures to automated security tools. The objective is to make the overall cost of the countermeasures less than the overall impact of the risk. Reducing the cost to implement the countermeasures while still achieving the same level of risk reduction provides more value to the organization. In cases where this

176 ISA , D7E5 174 ISA99, WG economy of scale exists, the IT discipline will manage the technologies where the scale can be leveraged. Thus, the detailed security policies of the IT discipline shall be examined for potent ial reapplication in the IACS space. When developing cyber security policies, it is important to consider the conformance and compliance requirements and the audit process as well. Since the IACS will need to be evaluated for its compliance with the security policies, it is necessary to make sure that the policies defined do not conflict with other, possibly more important risk management policies. For example, a security policy is created requiring all desktop computers to be password protected at a certai n nuclear facility. This blanket policy also requires all operator stations in the control room to be password protected, but these operator stations are required to be open due to safety regulations. The password policy for desktop computers would cause the system to be out of conformance to HSE policies. The cyber security policy should have originally been written considering the effect it would have on all the different systems at a particular facility. A better approach would be to define a policy that states that desktop computers to be protected from unauthorized use and then have procedures that may require password protection in some instances while providing physical isolation in other situations. C Determining the organization s tolerance for risk An organization should define a Risk Tolerance policy related to risk levels, corresponding to a particular combination of likelihood and consequence. This policy can be based on a qualitative risk assessment consisting of a list of assets or scenarios with an overall likelihood and a consequence ranking, which are defined and assigned as part of the organization s risk assessment process (see C.3.3). In the typical risk level matrix example shown in Table B.3, likelihood and consequence have both been broken down into three levels. The risk level has also been broken down into three levels. The risk levels in each block (High, Medium and Low) correspond to a particular combination of likelihood and consequence. An organization defines a Risk Tolerance policy related to each level, which will correspond to a particular level of corporate response to the risk. For example, risks that merit a High might be resolved within 6 months; risks that only merit a Low will not have any effort devoted to them; and Medium Risk Level items will deserve intermediate effort. In other words, the organization has stated it can tolerate a High-level risk for 6 months and no longer. C Reviewing and revising cyber security policies The cyber security policies should be reviewed regularly, validated to confirm that they are up -todate and being followed and revised as required ensuring that they remain appropriate. Where the cyber security policies are at a higher level, they should not need to be updated as often since they describe what instead of how. While the how of the procedure may change with new threats or techniques, the reason for protecting the system will remain relatively constant. C Deploying cyber security policies During the creation of cyber security policies, the method for deploying them should be defined. For example, security policies could be published on the corporate Intranet and users could be trained on how the policy affects them. The policies are the bedrock of the CSMS, so the system for deployment should be consistent with the implementation of the management system. C Supporting practices C Baseline practices The following five actions are baseline practices: a) Establishing management commitment, involvement and support while creating and enforcing cyber security policies.

177 ISA99, WG ISA , D7E b) Requiring review and approval by all affected business units and departments, including operations management. c) Publishing written documents that describe the cyber security policies. d) Reviewing, validating and revising the policies regularly to confirm that they are up-to-date and being followed. e) Communicating and disseminating cyber security policies to all personnel. C Additional practices The following ten actions are additional practices: a) Creating consistent policies with an organization-determined lifecycle. The policies are neither changed constantly, nor are they changed in reaction to hot topics. b) Creating supporting policies that pertain to specific roles or groups that define how the higher - level policy is implemented for each of these groups. For example, physical access control and password restrictions may not be appropriate in certain industrial control situations. Exceptional procedural safeguards may be required to compensate. c) Creating security policies to address a number of security concerns, including the mitigation of risks and the changing of staff attitudes towards cyber security. d) Aligning the security policies with overall organizational policies and strategies. e) Integrating the cyber security policies with or as a part of an overall security policy that addresses physical elements too. f) Identifying how the policies are enforced and by whom. g) Identifying how users need to conform to the provisions of the policies. h) Providing a consistent policy management framework. i) Establishing which policies apply to specific users or user groups. j) Identifying how to measure conformance requirements for the policies. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C.4.3 Element group: Selected security countermeasures C Description of element group The second element group within this category is Selected Security Countermeasures. The elements within this group discuss some of the main types of security controls that are part of a well-designed CSMS. This document does not attempt to describe the full implementation of any of these selected security countermeasures. It discusses many of the policy, procedure a nd practice issues related to these particular security countermeasures. Figure B.7 shows a graphical representation of the six elements in the element group: Personnel security, Physical and environmental security, Network segmentation, Access control Account administration, Access control Authentication and Access control Authorization.

178 ISA , D7E5 176 ISA99, WG02 Addressing risk with the CSMS Selected security countermeasures Personnel security Physical and environmental security Network segmentation Access control - Account administration Access control - Authentication Access control - Authorization Figure B.7 Graphical view of element group: Selected security countermeasures A CSMS is the system via which an organization s security countermeasures are selected and maintained. Therefore particular countermeasures are considered as a result of this system rather than as a part of the CSMS itself. However, the countermeasures discussed in this subclause have been included in this standard because their application is fundamental to the formulation of security policy and architecture. For this reason, they should be considered up front during the creation of a CSMS. C Element: Personnel security C Description of element Personnel security involves looking at potential and current personnel to determine if they will carry out their responsibilities for IACS security in the organization and establishing and communicating their responsibilities to do so. Employees, contractors or temporary personnel that have access to industrial operation sensitive information or the IACS networks, hardware and software create a potential exposure if sensitive information is revealed, modified or if unauthorized access to IT systems or IACS is granted. C Requirements for personnel security In many organizations, the personnel security requirements have been driven by concerns about insider threats and the possibility of accidents caused by inattention to detail or by personnel unfit for a job due to lack of proper background or use of substances that might cloud judgment. By implementing personnel security policies it may be possible to reduce these type s of problems. When developing a program for personnel security, it is important to include personnel that can access all systems in scope and not just limit the effort to personnel using traditional computer room facilities. Computers in IACS operations are tools used to operate the facility productively and safely. It is the personnel that operate the systems that are the heart of the operations and every care should be taken to ensure that these people are qualified and fit for these positions. This proc ess begins at the recruitment phase and continues through termination. It requires constant attention by management and co-workers to ensure that the system is operated in a secure manner. A personnel security policy should clearly state the organization s commitment to security and the security responsibilities of personnel. It should address security responsibilities of all personnel (both individual employees and the organization) from recruitment through the end of employment, especially for sensitive positions. (This includes employees, prospective employees, contract employees, third-party contractors and company organizations such as human relations.) All personnel, including new hires and internal transfers to sensitive positions (for example, those requiring privileged access) should be screened during the job application process. This screening should include identity, personal and employment references and academic credentials.

179 ISA99, WG ISA , D7E Background screenings may also include credit history, criminal activity and drug screening as this information may be useful in determining the applicants suitability (subject to local Privacy Laws). Third-parties, contractors, and the like are subject to background screening at least as rigorous as employees in comparable positions. Employees and contractors may also be subject to ongoing scrutiny, such as for financial, criminal and drug activities. Due to the amount of industrial operation sensitive data and potential HSE risks in some IACS environments, it may be necessary to screen a wide group of employees who have access to the IACS. Plant-floor employees may need the same level of background checks and scrutiny as a typical IT system administrator. The terms screening and background checks are left intentionally vague so that the organization can determine the level of screening to be performed on personnel. Sensitive positions is also left to be defined by the organization because it is realized that some positions can have little or no effect on the security of the system. During the hiring process, the terms and conditions of employment should clearly state the employees responsibility for cyber security. These responsibilities should extend for a reasonable period of time after employment ceases. While hiring contractors or working with third -party personnel, their security responsibilities should be documented and included in any agreements. Where possible, the responsibilities should be specific and measurable. Personnel should be made aware of the organization s security expectations and their responsibilities through clearly documented and communicated statements by the organization. Personnel need to accept their mutual responsibility to ensure safe and secure operation of the organization. Organizations may consider having all personnel of information processing facilities sign a confidentiality or nondisclosure agreement. Any confidentiality agreements should be reviewed with and signed by employees as part of the initial employment process. Third -party contractors, casual staff or temporary employees not covered by a formal nondisclosure agreement should also sign a confidentiality agreement prior to beginning work. Organizations should create job roles based on the segregation of duties to assure that access to information is on a need-to-know basis and high-risk operating steps require more than one person to complete. These duties should be segregated amongst personnel to maintain the appropriate checks and balances, so that no single individual has total control over actions that change the functional operation of the IACS. The security roles and responsibilities for a given job should be periodically reviewed and revised to meet the changing needs of the company. All personnel should be expected to remain vigilant for situations that may lead to safety or security incidents. Companies need to train managers to observe personnel behavior that may lead to theft, fraud, error or other security implications. A disciplinary process for cyber security violations should be established and communicated to personnel. This should be tied to the legal and punitive measures against such crimes in the country. C Supporting practices C Baseline practices The following eight actions are baseline practices: a) Screening personnel during the recruitment phase, such as background checks prior to hiring or movement to sensitive jobs, especially for sensitive positions. b) Scrutinizing personnel, especially those in sensitive positions, on a regular basis to look for financial problems, criminal activity or drug problems. c) Communicating the terms and conditions of employment or contract to all personnel stating the individual s responsibility for cyber security. d) Documenting and communicating the organization s security expectations and personnel responsibilities on a regular basis.

180 ISA , D7E5 178 ISA99, WG e) Requiring personnel to accept their mutual responsibility to ensure safe and secure operation of the organization. f) Segregating duties amongst personnel to maintain the appropriate checks and balances. g) Requiring all personnel to sign a confidentiality or nondisclosure agreement. h) Establishing a disciplinary process for personnel who have violated the security poli cies of the organization. C Additional practices The following two actions are additional practices: a) Creating job roles based on the segregation of duties to assure that access to information is on a need-to-know basis and high-risk processing steps require more than one person to complete. b) Documenting the security responsibilities and including them in job descriptions, contracts or other third party agreements. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C Element: Physical and environmental security C Description of the element Physical and environmental security relates to creating a secure environment for the protection of tangible or physical assets (that is, computers, networks, information and operations equipment) from damage, loss, unauthorized access or misuse. Physical and environmental security of information systems is a well-established discipline that draws knowledge and experience from other areas of physical or facilities security. Physical and environmental security measures should be designed to complement the cyber security measures taken to protect these assets. Physical and environmental security measures are different, but linked since they both try to protect the assets of an organization from threats. Physical security measures ensure that the assets of an organization are protected physically from unauthorized access, loss, damage, misuse, and the like. Environmental security measures ensure that the assets of an organization are protected against environmental conditions that would make them unusable or damage the information they contain. Although cyber security policies and procedures are important for the proper protection of information and control systems, in order to have truly effective protection, they should be complemented by the appropriate level of physical security. For example, maintaining tight controls such as authentication and access control does little to protect system integrity if it is possible to enter a facility and physically remove or damage electronic media. C Considerations for physical and environmental security C General In many organizations, the environmental and physical perimeter security requirements have been driven by concerns about only the physical assets of the organization and may not fulfill the cyber security requirements. Due to the integration of multiple organizations within specific sites (that is, business partners, contractors and third-parties), additional physical security protection for IACS assets may be required. In IACS facilities, physical security is focused more at protecting IACS assets than it is to the operations information itself. The concern is not so much the actual theft or

181 ISA99, WG ISA , D7E corruption of the computing and control devices, but rather the impact this would have on the ability to sustain production in a safe manner. When developing a program for physical security of assets, it is important to include all systems in scope and not just limit the effort to traditional computer room facili ties. ISA Error! Reference source not found. discusses criteria that can be used to determine which physical assets should be considered in the scope of the CSMS. Computers comprising the IACS are tools used to operate the facility productively and safely. They are a means to the end as well as the asset that is to be protected. In some cases, safety and/or productivity is threatened by locking equipment behind doors because the response time to access the equipment may be increased. Practical engineering judgment balancing all risks should be used to determine the physical security procedures for the assets to be protected. Although it is common practice to locate routers and other network equipment in locked environments, it may be of limited value to expand this practice much beyond this level. Field devices (that is, valve actuators, motor starters and relays) are usually given the ability to be actuated directly in the field without control signals over the IACS network. It can be cost-prohibitive to protect each field device individually, so strong physical perimeter access procedures are usually needed in facilities that involve a high risk. The following list contains items that should be considered when creating a secure environmen t for the protection of tangible assets from physical damage due to physical intrusion or environmental conditions. C Security policy A written security policy contains directives that define how an organization defines security, operates its security program and reviews its program to make further improvements. These written policies allow personnel to clearly understand their roles and responsibilities in securing the organization s assets. The organization needs to establish a physical and environmental se curity policy that is complimentary to both the organization s cyber security policy and its physical security policy. The primary objective is to bridge any gaps that might exist between these two policies. The physical and environmental security policy should be consistent with and follow the same policies, as discussed earlier, as other security policies dealing with the security of the control system. A physical security detailed risk assessment is used to determine the appropriate physical security procedures to be implemented. C Security perimeter Critical information or assets should be placed in a secure area protected by security perimeters and entry controls. These physical security controls work in conjunction with cyber security measures to protect information. One or more physical security perimeters should be established to provide barriers for unauthorized access to facilities. Multiple perimeters may be nested to provide successively tighter controls. An example may be locked cabinet inside a co ntrol room with key card access within a facility with a guarded perimeter fence. C Entry controls At each barrier or boundary, appropriate entry controls should be provided. These entry controls may be things like locked gates, doors with appropriate locks or guards. The entry controls should be appropriate to the level of security required in the area secured by the entry controls and relative for the need for quick access. C Environmental damage protection Assets need to be protected against environmental damage from threats such as fire, water, smoke, dust, radiation and impact. Special consideration should be given to fire protection systems used in areas affecting the IACS to make sure that the systems responsible for protecting the

182 ISA , D7E5 180 ISA99, WG facility offer protection to the IACS devices without introducing additional risk to the industrial operation. C Security procedures Personnel need to be required to follow and enforce the physical security procedures that have been established to reinforce the entry and other physical controls. Personnel should not circumvent any of the automated entry and other physical controls. An example of an employee circumventing a physical control would be to have an entry door to a protected control room propped open with a chair. C Single points-of-failure Single points-of-failure should be avoided when possible. Redundant systems provide a more robust system that is capable of handling small incidents from affecting the plant or organization, for example, using a redundant power supply in a critical system to ensure that if one power supply is damaged, the critical system will remain functioning. C Connections All connections (that is, power and communications, including I/O field wiring, I/O bus wiring, network cables, inter-controller connection cables, modems, and the like) under the control of the organization should be adequately protected from tampering or damage. This may include putting connections in locked cabinets or within fenced enclosures. The level of physical security for these connections should be commensurate with the level of security for the systems to which they connect. In considering physical security, the consequences of environmental damage should also be considered. These connections should also be protected against natural factors such as heat, fire, dust, and the like that could cause failures. C Equipment maintenance All equipment, including auxiliary environmental equipment, should be properly maintained to assure proper operation. Maintenance schedules should be established and preventive maintenance performed. Equipment maintenance should be tracked and trends noted to determine if maintenance schedules should be adjusted. C Alarms Proper procedures should be established for monitoring and alarming when physical and environmental security is compromised. Personnel should be required to respond to all alarms with the appropriate response measures. All facilities, commensurate with their security level, should be alarmed for both physical and environmental intrusions. These may include motion detectors, cameras or door alarms for physical intrusions and fire alarms, water detectors or temperature sensors for environmental concerns. C Equipment lifecycle Proper procedures should be established and audited with respect to the addition, removal and disposal of all equipment. Proper asset tracking is a good practice. These procedures would include workstation disposal, format, clean drive, and the like. The procurement of hardware would also take into account how the equipment can be tracked and how it can be sanitized and disposed when the time comes that it is no longer needed. C Physical information All information, expressed in a physical form (that is, written or printed documents, magnetic storage media and compact disks), needs to be adequately protected against physical threats. This may include placing these items in locked rooms or cabinets to prevent unauthorized access. Consideration should also be given to protecting the information from environmental damage such as magnetic fields, high humidity, heat or direct sunlight, and the like that could damage the

183 ISA99, WG ISA , D7E information. Like those for equipment, procedures should be in place to securely dispose of physical media when no longer needed. C Use of assets outside controlled environments Special care should be taken when using assets that affect the IACS outside of the IACS network. This includes staging the assets at a system integrator facility prior to installation. Also, assets like laptop computers with access to the IACS network used off-site should be handled as an extension of the IACS network with all of the appropriate physical and environmental security procedures being followed. Consideration should be given to using the same level of security for assets that are temporarily outside of the normal security boundaries. This may require special planning or facilities to protect these assets against unauthorized access or use or from environmental damage. C Interim protection of critical assets During and following either a physical or environmental event, power or other service may be lost to critical systems. Provisions should be made to protect these critical systems. This could include such things as supplying backup power, covering or damming to prevent water damage, an d the like. C Supporting practices C Baseline practices The following nine actions are baseline practices: a) Establishing physical security perimeters to provide barriers for unauthorized access to facilities. At each barrier or boundary, appropriate entry controls are provided. b) Protecting assets against environmental damage from threats such as fire, water, smoke, dust, radiation and impact. c) Requiring personnel to follow and enforce the physical security procedures that have been established to reinforce the entry and other physical controls. d) Requiring redundant sources of power to prevent single points-of-failure. e) Protecting all external connections from tampering or damage. f) Maintaining all equipment, including auxiliary environmental equipment, to assure proper operation. g) Establishing procedures for monitoring and alarming when the physical and/or environmental security is compromised. h) Establishing and auditing procedures with respect to the addition, removal and disposal of all assets. i) Using special procedures to secure assets that affect the IACS outside of the IACS network. C Additional practices The following seven actions are additional practices: a) Using security cables, locked cabinets, protected entrances at the home office, keeping equipment out of sight and labeling and tagging assets. b) Using password settings for boot and login commands on computers not in the control room, encrypted file system, laptops using thin-client techniques, and the like. c) Protecting computer equipment not in control rooms such as routers or a firewall by placing them in a locked environment. d) Having control rooms staffed continuously. This can often be the first line of defense in physical protection. Use control rooms to house information and technology assets.

184 ISA , D7E5 182 ISA99, WG e) Requiring personnel who are leaving the organization to return the equipment in good working order. f) Using an equipment tracking system to determine where equipment is located and who has responsibility for the equipment. g) Requiring environmental protection for assets including proper housing for equipment that is located where it may be subjected to dust, temperature extremes, moisture, and the like. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C Element Network segmentation C Description of element Network segmentation involves separating key IACS assets into zones with common security levels in order to manage security risks to achieve a desired target security level for the zone. Network segmentation is an important security countermeasure employed in conjunction with other layers of defense to reduce the risk that may be associated with IACS. Today s IACS are connected to and integrated with business systems both within and between partner companies. Despite the need for connectivity and tight integration, IACS do not need to utilize the vast majority of data traversing corporate networks. Exposing the IACS devices to all this traffic increases the likelihood of a security incident within the IACS. In keeping with the principle of least privilege and need to know, IACS should be architected in a manner that filters/removes unnecessary communication packets from reaching the IACS devices. Network segmentation is designed to compartmentalize devices into common security zones where identified security practices are employed to achieve the desired target security level. The goal is to minimize the likelihood of a security incident compromising the functional operation of the IACS. Compartmentalizing devices into zones does not necessarily mean isolating them. Conduits connect the security zones and facilitate the transport of necessary communications between the segmented security zones. The overriding security premise is that the use of security countermeasures should be commensurate with the level of risk. Network segmentation of an IACS may not be necessary if the security risks are low. The risk management and implementation element provides additional information on the subject of managing risk. It should be reviewed prior to implementing a network segmentation countermeasure strategy discussed in this element of the CSMS. C Network segments and zones C General ISA , Clause 6 Error! Reference source not found. introduces reference models and provides the context for discussing this countermeasure. Networks are segmented through the use of some sort of a barrier device that has the ability to control what passes through the device. On Ethernet based networks running TCP/IP, the most common barrier devices in use are firewalls, routers and layer 3 switches. Frequently, IACS are comprised of several different networks employing different physical and application layer technologies. These non-tcp/ip networks also employ barrier devices to separate and segment communications. The barrier devices may be standalone gateways or integrated into the network interface module of an IACS device. While placing a barrier device into the network may create a new network segment and security zone, a security zone also may encompass multiple network segments. Figure B.8 below illustrates a possible segmented architecture for a generic IACS. This figure attempts to depict how functional equipment levels may translate into the physical world of an IACS and the logical world of a zone.

185 3Com 3Com d i g i t a l d i g i t a l d i gi t a l Modem Bank d i g i t a l d i g i t a l d i g i t a l d i gi t a l Modem Bank d i g i t a l Modem Bank d i gi t a l 3Com d i g i t a l ISA99, WG ISA , D7E (The figure is fairly high level and does not include all the network devices required in an actual installation.) It is important to not confuse the functional levels of the reference model with security levels associated with security zones. While it is generally true that the lower level equipment plays a greater role in the safe operation of the automated industrial operation, it may not be practical or possible to employ a segmentation strategy aligned one-for-one with the equipment levels. In this figure, the control zone contains equipment with a common target security level. The figure depicts a TCP/IP-based process control network (PCN) segment, a proprietary regulatory control network (RCN) segment and a proprietary field device network (FDN) segment. These networks link the Level 0, 1, 2 and 3 equipment shown in the reference models of ISA , 5.2 Error! Reference source not found.. The barrier devices for each of these network segments regulate the communication entering and leaving their segment. Level 4 Level 3 Level 2 Level 1 Level 0 Figure B.8 Reference architecture alignment with an example segmented architecture C ISA-99 reference architecture Business/enterprise zone DMZ zone Enterprise systems (business planning and logistics) Site manufacturing operations and control Area and supervisory control Safety instrumented systems Process I/O devices Basic control devices zone Business/enterprise zone Site router DMZ PCN firewall Gateway zone Enterprise domain controller Site resource domain controllers Domain controller Business resource planning system Segmentation architecture (logical/physical) Application server lers Field I/O devices Manufacturing application server Application server Support workstation Corporate patch management server WAN Patch management server for PCN and DMZ devices Field device gateway For low-risk IACS, it may not be necessary to employ network segmentation as a countermeasure, which would require creation of a distinct control zone. However for medium- to high-risk IACS, network segmentation is a countermeasure providing very significant risk reduction. The generally accepted good practice is to use a barrier device such as a firewall to manage the communication across the conduit that links the control zone to the business zone, as shown in Figure B.8. Office workstations Office workstations RCN Field I/O devices Safety system zone Corporate anti-virus server Operator consoles SIS Site LAN DMZ PCN FDN Field I/O devices

186 ISA , D7E5 184 ISA99, WG Common filtering strategies at the barrier device include: a) The base configuration of the barrier device should be to deny all communication by default and only allow communication by exception to meet a critical business need. This applies to both intermittent, interactive user communication across the conduit and continuous, task -totask communication between devices in these two zones. Whenever possible, communications should be filtered by ports and services between matched IP pairs for the devices communicating over the conduit. b) Ports and services frequently used as attack vectors should not be opened through the barrier device. When the service is required due to business justification, extra countermeasures should be employed to compensate for the risk. As an example, inbound http, which is a common attack vector, may be necessary to support an important business function. Additional compensating countermeasures such as blocking inbound scripts and the use of an http proxy server would help lessen the risk of opening this high risk port and service. c) The fewer the number of ports and services open through the barrier device the better. Communication technologies that require a large number of ports to be open should be avoided. The barrier device can serve as a good automated tool to enforce that security practices be followed in the control zone, such as not allowing inbound or communications to/from the Internet. C Demilitarized zone (DMZ) For high risk IACS, the use of a DMZ in conjunction with a zone offers additional risk reduction opportunities between the low-security level Business zone and the high-security level control zone. The security level for the DMZ is higher than the Business zone but less than the control zone. The function of this zone is to eliminate or greatly reduce all direct communication between the control zone and the business zone. Devices should be located in the DMZ that function as a bridge or buffer between devices in the business zone and control zone. Communication is setup between a device in the business zone and the DMZ. The device in the DMZ then passes along the information to the recipient device in the control zone. Ideally the ports and services employed between the device in the business zone and the DMZ are different from the ports and services used between the DMZ device and the destination control zone device. This reduces the likelihood that malicious code or an intruder would be able to negotiate the combined conduits connecting the business zone to the control zone. The filtering strategies listed above for the control zone are also applicable for the DMZ. However, some riskier protocols like telnet may be allowed to facilitate management of devices in the DMZ and control zones. There are several use cases where a DMZ can be of benefit. These are included here to illustrate the security concepts. They are not meant to be an exhaustive or detailed list of how to implement a DMZ: a) Minimizing the number of people directly accessing control zone devices. Historian servers are often accessed by people located on the site LAN in the business zone. Rather than locating the historian server in the control zone and allowing direct access to this device from the business zone by a large number of users, the security level of the control zone can be maintained at a higher level if the historian server is located in the DMZ. b) Providing greater security for important IACS devices. In the case of the historian server mentioned above, an option would be to locate the historian on the site LAN where the majority of the users are located. This would reduce the number of people needing to access the PCN. However, since the business zone is a low-security level

187 ISA99, WG ISA , D7E zone, the historian server would be subjected to a less secure environment. The potential for compromise of the server would be greater. c) Compensating for patching delays. The DMZ offers additional security protection to important IACS devices that cannot be patched as quickly while waiting for patch compatibility testing results from the application vendor. d) Providing improved security for the control zone by moving management devices to a higher security level. The DMZ is a good place to locate devices like anti-virus servers and patch management servers. These devices can be used to manage deployment of security modules to the control zone and DMZ devices in a more controlled manner without subjecting the high-security level control zone to direct connection to servers that may be communicating to hundreds of devices. C Safety system zone Some IACS may employ a set of safety interlocks that are relay-based or microprocessor-based. A microprocessor-based logic solver SIS may require a slightly different set of security practices from that employed in the control zone. The target security level for this zone should be determined and appropriate actions taken to ensure appropriate countermeasures are employed to meet the target security level. C Isolated IACS The risk associated with the IACS may be too great to allow any opportunity for compromise by an external agent. A facility may choose to disconnect all conduits between the control zone and any other zone. This is a very valid network segmentation strategy for consideration. Facilities choosing to adopt this isolation approach are not automatically eliminating all risk. There may still be much vulnerability that could be exploited locally. Appropriate layers of cyber and physical protection should be employed to address the residual risk remaining after isolation of the IACS from the business zone. C SCADA segmentation architecture The above discussion described a segmented architecture for an IACS typically found in a single operating facility. Segmentation is a countermeasure that has equal applicability for a SCADA-type IACS. Figure B.9 illustrates one possible segmentation approach for this type of architecture. Although not shown due to space constraints, the DMZ and safety system zone described in the single operating facility IACS can also be employed in a SCADA architecture.

188 ISA , D7E5 186 ISA99, WG Figure B.9 Reference SCADA architecture alignment with an example segmented architecture C Suggested practices C Baseline practices The following four actions are baseline practices: a) Employing barrier devices such as firewalls to segment high-risk IACS devices into control zones. b) Employing gateways or internal barrier devices within the IACS device to separate regulatory control networks from the PCN. c) Employing sound change management practices on the barrier device configuration. d) Disconnecting high-risk IACS from the business zone. C Additional practices The following four actions are additional practices: a) Employing add-on, supplemental barrier devices within the control zone to further segment the network.

189 ISA99, WG ISA , D7E b) Employing a common and centrally managed security profile on all control zone barrier devices. c) Employing a DMZ segmentation architecture. d) Performing automated assessment tests to verify that the barrier device configuration has been correctly implemented per the design specification. C Resources used This element was based in part on material found in the following reference, which is listed in the Bibliography: Error! Reference source not found.. C Element: Access control: Account administration C General description of access control Access control is the method of controlling who or what resources can access premises and systems and what type of access is permitted. The misuse of data and systems m ay have serious consequences, including harm to human life, environmental damage, financial loss and damage to the corporate reputation. These risks are increased when personnel have unnecessary access to data and systems. It is very important that the security policy that defines the access control rules and procedures is clearly documented and communicated to all personnel (that is, employees, joint ventures, third-party contractors and temporary employees). One of the most important security elements for any computer system is having a sound and appropriate set of access control procedures. There are three key aspects associated with access control: Account administration; Authentication; and Authorization. Each of these is described separately in their own element subclause of this document. However, all three aspects need to work together to establish a sound and secure access control strategy. Within each of the three aspects of access control, rules should be established to confirm that a user s access to systems and data is controlled. The rules generally should be applied to roles or groups of users. They should have access to systems and data that are required to meet defined business requirements but should not have access if there is no defined business purpose for it. There are rules that are enforced administratively and those that are enforced automatically through the use of technology. Both kinds of rules need to be addressed as part of the overall access control strategy. An example of an administrative rule that an organization might have is the removal of employee s or contractor s account after their separation from the organization. An example of a technology enforced rule is requiring remote users connecting to the corporate network to utilize a VPN. In addition to rules, there are both physical security procedures and cyber security procedures that work together to establish the overall security framework for the system. Physical security procedures include such measures as locking rooms where user interface equipment is located. This standard provides a basic description of the parts of physical security that relate to cyber security in C There is both a real-time aspect to access control and an off-line aspect. Quite often, insufficient attention is paid to the off-line activities of access control for IACS. The off-line activity, here described as Account administration, is the first step in the process and includes defining the user privileges and resource needs for the user. These are based upon the role of the user and the job to be performed. The off-line method also includes an approval step by a responsible party before the access account is configured to provide the proper access.

190 ISA , D7E5 188 ISA99, WG C Description of element Figure A.10 Access control: Account administration Account administration, one of the three legs of access control as shown in Figure A.10, is the method associated with initially setting up permission and privileges to access specific resources on the network or system and to review those permissions and privileges on a periodic basis. It may be linked in some way to the physical access to resources. Account administration in the IACS environment goes beyond the traditional IT definition of operating system account access for a particular user. In the IACS environment, access accounts are more role-based for the functions they can perform on a particular machine rather than the data they can access. A user s role may change in an organization over time, so the administration process may be used more frequently on IACS accounts. Privileges often include access to file directories, hours of access and amount of allocated storage space. The role assigned at the application level for the access account shall be identified and understood during the administration phase. Several steps are involved which include identification of the resources needed to perform that person s job function, independent approval by a trusted person and setup/configuration of the computer account that automati cally assigns the resources when requested. In addition to the task of creating access accounts and assigning users to roles at the operating system level, many manufacturing applications require additional role assignments. System administrators for IACS shall be skilled and trusted to perform these account administrative functions on live equipment control applications. The change management process for making these account changes should clearly identify any timing constraints that shall be followed due to the safety risks during certain sequences of the control operation. C Considerations for account administration C General When developing a program for account administration, it is important to include all systems in scope and not just limit the effort to traditional computer room facilities. C Rules to control a user s access to systems, data and specific functions Each organization should establish rules to control a user s access to the systems, data and functions. These rules should be based on the risk to the system and the value of the information. These rules should be conveyed to all personnel. C Standard administration process A standard administrative process should be followed for the creation of access accounts. Although it may be more cost efficient for a single organization to provide the account administration function for all computer systems in a company, IACS and IT systems may have different sets of people providing administrative control of the account creation and maintenance process. This is often due to the different set of risks associated with these systems. Account approvals may also require approval by a supervisor familiar with the IACS tasks and operations.

191 ISA99, WG ISA , D7E C Role based access accounts A standard administrative process should be followed for the creation of access accounts. The accounts should be role based and grant the user only those privileges and access to resources that are needed to perform their particular job function. C Minimum privileges Users should be assigned the minimum privileges and authorizations necessary to perform their tasks. Access should be granted based on the need to support a particular job function. The role - based privileges should consider special requirements for installing software, requirements for configuring services, file-sharing needs and remote access needs. C Separation of duties The account administration process includes principles of separation of duties with separate approvers and implementers of account configuration. This principle provides an additional layer of protection so that one person cannot compromise a system alone. C Identify individuals Every user should be identifiable with separate access accounts unless there are HSE risks for such accounts. In such cases, other physical security controls should be employed to limit access. Access needs to be controlled by an appropriate method of authentication (that is, user ID and password, personal identification numbers (PINs) or tokens). These personal credentials should not be shared except in certain special situations. One special case is in a control room where the operators function as a single work team or crew. In this situation, everyone on the work team may use the same credentials. (Additional discussion is provided on this subject in C ). An alternate identification process should exist in the event of a forgotten password. C Authorization Access should be granted on the authority of an appropriate manager (either from the responsible company or a partner organization). Approvals should be made by supervisors familiar with the manufacturing/operations tasks and the specific training a person has had for that role. C Unneeded access accounts Access accounts are the means of controlling access to the system, therefore, it is important that these accounts be inactivated, suspended or removed and access permissions revoked as soon as they are no longer needed (for example, job change, termination, and the like). This action should be taken by the appropriate manager as soon as possible after the access account is no longer needed. C Review access account permissions The need for access to critical systems is explicitly reconfirmed on a regular basis. All established access accounts should be reviewed periodically to ensure that the account is still in use, their role and access needs are still correct, the user is still authorized and only has the minimum required permissions. Inactive or unneeded accounts should be removed. If an access account remains unused for an extended period, the need for it is explicitly confirmed by the account owner and account sponsor. C Record access accounts One of the primary functions of account administration is the recording of the individual access accounts. Records should be maintained of all access accounts, including details of the individual, their permissions and the authorizing manager.

192 ISA , D7E5 190 ISA99, WG C Change management The change management process for account administration should clearly identify any timing constraints that shall be followed due to the safety risks of making changes during certain industrial operation sequences. These changes are treated with as much importance as are process, software and equipment changes. The access account administration process should integrate with standard process safety management (PSM) procedures and include approval and documentation steps. The approvers of access accounts for manufacturing/operations functions may be a different set of people than are approving users for the IT systems. Approvals should be made by supervisors familiar with the manufacturing/operations tasks and the specific training a person has had for that role. C Default passwords Many control systems come with default passwords that are used in getting the system set up and ready for operation. These access account passwords are often widely known or easily determined from published literature or other sources. These default passwords should be changed immediately upon setup and before connection to the system. C Audit account administration Periodic reviews for compliance of access account administration information should be conducted. This ensures that the owners of the information or documents are comp liant with the appropriate policies, standards or other requirements set down by the organization. C Supporting practices C Baseline practices The following nine actions are baseline practices: a) Assigning the minimum privileges and authorizations to users necessary to perform their tasks. Access should be granted on the basis of the need to perform a particular job function. b) ling identification and access for each individual user by an appropriate method of authentication (for example, user ID and password). These personal credentials (that is, passwords, PINs and/or tokens) are not shared except in certain special situations. c) Establishing an alternate identification process in the event of lost credentials or a forgotten password. d) Granting, changing, or terminating access on the authority of an appropriate manager (from the organization, contracting organization, or third-party). A record is maintained of all access accounts, including details of the individual, their permissions, and the authorizing manag er. e) Suspending or removing all access accounts and revoking permissions as soon as they are no longer needed (for example, job change). f) Reviewing all established access accounts on a regular basis to ensure that they are still in use and they still require access to critical systems. g) Reconfirming the need for access accounts with the appropriate manager if the accounts are unused for an extended period of time. h) Requiring default passwords to be changed immediately. i) Requiring all personnel (that is, employees, joint ventures, third-party contractors, and temporary employees) to agree in writing to conform to the security policy, including access control policies. C Additional practices The following five actions are additional practices:

193 ISA99, WG ISA , D7E a) Using tools (that is, provisioning and identity management) to manage the process of access account creation, suspension, and deletion. A provisioning system also manages the approval workflow by which the business owner approves access, including logging. It may also automate the process of account creation/suspension on the target systems. b) Linking the account administration process to the human resources process so that employee changes trigger reviews and updates to access accounts. c) Defining and documenting the application roles/user privileges (that is, job functions mapped to application roles and access entitlements for each role) by the application information owner or delegate. d) Paying special attention to users with privileged access (that is, more frequent reviews and background checks). e) Allowing users to have more than one access account, based on their particular job-role at that particular time. A person would use a system administrator access account to perform an application update on a particular machine but would also need an operator access account to run and test the application. C Resources used This element was based in part on material found in the following reference, which is listed in the Bibliography: Error! Reference source not found.. C Element: Access control: Authentication C Description of element NOTE For additional information about the overall topic of Access control, see the introductory material in C Authentication, another of the three legs of access control as shown in Figure A.11, is the method of positively identifying network users, hosts, applications, services, and resources for some sort of computerized transaction so that they can be given the correct authorized rights and responsibilities. The method uses a combination of identification factors or credentials. Authentication is the prerequisite to allowing access to resources in a system. Figure A.11 Access control: Authentication Authentication in the IACS environment has several challenges not typically found in normal IT situations. Current IT authentication technologies have several limitations that are not well suited for the IACS environment and could actually result in increased HSE risks at the expense of decreased cyber security risks. It is important in the IACS environment to make sure that the right people have access to the correct information and systems and are not prevented from doing their job via authentication. Failure to authenticate a valid user could have HSE implications if the user is not able to perform tasks in a critical situation. In the IACS environment, there is a great emphasis on combining physical authentication measures with electronic authentication practices.

194 ISA , D7E5 192 ISA99, WG The physical location of the user may have a significant impact on the risk level of the access. For example, the user connecting to a system from inside a building that employs a guard and badge - reader system at the door is less of a risk than a user connecting from some other region in the world. The authentication strategy addresses the combined physical and cyber security controls to be used to control overall risk. The strategy clearly defines the authentication requirements for special situations. There are several types of authentication strategies and each has varying degrees of strength. Strong authentication methods are ones that are quite accurate in positively identifying the user. Weak authentication methods are ones that can be easily defeated to provide unwanted access to information. The physical location of the user may have a significant impact on the risk of accessing the IACS. Authentication for these cases will be discussed in the following subclauses. C Authentication for local users It is very important that only trained and designated resources take actions on industrial control HMI stations, such as operator control stations. Many industries control their equipment from control rooms staffed by several operators. These operators often function as a team and perform actions on multiple HMI stations as part of their normal job function. Common access accounts shared by the team of operators are frequently employed. Until cost-effective, robust, strong authentication schemes are available on the HMI stations, the recommended practice is to use physical controls to ensure that only designated individuals are performing actions on control room HMI stations. Access to control rooms should be managed by appropriate combinations of entrance control technologies and administrative procedures. Consider the HSE implications when developing the access control procedures. C Authentication for remote users A remote user is anyone who is outside the perimeter of the security zone being addressed. EXAMPLE A remote user might be a person in an office in the same building, a person connecting over the corporate wide area network (WAN) or a person connecting over public infrastructure networks. Physical and administrative controls that rely on visual authentication do not work for remote interactive users. However, there are numerous technology-based authentication schemes that can be used. It is important to employ an authentication scheme with an appropriate level of strength to positively identify the remote interactive user. Industrial operations w ith a low potential to create HSE incidents and that have low financial impact may be protected using weak authentication methods such as a simple user ID and password. However, industrial operations where there is a large financial or HSE stake should be protected using strong authentication technologies. For these types of operations, it is recommended that the system be designed in a way that the remote access user is not allowed to perform control functions, only monitoring functions. C Authentication for task-to-task communication The discussion above focused on interactive users. It is just as important to employ appropriate authentication schemes for task-to-task communication between application servers or between servers and controlled devices. The communications interface should employ methods to verify that the requesting device is indeed the correct device to perform the task. Some ways in which critical interfaces could authenticate task-to-task communications between devices are checking the internet protocol (IP) address, checking the media access control (MAC) address, using a secret code or using a cryptographic key to verify that the request is coming from the expected device. Interfaces with low risk may use less secure methods for authentication. An example of insecure communications is an anonymous file transfer protocol (FTP) for program upload/download/compare between the control HMI and a data repository.

195 ISA99, WG ISA , D7E C Considerations for authentication C General When developing a program for access control, it is important to include all systems in scope, and not just limit the effort to traditional computer room facilities. a) Defining an authentication strategy Companies should have an authentication strategy or approach that defines the method of authentication to be used. b) Authenticating all users before system use All users should be authenticated before using the requested application. This authentication may be a combination of physical and cyber authentication practices. c) Requiring strong secure accounts for system administration and/or application configuration Strong account user ID and password practices should be used on all system administrator and application configuration access accounts. The system administrator does not typically need quick access to perform system-level tasks on the computers. It is more important that untrained users be prevented from performing system-level functions than it is to provide quick access. d) Requiring local administration On highly critical systems, it is a good practice to perform all system administrator or application configuration functions locally at the device to reduce the potential for a network interruption causing a problem with the control of the equipment. The system administrator or application manager should coordinate all changes with the operator for the area so that production is not impacted during a configuration change. C Authentication for local users If a practice introduces the potential to delay an operator s ability to locally make quick corrective action to the industrial operation from the HMI control station, normal IT authentication practices may not be appropriate. To achieve security in control system operation while still providing for rapid response, a combination of physical and cyber controls have been found to produce the best results. Some of these controls include but are not limited to: manual locks (for example, key and combination) on doors to rooms or cabinets containing control system components; automated locks (for example, badge and card readers); control rooms staffed continuously; individual accountability by control room personnel to keep access limited to designated personnel and ensure that only trained personnel perform actions on operator control stations. Some examples of common IT practices that may not be applicable in an IACS environment are: a) Individual user IDs and passwords for each operator for work-team environments Many industries control their operations from control rooms staffed by several operators. Th ese operators often function as a team and perform actions on multiple HMI stations as part of their normal job function. Requiring each operator to log in and be authenticated and authorized each time they use a new HMI could compromise quick response to an operation event. b) Access to non-local domain controllers and active directory servers for access account authentication Network issues may interfere with timely login under this architecture. c) Automatic access account lockout after some number of failed login attempts

196 ISA , D7E5 194 ISA99, WG Under some conditions that require rapid response by an operator, the operator may become flustered and enter the wrong password. If the operator is then locked out, it could compromise the operator s ability to resolve the situation. d) Robust long passwords that contain a mix of alpha, numeric and special characters Although robust passwords provide an increased measure of security, in the control room environment, the requirement to enter such passwords could slow response time for an operator. A similar level of security could be achieved by physical means such as locked doors or continuous staffing of the control room by those that know cleared operators. e) Password changes after a specified number of days The impact of changing passwords is much like that of robust passwords, it may slow response to a situation when a quick response is needed. Passwords should be changed when there is a change in personnel, but changing after a set number of days may not be productive. f) Screen savers with password protection Many HMI stations are designed to report by exception. The operator may not need to take any action on the operator station until an alert occurs. Screen savers have the potential to interfere with the operator by blocking the view to the operation under control and delaying response to an emergency situation. C Authentication for remote users Remote users do not normally need to rapidly respond to situations common to operators. In addition, for remote users, accountability becomes more important than availability. Therefore, some of the practices common to IT security are also of benefit for remote users. These include: a) Authenticate all remote users at the appropriate level The organization should employ an authentication scheme with an appropriate level of strength to positively identify a remote interactive user. b) Log and review all access attempts to critical systems The system should log all access attempts to critical systems and the organization should review these attempts whether they were successful or failed. c) Disable access account after failed remote login attempts After some number of failed login attempts by a remote user, the system should disable the user s access account for a certain amount of time. This helps deter brute force password cracking attacks on the system. Although remote users do not normally need to respond rapidly to operation situations, there may be instances, such as unmanned control rooms or remote facilities (for example, SCADA systems controlling an electrical distribution system) where rapid access is required from a remote location. In these cases, disabling the access account may not be appropriate. Each organization should address authentication of remote users in a manner appropriate to their situation and tolerance for risk. d) Require re-authentication after remote system inactivity After a defined period of inactivity, a remote user should be required to re -authenticate before the system can be accessed again. This makes sure that the access account is no t left open and accessible from the remote device. Although remote users do not normally need to connect to the control system for long periods of time, there may be instances, such as unmanned control rooms or remote facilities (for example, SCADA systems on an electrical distribution system) where a remote operator may need to monitor the system over an extended period of time. In these cases, requiring re-authentication may not be appropriate. Each organization should address authentication of remote users in a manner appropriate to their situation and tolerance for risk. For remote users, the level of authentication required should be proportional to the risk to the system being accessed. Weak authentication may be appropriate if the system does not have

197 ISA99, WG ISA , D7E control over operations with a high HSE risk. For systems with HSE risks, strong authentication may be more appropriate. Examples of weak authentication include: 7637 connecting modems directly to industrial operation control devices or networks that employ 7638 simple user ID and password authentication; 7639 connecting industrial operation control devices or networks from the corporate LAN or WAN 7640 that employ simple user ID and password authentication; 7641 using Microsoft Windows user ID and password authentication at the application level on 7642 industrial operation control devices Examples of strong authentication include: 7644 using Physical token or smart card two factor authentication that requires both a physical 7645 device and unique knowledge (for example, a Personal Identifier Number, PIN) in the 7646 possession of the user; NOTE Security is enhanced by using secure PIN entry, for example, when the PIN is entered using a secure reader to prevent keylogging authenticating using smartcards or biometrics; 7650 authenticating users based on their location; 7651 connecting modems to industrial operation control devices or networks that employ a dial -back 7652 feature to a predefined phone number; 7653 connecting industrial operation control devices or networks to the corporate LAN or WAN and 7654 using smartcards or biometric authentication; 7655 connecting home computers to industrial operation control devices or networks using a VPN 7656 connection and two-factor authentication with a token and PIN C Authentication for task-to-task communication 7658 Task-to-task communications will not usually be monitored directly like user interactive sessions Authentication of task-to-task communications will typically happen at the startup of an industrial 7660 operation and at regular intervals afterwards. Systems should employ some technical solution to 7661 authenticate each device or network NOTE ISA TR Error! Reference source not found. provides an explanation of these and other technologies. It discusses their strengths and weaknesses and their applicability to the IACS environment. C Supporting practices C Baseline practices The following five actions are baseline practices: a) Establishing a strategy or approach that defines the method of authentication to be used. The method may vary depending on the risks, the consequences associated with the business process and the sensitivity of the data. b) Employing different strategies for users connecting from different geographical locations (including remote facilities) or for devices with special security requirements. This issue takes into account the physical security characteristics that interact with the cyber security characteristics to establish the overall security level for the user. c) Authenticating all users prior to being allowed use of a particular application. This requirement may be waived when there are compensating physical controls d) Requiring at least a manually entered user ID and password as the minimum level of electronic 7677 authentication.

198 ISA , D7E5 196 ISA99, WG e) Authenticating task-to-task communication by knowing the MAC and/or IP address for the device, a specific electronic key, the device name, and the like. C Additional practices The following action is an additional practice: a) Authorizing users inside a locked facility that employs guards and badge-readers to access systems having a greater level of risk than a remote user would be allowed. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found.. C ELEMENT Access : Authorization For additional information about the overall topic of Access control, see the introductory material in C Figure A.12 Access control: Authorization Authorization, the third leg of access control is shown in Figure A.12, is the automated procedure performed by the computer system to grant access to resources upon successful authentication of the user and identification of their associated access account. The privileges granted are determined by the access account configuration set up during the account administration step in the procedure. Some standard authorization procedures employed in the general IT work space may be inappropriate or inadequate for IACS. For example, access accounts in a typical IT system are primarily user-based with a limited number of roles assigned (that is, standard user or system administrator). Each user is usually only assigned one role. Access accounts in a typical IACS system will primarily be role-based with a greater granularity of roles (that is, operator, engineer, application specialist, vendor and system administrator). Users may be assigned multiple roles based on a particular job function they need to perform at a particular time. The user may have to login to a particular device and separately into an application to be authorized to make changes to industrial automation control variables. Or, a user may have to log off a system and re -login to perform system administration tasks on that same device. This subclause explores the controls aimed at protecting information and assets from deliberate and inadvertent destruction, change or disclosure. It focuses specifically on measures designed to ensure that the authenticated agents (that is, personnel, applications, services and devices) have access to required information assets. Information that is sensitive to disclosure needs to be properly protected both to maintain competitive advantage and to protect employee privacy. The authorization rules desired by an organization will determine how it assigns roles to specific users or groups of users and how privileges for these access accounts are configured. The

199 ISA99, WG ISA , D7E capability to implement a desired authorization policy depends upon features in underlying systems to distinguish the functions and data required for different job roles. Thus the definition of an authorization policy is an iterative procedure where the organization defines an ideal policy and then determines how closely that can be implemented using the capabilities of their systems and network. If procuring a new system, support for a desired authorization policy can be an element of the procurement specification. When designing a new network configuration, technologies like firewalls for remote users can be added to create an additional layer of authorization for critical devices, as described in the following paragraphs. C Considerations for authorization C General When developing a program for access control, it is important to include all systems in scope, and not just limit the effort to traditional computer room facilities. a) Authorization security policy Rules that define the privileges authorized under access accounts for personnel in various job roles need to be defined in an authorization security policy that is clearly documented and applied to all personnel upon authentication. b) Logical and physical permission methods to access IACS devices The permission to access IACS devices should be logical (rules that grant or deny access to known users based on their roles), physical (locks, cameras and other controls that restrict access to an active computer console) or both. c) Access to information or systems via role-based accounts Access accounts should be role based to manage access to appropriate information or systems for that user s role. Safety implications are a critical component of role definition. C Authorization for local users Many process industries control their operations from control rooms staffed by several operators. These operators often function as a team and perform actions on multiple HMI stations as part of their normal job function. Authorization to perform specific job functions is provided by the application. The local user is granted access to certain devices or operational displays based upon a role-based access account. The actual login user ID and password are typically common for everyone in the job role. This work-team approach to control room operation may conflict with standard IT authorization policy and practice. Safety implications shall be considered when developing the authorization strategy. For high - vulnerability industrial operations, authorization privileges should be set at the local process control device level and should not require access to devices at the LAN or WAN level to assign privileges. This supports the basic control principle of minimizing the potential points o f failure. Access accounts should be configured to grant the minimum privileges required for the job role. Training needs to be employed to establish common levels of skills for each of the job roles. Customizing individual access accounts to match skill levels of personnel should be avoided. All users in the same job function should utilize access accounts configured for the same role. C Authorization for remote users The authorization process discussed thus far places the authorization function at the end -node device and application level. In critical control environments, an additional destination authorization strategy should be employed at a barrier device (firewall or router) for the IACS network. Once a user is authenticated at the barrier device, role-based destination access rights should be assigned to the user so that the user can only attempt to connect to pre-assigned devices on the IACS network. The end-node login should establish the user s final privileges for performing

200 ISA , D7E5 198 ISA99, WG functions on the device. Facilities with high-vulnerabilities should take advantage of this additional level of destination authorization. Role-based access accounts should take into account geographic location. A person may utilize one access account when working on-site and a different one when dialing in from home to assist local personnel. This practice should be clearly defined in the administrative procedures. Compliance with administrative procedures should be based on individual accountability. C Supporting practices C Baseline practices The following two actions are baseline practices: a) Permitting access to IACS devices with logical controls (rules that grant or deny access to known users based on their roles), physical controls (locks, cameras, and other controls that restrict access to an active computer console) or both. b) Logging and reviewing all access attempts to critical computer systems, both successful and failed. C Additional practices The following six actions are additional practices: a) Protecting network connections between the organization and other organizations through use of a managed firewall. b) Using an authenticating proxy server for all outbound access to the Internet. c) Granting access to a remote user by enabling a modem on an industrial operations control device only when needed. d) Using ushered access when high-risk tasks are performed (for example, industrial operations that have HSE consequences or that constitute critical business risks). e) Segregating data with high sensitivity and/or business consequence from other internal information so that existing authorization controls can restrict access to that information. f) Separating the business network from the IACS network with an access control device and limiting user access to critical assets on both sides. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C.4.4 Element group: Implementation C Description of element group The third element group in this category is Implementation. This element within this group discusses issues related to implementing the CSMS. Figure B.13 shows a graphical representation of the four elements in the element group: Risk management and implementation, System development and maintenance, Information and document management and Incident planning and response.

201 ISA99, WG ISA , D7E5 Addressing risk with the CSMS Implementation Risk management and implementation System development and maintenance Information and document management Incident planning and response Figure B.13 Graphical view of element group: Implementation C Element: Risk management and implementation C Description of element The foundation of any CSMS or security program is to maintain risk at an acceptable level. Risk management and implementation addresses the selection, development and implementation of security measures that are commensurate with the risks. The security measures may take into account inherently safer industrial operation design, use of products with strong inherent security capabilities, manual and procedural security countermeasures, and technology based countermeasures to prevent or reduce security incidents. Although risk will never be totally eliminated, it can be managed. This subclause describes a framework to measure risk and then manage it through the implementation of various security countermeasures to reduce the likelihood of an incident occurring or reduce the consequence of the resulting event. In most cases risk is measured in terms of cost and or social conscience. While it may be easy to put a price on a production outage due to a cyber security incident, it is not possi ble to assign an exact cost to an event resulting in the injury or death of a person. Companies shall determine their risk tolerance to certain kinds of events and use this to drive the strategy for managing risk. C Building a risk management and implementation framework Because the elimination of all risk is usually impractical or impossible, organizations should focus on the most critical applications and infrastructures to decrease risk to an acceptable level. Deciding what cyber security countermeasures to implement is a matter of balancing risk and cost. Decisions should be based on a risk assessment and be documented to serve as a basis for future planning and action. Organizations should analyze the detailed risk assessment, identify the cost of mitigation for each risk, compare the cost with the risk of occurrence and select those countermeasures where cost is less than the potential risk. Because it may be impractical or impossible to eliminate all risks, focus on mitigating the risk for the most critical applications and infrastructures first. The same risks are often found at more than one location. It makes sense to consider selecting a standard set of countermeasures that may be applicable in more than one instance and then defining when to use them. This approach will allow the organization to leverage common solutions and reduce the design and implementation costs to improve the security posture of the organization. One possible way to approach this is to develop an overall framework for implementation that incorporates risk assessment, the organization s tolerance for risk, countermeasure assessment and selection and the strategy for implementing risk reduction activities. Each organization will likely have a different risk tolerance that will be influenced by regulations, business drivers and core values. The organization s risk tolerance for IACS incidents determines the amount of effort an organization is willing to spend to reduce the level of risk to an acceptable level. If the organization has a low risk tolerance it may be willing to commit a greater amount of financial and/or personnel resources to the task of improving the security level of the IACS.

202 ISA , D7E5 200 ISA99, WG Error! Reference source not found. identifies the organization s sensitivity to different types of risk and aggregates the various consequences into categories of high, medium, or low. When these categories of consequences are combined with the likelihood of an incident occurring, as in Table B.1, the result is a matrix of consequence category versus likelihood. In the absence of an analytical method to quantitatively measure likelihood and consequence, it may be practical to simply assign qualitative risk levels of low, medium and high to the points of intersection in the matrix. These risk levels reflect the organization s sensitivity to risk, as shown in Table B.3. These risk levels imply thresholds of tolerance which will drive the risk reduction implementation strategy. This is a clear way to communicate the organization s position on risk. The risk reduction strategy may employ different countermeasures, architecture practices, IACS device selection and the decisions of when and where to employ them based upon the risk level shown in Table B.3. Systems with a high risk warrant employing more extensive countermeasures to achieve a higher level of security. One way to capture the organization s decisions on countermeasure selection is to develop a chart listing specific countermeasures to be used for IACS devices based upon the risk-level of the IACS. An example of a possible countermeasure chart is show in Table B.4. The table defines the common solution set of countermeasures to be employed to try to reach the target security level. These countermeasures are to be employed unless there is some unique constraint that makes this solution undesirable for a given IACS. The organization s risk reduction strategy may also use the risk-level ratings to establish priorities and timing for implementing the identified countermeasures shown in Table B.4. IACS with high-risk ratings should probably be addressed with greater urgency than lower risk IACS. The countermeasures to address a specific risk may be different for different kinds of systems. For example, user authentication controls for an advanced application control server associated with a DCS may be different than the authentication controls for the HMI on the packaging line. Formally documenting and communicating the selected countermeasures, along with the application guidance for using the countermeasures, is a good strategy to follow. Table B.4 Example countermeasures and practices based on IACS risk levels Countermeasure and architecture practices Two-factor authentication to control access to the device High-risk IACS Medium-risk IACS Low-risk IACS Required Required Optional Hardening of the operating system Required Recommended Optional Employ network segmentation Required Required Optional Employ antivirus application Required Required Required Use of WLAN Not allowed May be allowed Allowed Strong password authentication at the application level Required Recommended Recommended Other countermeasures There are many different information technology risk mitigation countermeasures that can and should be applied to IACS devices. Guidance on specific countermeasures is addressed in other parts of the ISA/IEC series that are still in development, such as ISA Error! Reference source not found. and ISA Error! Reference source not found., which provide an in-depth look at different available countermeasures and their application to the IACS environment.

203 ISA99, WG ISA , D7E Most organizations will have a limited set of financial and personnel resources to apply to CSMS activities. As a result, it is important to use these resources in a manner that yields the greatest returns. A risk management framework begins with understanding vulnerabilities that exist within the IACS and the potential consequence that could occur should that vulnerability be exploited. Once risks are understood, the company needs to develop an implementation framework to reduce risk or keep it at an acceptable level. Several of the security models discussed in ISA Error! Reference source not found. will be used in creating the implementation framework. The models include the Security Level Model along with the Zone and Conduit Model. NOTE This subclause of the document discusses one possible way to approach this key CSMS element using the ISA Error! Reference source not found. security models. There is no one right approach to this element. Alternate approaches can result in a very functional framework for managing risk. The detailed discussion and example that follows on the topic of risk management and implementation describes the framework process as it is applied to reduce cyber security risks to an existing system in a single industri al operating area. The framework is equally applicable to many new IACS in multiple locations around the world. No matter what detailed risk management and implementation approach is employed, a good quality framework shall address four main sets of tasks over the life of an IACS: Assessing the risk of the IACS; Developing and implementing countermeasures; Documenting countermeasures and residual risk; Managing residual risk over the life of the IACS. These tasks are covered in detail in C through C and are graphically represented in the security lifecycle models discussed in ISA , 5.11 Error! Reference source not found.. C Assessing the risk of the IACS to determine the IACS cyber security risk level C General The zone and conduit model, security level lifecycle model, and reference model are described in detail in ISA Error! Reference source not found.. The use and integration of these models will be discussed in this subclause. C.3.3 provides guidance on a procedure to be followed in order to analyze the risk of the IACS. This is one of the earliest activities in the assess phase of the security level lifecycle model. An organization needs to develop and document a risk analysis process so that it can be used on multiple IACS at different locations throughout the organization with repeatable results. This subclause explains how the assessment phase fits into the overall risk management strategy. This is illustrated by walking through the scenario of examining an existing IACS and improving the cyber security position of this system to reduce risk. Figure B.14 shows the Security level lifecycle model s Assess phase.

204 ISA , D7E5 202 ISA99, WG02 Address security of IACS No Are zones established for the IACS? Vendor and user task Assess consequence/risk of the process Establish IACS zones and conduits Reassess SL(target) of IACS From maintain phase Vendor task Legend Is SL(target) known for the zone and conduit? Assess company s risk tolerance Review the degree of security protection offered by each SL User task Select appropriate SL(target) for the zone and conduit SL(target) goal for zone and conduit Figure B.14 Security level lifecycle model: Assess phase For an existing IACS that has never undergone a risk assessment and has not yet employed the Zone model, the activity begins with the box labeled Assess consequence/risk of the process. The purpose of the assessment is to understand the risk impact to the business in the event the IACS is compromised by a cyber incident and is not able to perform its intended control functions or performs unintended functions. Once the risk associated with the IACS has been documented the activities associated with managing and mitigating the risk should be performed. Yes No Yes To develop and implement phase

205 ISA99, WG ISA , D7E The output of the risk analysis will be a table listing the consequence rating and likelihood rating for each IACS asset or some collection of assets. Table B.5 is an example output of a detailed risk assessment and results from combining Table B.1, Error! Reference source not found. and Table B.3 of this document. The likelihood rating is assigned based upon the detailed vulnerability assessment of each of the assets listed, and the likelihood of related threats being realized. C Table B.5 Example IACS asset table with assessment results IACS device asset Consequence rating Operator control room console A Medium Remote operator console C High Engineering configuration station A High Historian server B Medium ler A Medium Gateway B Medium Other devices C Low Determining the IACS risk level Likelihood rating Table B.3 above is a simplified example model for translating a company s sensitivity to risk into qualitative levels of risk for the IACS. It should be prepared by the organization s responsible leadership before the risk analysis is conducted. The intersection of the Consequence and the Likelihood ratings yields the Risk Level. EXAMPLE An IACS device with a consequence rating of B and a likelihood of High would represent a high -risk device. The risk postures in Table B.3 can be applied to the IACS device assets in Table B.5 resulting in an overall rating for the IACS as shown in Table B.6. This table provides a priority ordering for particular vulnerabilities. Each device has a cyber security risk level associated with it. In a tightly integrated IACS, the control functions provided by each device are highly dependent upon the integrity of the other devices in the IACS. The functional integrity of the control system will be impacted by t he integrity of the weakest device. A simplifying security assumption is that the device with the highest IACS risk level establishes the inherent risk level for the entire IACS. In the example IACS listed in Table B.6, the inherent risk level for the IACS is High-risk because several of the IACS devices have a risk level identified as High-risk. Table B.6 Example IACS asset table with assessment results and risk levels IACS device asset Consequence rating Likelihood rating Operator control room console A Medium High-risk IACS device risk level Remote operator console C High Medium-risk Engineering configuration station A High High-risk Historian server B Medium Medium-risk ler A Medium High-risk Gateway B Medium Medium-risk Other devices C Low Low-risk

206 ISA , D7E5 204 ISA99, WG Understanding this base inherent risk level is a key to carrying out a risk management plan. It establishes the target security level needed to reduce risk. This establishes the justification for implementing a risk reduction and management plan, if the IACS is not already operating at that target level. Various security countermeasures will be employed to reduce the risk to the IACS to a tolerable level. However, a failure of these countermeasures to mitigate the risk could result in an incident with a consequence of the magnitude identified during the risk analysis task C Establishing security zones and associating IACS devices to the zones The reference model discussed in ISA Error! Reference source not found. identifies several different operational or equipment levels of an IACS. Although there may be different operational levels within an IACS, the cyber security requirements may be similar for several of these operational or equipment levels. It may be possible to incorporate several operational/equipment levels into a single logical security zone. The security level model introduces the concept of employing zones assigned to one of three or more security levels. For illustration purposes in this example, assume there are three security levels qualitatively described as Low, Medium and High. The task at hand is to examine the security needs of the various IACS device assets and assign them to these different zones. Table B.6 lists the IACS cyber security risk level for each of the assets. Assets with a High -risk level share a need for a high level of cyber protection to reduce risk. These assets should be assigned to a common security zone. Assets with lower risk levels should be assigned to a lower security zone. At this point in the risk management process, it is appropriate to superimpose the identified security zones onto the system physical network diagram developed for conducting the risk analysis. Given today s security countermeasure technologies, security zones will typically align with physical network segments. An IACS device may not be currently located on the proper network segment based upon the risk analysis results for that device. If this is the case, the device may need to be relocated to a different network segment. An asset with a Low-risk level may be assigned to a higher risk security zone, but assets with a High-risk level should not be placed into a lower risk security zone. To do so would raise the risk of an unacceptable consequence in the event of a cyber security incident. During the implementation phase of the security level lifecycle model, the devices with security needs that do not match with the zone the devices are physically located in should be relocated to the appropriate network segments to meet the security requirements. An organization may choose to establish a common approach to security zones in an effort to improve the efficiency of managing risk. One way to do this is to adopt a corporate template architecture incorporating network segmentation strategies and security zones for the various kinds of devices and systems employed in the enterprise. Figure B.15 shows an example of a security zone template architecture for an organization. Figure B.16 shows how the IACS assets in the example are mapped to the zones in the template architecture that employs a three-tier zone approach.

207 ISA99, WG ISA , D7E Figure B.15 Corporate security zone template architecture

208 ISA , D7E5 206 ISA99, WG Figure B.16 Security zones for an example IACS C Determining the target security level The security level model introduces the concept of assigning a security level to the zone. In the example shown in Figure B.16 above, the inherent risk level of the IACS was determined to be High-risk based upon the detailed risk assessment of each IACS device. Extra security countermeasures need to be employed to protect the devices falling within the Plant A control zone. Using the security levels listed in ISA , Table 8, it is appropriate to assign a target security level to each of the zones, as seen in Table B.7.

209 ISA99, WG ISA , D7E Table B.7 Target security levels for an example IACS Zone Plant A control zone Plant A DMZ Plant A LAN zone Enterprise zone Target security level = SL(target) High Medium Low Low C Selecting devices and a system design based upon SL(capability) The security level capability of each device shall be examined to understand the security strengths and vulnerabilities it introduces to the zone. Although the SL(capability) cannot be quantitatively measured at this point in time, there are some more qualitative means to assess the relative SL(capability) of the devices comprising the IACS. These assessment items are typically covered as part of a detailed vulnerability assessment. For example: If the device is a web server, running an assessment tool to identify weaknesses of web server applications and determine if the weaknesses can be remediated. Running an assessment tool to identify the number of services and ports required for the application to function on the device. Examining the required ports and services to determine if these have been historically used by attackers to exploit system vulnerabilities. Examining the operating system of the device and determine if security patches and upgrades are still being supplied for the version in use. Running an assessment tool to subject the application to unusual inputs to determine if the device and application will continue to function under abnormal communication streams. Examining the exploit history of the underlying technologies used in the device to ascertain the likelihood for future exploits. The organization should have some acceptance criteria for a device to be used in a particular target security level based upon the results of these assessment tools and identified weaknesses. If the SL(capability) of the device is simply too low to achieve the SL(target) for the zone, an alternate device may need to be selected. For an existing IACS comprised of older generation devices, it may be necessary to replace the device with a newer generation device with improved SL(capability). An example of this might be a PC-based operator control station running on Microsoft Windows NT as its operating system. The detailed vulnerability assessment results for this device and application may show significant vulnerabilities. The security features built into this older operating system are less than in many of the newer generation operating systems. Additionally, security patches to address these vulnerabilities are no longer being supplied by the vendor. This leaves the device in a relatively weak position with respect to its SL(capability). The SL(capability) of each new IACS device should be examined to ensure that it supports the goal SL(target) for the zone. Although quantitative measurements of SL(capability) may not be available and/or published, vendors may be able to provide some more qualitative measures based upon assessments they or third-parties have conducted using standard security tools and field trials. These detailed vulnerability assessment results should be considered and used in the decision process for selecting IACS devices. The preliminary design identifying IACS devices and zone assignments shall be transformed into a detailed design identifying all equipment and network segments to be employed in the IACS. This is the time to relocate devices whose security risk needs do not align with the SL(target) f or the zone. The output of this step should be a detailed network diagram locating all IACS and network devices that will be a part of the overall IACS.

210 ISA , D7E5 208 ISA99, WG C Developing and implementing the selected countermeasures for each zone C General The Security level lifecycle model s Develop and implement phase addresses the steps and tasks to reduce risk. The overall concept of this phase is to employ countermeasures to an IACS to achieve the target security level for the zone established during the assess phase. Figure B.17 addresses several different starting points. It applies to implementing a new IACS, making changes to an existing IACS in the form of new equipment, and improving the security of existing IACS. Figure B.17 is a frame of reference to guide thinking rather than a detailed flow diagram or checklist of steps that have to be followed.

211 ISA99, WG ISA , D7E5 New IACS From assess phase Change to IACS Change to SL(target) To maintain phase Design IACS to meet SL(target) Select devices based on SL(capability) Develop integrated design SL(achieved)t0 for the zone and conduit Note: t0 = at time 0 Is this a new or existing IACS? Factory acceptance test IACS using the security assurance properties for the SL level Validate system SL(capability) Install IACS in the field Yes New Is SL(achieved) acceptable? No Existing Install new IACS devices in the field Test integrated IACS for the security assurance properties Factor in the security assurance implications associated with the security measures in place in the field Vendor and user task Vendor task User task Implement additional compensating security measures or accept risk Determine the SL(achieved) Legend Figure B.17 Security level lifecycle model: Develop and implement phase

212 ISA , D7E5 210 ISA99, WG The beginning point of this phase is the security goal to be achieved. This is expressed as the security level target for each zone of the IACS. Under the Assess phase these targets were established and preliminary zone assignments made for each of the IACS devices. The task at hand is to take this preliminary approach and create a detailed design for implementation. C Offline security testing Just as functional testing of an IACS is critical to implementing an IACS so that it will meet the needs of the operating facility, security testing of the devices is also important to make sure the operational integrity and robustness will be achieved. C provides more detailed information on performing security testing. If the IACS is a new system, security testing should be conducted while the system is in an offline environment. This could be a factory acceptance test at the vendor s location or an offline staging step at the final field location. The location is not as important as making sure the se curity testing steps are undertaken. While it would be very valuable to security test all devices and countermeasures employed in the final installed state, this may not be affordable and practical. So the testing design should focus more on the SL(capability) of the IACS devices and the countermeasures that are not specific to the installed field location. The preceding subclause noted several tools and items for consideration for testing SL(capability). These items are typically covered as part of a detailed vulnerability assessment. Security testing should include not only tests to assess the ability to resist typical security threats encountered under operating conditions, but should also include the measures that will be part of ongoing system security support. These include but are not limited to: testing the patching process for operating system patches and upgrades; testing the patching and upgrade process for IACS vendor updates; testing the offline system development environment; testing deployment of antivirus software and malware signature updates. The overall goal of the security testing activities shown in the middle of Figure B.17 above is to validate that the SL(capability) of the devices aligns with the design basis. C Field security testing The items shown on the right side of Figure B.17 above identify the testing activities associated with the final destination environment. This is the point where all the employed countermeasures are tested and/or examined to determine if the achieved security level equals or exceeds the target security level design basis for the zone. If this is a new IACS being installed it is probably possible to conduct these tests before the IACS is placed online. If the activity is to retrofit and replace an existing IACS device or implement some new security countermeasures to the IACS, it may not be possible to obtain a window of opportunity to do full offline field security testing. Instead the challenge is often implementing the new device or countermeasure and field testing that the basic operating function of the IACS has not be en unacceptably impacted by the security measures. It is important to keep in mind that system performance testing should include system response to normal and abnormal industrial operating type events as well as normal and abnormal security incident type events. These combine to yield an overall measure of the robustness and integrity of the system. Because each industrial operation is slightly different, it is not possible to identify a cookbook type procedure for this testing. It will require considerable design work to determine the best way to assurance test that the security functions are meeting the security objectives to achieve the Target Security Level.

213 ISA99, WG ISA , D7E C Meeting the target security level Achievement of the target security level in the field may require some degree of iteration. The field is not a perfect world. Typically it is appropriate to try to apply a common set of countermeasures to all the devices within the zone to achieve the desired security level. A selected countermeasure identified for implementation on all devices may not be useable on a particular device because of an operational or physical constraint not initially recognized during system security design. Therefore it is important to recognize that real world situations may require the elimination of, as well as the addition of, countermeasures for individual devices within a zone to achieve the proper balance of security benefit versus risk so that all parties involved with the decision process are satisfied. C Illustrating the design process using the IACS example The previous subclauses discussed the principles regarding implementing security countermeasures to meet the SL(target) for the zone. This subclause describes the design process of applying these principles to a real world example. Table B.6 identified a historian server with a device risk level of Medium. Using the corporate template security architecture, this device was identified as needing to be located in a security zone with a SL(target) of medium or higher. The Plant A DMZ was identified as the appropriate zone for this device even though the device is currently located on the Plant A LAN zone. In preparation for physical implementation of the Plant A DMZ, the SL(capabilit y) of the historian server is examined to determine if it meets the SL(target). Examination of the vulnerabilities from performing a detailed vulnerability assessment reveals that: The operating system for the server is Microsoft Windows NT, for which security updates are not available. No antivirus application is running on the server. The vendor of the historian application has not qualified any antivirus software products as compatible with the historian application. The majority of the users of the historian application are located in office areas with PC connections to the lower security Plant A LAN zone. Efforts to harden the server by shutting down non-needed tasks were not successful because the historian application vendor would not certify that the application would run properly if the services were shut down. The conclusion is that the inherent SL(capability) of the historian server is inconsistent with the SL(target) for the Plant A DMZ. Since the inherent SL(capability) is too low, the use of additional supplementary countermeasures are examined to determine if they can successfully reduce risk to meet the SL(target). Additional countermeasures such as eliminating Internet access, eliminating , disabling media ports on the server, employing strong passwords are examined. Although these can contribute to risk reduction, it is felt that employment of these additional security practices would not compensate for the low inherent SL(capability) of the historian server. Since the historian server directly interfaces to the IACS gateway of the regulatory control network, the security weaknesses of this device also lowers the SL(achieved) of the Plant A control zone. The conclusion is that the best way to address these unacceptable SL(achieved) states of both the Plant A DMZ and the Plant A control zone is to replace the present historian server with a newer historian software application running on a currently supported operating system. After examining the SL(capability) of the newer server and historian application to ensure it aligns with the SL(target), the server and application are tested and implemented in the Plant A DMZ during an industrial operation shutdown.

214 ISA , D7E5 212 ISA99, WG There are some important points worth highlighting in association with this example. The SL(achieved) of a zone is dependent on the SL(capability) of the devices in the zone but also the connectivity within and between zones. A vulnerability analysis for a device considers not only inherent properties of the device considered in isolation, but also the connectivity of this device in the network. This is important because an IACS that uses only devices that have High SL(capability) when considered in isolation may, when considered together, not necessarily achieve the desired High SL(target) for a zone. For example, a new IACS device employing a new operating system, even if fully patched and running antivirus software, has a lower SL(achieved) when directly connected to the corporate IT network. Conversely, if one limits physical access and network connectivity to a zone, devices of lower SL(capability) might together achieve a higher SL(achieved) for the zone. The security of the conduit between zones can also impact the SL(achieved) of the zone. For example, a conduit using a wireless communications link rather than a physical cable may have a different SL(achieved) for the conduit and have an impact on the SL(achieved) of the zones joined by the conduit. Similarly the SL(achieved) of the zone in consideration may be impacted by the securit y level of the zone connecting to the zone in consideration. In the example, the users of the historian application are in a zone with a lower security level than the historian server. Even if the SL(achieved) of the conduit between these zones is High, the lower SL(achieved) of the Plant A LAN zone can potentially negatively impact the SL(achieved) of the Plant A DMZ. C Maintaining the security levels for each zone C General The level of security of a device is constantly eroding. New security vulnerabilities are discovered nearly every week. During the period of time that vulnerability exploits are known and unmitigated, the IACS may be at risk and the SL(achieved) of the zone is potentially lower than the SL(target). This real-world situation shall be addressed with a plan to maintain the security level of the zone to an acceptable security level. The Security lifecycle model s Maintain phase, shown in Figure B.18 below, depicts the cyclical set of activities that are critical to sustaining the security of the zone. The triggers to initiatin g the reassessment of risk include but are not limited to: a change to the physical industrial operation or changes to the IACS which could introduce new risks; a new vulnerability discovered in a software module used in the IACS; the release of a new operating system or application patch which triggers the deployment of exploit code to the Internet; scheduled periodic security audits and reviews.

215 ISA99, WG ISA , D7E5 From develop and implement phase Process change New vulnerability detected Scheduled periodic security review MS issues OS patches and updates Vendor tests OS patches and updates for functional compatibility and security assurance properties Vendor develops application fixes as necessary Vendor application fixes Vendor and user task C Vendor task Legend Conduct security review to assess vulnerabilities Vendor publishes results Compatibility and SL(capability) impact User task Figure B.18 Security level lifecycle model: Maintain phase Patching IACS Devices Examine impact, determine SL(achieved)tn+1 Note: tn = at some later time other than at time 0. Review vendor assessment of OS patches and updates Test OS patches and updates and application fixes in off-line environment No Accept the risk and document SL(achieved)tn Is actual SL(achieved) acceptable? Is there a patch addressing the vulnerability? Deploy patches and updates in controlled manner to minimize potential of common mode failure Determine SL(achieved)tn +1 Is actual SL(achieved) acceptable? Record SL(achieved)tn +1 Implement additional security measures To assess phase New SL(achieved)tn for the zone and conduit Figure B.18 above offers a high-level overview of how patching fits into the maintain phase of the security level lifecycle model. This subclause is not meant to be a comprehensive discussion of all the aspects associated with patching. The goal is to depict the iterative aspect of examining the SL(achieved) state of the zone and the need to make solid decisions about what patches to apply and when to apply them. Vendors of IACS devices and applications share responsibility with users for addressing security risks. Users count on the vendors to understand the inner workings of their IACS applications, to Yes No Yes No Yes No

216 ISA , D7E5 214 ISA99, WG determine the applicability of the patch and to perform thorough automated regression testing for compatibility of the IACS application with operating system patches and major revision updates. Since installing patches has the potential to interfere with the normal operation of the IACS software application, users need as much assurance as possible that the installation of the revised software will not result in a failure of the control device. As Figure B.18 indicates, vendor compatibility testing is the first step in a multiphase testing plan before widespread patching is conducted on the running IACS. Additional testing should be conducted with the target environment of the device. Ideally this would be performed on an offline device identical to the live IACS. If this is not possible, alternate approaches should be considered which could include testing in a virtual environment or in a very controlled deployment to the live IACS. Armed with vulnerability information from the operating system vendor, patch applicability information from the IACS vendor, compatibility information from the IACS vendor, knowledge of the use of the IACS device and finally user testing, the user shall make a decision on field deployment of the patch. C Employing additional countermeasures It may be necessary to employ additional countermeasures to address unmitigated vulnerabilities from patches or vulnerabilities introduced by changes to the industrial operation. This is determined by assessing the SL(achieved) and comparing this to the SL(target) for the zone. As was noted earlier, this is rather subjective rather than being easily measured in good quantitative terms. In some cases the business risk of taking action to raise SL(achieved) may be cost prohibitive in the short or long term. In this case, the technical decision makers should document: the risks; the countermeasures employed; the countermeasures considered, rejected and reasons why; the recommendation to business leaders to accept the risk for some period of time until a more acceptable countermeasure or security solution can be identified, tested and implemented. Business leaders should formally signoff to document acceptance of this strategy. C Scheduled security reviews A comprehensive CSMS includes a conformance element that should include a periodic assessment that the security practices and countermeasures as identified in the corporate security policy and standards are being employed and are effective in reducing risk to achieve the SL(target) level. This is another trigger to the Security level lifecycle model s Maintain phase. A security audit may measure the degree of conformance to the defined policies and standards and result in metrics that are valuable to sustaining security. However, in addition to veri fying alignment with the required practices, an organization should periodically (and based on triggers as shown in Figure B.18), assess whether the SL(achieved) meets or exceeds the SL(target) in its IACS zones. C Supporting practices C Baseline practices The following eight actions are baseline practices: a) Defining and validating security policies. Detailed security policy statements define the operational level commitment to mitigate each of the security risks during the risk assessment.

217 ISA99, WG ISA , D7E b) Developing procedures that provide details, like actions to take for preventing, detecting and responding to threats. c) Adapting standards from international organizations in the area of cyber security for use in the organization s IACS environment. d) Developing services such as secure OS images and common applications for secure IACS use. e) Identifying security tools and products to implement parts of the security pol icy. While security tools and products, like firewalls and VPNs, may be used in the IT and IACS environments, the rule sets and application of these types of tools and products may be significantly different due to the different risks associated with the environments. f) Establishing a formal methodology for accepting risk, including the appropriate management level approval based on scope and documentation. g) Implementing policies, procedures, tools, and the like in a manner that minimizes administrative overhead and burden on the end-user without compromising effectiveness. Well-designed controls often leave behind their own audit trail that can be used for verification later. h) Documenting the reasons for selecting or not selecting certain security countermeasures and the risks they address in a Statement of Applicability (SoA). Good documentation on security mitigation controls aids in the decision making process, facilitates the communication of the decisions, provides a basis for training people to respond to incidents and threats and provides a basis for self-assessments or audits of the conformance to the countermeasures. C Additional practices NOTE 1 ISA TR Error! Reference source not found. and ISA Error! Reference source not found. will address related practices when they are completed. NOTE 2 The authors of this standard realize that there are many different types of countermeasures available. They also realize that to include a list of different types of countermeasures here would either provide the reader with too much information to digest or not provide enough detail for the reader to accurately apply the controls to IACS. The authors therefore have chosen to defer the discussion of additional IACS security practices related to countermeasures to other documents, which can provide the reader with a much more in -depth look at the different types of countermeasures available and how to apply them correc tly to the IACS environment. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., [16], Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C Element: System development and maintenance C Description of element This element addresses supporting methods necessary to develop and maintain the IACS information technology systems that impact and are impacted by the CSMS. It discusses the cyber security aspects of: requirements documentation, design, procurement, testing, change management, patch management and backup and recovery processes. The key point of this element is to give insight about how to implement these methods in a cyber security aware manner. The approach s aim is not to reproduce documentation describing the fundamentals of these methods but to explain how security issues are inherent in system development and maintenance processes. Security issues shall be addressed throughout the normal course of all System Development and Maintenance processes. C Requirements documentation C introduces the concept of a target security level. The term requirements refers to capabilities and/or characteristics of a given system or device. Requirements may refer to many

218 ISA , D7E5 216 ISA99, WG characteristics in many contexts: systems or software, product or industrial operation, functional or non-functional requirements. However, for the purpose of this element, System requirements are defined as the attributes of the target security level and Device requirements are defined as the countermeasure characteristics necessary for the devices within the zone to achieve the desired target security level. Because the system requirements define the target security level, they shall be determined in the Risk management and implementation phase. These system requirements are often referred to as high-level requirements. The device requirements may change depending on the results of the design phase. For example, a system requirement for the control zone might be to limit all network traffic to authentic control and automation traffic. A device requirement for a control operator console might be to disable all unused networking and communications protocols. In this case, that device requirement might only partially achieve the system level requirement. It may be necessary to have multiple device requirements to meet the system requirements. The detailed, verifiable, set of system and device requirements is the foundatio n for the testing methods and for the verification and validation design, procurement, change management and patch management processes. It is extremely difficult to tell if design, procurement, system changes, or patches violate the Target Security Level if the specific capabilities necessary to achieve at that level are not defined. C Design Cyber security should be built into the IACS during the design process. This objective should be considered during system procurement and development as well as during maintenance of the system. Numerous documents exist that discuss sound system design processes. This standard does not attempt to cover this subject. But it is worth emphasizing that a critical aspect of the design process is that specific countermeasures should be mapped to each of the system requirements in order to verify that the devices and the system as a whole satisfies the target security level. The design process not only covers the preparation of the project specification but also planning the verification approach and initial verification that the project meets the stated requirements. The initial verification may be performed through a paper analysis. The final verification is performed through testing of the system. It is important to realize that new projects are continually being initiated and executed. To avoid the potential for rework when these projects are installed and go on-line, the operations and engineering groups responsible for executing projects need to be aware of any applicable in dustryspecific cyber security standards and corporate cyber security policies and procedures. C Procurement The procurement process is particularly important in attaining the desired target security level. While specifying new or updated equipment to a vendor, it is important to include requirements for cyber security. If there are specific device requirements that are required to meet the system requirements, then these need to be explicitly declared in the procurement process for those devices. It may also be necessary to specify any device requirement for things that the vendor or integrator should not do. There are some practices that are common for device vendors or integrators to do on their devices that may lead to unnecessary security holes that would prevent the system from reaching the target security level. For example, vendors historically placed back - doors into their products in order to facilitate trouble-shooting and improve customer service response times. These back-doors are a vulnerability that an attacker could exploit. A sales representative may not even be aware of these back-doors and such trouble-shooting points should not be allowed unless they are explicitly included in the procurement requirements.

219 ISA99, WG ISA , D7E The topic of procurement language for cyber security is too large for this standard. Other groups have been developing this language and may be able to provide more information (for example, see Error! Reference source not found.). C Testing C General The purpose of a testing program is to assure that the system meets the stated requirements for the project. For a well-designed system, it should be designed to meet both the operational and security requirements. One of the earlier decisions to be made when developing a testing program is what level of assurance the organization requires from its vendors and integrators about the cyber security of the devices or systems. The level of assurance required for a particular device or system will determine the type of testing required. A vendor may have a recommended testing strategy for a particular device or system, but the user will need to determine whether that testing strategy is sufficient to validate their security requirements. Ideally, a system would be tested under all possible states to ensure that every security contingency is met or at least so that the residual risk is known. While complete system testing is theoretically possible, it is unobtainable for most specifications given financial and personnel constraints. Therefore, the challenge is to determine an acceptable level of risk and then perform a sufficient level of testing commensurate with the acceptable risk. After the initial test planning, written test plans and procedures should be prepared for each testing stage. These should define the tests to be performed and the expected results. They should include system configuration, system inputs and outputs and tolerable error bands. During testing, it is important to at least do a cursory check of the results to verify that they are as expected or determine if corrective action needs to be taken. After each stage of the testing is completed, the results should be evaluated. Following the system validation test, a final report should be prepared reviewing the results of all of the testing and summarizing the conclusions. C Types of testing Cyber security testing, like other testing in other domains, includes verification and validation testing. According to the Capability Maturity Model Error! Reference source not found.: Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that you built it right. Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that you built t he right thing. To summarize this, verification determines if the implementation satisfies the specification, while validation determines if the specification satisfies the requirement. The specific testing performed will depend on the level of testing required, the component or system being tested and the type of testing required for the system or component. Cyber security testing is typically performed in three stages: component testing, integration testing, and system testing. Verification testing shall be implemented during the component and integration stages, although validation testing may also be useful. Both verification and validation testing shall be implemented at the system testing stage. C Component testing Component testing should be performed by the vendor and verified by the system owner. The component may be software, hardware, firmware or any combination of these. The component needs to be tested to verify that it meets the specific operational and security requirements. Component testing is normally workbench testing and is necessary to ensure that, when the components are combined into a system, there is confidence that each individual component performs as intended.

220 ISA , D7E5 218 ISA99, WG C Integration testing Integration testing should be performed by the integrator and verified by the system owner. Such testing involves operational and security testing of the various components perhaps from different vendors, that are connected together on a workbench or in an auxiliary test bed in an effort to see if all of the components will work together correctly before being placed in the IACS environment. Integration testing may involve using additional test tools, like network management and administration tools, which were not necessary during the component testing phase. Rarely will a test bed have the exact configuration of the control system that exists in the operating facility. Often a simplified or replica system in a development or laboratory setup is best suited for the component and integration test phases. The integration tests should be designed around this test bed facility. Care should be taken to note differences between the integration test setup and the IACS environment as well as any additional tools needed so that items that could not be fully tested during integration testing are tested during system testing. For this reason, it may be helpful, especially during the integration test phase, to locate the simplified or replica system near the site of an operational system. In some instances, it is possible to perform a non-production integration test to see how security countermeasures will work together and how they will interface with the operational features. For example, security countermeasures that consist of discrete hardware/software may be connected via a laboratory test bed network. In other cases, this integration may not be possible. The integration test plan should take advantage of any test bed scheme that can be configured to test combinations of operating conditions that may be present in the operational system. C System testing System testing should be verified and validated by the owner. The objective of validation testing is to demonstrate through appropriate techniques, procedures, and procedure refinements (as needed) that the management, operational and technical countermeasures for the IACS are implemented correctly, are effective in their application, and ensure that the new security countermeasures, as procured and installed, meet the requirements. System testing may include penetration testing of the system to ensure that the security components are capable of protecting the system from various threats as necessary to satisfy the security level for each zone. Penetration testing is where a known person tries to penetrate the security defenses in a system, looking for weaknesses and vulnerabilities that can be exploited to gain either access or control over that system. Many companies specialize in penetration testing for traditional IT systems. It may be more difficult to find a group that understands the special requirements of IACS. A variety of testing tools such as test scripts, databases of variables, baseline configurations with an assumed start state, metrics and calibration tools are available to assist with the actual testing. Commercial and freeware tools that are preconfigured to perform diagnostic routines and simulate gateways and connected devices are also available. If any penetration tests are conducted, the performance of the system during the tests needs to be noted in addition to the penetration testing results. There will most likely be some performance degradation in the system or components due to the penetration testing. These performance degradations should be noted for future use. It is important to emphasize that security countermeasures may also involve people operating through policies and procedures, as well as manual checks of security. A countermeasure, for instance, may consist of a control engineer installing a security patch issued for hardware or software. The test plan might go through the sequence of a dry-run of the patch installation, noting other factors it influences.

221 ISA99, WG ISA , D7E C Separation of development and test environments Development and test activities can cause serious problems, such as unwanted modification of files or system environment or even system failure. It is important to conduct cyber security testing on systems that are not operational because of this, thus reducing the risk of accidental change or unauthorized access to operational software and business data through inappropriate developer access. If the development and test staff have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. Developers and testers also pose a threat to the confidentiality of operational information. Development and testing activities may cause unintended changes to software and information if they share the same computing environment. The preferred method of eliminating these problems is to use a system that is separate from the operational system to perform the initial development and testing. If this is not possible, care shall be taken to ensure that the system uses a properly defined change management system to document any changes that are made to the system and provide the capability to undo those changes. C Change management Change management systems for SIS are used in some industries based on regulatory requirements. For a complete CSMS, change management systems should be used for all IACS. The change management process should follow separation of duty principles to avoid conflicts of interest. This means that the same individual cannot both approve a change and implement the change. A technically knowledgeable individual should review proposed changes to IACS for their potential impact to HSE risks and cyber security risks based on clearly defined policies. If one of the policies is violated by the change, then the proposed change may need to be reviewed by other knowledgeable personnel to verify that it is valid or disapprove the change. For change management to be effective, there should be a detailed record of what is installed and this should form the basis for change proposals. The change management system shall be supported by a documented and proven backup and restoration procedure. It is critical that all system upgrades, patches and policy changes are implemented in accordance with the change management system procedures. C Patch management Installing patches, upgrades, and policy changes, which seem innocuous in isolation, may have serious cyber security ramifications. Failure to install these can also present serious hazards. A method shall be developed to determine the relevance and criticality of the vulnerabilities new patches are intended to mitigate. Such a method shall determine the impact on the ability to maintain the Target Security Level if the patch is applied and if it is not applied. NOTE ISA TR Error! Reference source not found. is a planned technical report on patch management. C Backup and recovery Special care should be taken to verify that the backup and recovery processes are compatible with the Target Security Level for the system. Generally, the backup and recovery process should ensure that backup copies are protected to the same extent as the originals. This may require special procedures to verify that backups have not been corrupted and that mechanisms that flag a successful backup or restoration have not been compromised. The stability of backups should be verified on a regular basis to make sure that the media containing the files has not degraded and also that the data contained on the media is still capable of being read and used. It may be necessary to keep legacy equipment in instances where older backups cannot be read by newer equipment.

222 ISA , D7E5 220 ISA99, WG C Supporting practices C Baseline practices The following six actions are baseline practices: a) Documenting security requirements (threats/countermeasures/testing plans). b) Mapping security countermeasures to security requirements. c) Defining expected failure response behavior. d) Defining, developing, and testing component functionality so that the entire system meets the target security level. e) Verifying and validating cyber security during component, integration and system testing. f) Including an authorization trail, a backup and restoration system, a patch management system and an antivirus/malware procedure into the change management system. C Additional practices The following five actions are additional practices: a) Implementing separate development, test and operational environments. b) Employing independent component verification and validation procedures. c) Employing independent integration verification and validation procedures. d) Employing independent system verification and validation procedures. e) Integrating IACS change management procedures with existing PSM procedures. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., Error! Reference source not found.. C Element: Information and document management C Description of the element Information and document management is the process for classifying all data, safeguarding the information, managing the documents and making appropriately available the information associated with the IACS and CSMS. IACS document management may be included in the organization s general records retention and document management system. Information and document management ensures that data is available for the required length of time based on internal (for example, organization policies and device maintenance) or external (for example, legal, regulatory and political) requirements. C Considerations for information and document management Information associated with an organization s CSMS is important, often sensitive and needs to be appropriately controlled and managed. Organizations therefore should employ comprehensive information and document management policies for their CSMS. Information associated with the development and execution of a CSMS, risk analyses, business impact studies, risk tolerance profiles, and the like may be organization sensitive and may need to be protected, as are countermeasures, philosophy and implementation strategies. Additionally, business conditions change and require updated analyses and studies. Care should be given to protect this information and verify that the appropriate versions are retained. Inherent in this is an information classification system that allows information assets to receive the appropriate level of protection. One of the first steps to creating an IACS information and document management system is to define information classification levels. Information (for example, confidential, restricted and public) should be defined for managing access and control of information assets. The levels and

223 ISA99, WG ISA , D7E associated practices should address sharing, copying, transmitting and distributing information assets appropriate for the level of protection required. After the basic levels have been defined, the information associated with the IACS (for example, control system design information, vulnerability assessments, network diagrams and industrial operation control programs) needs to be classified to indicate the level of protection required. This level of protection should be determined based on the sensitivity of the information and the potential consequences if the information was released. The classification level should indicate the need and priority of the information, as well as the sensitivity of the information. Policies and procedures for access to the information or documents need to be linked to the access control procedures as defined in C.4.3.5, C.4.3.6, and C A lifecycle document management process should be developed and maintained for this purpose. This process should confirm the security, availability and usability of the control system configuration. This includes the logic used in developing the configuration or programming for the life of the IACS. This process should also include a mechanism for updates when changes occur. Policies and procedures should be developed detailing retention, protection, destruction and disposal of company information including written and electronic records, equipment and other media containing information, with consideration for legal or regulatory requirements. The policies and procedures developed for the IACS information and document management system should be consistent with and feed into any corporate information and document management system. Legal reviews of the retention policies should be performed to ensure compliance with any laws or regulations. Documents requiring retention should be identified and a retention period should be documented. It is also necessary to ensure that appropriate measures are employed to ensure that long -term records can be retrieved (that is, converting the data to a newer format, retaining older equipment that can read the data). Methods and procedures should be developed to prevent corruption of backup data. Backup copies should be made on a regular basis. These backups should be tested to verify that they are still viable. Restoration procedures should also be regularly checked and tested. Periodic reviews of the classification levels of information and documents should be conducted. The need to treat some information or documents with special control or handling needs to be evaluated during these reviews. A method to increase or decrease the classification level of a particular piece of information or document will also need to be developed. Periodic review of the information and document management system, as a whole, should al so be conducted. This ensures that the owners of the information or documents conform to the appropriate policies, standards or other requirements set down by the organization. C Supporting practices C Baseline practices The following six actions are baseline practices: a) Defining information classification levels (that is, confidential, restricted and public) for access and control to include sharing, copying, transmitting and distributing appropriate for the level of protection required. b) Classifying all information (for example, control system design information, vulnerability assessment results, network diagrams and industrial operation control programs) to indicate the need, priority and level of protection required commensurate with its sensitivity and consequence. c) Reviewing information that requires special control or handling on a periodic basis to validate whether special handling is still required.

224 ISA , D7E5 222 ISA99, WG d) Developing and including policies and procedures detailing the record update, retention, destruction and disposal of information including written and electronic records, equipment and other media containing information. Any legal or regulatory requirements should be considered when developing these policies and procedures. e) Developing and employing methods to prevent data-corruption around backup processes and logging. f) Confirming the security, availability and usability of the control system configuration. This includes the logic used in developing the configuration or programming for the life of the IACS. C Additional practices The following four actions are additional practices: a) Employing the appropriate measures to ensure long-term records information can be retrieved (that is, converting the data to a newer format or retaining older equipment that can read the data) EXAMPLE Emissions data recorded over a decade ago on a system that does not currently exist or is in a proprietary format b) Performing periodic reviews of conformance to the information and document management policy. c) Performing legal reviews of the retention policies to ensure conformance to any laws or regulations. d) Encrypting all communications over the Internet involving private information with secure socket layer (SSL) or equivalent strength encryption. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found., [16], Error! Reference source not found.. C C Element: Incident planning and response Description of the element Incident planning and response addresses the need to be vigilant in efforts to detect cyber security incidents and to promptly identify and respond to these incidents. No matter how much care is taken in protecting a system, it is always possible that unwanted intrusions might compromise the system. Technology vulnerabilities continue to exist and external threats are increa sing in number and sophistication, thereby requiring a robust strategy for determining the appropriate planning and response. Incident planning and response allows an organization to predefine how it will detect and react to cyber security incidents. This allows the organization to be proactive with its cyber security program instead of reactive. Incident planning and response provides the organization the opportunity to plan for security incidents and then to respond per the established practices. The goals of incident planning and response are very similar to those from business continuity planning, but usually relate to smaller - scale and possibly more real-time, incidents. Part of the incident plan should include procedures for how the organization will respond to incidents, including notification processes, documentation processes, investigation and subsequent follow-up practices. Responding to emergencies, ensuring personnel safety and getting systems back online are part of incident response. Identifying an incident early and responding appropriately can limit the damage/consequence of the event Incident planning and response is a key element of the management system for any type of risk to an organization, including cyber security risks. Sound information management practices recognize the need to have a formal incident planning and response system in place.

225 ISA99, WG ISA , D7E There are three main phases that are part of incident planning and response: planning, response and recovery. The planning phase includes the initial system program development and the specific contingency planning efforts. The response phase involves the ability to respond to actual incidents. The recovery phase restores IACS to their previous operational states. C Planning phase A program should be established to recognize and respond to incidents within the IACS environment. This program needs to include a written plan, documenting the types of incidents that will be dealt with and the expected response to each of those incidents. The incident plan should include the types of incidents that may occur and the expected response to those incidents. The various types of incidents that a system intrusion might cause should be identified and classified as to the effects and likelihood, so that a proper response can be formulated for each potential incident. This plan should include step-by-step actions that the various organizations should take. If there are reporting requirements, these should be noted, as well as where the report should be made and phone numbers in order to reduce reporting confusion. During the preparation of the incident response plan, input should be obtained from the various stakeholders including operations, management, legal and safety. These stakeholders should also sign-off and approve the plan. The incident plan should include contingency plans covering the full range of consequences that may occur due to failures in the IACS cyber security program. These contingency plans should include procedures for separating the IACS from all nonessential conduits that may provide attack vectors, protecting essential conduits from further attacks and restoring the IACS to a previously known state in the event of an incident. They should also be tested periodically to ensure that they continue to meet their objectives. Another important piece of information that needs to be included in the incident plan is the contact information for all the personnel responsible for responding to incidents within the organization. It may be difficult to locate this information in the event of an incident occurring. After the incident plan is complete, the organization needs to distribute copies to all appropriate personnel groups within the organization, as well as any appropriate outside organizations. All associated personnel and organizations need to be made aware of their responsibilities before, during and after an incident. In addition to just distributing the plan to all appropriate organizations, the plan should be tested periodically to ensure that it is still relevant. The organization should conduct drills of the incident response plan and analyze the results of those drills. Any problems found during the drills should be addressed and the plan should be updated. C Response phase There are several responses that can be taken in the event of a security incident. These range from doing nothing to having a full system shutdown. The particular response taken will depend on the type of incident and its effect on the system. A written plan should have been prepare d during the Planning Phase that clearly documents the types of incidents that may occur and the expected response to those incidents. This will provide guidance during times when there might be confusion or stress due to the incident. The organization needs to have procedures in place to identify and report incidents. These procedures should establish guidelines to determine what might constitute an incident and how potential incidents should be reported and classified. These guidelines should include info rmation about recognizing and reporting unusual experiences that may actually be cyber security incidents. The procedures should also include any special responsibilities (for example, identification methods, reporting requirements and specific actions) that personnel need to be aware of when dealing with a cyber security incident.

226 ISA , D7E5 224 ISA99, WG If an incident is detected, the details of that incident should be documented to record the incident itself, the response(s) taken, the lessons learned and any actions to be take n to modify the CSMS in light of this incident. The details of the incident need to be communicated to all appropriate groups within the organization (for example, management, IT, process safety, automation and control engineering and manufacturing) and any outside organizations affected by the incident. It is important that these details be communicated in a timely manner to help the organization prevent further incidents. Since every incident may not be initially recognized or detected, the organization should have procedures in place to identify failed and successful cyber security breaches. Depending upon the magnitude of the damage inflicted by a particular incident, cyber security forensic specialists may need to be consulted to determine the root cause of the incident, to evaluate the effectiveness of the response(s) taken and, in case of an intentional loss, to preserve the chain of evidence to support efforts to prosecute the perpetrator. If the incident occurs on a critical IACS system resulting in a business continuity interruption, the goal will likely be to get the facility back to running as quickly as possible. This may involve reformatting hard disks and a complete reload of the operating system and applications which probably removes all forensics data. Establishing incident response priorities and practices prior to an incident is important so that everyone understands the goals and methods. C Recovery phase The results of the incident might be minor or could cause many problems in the system. Step-bystep recovery actions should be documented so that the system can be returned to normal operations as quickly and safely as possible. An important component of the recovery phase is the restoration of systems and information (that is, data, programs and recipes) to operational states. This requires a sufficient backup and recovery system capable of handling the entire IACS. It may be made up of one or multiple physical backup and recovery devices, but they should all work together to aid in the reco very of the IACS. The organization should have an incident analysis process in place to address issues that are discovered and ensure they are corrected. The findings from the analysis process need to be incorporated into the appropriate cyber security policies and procedures, technical countermeasures and incident response plans. Cyber security-related incidents can be divided into three categories: malicious code such as viruses, worms, bots, rootkits and Trojan horses; accidental loss of availability, integrity or confidentiality (including production availability); unauthorized intrusion that extends to physical assets. Incidents in the first two categories are typically managed within the IT security incident response process. The third category would typically be managed in collaboration with HSE specialists and site leadership. C Supporting practices C Baseline practices The following nine actions are baseline practices: a) Establishing procedures for the overall organization to recognize and report unusual experiences that may actually be cyber security incidents. b) Establishing incident planning and response procedures which include: naming the responsible person for executing the plan when the need arises; structuring an incident response team that can be called in, including contributors from IT security and IACS and additional personnel;

227 ISA99, WG ISA , D7E establishing the responsibility for coordinating defense and response to an incident; handling the incident from initiation through final review; creating procedures for identifying, categorizing and prioritizing incidents; creating procedures for different types of incidents like DoS attacks, system hacking, malicious code, unauthorized access and inappropriate usage. c) Identifying proactive measurements to automatically identify incidents during their early stage. d) Preplanning responses to threat scenarios identified from vulnerability and risk assessments. e) Communicating IACS incidents to all appropriate organizations including the IT, industrial operations safety, automation and control engineering and operations organizations for awareness building. f) Communicating metrics and incidents to executive management. g) Carrying out regular reviews of past incidents, to improve the CSMS h) Documenting the details of the incident, the lessons learned and any actions to be taken to modify the CSMS in light of this incident. i) Conducting drills to test the plan. Holding meetings following the drills to identify areas for improvement. C Additional practices The following thirteen actions are additional practices: a) Developing forensic investigation capabilities for IACS systems either internally or externally. b) Developing a process for immediately reporting cyber security incidents. Ensuring that the process has links to the organization s crisis management team. Educating personnel with examples of reportable incidents so they can better comply with reporting requirements. c) Understanding any potential links between IT, safety and IACS and incorporating this understanding into integrated security incident response procedures. d) Developing, testing, deploying and documenting the incident investigation process. e) Developing corporate policies for reporting cyber security incidents and sharing incident information with industry-wide groups and government agencies where corporate policies allow. f) Specifying roles and responsibilities with respect to local law enforcement and/or other critical stakeholders in an internal and shared incident investigation program. g) Expanding the investigation of incidents based on the potential outcome that could have occurred rather than the actual outcome, recognizing that the cyber incident may include malicious intent. The level of incident investigation may need to be upgraded depending on the potential seriousness of the incident. h) Developing methodologies and mechanisms to ensure that corrective actions identified as the result of a cyber security incident or a drill are fully implemented. i) Providing security incident response training to organizational cross-functional training teams. j) Reviewing final incident investigation results with all personnel whose job tasks are relevant to the findings. Reviewing the incident in light of trends and recording it so it can be used for subsequent trend analyses. k) Promoting peer-to-peer and cross-industry mutual assistance activities in order to learn from others experiences regarding cyber security incident evaluation, response, investigation, communication and correction. l) Identifying previously unforeseen consequences, especially those that may affect future application of the plan. Incidents may include risk events, near misses and malfunctions. Also

228 ISA , D7E5 226 ISA99, WG included are any observed or suspected weaknesses in the system or risks that may not have been previously recognized. m) Incorporating emergency response planning into incident response planning. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: Error! Reference source not found., Error! Reference source not found.. C.5 Category: Monitoring and improving the CSMS C.5.1 Description of category A CSMS includes all the measures necessary to create and maintain a cyber security program. The scope and level of this effort are dependent on the organization s objectives, tolerance for risk and cyber security program maturity. This management system should address the requirements, methods, devices, interfaces and personnel necessary to implement the cyber security program. Monitoring and improving the CSMS involves both ensuring that the CSMS is being used and also reviewing the CSMS itself for effectiveness. Figure B.19 shows the two elements that are part of the category: C.5.2 Conformance and Review, improve and maintain the CSMS. C Figure B.19 Graphical view of category: Monitoring and improving the CSMS Element: Conformance Description of element Conformance is the process of validating that the organization is following the cyber security program that was developed. The CSMS is only as good as an organization s ability to follow it. The organization needs to be held accountable to the policies and procedures set down as part of the CSMS or the management system will be ineffective. By validating its conformance with the CSMS, the organization can use the built-in processes of the CSMS to improve the overall system in the future. As part of validating conformance with the CSMS, there are scheduled and unscheduled activities. Periodic reviews of the CSMS would be considered scheduled, but responding to a cyber security incident would most likely be considered unscheduled. Establishing key performance indicators (KPI) will give the organization a way to measure the performance of the CSMS. Using KPI that are consistent with best-in-class solutions from industry groups or other organization will allow for benchmarking of the CSMS. C Conformance Monitoring and improving the CSMS Scheduled versus unscheduled activities Review, improve and maintain the CSMS Many subclauses of the CSMS include the idea of periodic reviews of some item in order to monitor or improve the CSMS over time. These reviews are all part of the Maturity Model of a security program as discussed in ISA Error! Reference source not found.. The reviews conducted as a standard part of a CSMS keep the system from degrading over time due to new threats, vulnerabilities or situations that did not exist when the system was first developed.

229 ISA99, WG ISA , D7E There may also be critical threats, vulnerabilities or situations that arise that need to be dealt with before the next scheduled review period. These would constitute unscheduled activities and may require a re-evaluation of the CSMS in order to ensure effectiveness Periodic reviews and audits of the CSMS determine if the desired policies, procedures and 8781 countermeasures have been implemented properly and that they are performing as intended. In 8782 the IACS environment, auditors shall fully understand the corporate cyber security policies and 8783 procedures and the specific HSE risks associated with a particular facility and/or industrial 8784 operation. Care shall be taken to ensure that the audits do not interfere with the control functions 8785 provided by the IACS equipment. It may be necessary to take a system off-line before the audit 8786 can be conducted. The audit should verify that: 8787 the policies, procedures and countermeasures present during system validation testing are still 8788 installed and operating correctly in the operational system; 8789 the operational system is free from security compromises; NOTE Should an incident occur, logs and records are expected to be generated, capturing information on the nature and extent of the incident the management of change program is being rigorously followed with an audit trail of reviews 8793 and approvals for all changes A particular unscheduled activity that may trigger a review of the CSMS may be the addition or 8795 removal of assets from the IACS. A common practice during system maintenance or retooling may 8796 be to add, upgrade or remove equipment or software from the IACS. A well-defined and followed 8797 change management process will catch this, which may trigger a review or audit of the CSM S. This 8798 review or audit would ensure that the change did not adversely affect the cyber security of the 8799 IACS. Another example of an unscheduled activity would be a response to a virus outbreak at a 8800 facility. After the CSMS system has been used to respond and recover from the incident, a review 8801 or audit of the CSMS should be conducted to determine where the failure occurred that allowed 8802 the virus to spread Any cyber security reviews or audits (internal or external) will provide the organization with 8804 valuable data in order to improve the CSMS. The results of these reviews or audits should include 8805 as much detailed information as necessary to both ensure that any legal or regulatory requirements 8806 are satisfied and that any modifications indicated by the review or audit can be made. The results 8807 should be sent to all of the appropriate personnel (that is, stakeholders, managers and security 8808 personnel) C Key performance indicators 8810 KPI allow the organization to determine how well the CSMS in performing and helps it di rect any 8811 resources towards areas that may need improvement. KPI should, as much as possible, be 8812 quantitative values (that is, numbers or percentages) indicating how a particular part of the CSMS 8813 performs with respect to expected conditions Since any reviews or audits or the CSMS should be expressed using these KPI, it is important to 8815 pick indicators that are relevant, meaningful and consistent with the CSMS and other requirements 8816 on the organization. The results of periodic scheduled activities may be expressed as the 8817 performance against a set of predefined metrics to indicate security performance and security 8818 trends. The results of unscheduled activities may be expressed as the effectiveness of the CSMS 8819 to deal with the unscheduled event or incident Organizational capability data should be a part of the performance indicators. Companies should track the percentage of personnel assigned to IACS roles and the percentage of those personnel who have passed the training and qualification requirements for their roles. While these data may seem esoteric, systemic problems can be indicated here before being noticed in poor audit results.

230 ISA , D7E5 228 ISA99, WG Benchmarking the KPI and the results of reviews or audits against other organizations or requirements is a good method for validating the CSMS. If benchmarking data are collected over a period of time, it may be possible for the organization to determine trends in either threats or countermeasures. These may indicate places where the CSMS requirements may have to be reviewed as part of the review, improve and maintain subclause of the CSMS (see C.5.3). C Supporting practices C Baseline practices The following two actions are baseline practices: a) Providing assurance that the appropriateness of the control environment and compliance with the overall cyber security objectives are being met. Detecting if additions, upgrades, or removals (that is, software patches, application upgrades, and equipment changes) have introduced security exposures. b) Confirming that, over a specified regular audit period all aspects of the CSMS are functioning as intended. A sufficient number of audits should be planned so that the audit task is spread uniformly over the chosen period. Management should ensure periodic audits are conducted. Management should ensure that there is evidence to: verify that documented procedures are being followed and are meeting their desired objectives; validate that technical controls (that is, firewalls and access controls) are in place and are working as intended both consistently and continuously. C Additional practices The following three actions are additional practices: a) Requiring that the cyber security metrics program is built upon the seven key steps listed as follows: 1) defining the metrics program goal(s) and objectives; 2) deciding what metrics to generate in order to measure the degree of adoption and conformance to the policies and procedures defined in the CSMS: proactively assessing any potential security vulnerabilities (for example, % of security audit weaknesses fixed by the agreed date); tracking implementation and usage of security and preventive measures (for example, % of conformance with security standards). 3) developing strategies for generating the metrics; 4) establishing benchmarks and targets; 5) determining how the metrics will be reported and to whom; 6) creating an action plan and acting on it; 7) establishing a formal program review/refinement cycle. b) Reviewing the results of audits, self-assessments, cyber security incident reports and feedback provided by key stakeholders regularly to understand the effectiveness of the CSMS. c) Conducting operational security reviews on the IACS by security trained IACS engineers. In addition, security issues are frequently reviewed at a broader level by a governance body. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: [16], Error! Reference source not found., Error! Reference source not found., Error! Reference source not found., Error! Reference source not found..

231 ISA99, WG ISA , D7E C.5.3 Element: Review, improve and maintain the CSMS C Description of element The process of continuously monitoring and reviewing the CSMS allows an organization to establish, with evidence, that it is meeting the goals, policies and procedures laid out in the CSMS. The KPI defined while developing the CSMS are used to evaluate the performance of the CSMS during the conformance review process. The Conformance element verifies that the CSMS is operating as defined, while this element verifies that the requirements used to develop the CSMS meet the organization s cyber security goals. Internal checking methods, such as conformance audits and incident investigations, allow the organization to determine the effectiveness of the management system and whether it is operating according to expectations. It is also important to establish that the management system still meets the goals, targets and objectives set out during the planning process. If there are deviations from the original goals, targets or objectives, systematic changes to the management system may be required. Because both threats and technologies for addressing security are evolving, it is anticipated that the organization s cyber security program will evolve, reflecting new threats and capabilities that are available. Organizations should be tracking, measuring and improving security efforts to keep people, property, products, industrial operations, data, and information systems secure. The overall objective is to ensure that the CSMS remains effective by incorporating improvements made based on new threats, new capabilities and regular reviews. Continual attention to security provides an indicator to personnel that cyber security is a core company value. C Review of conformance to the CSMS Conformance to the CSMS has been discussed in an earlier element. It verifies that the organization is following the policies and procedures expressed in the CSMS. As part of the conformance process, key performance indicators have been defined to measure the performance of the organization s CSMS. Poor marks in these KPI in one review cycle may indicate a singular problem that can be remedied by simple solutions. Poor marks in many of the KPI or in the same KPI over repeated reviews may indicate systemic problems with the CSMS. It may indicate that training or enforcement needs to be improved, resources are inadequate or that the implemented procedures are impractical. Managing the CSMS involves making these judgments. Whether the KPI are evaluated through independent or self-audits, it is useful to consult with the organization whose actions are being measured, to help make this determination. It is important that the CSMS include requirements for improving conformance results. The responsible individual(s) should also be chartered to develop a long-term strategy for the improvement to assure a consistent cost-effective improvement path over time. C Measure and review the effectiveness of the CSMS Measuring the effectiveness of the CSMS at a minimum involves reviewing incident data. The greater an organization s capability to detect failed and successful cyber security breaches and record these as incidents, the greater its capability to measure effectiveness of the CSMS in lowering risk. Incident data include the number of incidents, the type or class of incidents and the economic impact of the incidents. These data are extremely important both to understand the current economic impact of cyber security threats and to assess the effectiveness of specific countermeasures employed. While analysis of incident data can measure effectiveness of the CSMS in the past, CSMS management is also charged with maintaining the effectiveness of the CSMS into the future. To accomplish this, it is necessary to monitor changes to factors that might increase or decrease its effectiveness going forward. Key factors to monitor are the following:

232 ISA , D7E5 230 ISA99, WG the level of risk, which may change due to a change in threat, vulnerability, consequence or likelihood; the organization s risk tolerance; the implementation of new or changed systems or industrial operations; industry practices; available technical and non-technical countermeasures; legal and regulatory requirements. An organization s CSMS should be reviewed at regular intervals, to assess both its past effectiveness and the view going forward. This review should include a periodic assessment of cyber security policies and procedures to affirm that those policies and procedures are in place and working and meet the legal, regulatory and internal security requirements. In appropriate circumstances, assessments also apply to the policies and procedures of the organization s business partners, such as suppliers, support providers, joint ventures or customers. In addition to regular reviews, major changes to the factors listed above should also trigger review of related aspects of the CSMS. An organization should determine a set of change triggers and thresholds, which would trigger such a review. These triggers should include the following factors: Internal factors: Based on the performance of the CSMS and the results of KPI and other suitable internal indicators (for example, risk tolerance, management changes, and the like). External factors: Changes in the threat environment, industry best practices, available solutions and legal requirements may indicate a need or opportunity for improvement of the CSMS. The organization assigned to manage changes to the CSMS should also be responsible for reviewing the triggers and thresholds for changes and for using them to kick off the review process. C Legal and regulatory implications for the CSMS The legal and regulatory environment that the organization is subject to may change over time. The organization may still be compliant with the CSMS as it was originally defined, but that CSMS may no longer satisfy the legal and regulatory requirements that apply. The organization should periodically review its applicable legal and regulatory requirements and identify any areas where they may affect the CSMS. Also, any major changes to the legal and regulatory requirements, such as major new or updated requirements, should trigger a review of the CSMS to ensure it meets the new requirements. C Manage CSMS change To have a coordinated system, an organization/team should be assigned to manage and coordinate the refinement and implementation of the CSMS changes. This organization/team is likely to be a matrix type organization drawing on key people from different business organizations. This team should use a defined method for making and implementing changes. A number of internal and external factors will necessitate changes to the CSMS. The management of these changes requires coordination with the various stakeholders. When implementing changes to the management system, it is important to examine possible side effects relating to system operation or safety. IACS security also needs to take into account the different organizations, practices and response requirements when incorporating improvements. Written procedur es should be developed to manage changes to the CSMS. This process might include the following steps: a) Defining the current management system Before the CSMS can be refined, it is necessary to know and understand the current management system. All the policies relating to cyber security should be reviewed so all the

233 ISA99, WG ISA , D7E stakeholders clearly understand the current policy and how it is being implemented. In addition, all assets and procedures related to the CSMS should be identified. b) Defining the procedures for proposing and assessing changes to the CSMS Once the current management system is understood, it should be reviewed for compliance and effectiveness, as described previously. Weaknesses or gaps in the management system should be identified and corrections proposed. The evaluation of the management system should identify areas where changes might be required. In addition, industry best practices and requirements outlined in this standard might be considered in defining changes that would strengthen the CSMS. Selection of new countermeasures will follow the principles outlined in the Risk Management and Implementation element of this standard (see C.4.4.2). Once defined, the proposed changes to the CSMS should be documented in a concise manner so that they can be consistently presented to other stakeholders. c) Proposing and evaluating changes to the CSMS With the changes identified and documented, they should be presented to the stakeholders. The proposed changes should be reviewed to determine if they will produce any negative or unforeseen side effects. They should also be evaluated to determine if any changes need to be made to the CSMS against the original requirements and testing suites. As new capabilities are developed, the reaction of many organizations is to incorporate the newest technology into the system. In the IACS environment, it is important to validate any new cyber security technology or solution before incorporating it. d) Implementing CSMS changes After the stakeholders agree on the change, the changes to the CSMS should be implemented. Changes to the policy should follow company procedures for policy changes and at a minimum these changes should be documented and written approval should be obtained from key stakeholders. Special attention to systems testing, validation and control vendor involvement is required. e) Monitoring CSMS changes With the new or revised CSMS in place, it is important to monitor and evaluate its performance. A review of the management system should be performed on a regular basis and whenever there are changes to the CSMS. C Supporting practices C Baseline practices The following twelve actions are baseline practices: a) Using a method to trigger a review of the level of residual risk and risk tolerance when there are changes to the organization, technology, business objectives, industrial operation or external events including identified threats and changes in social climate. b) Analyzing, recording and reporting operational data to assess the effectiveness or performance of the CSMS. c) Analyzing the results from the periodic reviews and audits of the CSMS to determine if a change is needed. d) Investigating ineffective CSMS policies and procedures to determine any root causes where there are systemic problems. Actions are identified not only to resolve the issue, but also to minimize and prevent reoccurrences. e) Reviewing potential threats and conducting an impact analysis on a regular basis to determine if countermeasures are required. f) Identifying applicable and changing regulations and legislation and contractual cyber security obligations and requirements.

234 ISA , D7E5 232 ISA99, WG g) Involving the key stakeholders in the organization for confirmation on areas for further investigation and planning. The key stakeholders should include personnel from all of the different groups affected by the CSMS (that is, IT, IACS and safety). h) Identifying appropriate corrective and preventive actions to further improve the performan ce process. i) Prioritizing improvements in the CSMS and putting plans in place to implement them (that is, budgets and project planning). j) Implementing all changes using the management of change processes within the organization. Special attention to systems testing, validation and control vendor involvement is required due to the HSE implications of the IACS environment. k) Validating that agreed actions from previous audits and reviews have been implemented. l) Communicating action plans and areas of improvement to all the stakeholders and the affected personnel. C Additional practices The following two actions are additional practices: a) Requiring that the cyber security metrics program is built upon the seven key steps listed as follows: 1) defining the metrics program goal(s) and objectives; 2) deciding what metrics to generate to measure the effectiveness of the CSMS to meet the organization s security goals; NOTE It may be good to provide a retrospective view of security preparedness by tracking the number and severity of past security incidents, including patterned small events. 3) developing strategies for generating the metrics; 4) establishing benchmarks and targets; 5) determining how the metrics will be reported and to whom; 6) creating an action plan and acting on it; 7) establishing a formal program review/refinement cycle. b) Undertaking many different strategies to drive continuous improvement in cyber security activities. The strategies are commensurate with risk and dependent upon corporate culture, existing systems, and size or complexity of digital systems. Some potential strategies are the following: conducting benchmarking security activities both within and outside of the industry including the use of external validation to help validate improvements; seeking employee feedback on security suggestions actively and reporting back to senior management as appropriate on performance shortcomings and opportunities; using standard corporate business methodologies, such as Six Sigma, for measuring, analyzing, improving and sustaining cyber security improvements. C Resources used This element was based in part on material found in the following references, all of which are listed in the Bibliography: [16], Error! Reference source not found., Error! Reference source not found., Error! Reference source not found..

235 ISA99, WG ISA , D7E

236 ISA , D7E5 234 ISA99, WG BIBLIOGRAPHY NOTE This bibliography includes references to sources used in the creation of this standard as well as references to sources that may aid the reader in developing a greater understanding of cyber security as a whole and developing a management system. Not all references in this bibliography are referred to throughout the text of this standard. The references have been broken down into different categories depending on the type of source they are. References to other parts, both existing and anticipated, of the ISA/IEC series: NOTE Some of these references are normative references (see Clause 2), published documents, in development, or anticipated. They are all listed here for completeness of the anticipated parts of the ISA/IEC series. SKELETON NOTE For the reference to this document below, change the document reference to a note stating This standard is. You can t have a circular reference from a document to itself. [1] ANSI/ISA , Security for industrial automation and control systems: Terminology, concepts and models [2] ANSI/ISA TR , Security for industrial automation and control systems: Master glossary of terms and abbreviations [3] ANSI/ISA , Security for industrial automation and control systems: System security compliance metrics [4] ANSI/ISA , Security for industrial automation and control systems: Establishing an industrial automation and control system security program [5] ANSI/ISA TR , Security for industrial automation and control systems: Operating an industrial automation and control system security program [6] ANSI/ISA TR , Security for industrial automation and control systems: Patch management in the IACS environment [7] ISA , Security for industrial automation and control systems: Certification of IACS supplier security policies and practices [8] ANSI/ISA TR , Security for industrial automation and control systems: Security technologies for industrial automation and control systems [9] ANSI/ISA , Security for industrial automation and control systems: Target security levels for zones and conduits [10] ANSI/ISA , Security for industrial automation and control systems: System security requirements and security levels [11] ANSI/ISA , Security for industrial automation and control systems: Product development requirements [12] ANSI/ISA , Security for industrial automation and control systems: Technical security requirements for IACS components Other standards references:

237 ISA99, WG ISA , D7E [13] ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards [14] ANSI/ISA , Batch, Part 1: Models and Terminology [15] ANSI/ISA , Enterprise- System Integration, Part 1: Models and Terminology [16] ISO/IEC 27001:2005, Information technology Security techniques Information security management systems Requirements [17] ISO/IEC 27002:2005, Information technology Security techniques Code of practice for information security management [18] SKELETON NOTE Anything that can have an ISO/IEC, NATO, etc. number should be included in the Other standards references section. For ISA documents, these should receive their ISA numbers if they have them, otherwise, use the international numbering. For IEC versions of the documents, these numbers should be replaced with their international number equivalents. (For example, ANSI/ISA would be replaced by IEC in the IEC version.) In addition to the two sections of references above, you can also have other sections like: Industry-specific and sector-specific references Trade organization documents and such. Other documents and published sources National/government documents or any other published resources. NIST FIPS/SP documents fall into this category. Websites Full sites or pages within specific sites containing reference material.