PROCESS CONTROL DOMAIN - SECURITY REQUIREMENTS FOR SUPPLIERS

Transcription

1 DEP SPECIFICATION PROCESS CONTROL DOMAIN - SECURITY REQUIREMENTS FOR SUPPLIERS DEP Gen. DESIGN AND ENGINEERING PRACTICE DEM Shell Group of companies All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, published or transmitted, in any form or by any means, without the prior written permission of the copyright owner or Shell Global Solutions International BV.

2 Page 2 PREFACE DEP (Design and Engineering Practice) publications reflect the views, at the time of publication, of Shell Global Solutions International B.V. (Shell GSI) and, in some cases, of other Shell Companies. These views are based on the experience acquired during involvement with the design, construction, operation and maintenance of processing units and facilities. Where deemed appropriate DEPs are based on, or reference international, regional, national and industry standards. The objective is to set the recommended standard for good design and engineering practice to be applied by Shell companies in oil and gas production, oil refining, gas handling, gasification, chemical processing, or any other such facility, and thereby to help achieve maximum technical and economic benefit from standardization. The information set forth in these publications is provided to Shell companies for their consideration and decision to implement. This is of particular importance where DEPs may not cover every requirement or diversity of condition at each locality. The system of DEPs is expected to be sufficiently flexible to allow individual Operating Units to adapt the information set forth in DEPs to their own environment and requirements. When Contractors or Manufacturers/Suppliers use DEPs, they shall be solely responsible for such use, including the quality of their work and the attainment of the required design and engineering standards. In particular, for those requirements not specifically covered, the Principal will typically expect them to follow those design and engineering practices that will achieve at least the same level of integrity as reflected in the DEPs. If in doubt, the Contractor or Manufacturer/Supplier shall, without detracting from his own responsibility, consult the Principal. The right to obtain and to use DEPs is restricted, and is typically granted by Shell GSI (and in some cases by other Shell Companies) under a Service Agreement or a License Agreement. This right is granted primarily to Shell companies and other companies receiving technical advice and services from Shell GSI or another Shell Company. Consequently, three categories of users of DEPs can be distinguished: 1) Operating Units having a Service Agreement with Shell GSI or another Shell Company. The use of DEPs by these Operating Units is subject in all respects to the terms and conditions of the relevant Service Agreement. 2) Other parties who are authorised to use DEPs subject to appropriate contractual arrangements (whether as part of a Service Agreement or otherwise). 3) Contractors/subcontractors and Manufacturers/Suppliers under a contract with users referred to under 1) or 2) which requires that tenders for projects, materials supplied or - generally - work performed on behalf of the said users comply with the relevant standards. Subject to any particular terms and conditions as may be set forth in specific agreements with users, Shell GSI disclaims any liability of whatsoever nature for any damage (including injury or death) suffered by any company or person whomsoever as a result of or in connection with the use, application or implementation of any DEP, combination of DEPs or any part thereof, even if it is wholly or partly caused by negligence on the part of Shell GSI or other Shell Company. The benefit of this disclaimer shall inure in all respects to Shell GSI and/or any Shell Company, or companies affiliated to these companies, that may issue DEPs or advise or require the use of DEPs. Without prejudice to any specific terms in respect of confidentiality under relevant contractual arrangements, DEPs shall not, without the prior written consent of Shell GSI, be disclosed by users to any company or person whomsoever and the DEPs shall be used exclusively for the purpose for which they have been provided to the user. They shall be returned after use, including any copies which shall only be made by users with the express prior written consent of Shell GSI. The copyright of DEPs vests in Shell Group of companies. Users shall arrange for DEPs to be held in safe custody and Shell GSI may at any time require information satisfactory to them in order to ascertain how users implement this requirement. All administrative queries should be directed to the DEP Administrator in Shell GSI.

3 Page 3 TABLE OF CONTENTS 1. INTRODUCTION SCOPE DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS DEFINITIONS CROSS-REFERENCES SUMMARY OF MAIN CHANGES COMMENTS ON THIS DEP GENERAL SECURITY POLICY DEMONSTRATING COMPATIBILITY VIA INDEPENDENT CERTIFICATION SECURITY APPLICATION PROCESS CONTROL SECURITY FOCAL POINT CONTROLS AGAINST MALICIOUS CODE SOFTWARE PATCH MANAGEMENT SYSTEM HARDENING PROTECTION OF PCD DOCUMENTATION ACCOUNT MANAGEMENT BACKUP, RESTORE AND DISASTER RECOVERY REMOTE ACCESS AND TRANSFER OF DATA FILES WIRELESS CONNECTIVITY SECURE CONNECTIONS TO INSTRUMENTED PROTECTIVE SYSTEMS STANDARDS AND CERTIFICATION SECURITY MONITORING PROCESS CONTROL DOMAIN NETWORK ARCHITECTURE HANDLING OF REMOTE AND ADVISORY SETPOINTS DATA HISTORIANS COMMISSIONING AND MAINTENANCE REFERENCES...26 APPENDICES APPENDIX 1 ARCHITECTURE LEVELS IN ISA , PART APPENDIX 2 DATA ACQUISITION AND CONTROL ARCHITECTURE...28

