DEP SPECIFICATION

PROCESS CONTROL DOMAIN - SECURITY

REQUIREMENTS FOR SUPPLIERS

DEP 32.01.23.17-Gen.

February 2014

DESIGN AND ENGINEERING PRACTICE

© 2014 Shell Group of companies

All rights reserved. No part of this document 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.
 DEP 32.01.23.17-Gen.
February 2014
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 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 3

TABLE OF CONTENTS
1. INTRODUCTION ........................................................................................................ 4
1.1 SCOPE........................................................................................................................ 4
1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS ......... 4
1.3 DEFINITIONS ............................................................................................................. 4
1.4 CROSS-REFERENCES ............................................................................................. 6
1.5 SUMMARY OF MAIN CHANGES ............................................................................... 6
1.6 COMMENTS ON THIS DEP ....................................................................................... 7
2. GENERAL SECURITY POLICY ................................................................................. 8
2.1 DEMONSTRATING COMPATIBILITY VIA INDEPENDENT CERTIFICATION ......... 8
2.2 SECURITY APPLICATION ......................................................................................... 8
3. PROCESS CONTROL SECURITY FOCAL POINT ................................................... 8
4. CONTROLS AGAINST MALICIOUS CODE .............................................................. 8
5. SOFTWARE PATCH MANAGEMENT ....................................................................... 9
6. SYSTEM HARDENING ............................................................................................ 10
7. PROTECTION OF PCD DOCUMENTATION........................................................... 11
8. ACCOUNT MANAGEMENT ..................................................................................... 11
9. BACKUP, RESTORE AND DISASTER RECOVERY .............................................. 12
10. REMOTE ACCESS AND TRANSFER OF DATA FILES ......................................... 13
11. WIRELESS CONNECTIVITY ................................................................................... 14
12. SECURE CONNECTIONS TO INSTRUMENTED PROTECTIVE SYSTEMS ......... 15
13. STANDARDS AND CERTIFICATION ...................................................................... 16
14. SECURITY MONITORING ....................................................................................... 16
15. PROCESS CONTROL DOMAIN NETWORK ARCHITECTURE............................. 16
16. HANDLING OF REMOTE AND ADVISORY SETPOINTS ...................................... 17
17. DATA HISTORIANS ................................................................................................. 17
18. COMMISSIONING AND MAINTENANCE ............................................................... 17
19. REFERENCES ......................................................................................................... 19

APPENDICES
APPENDIX 1 ARCHITECTURE LEVELS IN ISA-99.00.01, PART 1 ................................... 20
APPENDIX 2 DATA ACQUISITION AND CONTROL ARCHITECTURE ............................. 21
 DEP 32.01.23.17-Gen.
February 2014
Page 4

1. INTRODUCTION

1.1 SCOPE
This DEP specifies requirements and gives recommendations 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 is a revision of the DEP of the same number dated February 2011; 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
authorisation 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 shall 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
1.3.1 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 word should indicates a recommendation.
 DEP 32.01.23.17-Gen.
February 2014
Page 5

1.3.2 Specific definitions

Term Definition
PCD Security When a Supplier’s solution complies with the requirements in this DEP, the
Compatible solution is considered by Shell to be PCD Security Compatible.
Network Electronic equipment that connects or manages network traffic; e.g.,
device switches, routers and firewalls.
Compatible A supplier is compatible with the Principal’s security policy and standards
Supplier 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
system 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.
Derogation an authorised variance or exemption from a Process Safety requirement,
with specified conditions.
Process the management of hazards that can give rise to major accidents involving,
Safety personnel safety, the release of potentially dangerous materials, and
release of energy (such as fire or explosion) or both.
IT security The equivalent to Process Control System Cyber Security, and Process
Control System Cyber Security Controls.

1.3.3 Abbreviations

Term Definition
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
Instrumented Protective Function; All instruments and systems required to
IPF 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
IPS
(SIS)
In this DEP, IT security is equivalent to process control system cyber
IT security
security, and process control system cyber security controls
 DEP 32.01.23.17-Gen.
February 2014
Page 6

Term Definition
L1 Network Level 1 – Basic Process Control (Appendix 1)
L2 Network Level 2 – Area Supervisory Control (Appendix 1)
Network Level 3 – Site Maufacturing Operations (Appendix 1). Equivalent to
L3
the Process Control Network (PCN)
Network Level 4 – Site Business Planning (Appendix 1). Equivalent to the
L4
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)
Safety Instrumented System; equivalent to Instrumented Protective System
SIS
(IPS)
SNMP Simple Network Management Protocol
SSID Service Set Identifier
TCP/IP Transmission Control Protocol/Internet Protocol
TPA Third Party Access (for Shell Global Infrastructure)
WMI Windows Management Instrumentation

1.4 CROSS-REFERENCES
Where cross-references to other parts of this DEP are made, the referenced section or
clause 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 minor revision of the DEP of the same number dated February 2011. The
following are the main, non-editorial changes.

Section/Clause Change
General With this revision, the DEP is no longer DEM1 status.
2.1 Entire paragraph re-worded
12.1 The SHALL [PS] statement previously in this clause has been
changed to “shall”.
 DEP 32.01.23.17-Gen.
February 2014
Page 7

1.6 COMMENTS ON THIS DEP

Comments on this DEP may be submitted to the Administrator using one of the following
options:

Shell DEPs Online Enter the Shell DEPs Online system at

https://www.shelldeps.com
(Users with access to
Shell DEPs Online) Select a DEP and then go to the details screen for
that DEP.
Click on the “Give feedback” link, fill in the online
form and submit.

DEP Feedback System Enter comments directly in the DEP Feedback

(Users with access to System which is accessible from the Technical
Shell Wide Web) Standards Portal http://sww.shell.com/standards.
Select “Submit DEP Feedback”, fill in the online form
and submit.

DEP Standard Form Use DEP Standard Form 00.00.05.80-Gen. to record

(Other users) feedback and email the form to the Administrator at
standards@shell.com.

Feedback that has been registered in the DEP Feedback System by using one of the above
options will be reviewed by the DEP Custodian for potential improvements to the DEP.
 DEP 32.01.23.17-Gen.
February 2014
Page 8

2. GENERAL SECURITY POLICY

2.1 DEMONSTRATING COMPATIBILITY VIA INDEPENDENT CERTIFICATION

Suppliers shall demonstrate PCD Security capability maturity to this DEP by one of the
following methods agreed by both Supplier and Principal:
1. Wurldtech’s Achilles Practices Certification (APC) level bronze, or
2. Shell PCD IT Security Controls Maturity & Compliance Assessment

2.2 SECURITY APPLICATION

2.2.1. The Supplier shall, within their own organization, practice and maintain policies, standards
and procedures that are compliant with the requirements specified in this DEP.
2.2.2. 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.
2.2.3. 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.
2.2.4. Confidentiality agreements and user agreements to follow applicable standards and
procedures shall be signed by all persons having access to the Principal’s PCD.
2.2.5. 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.
2.2.6. 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.

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.

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.
 DEP 32.01.23.17-Gen.
February 2014
Page 9

4.2. 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.
4.3. The Supplier shall provide documentation describing how approval of virus definition files
shall be communicated to the Principal.
4.4. 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.
4.5. The Supplier shall provide evidence that the configured equipment has been checked to be
free of malicious code prior to shipment to the Principal.
4.6. The Supplier shall provide documented instructions for ensuring the proper installation,
configuration and update of anti-virus software.
4.7. 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.
4.8. 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.
4.9. 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.
4.10. 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 anti-
virus software.

5. 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.
5.1.1. The Supplier shall review their product security policy annually to address new
threats and vulnerabilities.
5.1.2. 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.
5.2. The Supplier shall qualify all software patches for use on its system during its supported
lifetime.
5.2.1. 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.
5.2.2. 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.
5.2.3. 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 10

5.3. 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.
5.4. 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.
5.5. Patches and service packs approved by the Supplier shall not be re-distributed by the
Supplier, when available from the Manufacturer of the software.
5.6. 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.
5.7. 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.
5.7.1. When using a patch management server, documentation shall be provided to show
how to configure the Supplier’s system to receive updates.
5.7.2. For manual patching using portable media, detailed instructions shall be supplied on
how to install patches and how patching status reports shall be provided.
5.8. The Supplier shall describe a recommended roll-out procedure for software patching and
upgrading of all parts of its system.
5.9. 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.