4 Page 4 1. INTRODUCTION 1.1 SCOPE This DEP specifies requirements for PCD IT security of control & automation systems to be supplied for use in Shell-owned Process Control Domains (PCDs), and is applicable to suppliers supplying such systems or services on such systems. This DEP covers both: Policy; addressing the Supplier s organization, IT security processes, technological solutions and governance of IT security Commissioning and maintenance of PCD systems Supplementing this DEP, a suite of PCD Security (DACA) Design and Engineering Practice (DEP) specifications and guidelines provide guidance on how to produce a PCD Security Compatible solution. This DEP contains mandatory requirements to mitigate process safety risks in accordance with Design Engineering Manual DEM 1 Application of Technical Standards. This is a revision of the DEP of the same number dated March 2010; see (1.5) regarding the changes. 1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS Unless otherwise authorised by Shell GSI, the distribution of this DEP is confined to Shell companies and, where necessary, to Contractors and Manufacturers/Suppliers nominated by them. Any authorised access to DEPs does not for that reason constitute an authorization to any documents, data or information to which the DEPs may refer. This DEP is intended for use in facilities related to oil and gas production, gas handling, oil refining, chemical processing, gasification, distribution and supply/marketing. This DEP may also be applied in other similar facilities. When DEPs are applied, a Management of Change (MOC) process should be implemented; this is of particular importance when existing facilities are to be modified. If national and/or local regulations exist in which some of the requirements could be more stringent than in this DEP, the Contractor shall determine by careful scrutiny which of the requirements are the more stringent and which combination of requirements will be acceptable with regards to the safety, environmental, economic and legal aspects. In all cases the Contractor shall inform the Principal of any deviation from the requirements of this DEP which is considered to be necessary in order to comply with national and/or local regulations. The Principal may then negotiate with the Authorities concerned, the objective being to obtain agreement to follow this DEP as closely as possible. 1.3 DEFINITIONS General definitions The Contractor is the party that carries out all or part of the design, engineering, procurement, construction, commissioning or management of a project or operation of a facility. The Principal may undertake all or part of the duties of the Contractor. The Manufacturer/Supplier is the party that manufactures or supplies equipment and services to perform the duties specified by the Contractor. The Principal is the party that initiates the project and ultimately pays for it. The Principal may also include an agent or consultant authorised to act for, and on behalf of, the Principal. The word shall indicates a requirement. The capitalised term SHALL [PS] indicates a process safety requirement. The word should indicates a recommendation.

5 Page Specific definitions term definition PCD Security Compatible Network device Compatible Supplier system Derogation Process Safety IT security Specific definitions Term Definition When a Supplier s solution complies with the requirements in this DEP, the solution is considered by Shell to be PCD Security Compatible. Electronic equipment that connects or manages network traffic; e.g. switches, routers and firewalls. A supplier is compatible with the Principal s security policy and standards when the supplier is compliant with this DEP. The Supplier cannot be compliant with the Principal s policy and security standards because part of it should be accomplished by the Principal a combination of hardware and software components, which together provides a function or service. Where its systems is used in this DEP, this refers to all systems supplied and supported by the Supplier over the systems lifecycle. an authorised variance or exemption from a Process Safety requirement, with specified conditions. the management of hazards that can give rise to major accidents involving, personnel safety, the release of potentially dangerous materials, and release of energy (such as fire or explosion) or both. The equivalent to Process Control System Cyber Security, and Process Control System Cyber Security Controls. ACL Access Control List APC Achilles Practice Certification AES Advanced Encryption Standard AV Anti-Virus (Appendix 2) CCR Centralised Control Room (Appendix 2) DACA Data Acquisition and Control Architecture (Appendix 2) DCS Distributed Control System DHCP Dynamic Host Configuration Protocol DMZ Demilitarized Zone EWS Engineering Work Station HIDS Host-based Intrusion Detection System HMI Human to Machine Interface ICMP Internet Control Message Protocol IPF IPS Instrumented Protective Function; All instruments and systems required to safeguard the process, including the hook-up of the instruments (initiators and end-elements) and wetted parts of the system. Instrumented Protective System; equivalent to Safety Instrumented System (SIS) IT security In this DEP, IT security is equivalent to process control system cyber security, and process control system cyber security controls L1 Network Level 1 Basic Process Control (Appendix 1)