6. 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., E-mail, 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 11

7. 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.

8. ACCOUNT MANAGEMENT
This section has been split into two almost identical parts for certification reasons.
Section (8.1) is about supporting requirements and (8.2) is about enforcing requirements,
as follows:
8.1. The Supplier’s system shall support use of secure user accounts, as follows.
8.1.1. The Supplier’s system shall support that default passwords used for system accounts
(such as an administrator account) can be changed by Shell.
8.1.2. 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.
8.1.3. The Supplier’s network devices shall provide the capability to encrypt passwords
within the network device.
8.1.4. The Supplier’s network devices shall support role-based access (e.g., separate
passwords for administrators, service providers and operators).
8.1.5. The Supplier’s system shall support use of encryption for administration of network
devices within the PCD over Ethernet.
8.1.6. 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.)
8.1.7. 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.
8.1.8. The Supplier’s system shall support that service; auto-login and operator accounts
shall never expire or be disabled automatically.
8.1.9. 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.
8.2. Use of secure user accounts shall be enforced as follows.
8.2.1. All users other than operators and service groups shall have individual user names
and passwords. Individual passwords shall not be divulged to other persons.
8.2.2. 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.
8.2.3. System accounts (such as an administrator account) shall not use a default
password.
8.2.4. Unused default accounts shall be removed or disabled; e.g., Supplier “super-user”
and “Guest” accounts.
8.2.5. Network devices shall have passwords encrypted within the device.
 DEP 32.01.23.17-Gen.
February 2014
Page 12

8.2.6. Network devices shall be implemented with role-based access (e.g., separate
passwords for administrators, service providers and operators).
8.2.7. Encryption shall be used during administration of network devices within the PCD
over Ethernet.
8.2.8. 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.)
8.2.9. 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.
8.2.10. Service, auto-login and operator accounts shall be configured so that they never
expire, or become disabled automatically.
8.2.11. Workstations located in areas that are normally unattended shall require
authentication and shall have an active automatic locking or disconnection
mechanism.

9. 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:
9.1.1. 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.
9.1.2. 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)
9.1.3. 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
 DEP 32.01.23.17-Gen.
February 2014
Page 13

9.1.4. 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.
9.3. 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.
9.4. The Supplier shall provide a procedure for verification of backups of its system.
9.5. The Supplier shall provide procedures for control and management of removable backup
media.
9.6. 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.
9.7. The backup and restore system shall maintain an audit trail of all backup and restore
activities.

10. 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:
10.1. 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)
10.2. The Supplier shall provide detailed instructions on how to install, configure and operate the
selected remote access software on the Supplier’s system.
10.3. 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.
10.4. 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 14

10.5. 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.
10.6. 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.
10.7. 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.

11. WIRELESS CONNECTIVITY

11.1. 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.
11.2. Industrial wireless field devices shall be based on ISA 100 or WirelessHART. Other
techniques shall not be used unless approved by the Principal.
11.3. Pre-shared encryption keys shall support at least 128 bit encryption.
11.4. 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.
11.5. Wireless field instruments shall be able to be configured by the PAS (in a similar manner to
wired solutions).
11.6. It shall be possible to view the latest configuration of a wireless field device used for
monitoring and control from the PAS.
11.7. The SSID shall only be broadcasted if services require its visibility.
11.8. 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.
11.9. Wireless devices connected to a TCP/IP port shall use static IP addresses; i.e., Dynamic
Host Configuration Protocol (DHCP) shall be disabled.
11.10. Encryption or a secure tunnel between wireless devices shall be used where possible.
11.11. For wireless connections, the highest feasible level of WPA, WPA2 or AES security /
encryption shall be used.
11.12. The point of connection to a wired Ethernet network shall be a firewall with documented
firewall rules.
11.13. 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.
11.14. 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.
11.15. 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 15

11.16. 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.
11.17. Unused ports provided on wireless devices, such as a RS232 interface for configuration,
shall be made physically secure or disabled where possible.
11.18. 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.
11.19. ACLs and authentication methods shall be implemented to secure the wireless network.
11.20. The system design Supplier (or Contractor) shall provide architecture documentation
describing how wireless systems will:
• Provide data exchange between L1 and wireless instrumentation
• 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