6 Page 6 Term Definition L2 Network Level 2 Area Supervisory Control (Appendix 1) L3 Network Level 3 Site Maufacturing Operations (Appendix 1). Equivalent to the Process Control Network (PCN) L4 Network Level 4 Site Business Planning (Appendix 1). Equivalent to the Office Domain (OD) L5 Network Level 5 Enterprise (Appendix 1) MIB Management Information Base OD Office Domain OPC OLE for Process Control PAS Process Automation System PCAD Process Control Access Domain PCD Process Control Domain PCN Process Control Network. This is equivalent to Network Level 3(L3) PLC Programmable Logic Controller RDP Remote Desktop Protocol (used by Microsoft Terminal Services) SIS SNMP SSID TCP/IP TPA WMI Safety Instrumented System; equivalent to Instrumented Protective System (IPS) Simple Network Management Protocol Service Set Identifier Transmission Control Protocol/Internet Protocol Third Party Access (for Shell Global Infrastructure) Windows Management Instrumentation 1.4 CROSS-REFERENCES Where cross-references to other parts of this DEP are made, the referenced section number is shown in brackets. Other documents referenced by this DEP are listed in (19). 1.5 SUMMARY OF MAIN CHANGES This DEP is a revision of the DEP of the same number dated March The following are the main, non-editorial changes. Old section New section Change The old document has been split into 2 new documents, i.e. DEP Standard and DEP informative. The DEP standard only contains the mandatory requirements. After the split the document was sent on global comment round and its agreed changes are included in this version 1.6 COMMENTS ON THIS DEP Comments on this DEP may be sent to the Administrator at standards@shell.com, using the DEP Feedback Form. The DEP Feedback Form can be found on the main page of DEPs on the Web, available through the Global Technical Standards web portal and on the main page of the DEPs DVD-ROM.

7 Page 7 2. GENERAL SECURITY POLICY 2.1 DEMONSTRATING COMPATIBILITY VIA INDEPENDENT CERTIFICATION Suppliers shall demonstrate PCD Security Compatibility to the Principal by achieving certification by independent parties that have been approved by the Principal. The requirements in this DEP are aligned with WIB Report M 2784 X10 version 2, October 2010 and Wurldtech s Achilles Practices Certification (APC) level silver. 2.2 SECURITY APPLICATION The Supplier shall, within their own organization, practice and maintain policies, standards and procedures that are compliant with the requirements specified in this DEP The Supplier shall conduct security-related background checks on personnel before they are assigned to the Principal s projects; e.g. identity verification and criminal record check. The Supplier shall ensure, based upon the results of the security-related checks that personnel assigned to activities on the Principal s PCD will not pose a security risk The Supplier shall ensure that for each project a security lead with sufficient IT security competency is assigned to Principal s projects. The security lead shall instruct Supplier s assigned personnel about the content of this document, prior to being authorized access to the Principal s PCD Confidentiality agreements and user agreements to follow applicable standards and procedures shall be signed by all persons having access to the Principal s PCD Unless stated otherwise, the requirements in this DEP shall be applied independent of the type of operating system software (e.g. Microsoft Windows or Unix-like operating system) supplied by the Supplier The Supplier shall have a policy and procedures for security testing, approval and maintenance of their system, with all integrated third party software installed on the Supplier s system.

8 Page 8 3. PROCESS CONTROL SECURITY FOCAL POINT The Supplier shall nominate a Process Control Security Focal Point in its organization, who is responsible for the following: 3.1 Shall act as liaison with the Principal about compliance of the Supplier s system with this DEP. 3.2 Shall ensure that tenders to as required by the Principal are in compliance with this DEP and communicate requested deviations from this DEP 3.3 Shall provide the Principal with timely information about cyber security vulnerabilities in the supplier s supplied systems and services. 3.4 Shall provide timely support and advice to the Principal and SME in the event of cyber security incidents involving the Supplier s systems and services. 3.5 Shall provide information to the Principal SME on the Supplier s views and implementation on process control security.

9 Page 9 4. CONTROLS AGAINST MALICIOUS CODE The Supplier shall protect its system against malicious code without this protection affecting the system s normal functionality, as follows: 4.1. Each system in the PCD shall have virus detection software installed. Where the installation of antivirus software is not technically possible, a listing of all computers where antivirus software cannot be installed shall be maintained, and other mitigating factors shall be in place to reduce the risk of infection New technology to replace the need for virus detection software (e.g. White listing) shall only be allowed to be applied when Supplier has demonstrated to the Principal that the new solution is equal or better than the existing virus detection software. The Principal shall provide written approval that the new technology has demonstrated improvement in functionality, integrity, and availability of the Supplier s system before the new technology can be implemented The Supplier shall provide documentation describing how approval of virus definition files shall be communicated to the Principal The Supplier shall provide documentation describing how the approved virus definition files shall be installed on the system. New virus definition files shall be distributed to systems in the PCD via the PCAD The Supplier shall provide evidence that the configured equipment has been checked to be free of malicious code prior to shipment to the Principal The Supplier shall provide documented instructions for ensuring the proper installation, configuration and update of anti-virus software The Supplier s system shall support use of antivirus software that has been approved by Shell. However, alternative solutions, as recommended by the system Supplier, may be used with approval by the Principal The Supplier shall document a procedure for its staff stating that portable media (e.g. laptops and USB storage) used by the Supplier for commissioning and maintenance of equipment or devices in the PCD shall only be used for this purpose. The procedure shall also include instructions for ensuring that the portable media is free of malicious code The Supplier shall ensure use of correctly installed, configured and up-to-date anti-virus software during all phases of the project until successful handover and acceptance by the Principal. Virus definition files shall be released for installation by the Supplier as soon as possible, within a maximum of 30 days after initial release The Supplier shall provide evidence, acceptable to the Principal, during the project acceptance testing that malicious code can be detected and correctly handled by the antivirus software.

10 Page SOFTWARE PATCH MANAGEMENT The Supplier software patch management for operating system and other software shall address, as a minimum, the following: 5.1. The Supplier shall provide documentation describing the software patching and hardening policy for its system The Supplier shall review their product security policy annually to address new threats and vulnerabilities The policy shall describe controls to ensure that patching does not reinstall software that has been removed for hardening purposes, or change system configuration settings The Supplier shall qualify all software patches for use on its system during its supported lifetime The supplier shall test all relevant security patches that are released by the manufacturer of the operating system and third party software used on their system If a security patch is considered not relevant by the Supplier for use on its system, then the reason shall be provided to the Principal If a security patch is not approved by the Supplier for use on its system, then the reason and a remediation plan shall be provided to the Principal. The remediation plan shall describe how a solution will be provided within 12 months The Supplier shall maintain and provide secure access to a list of patches and service packs relevant to its system including the approval status of each. (i.e. approved, not approved, in test). For Microsoft software, the Supplier s on-line patch list shall be in a standardized downloadable format, preferably compatible with Microsoft Windows Server Update Services (WSUS) or equivalent The Supplier shall inform Shell about approved, not approved and not relevant security patches within 30 days after release by the manufacturer of the software. This shall also include a warning if the application of a patch requires or causes a re-start of the system, if not already documented in the patch release notes Patches and service packs approved by the Supplier shall not be re-distributed by the Supplier, when available from the manufacturer of the software The Supplier shall be able to provide tools to audit the current patch status of the Supplier s system and provide a list of missing patches The Supplier shall describe the approved patching procedure and configuration instructions for its system, describing how to perform patching both manually and via a patch management server. Where possible, Shell shall use Microsoft Windows Server Update Services (WSUS) for patching of Microsoft software When using a patch management server, documentation shall be provided to show how to configure the Supplier s system to receive updates For manual patching using portable media, detailed instructions shall be supplied on how to install patches and how patching status reports shall be provided The Supplier shall describe a recommended roll-out procedure for software patching and upgrading of all parts of its system For systems maintained by the Supplier, the security patch levels of all PCD systems shall be kept current to within 3 months of the security patch being available and qualified by the system Supplier. If the installation of patches requires an outage that can impact operations or impact performance, a mitigation plan shall be developed and documented, and deferred only with approval by the Principal.

11 Page SYSTEM HARDENING The Supplier shall describe the hardening requirements for its systems and make the document available to Principal at least 30 days prior to factory acceptance testing. The requirements shall address at least the following: 6.1 Removal or non-installation of software and functionality that is not required by the Principal for the intended functional purpose of the system; e.g. , office applications, games, USB ports, Bluetooth and Wi-fi communication, etc. 6.2 Physical and logical access to diagnostic and configuration ports that shall be protected. 6.3 All unused ports on switches and routers shall be disabled to assist in preventing unauthorized access to the PCD network infrastructure. 6.4 The Supplier shall demonstrate the use of hardening guidelines, tools and instructions from either the original manufacturer (e.g. Microsoft) and/or reputable organizations (e.g. NSA security configuration guides, NIST). 6.5 The Supplier, when providing maintenance services, shall be able to demonstrate upon request of the Principal that proper maintenance processes are in place that maintains the system-hardened state during the system s lifetime.