12. SECURE CONNECTIONS TO INSTRUMENTED PROTECTIVE SYSTEMS

In addition to Supplier compliance to the requirements as presented in Instrumented
Protective Functions, DEP 32.80.10.10-Gen. Section 6.7.5.3, the following requirements
shall also be met:
12.1. The Supplier shall 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).
12.2. 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.
12.3. 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.
12.4. 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.
12.5. 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 Inter-
connections below.
 DEP 32.01.23.17-Gen.
February 2014
Page 16

Figure 1 IPF Inter-connections

13. STANDARDS AND CERTIFICATION

13.1. 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.

14. SECURITY MONITORING

14.1. The Supplier’s system shall support (system) security monitoring using at least one of the
following methods: HIDS, Syslog, WMI or SNMP traps.
14.2. 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.
14.3. The Supplier shall prove that ‘its system’ is robust against system scans during normal
operation.

15. PROCESS CONTROL DOMAIN NETWORK ARCHITECTURE

15.1. 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 L3.
15.2. 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 17

15.3. 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 (non-preferred
option).
15.4. 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.
15.5. 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.

16. 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.

17. DATA HISTORIANS

17.1. 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).
17.2. The Supplier shall demonstrate the capability to interface to Historians in a secure manner.

18. 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:
18.1. 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.
18.2. 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.
18.3. During testing and commissioning and when encryption is required for wireless
connectivity, the Supplier shall demonstrate that encryption keys and pre-shared keys input
 DEP 32.01.23.17-Gen.
February 2014
Page 18

to wireless devices are managed to ensure they are protected and accessible with the
appropriate permissions.
18.4. The Supplier shall supply and maintain an inventory register of the components supplied by
the Supplier in a confidential manner.
18.5. The Supplier shall provide Shell with as-built documentation, in a format as agreed by the
Principal, of equipment connections and configurations.
18.6. Temporary user accounts used during commissioning and testing shall be removed at the
end of the activity.
18.7. 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.
18.8. 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.
18.9. 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.
18.10. 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.
18.11. 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.
 DEP 32.01.23.17-Gen.
February 2014
Page 19

19. 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 http://sww.shell.com/standards/.

SHELL STANDARDS
DEP feedback form DEP 00.00.05.80-Gen.
Instrumented Protective Functions (IPF) DEP 32.80.10.10-Gen.
Shell HSSE & SP Control Framework, Design Engineering Manual DEM1
(DEM) 1 – Application of Technical Standards
http://sww.manuals.shell.com/HSSE/

AMERICAN STANDARDS
Manufacturing and Control Systems Security - Part 1: Concepts, ISA-99.00.01 (2005 Draft)
Models and Terminology

INTERNATIONAL STANDARDS
Process Control Domain - Security Requirements for Suppliers Report M 2784 - X-10
WIB Working Group: Plant Security (October 2010)
Issued by: International Instrument Users' Association -WIB
 DEP 32.01.23.17-Gen.
February 2014
Page 20

APPENDIX 1 ARCHITECTURE LEVELS IN ISA-99.00.01, PART 1

Ref. ISA-99.00.01 (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.
 DEP 32.01.23.17-Gen.
February 2014
Page 21

APPENDIX 2 DATA ACQUISITION AND CONTROL ARCHITECTURE

PCD Security Vendors & Internet

3rd Parties

Shell Access Manager

OD Apps GI (TPA/MOB/MOP)
Historian
& CWE Clients

OFFICE NETWORK (GI-Network or L4)

Office Domain (OD)

Portal AV/Patch
Firewall
(PCDP) Server
Process Control Access Domain (PCAD)

Process Control Domain (PCD)

PROCESS CONTROL NETWORK (PCN or L3)

Router+ACL
CCR Historian PCD Apps
or Firewall

PAS (DCS/PLC)
CONTROL BUS (L2) Fire&Gas
SIS (IPS)
Detection

SIS(IPS)
(IPS) Fiscal Special
HMI Control Apps Gateway SIS Monitoring
Metering

FIELD BUS (L1)

L0

PTE/PACO Version: 2.4