12 Page PROTECTION OF PCD DOCUMENTATION 7.1 The Supplier shall not make available any information or architecture diagrams associated with Shell PCD Systems without written approval by the Principal. 7.2 The Supplier shall provide the Principal a copy of procedures that describe the treatment of the Principal's PCD or PCAD confidential information. Information deemed confidential includes, as a minimum: PCD/PCAD architecture, configuration data and IP-addresses. The Supplier shall report any breach of the security of such information immediately to the Principal.

13 Page ACCOUNT MANAGEMENT This section has been split into two almost identical parts for certification reasons. Section 8.1 is about supporting requirements and section 8.2 is about enforcing requirements, as follows: 8.1. The Supplier s system shall support use of secure user accounts, as follows The Supplier s system shall support that default passwords used for system accounts (such as an administrator account) can be changed by Shell The Supplier s system shall support that unused default accounts can be removed or disabled; e.g. Supplier back-door, super-user and guest accounts The Supplier s network devices shall provide the capability to encrypt passwords within the network device The Supplier s network devices shall support role-based access (e.g. separate passwords for administrators, service providers and operators) The Supplier s system shall support use of encryption for administration of network devices within the PCD over Ethernet The Supplier s system shall support use of passwords of at least eight characters in length and consisting of a combination of at least three of the following four character sets: lowercase, uppercase, numeric digit, and special character (%, #, etc.) The Supplier s system shall support that local and domain user account passwords on their Host-based devices, so they can be configured to automatically expire every 180 days, and prevent re-use of at least the three previously used passwords. Users shall be able to be prompted to change their passwords 30 days prior to expiration The Supplier s system shall support that service; auto-login and operator accounts shall never expire or be disabled automatically The administrator account shall not be used by default by the Supplier s system to run services. A dedicated service account shall be created with the minimum privileges necessary for running the service Use of secure user accounts shall be enforced as follows All users other than operators and service groups shall have individual user names and passwords. Individual passwords shall not be divulged to other persons A user name and password that is shared by a Supplier s service group shall be owned by a named representative of the Supplier, who is also accountable and responsible for maintaining a log of each individual s usage of that account System accounts (such as an administrator account) shall not use a default password Unused default accounts shall be removed or disabled; e.g. Supplier super-user and Guest accounts Network devices shall have passwords encrypted within the device Network devices shall be implemented with role-based access (e.g. separate passwords for administrators, service providers and operators) Encryption shall be used during administration of network devices within the PCD over Ethernet Passwords shall be of at least eight characters in length and consist of a combination of at least three of the following four character sets: lowercase, uppercase, numeric digit, and special character (%, #, etc.) Local and domain user account passwords shall be configured to automatically expire every 180 days, and prevent reuse of at least the three previously used passwords. Users shall be prompted to change their passwords [user defined] days prior to expiration, with a default of 30 days.

14 Page Service, auto-login and operator accounts shall be configured so that they never expire, or become disabled automatically Workstations located in areas that are normally unattended shall require authentication and shall have an active automatic locking or disconnection mechanism.

15 Page BACKUP, RESTORE AND DISASTER RECOVERY 9.1. The Supplier shall describe the recommended backup strategy and architecture for its systems and make the document available to Principal at least 30 days prior to factory acceptance testing. The document shall address at least the following: The system shall be able to be backed-up at [user defined] intervals which fulfill the data restore and disaster recovery objectives for the system, as defined in Shell's backup and recovery plan A backup shall be completed prior to an engineering change being made to the hardware or software, e.g.: Installing an operating system patch or upgrade Hardware modifications Before a change is made for which automatic roll-back is impossible After modifications to the system (scheduling changes, authorization and authentication changes, process trip or application changes) The following types of data shall be backed-up: Operating system files Applications (including middleware, such as an OPC tunneller) Configuration data Database files Log files Electronic log book Unconventional file types; e.g. network equipment settings, Process Automation System (PAS) controller settings (tuning parameters, set points, alarm levels, etc.), field instrumentation parameters and Microsoft Active Directory Other files, identified by the Supplier, required to create a complete backup of the Supplier s system The Supplier shall provide detailed instructions on how to make a full back-up of its system using at least one of the four methods below. Shell s preference is the Centralized backup architecture : Proprietary backup architecture on removable media Single system backup architecture on removable media Distributed backup architecture Centralized backup architecture 9.2. The Supplier s system shall function normally (no significant changes of CPU load shall be noticeable) whilst a backup is in progress It shall be possible to use a backup to restore the system back to a fully functioning system or to a simulation system to any point in time defined in (9.1.1). Restoration of the system shall not require special or specific knowledge or tools and shall be able to be performed by a Shell Control and Automation support person The Supplier shall provide a procedure for verification of backups of its system The Supplier shall provide procedures for control and management of removable backup media The Supplier shall both provide a procedure and then demonstrate using that procedure (during acceptance tests) that it is possible to create a complete backup of Supplier s system, and that it is possible to perform disaster recovery by restoring a fully functioning system from this backup The backup and restore system shall maintain an audit trail of all backup and restore activities.

16 Page REMOTE ACCESS AND TRANSFER OF DATA FILES As specified by the Principal, the Supplier shall be able to provide access to its system in the PCD from a remote location; i.e. connect to the system from a network and domain outside of the PCD. The following shall apply: As required, the Supplier shall provide remote access using at least one of the following connectivity applications (specified or later versions): Microsoft Terminal Services v5.2 (RDP) Symantec pcanywhere v10.51 RealVNC v4.0 TeamSoftware Solutions Public Web Browser v2.09 Citrix ICA v9.151 Sun Microsystems Tarantella NetSupport Manager v10 Attachmate Reflection for UNIX (Telnet only) The Supplier shall provide detailed instructions on how to install, configure and operate the selected remote access software on the Supplier s system The Supplier shall provide adequate information about proposed methods of data transfer between its system and other systems and networks to allow Shell to risk assess and approve the method of data transfer before it is implemented If the Principal has specified a requirement for remote access, the Supplier shall demonstrate, during acceptance testing, remote access the system using one of the allowed connectivity applications. A Shell TPA agreement shall also put in place between Principal and Supplier If remote Supplier support is to be provided via the Internet, then a Shell Third Party Access (TPA) connection shall be used to connect to the Shell Global Infrastructure network Modem connections to the systems in the PCD shall not be allowed without written approval by the Principal. Written approval shall only be provided where a TCP/IP network connection is not available (e.g. a legacy system that does not have this functionality). When a modem is used to access a PCD system, the modem make and connection method shall be approved by the Principal and shall be physically disconnected when not in use All system-to-system connections and user-to-system connections between Supplier s system and other non-supplier systems via a Supplier supplied Firewall or Router with ACL shall be approved by the Principal.

17 Page WIRELESS CONNECTIVITY Where wireless devices are appropriate, the Supplier s system should support and use approved international wireless standards (e.g. IEEE, ISA or IEC) rather than proprietary protocols. The use of proprietary and non-proprietary protocols shall not be used unless approved by the Principal Industrial wireless field devices shall be based on ISA 100 or WirelessHART. Other techniques shall not be used unless approved by the Principal Pre-shared encryption keys shall support at least 128 bit encryption Wireless bridges providing point-to-point backbone connectivity shall support strong encryption (e.g. WPA2, AES-256), or use VPN tunnels, secured with IPsec or SSL Wireless field instruments shall be able to be configured by the PAS (in a similar manner to wired solutions) It shall be possible to view the latest configuration of a wireless field device used for monitoring and control from the PAS The SSID shall only be broadcasted if services require its visibility A unique, location-specific SSID shall be used. The SSID shall be a descriptive acronym, not obviously associated with a Shell location by the general public; e.g. SHELL_PLANT shall not be used Wireless devices connected to a TCP/IP port shall use static IP addresses; i.e. Dynamic Host Configuration Protocol (DHCP) shall be disabled Encryption or a secure tunnel between wireless devices shall be used where possible For wireless connections, the highest feasible level of WPA, WPA2 or AES security / encryption shall be used The point of connection to a wired Ethernet network shall be a firewall with documented firewall rules When applicable, maintenance and/or engineering of wireless devices connected to L1 or L2 shall be via the PAS management workstation; i.e. direct access to these devices using wireless connections bypassing the DCS is not allowed Remote maintenance and/or remote engineering of wireless devices connected to L3 shall only be possible via wired connections through the PCAD. Direct access to these devices using wireless connections is not allowed Wireless devices are not allowed as an integral part of safeguarding functions; i.e. SIF, IPF, SIL 1 or higher. All sensors and final elements shall be directly hard-wired to the IPS. Wireless devices used for safety critical elements and that would be connected to the DCS shall be risk assessed and understanding of the wireless device limitations and associated fail safe conditions before being used Secure usernames and passwords shall be used on all wireless devices. Manufacturers' default user names and passwords shall be changed to locally specified ones when technically feasible Unused ports provided on wireless devices, such as a RS232 interface for configuration, shall be made physically secure or disabled where possible If a wireless worker (wireless handheld device) is used to present a DCS HMI in the field, then all wireless worker connectivity to the office domain shall be via the PCAD ACLs and authentication methods shall be implemented to secure the wireless network The system design Supplier (or Contractor) shall provide architecture documentation describing how wireless systems will: Provide data exchange between L1 and wireless instrumentation

18 Page 18 Provide data exchange between L2 and L3 via a secure wireless link Bridge the L3 network via a secure wireless link Prevent intruder access from the wireless system into PCD systems Restrict access for wireless workers to specific systems in the PCD If required, provide remote management of wireless systems

19 Page SECURE CONNECTIONS TO INSTRUMENTED PROTECTIVE SYSTEMS In addition to Supplier compliance to the requirements as presented in Instrumented Protective Functions, DEP Gen. Section , the following requirements shall also be met: The Supplier SHALL [PS] have periodic security risk assessments performed by a reputable third party (e.g. TÜV, Exida, SAIC or Wurldtech) on the Supplier s IPS product communications design and architecture, both internal and external to the safety network and to all related IPF, including the SIS Engineering Workstation(s) Connection to the IPS, and safety-related communication between IPS components (for SIL 1 and above), shall require a documented risk assessment to assure that cyber-security risks have been managed to ALARP. Acceptable risk mitigation approaches shall consider DCS-IPS integration approaches such as hard-wired, logical separation, or industry certified (e.g. TÜV) network integration The data connection between the DCS and the IPS (see Appendix 2) shall not be used for safety critical communications (e.g. communications associated with IPF functionality associated with distributed logic across IPS systems) unless a documented risk assessment has been completed to assure that cyber-security risks have been managed to ALARP. Acceptable risk mitigation approaches shall consider solutions such as hard-wiring between IPS systems, logical separation, or industry certified (e.g. TÜV) network integration In all cases the IPS engineering workstation (EWS) shall be configured such that remote access to the EWS is prevented (both from within the PCD and via the PCAD). Although the EWS may be networked to other PC s or devices within the Safeguarding System network, this network should have no connection or common elements with any other network (stand-alone network). The EWS shall be connected directly (EWS-1) or via the Control bus and dedicated gateways (EWS 2) to the IPS The EWS shall not be installed on another physical location, nor communicate via the PCN (or L3) to the IPS. The IPS shall not have a direct connection to the PCN. The IPS shall only be connected to the DCS, as indicated in Figure 1 IPF Inter-connections IPF Interconnections below. Figure 1 IPF Inter-connections

20 Page STANDARDS AND CERTIFICATION The Supplier shall provide Shell copies of attained process control security certificates; e.g. Wurldtech Security Technologies Achilles certification, ISA Security Compliance Institute (ISCI) or equivalent.

21 Page SECURITY MONITORING The Supplier s system shall support (system) security monitoring using at least one of the following methods: HIDS, Syslog, WMI or SNMP traps For Supplier s open systems that are capable of providing Management Information Base (MIB) the Supplier shall install and test a MIB for sharing system configuration information and for monitoring of system security performance with other 3rd-party software The Supplier shall prove that its system is robust against system scans during normal operation.

22 Page PROCESS CONTROL DOMAIN NETWORK ARCHITECTURE All PCD equipment capable of time-synchronization shall synchronize time from a secure and accurate source; e.g. via a Network Time Protocol (NTP) server connected to L When requested and feasible the Supplier shall provide products and systems in the PCD to further analyze and process the collected data, e.g. vibration monitoring data, control systems for compressors, distributed temperature sensors etc., and these systems shall be able to be connected to, e.g. data historians, SAP, or other applications in the office domain or on desktops of end-users and the Supplier. These systems are also subject to all requirements of this DEP. It is preferred not to install stand-alone systems (e.g. PCs, processors, etc.) in the PCD, but rather integrate the applications with the DCS using the systems and functionality already present in the PCD In Shell Upstream solutions, the Process Control Network (PCN or L3) and Distributed Control System (DCS) internal bus (L2) shall be physically separated by: Dedicated firewall (preferred solution), or Dedicated router with Access Control List (ACL) (non-preferred option), or Dual-homing connections without routing between these connections (nonpreferred option) In Shell Downstream solutions, the Process Control Network (PCN or L3) and Distributed Control System (DCS) internal bus (L2) shall be physically separated by a firewall The system design Supplier (or Contractor) shall provide Shell with logical and physical infrastructure architecture drawings in Autocad or Microsoft Visio drawing formats, demonstrating that the Supplier s systems and components are compliant with the infrastructure architectural requirements described in this DEP.

23 Page HANDLING OF REMOTE AND ADVISORY SETPOINTS A remote setpoint may be set by another system or human working remotely on network Level 2 or Level 3. An advisory setpoint is recommended by an application or human working on network Level 4. When changes to operating conditions come from remote or advisory setpoints, the Supplier's system shall be capable of both of the following two types of functionality: 1) Operator acknowledgement of the new setpoint. When not acknowledged, the last approved setpoint will remain valid. 2) New setpoints within a certain range are automatically accepted and used by the control system. When the new setpoint is outside the pre-selected range, an alarm will be generated and the new setpoint will not be used unless specifically approved by the operator. The last accepted setpoint shall remain valid.

24 Page DATA HISTORIANS The Supplier s system shall be capable of collecting Historian data, using an open standard communication protocol with embedded security (e.g. OPC, OPC UA, XI, SSL, OPC Tunneler, etc) The Supplier shall demonstrate the capability to interface to Historians in a secure manner.

25 Page COMMISSIONING AND MAINTENANCE The following shall apply whenever the Supplier is involved in commissioning and maintenance activities. Supplier shall provide evidence for certification purposes that a procedure is in place that demonstrates that: Supplier representatives shall follow and enforce the process control security procedures specified in this DEP and the Supplier s security policy during engagement in commissioning and maintenance activities on Shell sites The Supplier shall conduct a process control security risk assessment at the beginning of the commissioning phase. The Supplier shall describe potential security risks and recommended mitigation procedures to the commissioning team during security awareness training During testing and commissioning and when encryption is required for wireless connectivity, the Supplier shall demonstrate that encryption keys and pre-shared keys input to wireless devices are managed to ensure they are protected and accessible with the appropriate permissions The Supplier shall supply and maintain an inventory register of the components supplied by the Supplier in a confidential manner The Supplier shall provide Shell with as-built documentation, in a format as agreed by the Principal, of equipment connections and configurations Temporary user accounts used during commissioning and testing shall be removed at the end of the activity During testing and commissioning the Supplier shall perform a network scan at L2 and L3 to discover hidden systems or vulnerabilities, and to confirm that the configuration of communication ports is in compliance with the specifications The Supplier shall inform Shell of any adverse effects that hardware or software troubleshooting tools may have on PCD network performance. Use of troubleshooting tools shall be approved by Shell prior to being used on the PCD infrastructure Use of the Shell Management of Change (MOC) and Permit To Work processes shall be followed for changes involving devices or connections between devices in the PCD Supplier shall prove to the Principal that a sanitization process has removed all sensitive information from any part that will be replaced or that the part and the sensitive information have been destroyed During testing and commissioning, the Supplier shall demonstrate that security mechanisms have been installed in accordance with approved procedures and that the system is hardened.

26 Page REFERENCES In this DEP, reference is made to the following publications: NOTES: 1. Unless specifically designated by date, the latest edition of each publication shall be used, together with any amendments/supplements/revisions thereto. 2. The DEPs and most referenced external standards are available to Shell staff on the SWW (Shell Wide Web) at SHELL STANDARDS Instrumented Protective Functions (IPF) DEP Gen. AMERICAN STANDARDS Manufacturing and Control Systems Security - Part 1: Concepts, Models and Terminology Issued by: The International Society of Automation 67 Alexander Drive PO Box Research Triangle Park, NC 27709, USA ISA (2005 Draft) INTERNATIONAL STANDARDS Process Control Domain - Security Requirements for Suppliers WIB Working Group: Plant Security Report M X-10 (October 2010) Issued by: International Instrument Users' Association -WIB Prinsessegracht AP, The Hague., The Netherlands

27 Page 27 APPENDIX 1 ARCHITECTURE LEVELS IN ISA , PART 1 Ref. ISA (2005), Security for Industrial Automation and Control Systems, Part 1: Terminology, Concepts, and Models, Figure 5 DCS Example using the General Reference Model. Copyright 2005 ISA. All rights reserved. Reproduced and distributed with permission of ISA

28 Page 28 APPENDIX 2 DATA ACQUISITION AND CONTROL ARCHITECTURE PCD Security Vendors & 3 rd Parties Internet OD Apps & CWE Historian GI Clients Shell Access Manager (TPA/MOB/MOP) OFFICE NETWORK (GI-Network or L4) Office Domain (OD) Portal (PCDP) Firewall AV/Patch Server Process Control Access Domain (PCAD) Process Control Domain (PCD) PROCESS CONTROL NETWORK (PCN or L3) Router+ACL or Firewall CCR Historian PCD Apps PAS (DCS/PLC) CONTROL BUS (L2) Fire&Gas SIS (IPS) Detection HMI Control Apps Gateway SIS SIS (IPS) Fiscal Metering Special Monitoring FIELD BUS (L1) L0 PTE/PACO Version: 2.4