ESA Networks SSRS - Best Practicesemits.sso.esa.int/emits-doc/ESRIN/7921_DWH/ISMS-CITI-BP-1001-FCI … · ESA Networks SSRS - Best Practices ... 63 IX - 6 Video ... (FC-SP-2)”,

Prepared by EITD Reference ISMS-CITI-BP-1001-FCI-I Issue 1 Revision 0.1 Date of Issue 07/03/2014 Status Approved/Applicable Document Type BP Distribution ESA Internal

ESA UNCLASSIFIED – For Internal Use

esrin Via Galileo Galilei

Casella Postale 64 00044 Frascati

Italy T +39 06 9418 01

F +39 06 9418 0280 www.esa.int

ESA Networks System-specific Security Requirement Statement (SSRS) - Best Practices

Page 2/95 ESA Networks SSRS - Best Practices Date 07/03/2014 Issue 1 Rev 0.1


Title ESA Networks System-specific Security Requirement Statement (SSRS) - Best

Practices Issue 1 Revision 0.1

Author Geert Jacobs Date

Approved by Date

Marco Incollingo H/FCI-IRC

Angelika Mann, IT/NSM



Reason for change Issue Revision Date Outdated version of the “Implementation of the ESA Network Security Policy”

2 2(3) 28/09/2004

Issue 1 Revision 0.1 Reason for change Date Pages Paragraph(s) Create a new document that is in line with the “ESA Security Directives”, the “ESA Networks SSRS” and the evolved ESA network technology and requirements

07/03/2014 All All



Table Of Contents

I INTRODUCTION ......................................................................................... 17

I - 1 General .............................................................................................................................................. 17 I - 2 Purpose .............................................................................................................................................. 17 I - 3 Referrals ............................................................................................................................................ 18

II CONNECTING SYSTEMS TO A NETWORK ................................................ 19

II - 1 Connecting ESA Systems To ESA Networks ..................................................................................... 19 II - 2 Connecting non-ESA Systems To ESA Networks .............................................................................20

II - 2.1 Generic Non-ESA Systems Connectivity .................................................................................................... 20 II - 2.2 Bring Your Own Device (BYOD) Connectivity ........................................................................................... 20

II - 3 Connecting ESA Systems To Non-ESA Networks ............................................................................ 21 II - 4 Connecting ESA Systems In The Cloud ............................................................................................ 22 II - 5 Collocation Of ESA Systems ............................................................................................................. 24 II - 6 Connecting Blades, Hypervisors And Virtual Machines .................................................................. 24

II - 6.1 Connecting Blades ........................................................................................................................................ 24 II - 6.2 Connecting Hypervisors .............................................................................................................................. 27 II - 6.3 Connecting Virtual Machines ...................................................................................................................... 27

III INTERCONNECTING WITH ESA ............................................................. 28

III - 1 Third Parties Interconnecting With ESA .......................................................................................... 28 III - 1.1 Third Party Interconnection Over Shared Network ................................................................................... 29 III - 1.2 Third Party Interconnection Over Trusted Link ........................................................................................ 30

III - 2 Cloud Networks Interconnecting With ESA ..................................................................................... 31 III - 3 Using Content Delivery Networks For ESA ...................................................................................... 31

IV REMOTE ACCESS ..................................................................................... 32

IV - 1 Corporate Remote Access Services ................................................................................................... 32 IV - 1.1 Remote Access Services For Individuals ..................................................................................................... 33 IV - 1.2 LAN-To-LAN Remote Access Services ........................................................................................................ 36

IV - 2 Project-Specific Remote Access Services .......................................................................................... 36

V MOBILE OFFICES AND LAUNCH CAMPAIGNS ........................................ 38

V - 1 Corporate Mobile Offices .................................................................................................................. 38 V - 2 Launch Campaigns ............................................................................................................................ 39

VI PHYSICAL ACCESS CONTROL SERVICES ................................................ 41

VII STORAGE AREA NETWORKS (SANS) ..................................................... 42

VII - 1 Single SAN – Single Security Zone Connectivity .............................................................................. 42 VII - 2 Single SAN – Multi Security Zone Connectivity ............................................................................... 48

VIII NETWORK RELATED SERVICES ........................................................... 51

VIII - 1 Network Protocols ............................................................................................................................. 51



VIII - 2 IP Addressing .................................................................................................................................... 52 VIII - 3 ESA Domain Names .......................................................................................................................... 52 VIII - 4 Domain Name Services (DNS) .......................................................................................................... 53 VIII - 5 Automatic Network Configuration (DHCP) ..................................................................................... 54 VIII - 6 Time Synchronization Services (NTP) .............................................................................................. 56 VIII - 7 Routing .............................................................................................................................................. 56

IX SERVICE DEPLOYMENT ON ESA NETWORKS ........................................ 58

IX - 1 Directory Services ............................................................................................................................. 58 IX - 1.1 Corporate Directory Services ....................................................................................................................... 58 IX - 1.2 Project-Specific Directory Services ............................................................................................................ 60

IX - 2 Messaging Services ........................................................................................................................... 60 IX - 3 Collaboration Services....................................................................................................................... 61 IX - 4 Microsoft Windows Domain Services ............................................................................................... 62 IX - 5 Voice Over IP Services (VoIP) ........................................................................................................... 63 IX - 6 Video Conferencing Services ............................................................................................................. 63 IX - 7 Tele-Presence Services ...................................................................................................................... 64 IX - 8 Video Streaming Services .................................................................................................................. 64 IX - 9 Backup Services ................................................................................................................................. 65 IX - 10 Web Services ..................................................................................................................................... 66

IX - 10.1 “Single Server”-based Web Services ............................................................................................................66 IX - 10.2 “Multi-Tier” Web Services .......................................................................................................................... 68

X TECHNICAL NETWORK SECURITY CONTROLS ....................................... 73

X - 1 Physical Network Security ................................................................................................................ 73 X - 2 Network Infrastructure ..................................................................................................................... 74 X - 3 Firewall Services ................................................................................................................................ 74

X - 3.1 Screening Functionality ............................................................................................................................... 74 X - 3.2 Ownership .................................................................................................................................................... 75 X - 3.3 Corporate Firewall Services ......................................................................................................................... 75 X - 3.4 Project Firewall Services .............................................................................................................................. 76

X - 4 Application Gateway Services ........................................................................................................... 76 X - 4.1 Screening Functionality ............................................................................................................................... 76 X - 4.2 Ownership .................................................................................................................................................... 76 X - 4.3 Corporate Application Gateway Services .................................................................................................... 77 X - 4.4 Project Application Gateway Services ......................................................................................................... 77

X - 5 Network Access Control Services ...................................................................................................... 77 X - 5.1 Standard Network Access Control............................................................................................................... 77 X - 5.2 Next-Generation Network Access Control .................................................................................................. 79

X - 6 Intrusion Detection And Prevention Services ................................................................................. 80 X - 7 Logging And Log Retention .............................................................................................................. 81

X - 7.1 Network And Security Equipment .............................................................................................................. 81 X - 7.2 Systems Connected To The ESA Networks ................................................................................................. 81 X - 7.3 Central Logging And Corporate SIEM Service ........................................................................................... 81 X - 7.4 Log Retention .............................................................................................................................................. 82

X - 8 IT Infrastructure And Service Management ..................................................................................... 82

XI ADMINISTRATIVE NETWORK SECURITY CONTROLS ........................... 84

XI - 1 System (De-)Connection Requirements ........................................................................................... 84 XI - 1.1 Connecting Systems .................................................................................................................................... 84



XI - 1.2 Replacing or Re-Allocating Systems .......................................................................................................... 86 XI - 1.3 Removing or Decommissioning Systems ................................................................................................... 86

XI - 2 Security Plans .................................................................................................................................... 87 XI - 2.1 Systems And Services Requiring A Security Plan ....................................................................................... 87 XI - 2.2 Security Plan Assessment And Approval ................................................................................................... 90 XI - 2.3 Security Plan Management ......................................................................................................................... 90

XI - 3 Secops ............................................................................................................................................... 90 XI - 4 Security Delta Service Requests ....................................................................................................... 90 XI - 5 Network Request form ...................................................................................................................... 91

XI - 5.1 Network Request Form Contents ................................................................................................................ 91 XI - 5.2 Network Request Form Assessment And Approval ................................................................................... 93 XI - 5.3 Network Request Form Management ......................................................................................................... 93

XI - 6 Interconnection Security Agreement (ISA) ...................................................................................... 93 XI - 6.1 ISA Contents ................................................................................................................................................ 93 XI - 6.2 ISA Assessment And Approval .................................................................................................................... 93 XI - 6.3 ISA Management ..........................................................................................................................................94

XI - 7 Security Guidelines ........................................................................................................................... 94 XI - 8 Auditing ............................................................................................................................................. 94

XII SECURITY INCIDENTS ........................................................................... 95



List Of Figures

Figure 1 - Generic Blade System Connectivity Diagram ..................................................................................................................... 25 Figure 2 - Third Party Interconnection Over Shared Network, Using Dedicated VPN Gateways .................................................... 29 Figure 3 - Third Party Interconnection Over A Trusted Link ............................................................................................................. 30 Figure 4 - Generic Corporate Remote Access Services ....................................................................................................................... 32 Figure 5 - Corporate RAS For Authorized Individuals ....................................................................................................................... 33 Figure 6 - ESA Corporate Mobile Office Connectivity ........................................................................................................................ 38 Figure 7 - “Single SAN – Single Security Zone” running FCP or FCoE .............................................................................................. 43 Figure 8 – “Single SAN – Single Security Zone” running iSCSI or FCoIP ......................................................................................... 44 Figure 9 – “Single SAN – Multi Security Zone” running FCP or FCoE .............................................................................................. 49 Figure 10 - “Single SAN – Multi Security Zone” running iSCSI or FCoIP ......................................................................................... 50 Figure 11 - Reference architecture for a typical single web server deployment .................................................................................. 67 Figure 12 - Web Service tiers and applicable traffic restrictions ........................................................................................................ 69 Figure 13 - Reference architecture for a typical multi-tier web service deployment .......................................................................... 72

List of Tables

Table 1 - ESA Network Deployment In The Cloud .............................................................................................................................. 23 Table 2 – Accessibility To Specific ESA Directory Data Types From The ESA Networks ................................................................. 59 Table 3 - 802.1X Network Access Control On ESA Networks ............................................................................................................ 78 Table 4 - Security Plan Requirements on ESA Networks ................................................................................................................... 88



Applicable Documents

[AD-01] ESA Security Directives, ESA/ADMIN/IPOL(2008)6, rev.1 http://intramedia.sso.esa.int/public/security_office/ESA-ADMIN-IPOL%282008%296-rev1-Annex1_2.pdf

[AD-02] “ESA Networks SSRS”, issue 1, rev. 0.0; 16/12/2013

[AD-03] “ESA Networks SSRS – Security Baselines”, issue 1, rev. 0.0; 16/12/2013

[AD-04] “ESA Network Access Control Services - Acceptable Use Policy”, Issue 1, rev. 2, 04/11/2011

Reference Documents

[RD-01] “Implementation of the ESA Network Security Policy”, issue 2, revision 2(.3), 28/09/2004

[RD-02] Corporate IT Service Portal – IT Policies : http://itserv.esa.int/sites/ESP/ESAIT/Policies/Pages/default.aspx

[RD-03] Corporate IT Service Portal – Service Catalog : http://itserv.esa.int/sites/ESP/ServiceRequest/Pages/ServiceCatalogue.aspx

[RD-04] “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths”, NIST Special Publication 800-131A, January 2011 http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

[RD-05] “Fibre Channel — Security Protocols - 2 (FC-SP-2)”, ANSI, INCITS xxx-201x Security Protocols - 2 Rev 2.71 June 12, 2012 : http://www.t11.org/t11/docreg.nsf/indproj?OpenView&Start=137&Count=100&Expand=138#138

[RD-06] “Interconnection Security Agreements Guidelines”, ISMS-CITI-GL-1002-FCI-I; Issue 1 rev. 0; Dated 20/03/2012

[RD-07] ESACERT web pages http://forum.esacert.esa.int

[RD-08] “ESA System Security Plan Information” http://forum.esacert.esa.int/internal-forum/esacerton/ESA-System-Security-Plan

[RD-09] “ESA Network Security Incident Handling” http://forum.esacert.esa.int/internal-forum/esacerton/incident-handling

http://intramedia.sso.esa.int/public/security_office/ESA-ADMIN-IPOL%282008%296-rev1-Annex1_2.pdf

http://intramedia.sso.esa.int/public/security_office/ESA-ADMIN-IPOL%282008%296-rev1-Annex1_2.pdf

http://itserv.esa.int/sites/ESP/ESAIT/Policies/Pages/default.aspx

http://itserv.esa.int/sites/ESP/ServiceRequest/Pages/ServiceCatalogue.aspx

http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

http://www.t11.org/t11/docreg.nsf/indproj?OpenView&Start=137&Count=100&Expand=138#138

http://www.t11.org/t11/docreg.nsf/indproj?OpenView&Start=137&Count=100&Expand=138#138

http://forum.esacert.esa.int/

http://forum.esacert.esa.int/internal-forum/esacerton/ESA-System-Security-Plan

http://forum.esacert.esa.int/internal-forum/esacerton/incident-handling



Acronyms

3G and 4G : 3rd and 4th Generation Mobile Telecommunications

802.11 : IEEE set of standards for implementing wireless Local Area Networks

ACL : Access Control List

AD : Active Directory

AES : Advanced Encryption Standard

AfriNIC : African Network Information Centre

AP : Access Point

APNIC : Asia-Pacific Network Information Centre

AUP : Acceptable Use Policy

ARIN : American Registry for Internet Numbers

ARP : Address Resolution Protocol

AV : Anti-Virus; extend to Anti-malware

BSS : Basic Service Set

BYOD : Bring Your Own Device

CCMP : Counter Mode with Cipher Block Chaining Message Authentication Code Protocol

CDN : Content Delivery Networks

CSP : Cloud Service Provider

CURSA : CITI User Service Applications (services)

DC : Domain Controller

DCC : Data Communications Channel

DES : Data Encryption Standard

3DES : Triple DES



DH-CHAP : Diffie Hellman - Challenge Handshake Authentication Protocol

DHCP : Dynamic Host Configuration Protocol

DMZ : De-Militarized Zone

DNS : Domain Name System or Domain Name Services

DNSSEC : Domain Name System Security Extensions

EAP : Extensible Authentication Protocol

EAP-TLS : EAP-Transport Layer Security

EAP-TTLS : EAP-Tunneled Transport Layer Security

E-CAN : ESA External Corporate Applications Network

E-CSN : ESA External Corporate Services Network

E-CYN : ESA External Courtesy Network

E-GPN : ESA External General Purpose Network

E-LAB : ESA External Lab Network

E-MGT : ESA External Management Network

E-PDN : ESA External Pre-Deployment Network

E-PSN : ESA External Project Specific Network

EDGE : Enhanced Data GSM Environment

ESACERT : ESA’s Computer Emergencies Response Team

ESA : European Space Agency

ESAAD : ESA Active Directory

ESO : ESA Security Office

ESP : Encapsulation Security Payload

EVPN : ESA Virtual Private Network (services)

FC : Fibre Channel



FC-SP : Fibre Channel Security Protocols

FCI-I : Directorate of Finance, Controlling and Information Technology – Informatics Department

FCoE : Fibre Channel over Ethernet

FCoIP : Fibre Channel over Internet Protcol

FCP : Fibre Channel Protocol

FCS : Trusted Fibre Channel Switch

FDDI : Fiber Distributed Data Interface

FTP : File Transfer Protocol

FTPS : File Transfer Protocol Secure (FTP Secure or FTP-SSL)

GRE : Generic Routing Encapsulation

GSM : Global System for Mobile Communications (Groupe Spécial Mobile)

HBA : Host Bus Adaptor

HDLC : High-Level Data Link Control

HTTP : HyperText Transfer Protocol

HTTPS : HyperText Transfer Protocol Secure

I-CAN : ESA Internal Corporate Applications Network

I-CON : ESA Internal Corporate Office Network

I-CSN : ESA Internal Corporate Services Network

I-CYN : ESA Internal Courtesy Network

I-LAB : ESA Internal Lab Network

I-MGT : ESA Internal Management Network

I-PDN : ESA Internal Pre-Deployment Network

I-PSN : ESA Internal Project Specific Network

IaaS : Infrastructure as a Service (Cloud)



IANA : Internet Assigned Numbers Authority

IBSS : Independent Basic Service Sets

ICA : Independent Computing Architecture

ICANN : Internet Corporation for Assigned Names and Numbers

ICMP : Internet Control Message Protocol

ICN : ESA Inter-Connection Network

IDPS : Intrusion Detection and/or Prevention System

IKE : Internet Key Exchange

IO : INFOSEC Policy Officer

IMAP : Internet Message Access Protocol

IMAPS : Internet Message Access Protocol Secure

IPv4 : Internet Protocol version 4

IPv6 : Internet Protocol version 6

IPSec : Internet Protocol Security (suite)

IrDa : Infrared Data Association

ISA : Interconnection Security Agreement

iSCSI : Internet Small Computer System Interface

ISDN : Integrated Services Digital Network

ISE : (Cisco) Identity Services Engine

ISMS : Information Security Management System(s)

ISP : Internet Service Provider

IT/NSM : IT System and Network Security Manager

ITSOA : Information Technology System Operational Authority

LACNIC : Latin America and Caribbean Network Information Centre



LAN : Local Area Network

LDAP : Lightweight Directory Access Protocol

LDAPS : Lightweight Directory Access Protocol Secure

LEAP : Lightweight Extensible Authentication Protocol

LUN : Logical Unit

MUA : Multiple User Accounts

MPLS : Multi-Protocol Label Switching

NAC : (802.1X) Network Access Contol

NAS : Network Attached Storage

NFS : Network File System

NIC : Network Interface Card

NRF : Network Request Form

NTP : Network Time Protocol

O&M : Operations and Maintenance

OSI : Open Systems Interconnection (model)

PaaS : Platform as a Service (Cloud)

PAN : Personal Area Network

PEAP : Protected Extensible Authentication Protocol

POP3 : Post Office Protocol version 3

POP3S : Post Office Protocol version 3 Secure

PPP : Point-to-Point Protocol

PPTP : Point to Point Tunneling Protocol

PROM : Programmable Read-Only Memory

PSSO : Project/System Security Officer



PSTN : Public Switched Telephone Network

RADIUS : Remote Authentication Dial In User Service

RAS : Remote Access Services

RBAC : Role-Based Access Control

RDP : Remote Desktop Protocol

RIPE : Réseaux IP Européens Network Coordination Centre

RSA : Ron Rivest, Adi Shamir and Leonard Adleman public-key cryptography algorithm

RSCN : Registered State Change Notification

RTCP : RTP Control Protocol

RTP : Real-time Transport Protocol

RTSP : Real Time Streaming Protocol

SAA : System Accreditation Authority

SaaS : Software as a Service (Cloud)

SAN : Storage Area Network

SCC : Signaling Communication Channel

SCP : Secure File Copy (SSH)

SDH : Synchronous Digital Hierarchy

SDLC : Synchronous Data Link Control

SECOPS : Security Operating Procedures

SFTP : Secure File Transfer Protocol

SIEM : Security Information and Event Management

SIP : Session Initiation Protocol

SIRS : Security Interconnection Requirements Statement

SLIP : Serial Line Internet Protocol



SMTP : Simple Mail Transfer Protocol

SMTPS : Simple Mail Transfer Protocol Secure

SNMP : Simple Network Management Protocol

SNTP : Simple Network Time Protocol

SONET : Synchronous Optical Networking

SSH : Secure Shell

SSL : Secure Sockets Layer

SSRS : System-specific Security Requirement Statement

TCP : Transmission Control Protocol

TEB : Tender Evaluation Board

TKIP : Temporal Key Integrity Protocol

TLS : Transport Layer Security

UDP : User Datagram Protocol

UEFI : Unified Extensible Firmware Interface

USB : Universal Serial Bus

UTC : Coordinated Universal Time

VC : Video Conferencing

VDI : Virtual Desktop Infrastructure

VLAN : Virtual Local Area Networks

VoIP : Voice over Internet Protocols

VPN : Virtual Private Network

VS : Video Streaming

WAN : Wide Area Network

WEP : Wired Equivalent Privacy



WiMAX : Worldwide Interoperability for Microwave Access

WLAN : Wireless Local Area Network

WPA, WPA2 : Wi-Fi Protected Access; version 2

WPA-PSK : Wi-Fi Protected Access with Preshared Key

WWAN : Wireless Wide Area Network

WWN : World Wide Name

xDLC : Data Link Control technologies (e.g. SDLC, HDLC)

xDSL : Digital subscriber line technologies



I Introduction I - 1 GENERAL

In accordance to the ESA Security Directives, FCI-I, in its role of Information Technology System Operational Authority (ITSOA), is responsible for the “Implementation of the ESA Network Security Policy”. Together with the ESA Security Directives [AD-01], the “ESA Networks SSRS” [AD-02] and its “Network Security Baselines” annex [AD-03], this document composes the ESA network security policy and its practical implementation that, by default, applies to all networks where ESA systems are connected.

I - 2 PURPOSE

The purpose of this document is to :

• Identify the secure practices applicable to interconnectivity with ESA networks.

• Specify the supported ESA Remote Access scenarios.

• Give the security practices for ESA Mobile Office.

• State the network security practices for the physical access control systems used to enter sites, buildings, rooms.

• Indicate the ways how ESA systems and services are to be deployed, used and operated in the Cloud.

• Stipulate the security rules applying for the “Bring-Your-Own-Device” scenarios.

• Enumerate the conditions that apply for deploying “Storage Area Networks” on the ESA networks.

• Specify the applicable security practices for deployment, use and operations of several ESA network related services.

• List the technical security controls (to be) implemented in order to secure the ESA CIS environment.

• Enumerate the administrative security controls (to be) deployed that support the users, the ITSOA, all service managers and service providers in securely requesting,



running, maintaining, assessing and auditing the systems and services connected to the ESA networks.

• Indicate how security incidents are to be addressed This document is to be considered an integrated part of the “ESA Network Security Policy”, defined in [AD-01], [AD-02] and [AD-03].

I - 3 REFERRALS

Please refer to the corresponding sections in the “ESA Networks SSRS” document [AD-02] for :

• Scope • Audience And Applicability • Mandate • Document (Re-)Distribution And Retention • Document Updates • Enforcement And Non-Compliance • Changes From Former Version • Approval And Entry Into Force • ESA Network Security Policy Framework

Changes made in [AD-02] are also applicable in this document.



II Connecting Systems To A Network The general security aspects for systems that store, process and transit ESA data are discussed in the “ESA Security Directives”, [AD-01]. The types of systems that can connect to the different ESA network(sub-)types, have been stated in the “ESA Networks SSRS”, [AD-02]. The “ESA Network Security Baselines” that apply are defined in [AD-03]. These are pre-requisites to this “Best Practices” document. This section addresses the following connection scenario’s :

• Connecting ESA Systems to ESA Networks • Connecting non-ESA Systems to ESA Networks • Connecting ESA Systems to non-ESA Networks • Connecting ESA Systems in the Cloud • Collocation of ESA Systems at a hosting service provider • Connecting Blades, Hypervisors and Virtual Machines

Other connection scenario’s may be added if and when considered relevant.

II - 1 CONNECTING ESA SYSTEMS TO ESA NETWORKS

ESA systems are IT systems that are provided by the Agency to its workforce in order to allow them to perform business related work, offer ESA services to target communities, collaborate with other people internally and externally etc. They are deployed under one of the ESA owned DNS names. These systems can be connected to a security zone on an ESA network sub-type if [AD-01], [AD-02], [AD-03] and the “Best Practices” stated here, are adhered to. The need for keeping an ESA system connected to an ESA network shall be reviewed on a yearly basis. It is a responsibility of the PSSO to organize this yearly review and keep records of the system details and justification to keep the system connected. Systems that are no longer required are to be disconnected from the ESA networks and to be securely decommissioned or repurposed.



II - 2 CONNECTING NON-ESA SYSTEMS TO ESA NETWORKS

Non-ESA systems are any systems that fall outside the description of ESA-Systems – see section II - 1. These can be for instance, devices from visitors, service provider staff, personal devices from ESA’s workforce etc.

II - 2.1 GENERIC NON-ESA SYSTEMS CONNECTIVITY In general, these systems can be connected to an E-CYN security zone if :

• The systems are malware free, do not contain any offensive or copyright protected material and do not present a risk for the ESA community, the IT services or ESA’s reputation.

• These systems are subject to the ESA Network Access Control policy – see [AD-04]. • Unattended systems need to be disconnected from the ESA network.

SDSRs are not supported on these networks. Connectivity is granted only temporarily. Also these systems are subject to the requirement that they can be connected to only one network at a time; e.g. one cannot be connected to an E-CYN using 802.11 WiFi while at the same time using a 3 or 4 G network. See also [AD-02] section “ESA Network Reference Architecture”.

II - 2.2 BRING YOUR OWN DEVICE (BYOD) CONNECTIVITY “Bring Your Own Device” (BYOD), is a global phenomenon where people bring personally-owned mobile devices to their workplace and use them to access company resources such as email, file servers and databases as well as their personal application and data. In order to keep the risks related to this trend manageable within the Agency, the following applies :

• All BYOD users and systems are subject to the ESA Security Directives – see [AD-01].

• A BYOD can be connected to only one network at the same time – see [AD-02]

section “ESA Network Reference Architecture”.

• When agreed with their PSSO, users can connect their BYOD to following ESA network types :

o I-CON (wired and wireless)



o E-CYN (wired and wireless) o E-PSN (wired only) o E/I-LAB (wired only)

On all the other ESA network sub-types, BYODs are not allowed.

• Only BYODs connected to the I-CON, are allowed to directly access the ESA Intranet

when :

o the BYOD are configured according to the ESACERT configuration and security guidelines – see section [RD-07].

o the BYODs have an up-to-date anti-malware service and a personal firewall running.

o their operating system is up-to-date and patched to the latest security level. (BYODs for which the operating systems is not supported anymore for the vendor are not allowed on ESA networks.)

o only supported and secure applications that are covered with a valid software license are installed.

o the security measures enforced by the vendor are not bypassed; e.g. an iphone or ipad cannot be jailbroken.

o the BYOD is under FCI-I’s central Mobile Device Management when this is activated and the BYOD is supported.

• BYODs that do not meet these criteria cannot access the corporate IT services.

Note that authorized users who have their BYOD connected to the E-CYN “Beluga” WiFi security zone, can access some of the ESA corporate services in an indirect way. See [AD-02] Section “802.11 Wireless Profiles” for more details.

II - 3 CONNECTING ESA SYSTEMS TO NON-ESA NETWORKS

Typical examples of these situations are :

• people connecting their ESA laptops to their home networks, conference networks, Internet cafes etc.

• projects deploying an ESA system on a network from a partner in the context of a joint project, mission, collaboration etc.

These systems can be connected to a non-ESA network if :

• the systems meet the minimum ESA security requirements as defined by ESACERT – see [RD-07].

• the security requirements pertaining to the different ESA data classes are assured – see [AD-01].



When these ESA systems return at a later stage to an ESA network they shall be meeting the security requirements as stated in section II - 1.

II - 4 CONNECTING ESA SYSTEMS IN THE CLOUD

Traditionally, one can distinguishes following Cloud deployment models :

• Public Cloud : A public cloud is owned by a cloud provider and made available to the general public on a multi-tenant, pay-as-you-go basis.

• Private Cloud : A private cloud is owned and deployed by an organization for internal use as a single tenant. The “pay-as-you-go” model may or may not be used.

• Community Cloud : A community cloud is cooperatively shared by a select set of tenants, often by organizations that are related by a common industry.

• Hybrid Cloud : A hybrid cloud spans the cloud deployment models listed above, enabling applications and data to easily move from one cloud to the other.

Currently, ESA networks can be deployed in the cloud as stated in Table 1. Depending on the maturity of the Cloud services, this may change over time. The same security policy applies for ESA networks deployed in the Cloud as for networks deployed on-site, unless agreed differently with the PSSO who confirms this in writing. Similarly, the same security policy applies also for individual ESA systems and/or services deployed in Cloud as for systems deployed on-site. Until the Cloud security services mature, this policy applies to all main Cloud service models available today; i.e. SaaS, PaaS, IaaS.



Table 1 - ESA Network Deployment In The Cloud

In particular, projects and owners who consider deploying systems or services in the cloud shall assure that :

• The ESA Security Directives are adhered to – see [AD-01]. • Only ESA Unclassified data is processed and/or stored in the cloud. • The correct network classification and security level is allocated – see [AD-02],

section “ESA Network Classification” • The technical and administrative security controls are adhered to – see sections X

and XI. • Security incidents are addressed as stated in [RD-09]. • Roles and responsibilities are addressed as stated in the ESA Security Directives are

adhered to – see [AD-01]. • The Connectivity and Network Screening Security Baselines are applied unless

agreed differently with the PSSO, who confirms this in writing – see [AD-03]. The PSSO and/or system owner shall select the Cloud Service Provider (CSP) accordingly, negotiate these terms and conditions with the CSP and provide the corresponding documentation in the same way as when an ESA network, system or service would be deployed on-site.

Public Private Community HybridI DMZs

External General Purposes Networks (E-GPN)

External Project Specific Networks (E-PSN)

External Corporate Services Networks (E-CSN)

External Corporate Applications Networks (E-CAN)

External Courtesy Networks (E-CYN)

External Management Networks (E-MGT)

External Lab Networks (E-LAB)

II ISNs

Internal Corporate Office Networks (I-CON)

Internal Project Specific Networks (I-PSN)

Internal Corporate Services Networks (I-CSN)

Internal Corporate Applications Networks (I-CAN)

Internal Management Networks (I-MGT)

Internal Lab Networks (I-LAB)

III ICNs

Cloud Deployment ModelESA Network (Sub-)Type



The ESA responsible for the cloud contract needs to ask and obtain written evidence from the cloud provider(s) how security is addressed. The ESA cloud service purchasing entity shall verify that this has been adequately addressed before acquiring the Cloud service. To this end, the forthcoming “Policy for the Adoption of Cloud Computing Services in ESA” shall also apply when released. Securing ESA’s reputation and data remain an ESA responsibility. ESA systems deployed in the cloud, are subject to the same minimum security requirements as an on-site system. Systems deployed in the cloud need also to be covered with an approved Security Plan before becoming accessible. See section XI - 2.

II - 5 COLLOCATION OF ESA SYSTEMS

Some ESA systems and/or services are hosted on networks of a service provider; a typical example is the collocation of ESA web services at a web service provider. These systems are to be considered the same as an ESA system that is deployed on an E-PSN network. All security requirements stated for cloud based systems are also applicable for collocated ESA systems and services.

II - 6 CONNECTING BLADES, HYPERVISORS AND VIRTUAL MACHINES

The use of blades, hypervisors and virtual machines is sky-rocketing over the last years in ESA. The following security aspects are applicable when deploying these systems on an ESA network.

II - 6.1 CONNECTING BLADES A blade system is a combination of a number of blade servers hosted in a blade enclosure :

• A blade server is a stripped-down server computer with a modular design optimized to minimize the use of physical space and energy.

• A blade enclosure provides services such as power, cooling, networking, various

interconnects and management. It can hold multiple blade servers. The generic blade system connectivity diagram is shown in Figure 1.



Figure 1 - Generic Blade System Connectivity Diagram

Blades, on the same type of network, may span different security zones The following applies :

• Blade systems can be deployed on PSN, CSN, CAN, MGT and LAB ESA networks. They cannot be deployed on ICN or CYN networks.

• By default all blade servers shall belong to the same security zone on only one particular ESA network sub-type.

• Blade servers on the same enclosure can be connected to a DMZ or an ISN if they belong to the same project, are under the same administrative and technical responsibility while being connected to an ESA network sub-type of the same kind and security level. In this case it is necessary that traffic from the DMZ blade servers is strictly separated from the ISN blade servers; if not at ISO Layer 1 then at least at ISO Layer 2. Traffic shall remain separated at all times and shall end in the choke points for their own security zone. Here security policy enforcement and traffic screening will take place. Direct, on-blade system, interconnectivity between the blades on the DMZ and ISN is strictly forbidden.



• On-system switches shall only be used to connect the blades to the corporate network switches and to interconnect blade servers on the same blade system that belong to the same security zone.

• All security features of the built-in network switches are to be exploited. This shall be documented in the design documentation and stated in the security plans.

• The on-system switches are compatible and support ESA Network Access Control service.

• Blade management is to be performed from an E/I-MGT security zone. In the case when all blade servers of the enclosure are connected to ISN networks, management needs to be performed from a security zone on an I-MGT network. If the blade enclosure hosts blade servers that are connected to either ISN or DMZ networks, management for the blade system can be performed either from a security zone on an I-MGT network for the entire system or management can be split on E-MGT and I-MGT security zones.

• The Management Agents (MA) and Management Unit are to be connected to the security zone on the (E/I-)MGT network.

• Out of band management interfaces shall be connected to I-MGT or E-MGT network.

• If SNMP is used for management purposes, SNMP v3 is mandatory.

• The on-board DHCP service can be used only for the initial configuration and emergency boots. Under all other circumstances, every blade (sub-)system shall be registered in the ESA DNS and use fixed official ESA IP address – see sections VIII - 2, and VIII - 4.

• In case a Storage Area Network (SAN) storage solution is in combination with the blade system, it shall adhere to the security best practices stated in section VII.

• The blade enclosures and blade servers deployed on a DMZ require a security plan – see section XI - 2.

• Each blade server is to be considered as any other separate physical system and shall be subject to the same network security policy.

• The blade enclosure itself, is to be considered another separate system that is independent from the blade servers and shall also be treated as such.



Blade systems always require a PSSO who is responsible for the entire environment as stated in [AD-01]. Besides the tasks and responsibilities stated in the Security Directives, the PSSO shall also assure that a security incident capability is deployed that can interface with the ESACERT, the IT/NSM and the ESA Security Office whenever required.

II - 6.2 CONNECTING HYPERVISORS A hypervisor, also called virtual machine manager (VMM), is one of many hardware virtualization techniques allowing multiple operating systems, termed guests, to run concurrently on a host computer. In a way, the hypervisor can be considered the software counterpart of the above discussed blade systems where several systems are deployed in a single enclosure. As such, the same security controls apply – see section II - 6.1.

II - 6.3 CONNECTING VIRTUAL MACHINES A virtual machine (VM) is a completely isolated guest operating system installation within a hypervisor. It is a software implementation of a computer that behaves the same as any other physical machine. A VM is to be considered the same as any other physical server. Hence, each individual VM is subject to the same security policies and requirements as any other physical system.



III Interconnecting With ESA III - 1 THIRD PARTIES INTERCONNECTING WITH ESA

ESA’s third parties come in many forms; for example service providers, external companies who work under an ESA contract in remote location, pan-European projects where ESA is one of the contributing parties, partner Space Agencies, Universities, Research institutions, etc. Third Parties connectivity shall be limited to the agreed networks, systems and/or services as specified in the Interconnection Security Agreement (ISA) – see section XI - 6. This means that the security policy agreed in the ISA is applied to the ESA security zone(1) to which the third party connects. Likewise, at the side of the third party, no other systems, services or networks are accessible from the ESA’s security zone than the ones agreed in the ISA. The interconnected security zones must be of comparable security level. ESA’s security policies take precedence over security policies of any third party or partner. By default, third party networks and a security zone on an ESA network must be interconnected via the ESA Interconnection Network (ICN), where an interconnecting and security infrastructure is deployed; e.g. Remote Access Services, Frame Relay services, leased lines or equivalent, etc. terminated by a firewall and optional IDS – see sections III - 1.1 and III - 1.2 below. By default, the interconnection between ESA and a third party shall be screened by firewalls at both sides, unless agreed differently in the ISA. The network security policy agreed in the ISA is enforced on both these firewalls. Changes to the security policy implemented on either of these firewalls are to be documented in the ISA and approved by the signing parties. All ingress and egress traffic at the ESA side may be screened by an IDS service. If traffic is encrypted, it needs to be decrypted first. The terms and conditions of connectivity and use are to be specified in the ISA and agreed by the signing parties. Unless it concerns a trusted third party or partner, any other way to interconnect with ESA networks is not allowed. Details on the ICN are provided [AD-02].

(1) For the definition of security zones, see [AD-02]



FCI-I, in its role of ITSOA, needs to assess and approve the implementation aspects. The configuration and changes of the infrastructure deployed on that dedicated security zone are to be documented, approved by the PSSO and managed in the Corporate ISMS.

III - 1.1 THIRD PARTY INTERCONNECTION OVER SHARED NETWORK When the interconnection is established over a shared network such as the Internet, a VPN tunnel is to be deployed between ESA and the interconnecting party. The tunnel may be set up on-demand when necessary or may be used in permanent connection mode. By default, the VPN connection is initiated from ESA. However, if necessary and agreed in the ISA, the connection can also be initiated from the connecting party. The third party or partner can use the Corporate RAS services for individuals or LAN-to-LAN connections – see section IV - Figure 4. Alternatively, they may deploy their own VPN gateway and firewall on a dedicated security zone of the ESA ICN. This needs to be requested to and approved by the IT/NSM.

Figure 2 - Third Party Interconnection Over Shared Network, Using Dedicated VPN Gateways



This scenario is typically used for a trusted “integrated team” or service support setup, where interconnection of an ESA and third party security zone is required and when the cost for a trusted link is not justified or there are no other means but to use the Internet for the interconnection.

III - 1.2 THIRD PARTY INTERCONNECTION OVER TRUSTED LINK When the connection is set up over a leased line or equivalent (e.g. a Frame relay based IPVPN) the interconnection may be established over an unencrypted link if agreed between the PSSO and its peer from the interconnecting 3rd part(y)(ies).

Figure 3 - Third Party Interconnection Over A Trusted Link

This scenario is typically used for a long term trusted “integrated team” setup, where teams need to work together for an extended period of time and when there is a documented enhanced trust relationship between ESA and the third party; e.g. in the framework of space missions or a long term service contract. Examples are the numerous collaborations with partner organizations like CNES, NASA, DLR etc. or service providers who need to manage services deployed at ESA for which they are contractually responsible.



III - 2 CLOUD NETWORKS INTERCONNECTING WITH ESA

Networks and systems deployed in the cloud can be interconnected with an ESA network security zone under the conditions described in section III - 1.

III - 3 USING CONTENT DELIVERY NETWORKS FOR ESA

A Content Delivery Network (CDN) carries the content from an organization’s website to a multitude of servers strategically located around the world; e.g. ESA uses such services already for a while for its ESA web portal related services. While being and interesting service provision model for both customer and service provider, the following security measures are applicable for anyone offering ESA material to the target audience through a CDN. The use of CDN services extends the liability of ESA to the CDN. As such, the CDN shall protect ESA’s reputation in the same way as when the content would be distributed from an on-site, ESA network. The ESA Security Directives remain fully applicable, also for ESA content distributed through CDN services. An active PSSO needs to be appointed for the CDN enabled ESA service(s). The PSSO shall be interfacing between the project, the ESA ITSOA and the CDN service provider(s) for security related aspects. Besides the tasks stated in the ESA Security Directives [AD-01], the PSSO assures that :

• all material remains property of the Agency at all times • the CDN service is auditable by ESA and that in case of non-compliances, the service

provider implements the amendments requested by the ITSOA and/or the ESA Security Office.

• an effective incident management capacity is available that cooperates with IT/NSM, the ESACERT and ESA Security Office; e.g. :

o it is possible to cut the feeds to the CDN at any point in time when required. o the CDN service provider demonstrates its abilities in terms of security; e.g.

by adhering to security best practices standards, providing certifications for any of the former etc. It is the PSSO’s responsibility to verify this security posture remains in good standing over the contract period.

o the CDN service provider is able to react immediately on the request of ESA to remove the offending or copyright protected content from their CDN.

• contact and service details are known to the IT/NSM and ESACERT.



IV Remote Access ESA networks can be accessed from remote untrusted networks, using state-of-the-art Remote Access Services (RAS). At ESA one can distinguish between Corporate RAS and Project-specific RAS.

IV - 1 CORPORATE REMOTE ACCESS SERVICES

The Corporate RAS are provided by FCI-I and allow to connect to specific security zones from an untrusted network. Two types of corporate RAS scenario’s are allowed :

• Remote Access Services for authorized individuals • Remote Access Services for LAN-to-LAN connections

The applicable generic architecture is depicted in Figure 4.

Figure 4 - Generic Corporate Remote Access Services



Note that the RAS can be used to securely connect to specific security zones on DMZ’s or ISN’s. The corporate RAS are deployed on their own security zone on the InterConnection Network.

IV - 1.1 REMOTE ACCESS SERVICES FOR INDIVIDUALS The Remote Access Services for individuals are known as EVPN services. Authorized, remote users can access specific ESA security zones through the EVPN Services. The conceptual diagram is shown in Figure 5.

Figure 5 - Corporate RAS For Authorized Individuals

I-MGT RAS Security Zone

E-MGT RAS Security Zone

I-PSN RAS Security Zone

I-CAN

I-CSN

I-CON

I-PSNE-MGT

I-MGT

I-CON RAS Security Zone

ICN

Internet



Remote users can be anyone who has been authorized by their ESA management. The users may be permanently or occasionally require remote access for the agreed period.

IV - 1.1.1 EVPN ENDPOINTS The EVPN endpoints are :

• The remote user’s computing platform : This may be any type of modern computing platform that is compatible with the Corporate EVPN services. The computing platform must be patched to the latest security level. If commercially available, it must be protected with anti-malware and a host-based firewall. For the EVPN profiles that require it, the user’s computing platform shall be able to install and run an EVPN client software provided by ESA. In case the platform has a VPN client installed that is compatible with the EVPN service, it is allowed to use it as long as it is configured in the same way as the corporate EVPN client. User computing platforms may be screened for anti-malware services running, security patches applied and an active host-based firewall. Systems and VPN clients that are not in line with the corporate requirements shall not be able to connect to the ESA networks. The computing platform and software configuration requirements for using the EVPN are subject to change which is driven by imminent risks, implementation and technology changes.

• The EVPN RAS concentrator The EVPN RAS concentrator shall be deployed on the Corporate RAS security zone on the ESA ICN. It may be located on-site or on a trusted partner network of an appointed ESA Service Provider. It shall be separated from any other possible interconnection infrastructure deployed in other security zones deployed on the ICN. Connections and security events shall be logged locally and on central log server. The EVPN RAS concentrator shall always be set up, configured, patched and run according to best security practices.

Centrally managed systems connected via the EVPN services shall be managed and patched in the same way as their peers connected to on-site networks. Likewise all security updates for anti-virus, host based firewall or any other security enforcement solution as well as related security policy updates shall implemented on the centrally managed EVPN client when connected via the corporate RAS; i.e. the corporate RAS shall assure that this can be accomplished.

IV - 1.1.2 EVPN AUTHENTICATION Any client connecting to the ESA networks via the EVPN RAS, is required to successfully authenticate on the EVPN RAS Concentrator.



The EVPN RAS requires a strong authentication mechanism to connect to ISNs; e.g. hardware tokens, certificate based authentication, grid-based authentication etc. The only authentication mechanisms allowed and implemented will be the one(s) accredited by the ESA Security Office.

IV - 1.1.3 EVPN ENCRYPTION The Corporate RAS for individuals needs to implement state-of-the-art and up-to-date VPN technologies; e.g. IPSec, SSL based VPNs. All traffic passing through the VPN tunnel must be encrypted; e.g. simple transport mode tunnel is not allowed. Inadequate key lengths and encryption algorithms are to be avoided – see [RD-04].

IV - 1.1.4 EVPN TARGET SECURITY ZONE CONNECTIVITY When the remote client uses the EVPN to connect directly to the ESA networks, it becomes part of an ESA Network that is of the same type as the target security zone. As shown in Figure 5, the EVPN user can become part of :

• The I-CON RAS Security Zone This is the default security zone for all users who have a need to connect to corporate office services or applications. Most ESA users who have a need to work from remote location will be configured to connect to this RAS security zone.

• The I-MGT or E-MGT RAS Security Zone Third parties who have a need to remotely manage systems and services will be configured to connect to this RAS security zone.

• The I-PSN RAS Security Zone Projects with a need to connect mobile and/or remote collaborators to their Internal Project Specific Network (I-PSN) can be configured to connect to this RAS security zone.

By default, an EVPN user can be configured to connect to only one RAS security zone. If the remote user has a need to access multiple types of protected ESA networks from remote, the need shall be raised to their PSSO. The latter decides how to address the network connectivity need, without extending the security baseline services described in [AD-03]. See also section IV - 1.1.5. When connected via the EVPN, the client device shall be disconnected from any other network. For instance, it is not allowed to connect to the EVPN :



• When connected to another network via split-tunneling • While simultaneously being connected via 3 or 4G networks, Bluetooth, IrDa,

ZigBee, DECT, PSTN, etc. Permanent connections via these EVPN RAS are not allowed. They are intended for on-demand use only when there is an active need for it.

IV - 1.1.5 AUTHORIZATION TO ACCESS SYSTEMS AND SERVICES The EVPN RAS services limit the connectivity to a predefined set of services that are a common requirement for all users of the same RAS Security Zone. The baselines are stated in [AD-03]. When these remote users have additional connectivity needs that exceed the security baseline for their EVPN security zone, they shall access them through a controlled jump-host on which they have authorization to log on and use the services to access the required services. This may be through a VDI solution (e.g. Citrix) or via a dedicated system. FCI-I may deploy such a solution on a specific I-CSN security zone if there is a critical mass and the available resources.

IV - 1.2 LAN-TO-LAN REMOTE ACCESS SERVICES LAN-to-LAN connections via the Corporate RAS can be set up when authorized by the IT-NSM. The concept and security policy is the same as described in section III - 1. This type of RAS is usually restricted to service providers and project management support from a remote location under coverage of the contractual agreement for the services to be delivered.

IV - 2 PROJECT-SPECIFIC REMOTE ACCESS SERVICES

In case a project has a need to interconnect to a remote party, in a way that is not supported by the corporate network services, a project may deploy its own RAS on a project-specific security zone on the ESA ICN under the same conditions as stated in section III - 1. At the ESA side, connectivity from the remote side to ESA shall be limited to the I-PSN or E-PSN only. The concept and security policy is the same as described in section III - 1.



An Interconnection Security Agreement (ISA) is mandatory – see section XI - 6. The security policy applied on the Project-specific RAS is the one specified in the traffic matrix in the ISA. It is not allowed to use the Project-owned RAS setup to circumvent corporate security measures. All changes and operations are under supervision and approval of the PSSO. FCI-I, in its role of ITSOA, shall be in the position to audit the environment at any point in time. Likewise, in case of security incidents, increased risks, unauthorized use, etc., FCI-I shall always be in the position to shut down the Project-owned RAS. The PSSO shall assure that this aspect is an agreed section in the ISA.



V Mobile Offices And Launch Campaigns V - 1 CORPORATE MOBILE OFFICES

The Mobile Office Services are meant to offer all basic corporate office services on a remote location, usually in order to support an ESA Ministerial Conference or a launch campaign. All mobile office equipment is confined to a movable rack. The IT services offered include, messaging, printing, file sharing, backup, directory services, Internet access, local wireless services, LAN-to-LAN connectivity to the I-CSN and I-CAN.

Figure 6 - ESA Corporate Mobile Office Connectivity

ICN

I-CSNI-CON E-CYN

DMZs

ISNs

ISN DMZ

Internet

ESA Mobile Ofice



The networks implemented in the corporate Mobile Offices are to be considered as off-site ESA networks. The following security zones shall be implemented :

• Off-site I-CON • Off-site I-CSN • Off-site E-CYN

(See [AD-02] section “ ESA Network Security Model”.) If not physically separated at ISO Layer 1, these networks shall at least be separated logically at ISO Layer 2. The I-CON and I-CSN networks shall be linked up with a VPN link to the ESA ICN. All systems and services shall be designed, configured, operated and maintained as their on-site counter parts. Security event logging is to be enabled on mobile offices in the same way as on their on-site counterparts and duplicated on the central logging service. The log information shall be integrated in the corporate SIEM and events of the mobile office shall be correlated with the rest of the logging data.

V - 2 LAUNCH CAMPAIGNS

Launch campaigns may require a dedicated mobile office environment that deviates from the corporate one and even be designed, configured, operated and maintained by a dedicate launch campaign team. By default the same security best practices apply as the ones stated above in section V - 1. However the customized Launch Campaign Mobile Office is subject to the following additional security requirements :

• A PSSO shall be appointed and act as the single interface to FCI-I, the IT/NSM and the SAA.

• The customized mobile office design shall be documented and contain at least a

detailed design document, an SSRS, a network and service diagram, a traffic matrix stating the Network Screening Security Baselines and its SECOPS.

• The documentation shall be approved by the PSSO and assessed and agreed by the

IT/NSM.



The same ESA network reference architecture as described in [AD-02] shall be adhered to. As any other ESA network, it is subject to the ESA network security policy framework stated in [AD-02].



VI Physical Access Control Services As required by the ESA Security Directives, physical access control is to be implemented such that people only can access the physical on-site security zones for which they are authorized. A PSSO shall be appointed for these services. Only PSSO approved systems and services shall be connected to the dedicated security zone for the Physical Access Control Services. The IT infrastructure of the Physical Access Control Services shall be deployed on their own security zone on the I-CSN. If not physically separated at ISO Layer 1, these networks shall at least be separated logically at ISO Layer 2 from other security zones on the I-CSN. Similarly, management of this environment is to be deployed on its own network security zone on the I-MGT. It shall be logically separated from any other management security zone. As is the case for all Corporate Services Networks (CSNs), the physical access control services networks shall not host end-user devices. All systems used for physical access control services are subject to [AD-01], [AD-02], [AD-03] and these “Best Practices”.



VII Storage Area Networks (SANs) A storage area network (SAN) is a dedicated network that provides access to consolidated, block level data storage. SANs are primarily used to make storage devices, such as disk arrays, tape libraries, and optical jukeboxes, accessible to servers so that the devices appear like locally attached devices to the operating system. When used in ESA, they host Terabytes if not Petabytes of data. The cost for acquiring such environments is significant and often does not allow deploying a separate SAN infrastructure for different security zones in order to match the ESA Network Reference Architecture, presented in in [AD-02] section “ESA Network Reference Architecture”. The following deployment modes are distinguished and discussed below :

• Single SAN – Single Security Zone Connectivity • Single SAN – Multi Security Zone Connectivity

VII - 1 SINGLE SAN – SINGLE SECURITY ZONE CONNECTIVITY

“Single SAN – Single Security Zone Connectivity” refers to the situation where a single SAN infrastructure is used to serve servers connected to same security zones. SANs of this type can be deployed under specific conditions on a security zone on following networks :

• E-PSN, I-PSN • E-CSN, I-CSN • E-CAN, I-CAN • E-MGT, I-MGT

The security requirements for such a deployment are summarized below. Data Stored On The SAN The “Single SAN – Single Security Zone” approach can be used to store a mixture of data of classes :

• “ESA Unclassified - For official use” • “ESA Unclassified - Releasable to the Public” • “ESA Unclassified - For internal use”

The following data classes shall not be stored on such a SAN :



• “ESA Classified Information” SAN Architecture When the SAN is running Fibre Channel Protocol (FCP) or Fibre Channel over Ethernet (FCoE), the reference architecture to be used is as shown Figure 9.

Figure 7 - “Single SAN – Single Security Zone” running FCP or FCoE

The SAN is to be secured as stated in the rest of this section. When the SAN is running over IP (iSCSI, FCoIP), the reference architecture is as shown in Figure 10. In this case, a screening device (e.g. a firewall) is to be deployed on the SAN side. This screening device is considered part of the SAN infrastructure and shall be configured according to the agreed baseline which is specified in the SECOPS of the SAN infrastructure. The security screening baseline shall be approved by the PSSO. This SAN infrastructure shall be deployed on its own security zone. The common security requirements applicable to all SAN situations are listed below.

IP

FCP or FCoE



Figure 8 – “Single SAN – Single Security Zone” running iSCSI or FCoIP

Use Of Fibre Channel Security Protocols Apply Fibre Channel Security Protocols (FC-SP) for :

• Device Authentication • Per Message Security • Policy Distribution

See [RD-05]. LUN Masking LUN masking shall be implemented. Note however that this is just one level of the security mechanisms to be applied to secure SANs. It provides SAN segmentation (is similar to VLANs in Ethernets) and maps LUNs to World Wide Names (WWNs). As such it provides a simple basic level of security and is to be used to avoid that one Operating System sees SAN LUNs that are not theirs and/or monopolize the other LUNs or even the entire SAN. LUN masking is easily circumvented if not properly implemented (e.g. when implemented on Host Bus Adaptors (HBA), it increases chances for WWN guessing/spoofing). Hence additional security measures are required. LUN Mapping LUN mapping shall be implemented.

IP

FCP or FCoE



LUN mapping is another level of the security mechanisms to be applied to secure SANs. LUN Mapping (or persistent binding) is the mapping of a FC device into an Operating System at a specific device location. Hard Zoning Hard / port zoning shall be implemented. Hard zoning is a next level of the security mechanisms to be applied to secure SANs. It is used as a segmentation mechanism which is enforced in hardware. I.e. the device is identified by its port number on a SAN switch and only permits data exchange between switch ports that are configured to be in the same zone. Access to a zone is granted based on physical SAN switch port number, not on a WWN. Single Initiator Zones Single-initiator zones shall be configured. Single Host Bus Adaptor (HBA) zoning improves security and helps contain Registered State Change Notifications (RSCNs). It allows for easier SAN management and is less prone to disruption. When using single initiator zones, each zone should have only one host. Separate zones shall be used for tape and disk traffic when an HBA is carrying both types of traffic. Default Zoning Default zoning is mandatory. When applying default zoning, any host that is not allocated an active zone is dropped in a default zone. This avoids the “wide-open SAN problem”, as other hosts do not see hosts in the default zone. Zone Overlap Zone overlap is not allowed. Soft Zoning Soft zoning is not allowed. When using soft zoning, segmentation in zones is enforced through software. It uses simple name services in fabric to map WWNs to zones allowed. It results in the same security problem as for LUN masking; i.e. WWN guessing/spoofing can be used to gain access to a segment/zone.



Authentication Secure authentication of systems joining the fabric is mandatory. The fundamental problem with Fibre Channel is that it has no authentication mechanism between devices, meaning that attackers can join the SAN by spoofing and session hijacking. See also [RD-05]. SAN Management SAN management shall be performed from an approved I-MGT security zone. Management traffic cannot cross security zones unless screened. All management traffic is to be encrypted (web configuration, SSH, SNMP, etc.). Multilevel passwords are necessary. Use of certificates is desirable instead of passwords. Management protocols shall be locked down to the bare minimum. Management ACLs are mandatory and shall limit access to the authorized systems only. Fabric defaults for usernames and passwords shall be modified to a strong alternative. Access to SAN management station(s) shall be strictly limited and logged. SAN Configuration And Access Remote access to the SAN fabric shall be disabled by default. All Ethernet NICs on SAN components shall be placed in the allocated MGT security zone for the SAN. Unused SAN switch ports shall be disabled and physically locked. Port types shall be locked such that for instance “Node Ports” (N_Ports) cannot become a “switch Expansion Ports” (E_Ports). Port Level ACLs are mandatory to lock down access to the intended devices only. Following SAN Fabric security features are to be configured in the secure mode stated here or as per latest up-to-date security recommendation of the vendor :

• DH-CHAP • SSHv2 (using AES, 3DES, RSA) • SSL (using AES, 3DES, RSA) • HTTPS (using AES) • SNMPv3 • FC-SP • FC routing not used • Secure RPC • Secure file copy (SCP) • Telnet disable • Telnet timeout • IP filters (block listeners) • Secure passwords (centralized control via RADIUS/CHAP)



• Multiple User Accounts (MUAs),up to 255 • Role-Based Access Controls (RBACs) • Administrative Domains/Virtual Fabrics • Boot PROM password reset • Password hardening policies • Upfront login in Web Tools • Login banner • Monitoring of attempted security breaches (via audit logging) • Monitoring of attempted security breaches (via Fabric Watch Security Class) • Fibre Channel security policies: DCC and SCC • Trusted Switch (FCS) for central security management • Management access controls (SNMPv3,Telnet, FTP, serial port, front panel) • Hardware-enforced zoning by WWN and/or domain/port ID • Default zoning • RSCN suppression and aggregation • Configurable RSCN suppression by port • NTPv3 (to synchronize timestamps) • Event auditing • Change tracking • Firmware change alerts in Fabric Manager • Persistent port disable • Persistent domain ID • E_Port disable • On and Off-system logging (to a central log server)

Change Management Devices shall be attached to or removed from the SAN switch port after documented and traceable PSSO authorization only. Likewise, all changes to the SAN architecture, infrastructure, configuration must be agreed with the PSSO. Up-to-date configurations as well as all previous configuration versions shall be stored off-line and shall be available for review by authorized ESA security staff. All changes shall be documented in a change log document. SAN Fabrics Only fabrics of the same vendor shall be connected to each other (compatibility, interoperability and configuration mistake issues, which in turn lead to security issues). Only fabrics that can support these SAN security baselines can be used.



Mandatory Security Documentation The SANs deployment shall be covered with an approved SSRS, SECOPS and a Security Plan prior to deployment. These documents are to be approved by the PSSO. All documents shall be kept up to date across life cycle of infrastructure. They shall be available at any time to the PSSO and authorized security staff. Auditing The SAN environment may be audited at any time by an FCI-I appointed auditing entity.

VII - 2 SINGLE SAN – MULTI SECURITY ZONE CONNECTIVITY

“Single SAN – Multi Security Zone connectivity” refers to the situation where a single SAN infrastructure is used to serve servers connected to different security zones and possibly even on different network (sub-)types. SANs of this type can be deployed under specific conditions across following networks :

• E-PSN I-PSN • E-CSN I-CSN • E-CAN I-CAN • E-MGT I-MGT

The conditions that shall be met to be eligible for this kind of deployment are summarized below.



Data Stored On The SAN The “Single SAN – Multi Security Zone” approach can be used to store a mixture of data of classes :

• “ESA Unclassified - For official use” • “ESA Unclassified - Releasable to the Public”

The following data classes shall not be stored on such a SAN :

• “ESA Unclassified - For internal use” • “ESA Classified Information”

SAN Architecture When the SAN is running Fibre Channel Protocol (FCP) or Fibre Channel over Ethernet (FCoE), the reference architecture is as shown Figure 9.

Figure 9 – “Single SAN – Multi Security Zone” running FCP or FCoE

The SAN is to be secured as stated in the rest of this section. When the SAN is running over IP (iSCSI, FCoIP), the reference architecture is as shown in Figure 10. In this case, a screening device (e.g. a firewall) is to be deployed on the SAN side. This screening device is considered part of the SAN infrastructure and shall be configured according to the agreed baseline which is specified in the SECOPS of the SAN

IP

FCP or FCoE



infrastructure. The security screening baseline shall be approved by the PSSO. This SAN infrastructure shall be deployed on its own security zone.

Figure 10 - “Single SAN – Multi Security Zone” running iSCSI or FCoIP

The other security requirements are the same as listed in section VII - 1.

IP

iSCSI or FCoIP



VIII Network Related Services The following security aspects of the network related services are mandatory for anyone connecting, deploying or using ESA networks. Ignoring them may have serious consequences for anyone relying on the ESA Networks and this internally as well as externally. By default, FCI-I is responsible for design, deploying, managing, operating, securing, monitoring and auditing all network related services. Under specific conditions, FCI-I may delegate some (sub-)services to a confined community – see below. This requires an agreement with FCI-I, signed by department heads, and an SSRS that is agreed by the IT/NSM and approved by the SAA. All services shall be covered with an SSRS, that includes network diagrams, a traffic matrix, authorized user community, SECOPS and a policy and applicable corresponding guidelines. These documents shall be kept up-to-date. The PSSO shall validate and approve these documents. They shall be stored in the corporate ISMS and audited according to the ISMS governance policy.

VIII - 1 NETWORK PROTOCOLS

At OSI Layer 3 (network layer) and above, the TCP/IP protocol suite is the only protocol suite allowed and supported on ESA networks for data transport (2). Obviously, OSI Layer 2 (data link layer) and Layer 1 (physical layer) are required to support the TCP/IP protocol suite, but they shall be considered transparent for the users. As long as the protocols are compatible with the ESA network infrastructure standards and approved by the PSSO, they are allowed. IPv4 is currently the main communications protocol to transmit datagrams on the ESA networks. IPv6 is currently being investigated. The ESA user community shall not use IPv6 on their computing platforms until further notice. ESA Network Service Providers are allowed to use and deploy IPv6 at the external edge of the ESA networks to provide IPv6 interconnectivity when approved by the ITSOA. User graded OSI Layer 2 or 1 protocols, like Bluetooth, IrDA or similar, are allowed in a Personal Area Network (PAN) constellation, where systems participating in the PAN are disconnected from any other ESA network. Native use of corporate graded OSI Layer 2 (data link layer) or Layer 1 (physical layer) protocols for data transport is reserved for ESA network service providers to implement

(2) Note that this includes also ICMP and the IPSec protocol suite.



ESA interconnections. It concerns protocols like MPLS, FDDI, ISDN, PSTN, ATM, SDLC, Frame Relay, X25, SONET/SDH, etc. The protocols used are to be determined according to the need. The PSSO shall approve the use of these protocols and the implementation. Requirements, deployments and use of any other network protocol shall be requested to and assessed by the IT/NSM. The SAA shall approve the use of the protocol in ESA.

VIII - 2 IP ADDRESSING

ESANIC is the only authority in ESA to interface with external Internet authorities to request, amend and hand back public address space for ESA networks. The ESA IP address plan for all ESA networks, is designed, used, managed, deployed and monitored by FCI-I. By default, FCI-I has appointed the ESA Network Services team as the single entity in ESA who is responsible for managing, assigning and handing out IP addresses to be used on ESA networks. This holds for both public and private IPv4 address space. Currently only IPv4 address space is supported and handed out to the ESA user community. When IPv6 is validated and ready for use within ESA, users shall be able to request and use also IPv6 address space. Users shall request their public or private IP address space to the Corporate Service Desk. Users, projects or departments shall not assign their own public or private IP address space ranges, nor request new public address space from an Internet Authority like e.g. Internet Assigned Numbers Authority (IANA), any of the Regional Internet Registries (RIPE, ARIN, APNIC, AFRINIC, LACNIC) or an Internet Service Provider (ISP). Users shall return IP addresses and address ranges to the Corporate Service Desk when there is no system or service using them. An ESA IP addressing plan, policy and corresponding guidelines shall be created and made available to the ESA community on the Corporate IT Service Portal after validation and approval of the ITSOA. These documents shall be kept in the Corporate ISMS and audited according to the ISMS governance policy.

VIII - 3 ESA DOMAIN NAMES

ESANIC is the only authority in ESA to interface with external Internet authorities to request public top and second level domain names for ESA. Users shall request all their domain names to the Corporate Service Desk. They shall not interact with Internet authorities to obtain their domain names; e.g. with ICANN or any ISP.



The Corporate Service Desk mediated between the user and the ESANIC. Users shall inform the Corporate Service Desk when a domain name is no longer required.

VIII - 4 DOMAIN NAME SERVICES (DNS)

DNS services for ESA are under the single authority and responsibility of FCI-I. Only FCI-I approved DNS servers shall be connected to the ESA networks. It is recommended to deploy and run rogue DNS server detection services that are able to disconnect these rogue servers automatically from the ESA networks. All ESA DNS services shall be configured according to authoritative security guidelines. It is desirable to implement DNSSEC for all ESA internal and external DNS services. Zone transfers should be digitally signed. DNS services should run in split mode; i.e. from external networks such as the Internet, one will obtain only name resolution for ESA systems and services that are explicitly intended to be visible from these networks. For ESA systems and services that are not to be known on external networks, DNS resolution needs to be confined to the ESA networks only. Corporate DNS services shall be deployed on the security zone dedicated to DNS, NTP and DHCP services. Corporate master DNS servers need to be deployed only on an I-CSN security zone. Corporate slave DNS severs are to be deployed on the dedicated security zones of the I-CSN or E-CSN. (See also [AD-02] Section “Default Security Zones”.) The only exception to this, are the ESA Windows Active Directory DNS services, which may be deployed on the same security zone as the one where the rest of the Windows Active Directory services are hosted. Master servers for 3rd or lower level ESA domains for which FCI-I has delegated administration shall be deployed on their own I-PSN security zone. Corresponding slave DNS servers can be deployed on their own I-PSN or E-PSN security zone. The scope of DNS zones for which FCI-I has delegated administration shall remain within its own I- or E-PSN. If visibility of the zone is required outside its PSN, the zone needs to be slaved on the corporate DNS servers. The scope and visibility of DNS zones deployed on DNS servers connected on an E- or I-LAB network security zone remains confined to that specific security zone.



Only the corporate DNS servers deployed on the E-CSN DNS security zone are allowed to perform name resolution for non-ESA domains. All other authoritative ESA DNS servers shall forward their queries to these corporate E-CSN DNS servers. The security baselines will enforce this requirement. Any system connected to the ESA networks shall obtain DNS service resolution from authoritative ESA DNS servers only. The ESA DNS servers to be used by the other ESA systems and services will be made available to the ESA user community on the Corporate IT Service Portal. Departments and projects that run DNS services for their own local community on third or lower level domains are required to meet these same security requirements as the corporate DNS services.

VIII - 5 AUTOMATIC NETWORK CONFIGURATION (DHCP)

DHCP services for ESA are under the single authority and responsibility of FCI-I. Only FCI-I approved DHCP servers can be connected to the ESA networks. Rogue DHCP server detection and automatic disconnection capabilities are required on the ESA networks. All ESA DHCP services must be configured according to authoritative security guidelines. Corporate DHCP servers are to be deployed only on the I-or E-CSN security zone that is dedicated to DNS, NTP and DHCP services. (See also [AD-02] Section “Default Security Zones”.) Corporate DHCP services are offered to I-CON and E-CYN networks only. Projects may deploy DHCP services on their own PSN or LAB security zones as long as they are approved by the PSSO and remain strictly confined to that security zone. On all other ESA networks fixed IP addresses shall be used. ESA Active Directory DHCP services shall be offered to the I-CON only. It shall always be possible to perform a real-time tracing of an active system on the network that received a DHCP address. The trace-back needs to allow for identifying the physical and logical connection as well as the location and name of the owner of the system. All relevant information to perform this trace-back must be available to FCI-I and ESACERT in real-time. Logs are to be kept on the DHCP server(s) as well on a central logging infrastructure for the minimum time set by the IT/NSM.





VIII - 6 TIME SYNCHRONIZATION SERVICES (NTP)

NTP services for ESA are under the single authority and responsibility of FCI-I. Only FCI-I approved NTP servers can be connected to the ESA networks. It is desirable to deploy rogue NTP server detection and automatic disconnection capabilities on the ESA networks. All ESA NTP services shall be configured according to authoritative security guidelines. Corporate NTP servers must be deployed only on the I-or E-CSN security zone that is dedicated to DNS, NTP and DHCP services. (See also [AD-02] Section “Default Security Zones”.) Corporate NTP services are offered to all ESA networks, except the CYN. ESA Active Directory NTP services can be offered to the I-CON and the I-CSN Windows Active Directory security zone only. All systems connecting to CSN, CAN, PSN and ICN networks must be time synchronized. The only exceptions are systems for which there is no NTP agent available on the market. However, every effort shall be made to deploy systems on ESA networks which can be time synchronized. By default all systems synchronize with the corporate Stratum 2 NTP servers. Only systems with a specific need for higher timing accuracy can synchronize with the Corporate Stratum 1 servers. The PSSO shall request authorization to synchronize with the Corporate Stratum 1 NTP servers to the IT/NSM. The Corporate NTP servers to be used by the ESA community will be published on the Corporate IT Service Portal. Logs are to be kept on the NTP server(s) as well on a central logging infrastructure for the minimum time set by the IT/NSM.

VIII - 7 ROUTING

Network traffic routing for ESA network services is under the single authority and responsibility of FCI-I. ESANIC is the only authority in ESA to interface with external Internet authorities to request, amend and hand back Autonomous System numbers and related Internet routing entries for ESA.



Only FCI-I authorized routers and routing processes shall be deployed on the ESA networks. Rogue routers, routing traffic detection and automatic disconnection capabilities may be deployed on the ESA networks. All ESA routing services shall be configured according to authoritative security guidelines or any up-to-date vendor specific security guidelines. By default, routing shall only be enabled on dedicated devices (routers, layer 3 switches or firewalls) that are located in the core, at the edge or between different security zones. In a virtualized environment, routing may be enabled as long as it is under FCI-Is central management. Routing shall not be enabled on general purpose servers and/or operating systems. Deviations from this default needs to be approved by the PSSO and the SAA. Apart from the centrally managed routing services, it is not allowed to deploy routing services on ESA networks and/or interact with the ESA network routing schemes. Routing between the network sub-types is to be implemented and enforced according to the routing security baseline described in [AD-03] – Annex I.



IX Service Deployment On ESA Networks This section addresses the security aspects for critical or common services deployed on ESA networks.

IX - 1 DIRECTORY SERVICES

One can distinguish two main categories at ESA :

• Corporate Directory Services • Project-specific Directory Services

Both are discussed below.

IX - 1.1 CORPORATE DIRECTORY SERVICES These Directory Services are under the single authority and responsibility of FCI-I. Currently there are following Corporate Directory Services:

• ESA Internal Directory Services like the ESA Active Directory and Lotus Notes • ESA Pubic Directory Services like NAM (formerly known as DAM) to support the

Corporate Application (e.g. ESA-P, EMITS, Flexitime, etc.) Other corporate directories may be set up and/or derived from the above over time, in order to support other services like FTP service, collaboration and unified communication services, certificate related services, etc. These directory services store sensitive data such as user logon credentials, systems, authorization to use certain services etc. As such, they are to be treated with extreme care. All ESA Directory Services shall be configured according to authoritative and up-to-date security guidelines. On the server site, master directories shall be deployed on an appropriate I-CSN or I-CAN security zone only. (Sub-) Directory trees can be replicated in read only mode on a dedicated security zone on the E-CSN or E-CAN. (See also section [AD-02] Section “Default Security Zones”.) Network-wise, on the client side, the ESA corporate directory services are accessible from all networks, but not all data of all directories will be available on all ESA networks. See Table 2 for an overview. This means that access restrictions need to be set up, sub-trees



and/or sub-directory services may be required at Directory Services level to meet these requirements.

Table 2 – Accessibility To Specific ESA Directory Data Types From The ESA Networks

Notes :

• “Public” data in the ESA Directory Services, refers to directory entries that need to be accessible to any subscriber of the service for which the Directory Services are used, irrespective its location or network. These entries can be entered ad-hoc and may be ESA related or may be from partners, external users or systems etc.; examples can be X509 certificates of ESA users and external collaborators, credentials of ESA Public Relation Officers and external press attachés to access the ESA public FTP services, etc.

• “ESA Internal” data in the ESA Directory Services, refers to directory entries that are

restricted to ESA only. A typical example is the entries in Windows Active Directory that hold credentials for ESA users to log on the ESA Windows Domain, or to obtain network access on wired and wireless network services, etc.

Public ESA Internal CommunityI DMZs

External General Purposes Networks (E-GPN)

External Project Specific Networks (E-PSN)

External Corporate Services Networks (E-CSN)

External Corporate Applications Networks (E-CAN)

External Courtesy Networks (E-CYN)

External Management Networks (E-MGT)

External Lab Networks (E-LAB)

II ISNs

Internal Corporate Office Networks (I-CON)

Internal Project Specific Networks (I-PSN)

Internal Corporate Services Networks (I-CSN)

Internal Corporate Applications Networks (I-CAN)

Internal Management Networks (I-MGT)

Internal Lab Networks (I-LAB)

IV ICNs

ESA Network (Sub-)Type ESA Directory Services Data Type



• “Community” data in the ESA Directory Services, refers to directory entries that are limited to a specific community; e.g. a collaboration team with users from ESA and external 3rd parties and partners.

The protocol used to interface with the directory services shall be encrypt traffic end-to-end in order to assure authenticity, confidentiality and integrity; e.g. LDAPS.

IX - 1.2 PROJECT-SPECIFIC DIRECTORY SERVICES Project specific Directory Services are under the authority and responsibility of the project. A PSSO is required before one can deploy project specific Directory Services. Project specific Directory Services shall be deployed on their own PSN security zone. In case it concerns a service for a wider community, the Directory Services can be hosted on a security zone on the I-CSN or I-CAN. The remainder of the security requirements are the same as for the corporate Directory Services.

IX - 2 MESSAGING SERVICES

Messaging services include E-mail and any form of corporate instant messaging services. All ESA messaging services shall be configured according to authoritative and up-to-date security guidelines. Corporate messaging servers shall be deployed on an I- or E-CSN security zone only. (See also [AD-02] Section “Default Security Zones”.) Messaging services are offered to all ESA networks. By default, all messages to or from the Internet shall be routed through a single ESA external messaging gateway service under FCI-I’s control. Deviations can be granted in case the alternative messaging gateway service has the same or better security controls and operations in place than the corporate services. All messages intended for ESA internal use, shall be routed through a single ESA internal messaging gateway service under HFI’s control. All messages (mail and instant messages) shall be screened for malware and spam, both for inbound and outbound messages. All threats shall be stopped and removed at the ingress server of the message.



All client systems shall authenticate to the messaging servers before they are allowed to exchange messages via any ESA messaging server. Authentication details and credentials shall always be encrypted. Departments and projects that have obtained FCI-I clearance to run their own messaging services, are required to meet these at least the same security requirements as the corporate ones stated above.

IX - 3 COLLABORATION SERVICES

Corporate collaboration services are under the single authority and responsibility of FCI-I. Other collaboration services are under responsibility of the department who deploys them. Only PSSO approved collaboration servers shall be connected to the ESA networks. All collaboration services shall be configured according to authoritative and up-to-date security guidelines. On-site corporate collaboration servers shall be deployed only on CSN security zones. (See also [AD-02] Section “Default Security Zones”.) Other on-site collaboration servers shall be deployed only on PSN security zones. Collaboration services may also be deployed on the cloud as long as they meet the equivalent of the corporate security policies. Corporate collaboration services that are restricted to the ESA user community only, shall be offered to clients located on I-CON networks only. Corporate collaboration services that are open to a wider community shall be offered to clients located on I-CON, E-CYN and PSN ESA networks or the Internet. All users of any ESA collaboration service shall authenticate successfully to the service. All authentication traffic shall be encrypted end-to-end with state-of-the art encryption technology. Authentication methods that have proven to be broken shall be replaced. On-site corporate collaboration services shall use ESA Directory Services and authentication servers deployed on the E-CSN or the I-CSN. Other collaboration services may use the corporate directory services and/or authentication services under the conditions agreed with FCI-I. In case non-corporate directory services are used, directory services and authentication servers are to be deployed on their PSN(s). When using commercial cloud-based collaboration services such as WebEx, the Directory and authentication services shall be agreed by the PSSO.



All collaboration services traffic shall always be encrypted , using state of the art encryption technology; e.g. HTTPS, any SSL/TLS protected protocol, IPSec etc. This is true for both the front-end (client) as the back-end (database/data store) related traffic. In case an on-site web-based collaboration service is offered, the server shall deploy an ESA public trusted X509 certificate to authenticate the server to the client and encrypt all traffic. Only strong encryption algorithms shall be enabled on the collaboration servers. For commercial cloud based collaboration services, such as WebEx, the PSSO shall validate and approve the use of the appropriate certificates and encryption algorithms. Instructions on how to securely connect and use the collaboration services shall be made available to the ESA user community on the Corporate IT Service Portal.

IX - 4 MICROSOFT WINDOWS DOMAIN SERVICES

Microsoft Windows Domain Services are offered to all centrally managed systems connected to the ESA I-CON. These services are under the single authority and responsibility of FCI-I. Under specific conditions some subsets of these services may be delegated to other departments – see the introduction of section VIII. Only PSSO approved Microsoft Windows Domain Services servers shall be connected to the ESA networks. All ESA Microsoft Windows Domain Services shall be configured according to authoritative and up-to-date security guidelines. Corporate Microsoft Windows Domain Services related servers shall be deployed on an I-CSN security zone only; they shall not be extended to a DMZ or beyond. (See also [AD-02] Section “Default Security Zones”.) By default, the Windows Domain Services shall be offered to the I-CON only. For Windows based Active Directory Services, see section IX - 1. In case the Corporate Microsoft Windows Domain Services, or subsets thereof are required on another ISN, the PSSO shall assess the need, seek approval from the SAA while network related aspects are to be approved by the IT/NSM. Under all circumstances, the services shall remain confined to the ISNs and shall not be deployed or offered to any other ESA network (sub-)type. Departments and projects that have obtained the clearance to run subsets of the Corporate Microsoft Windows Domain Services are required to meet these same security requirements as the corporate services. They shall deploy the services under their responsibility on their own I-PSN security zone.



IX - 5 VOICE OVER IP SERVICES (VOIP)

While VoIP technology is already in use for several years at ESA for voice link interconnections between sites, FCI-I is now investigating and planning VoIP services for end users. The latter are not operational yet. ESA users shall not deploy their own VoIP services on the ESA networks Consumer grade VoIP services available through many public services such as Skype, Facebook, MSN, Google etc., are allowed from I-CON, E-CYN and E-LAB networks, as long as they are in line with the security baselines (see [AD-03]), do not cause security incidents or affect other services running over the ESA networks. The corporate VoIP service server-side shall be deployed on an I-CSN security zone. Corresponding Directory Services and authentication services shall be deployed on an I-CSN or E-CSN security zone. (See also [AD-02] Section “Default Security Zones”.) The corporate VoIP service client side shall be restricted to the I-CON only.

IX - 6 VIDEO CONFERENCING SERVICES

Corporate Video Conference services for ESA are under the single authority and responsibility of HFI. The on-site Video Conferencing (VC) services shall be deployed on their own security zones on an E-CSN and I-CSN. (See also [AD-02] Section “Default Security Zones”.) If not physically separated at ISO Layer 1, these networks shall at least be separated logically at ISO Layer 2. The security policy on these security zones shall be enforced on dedicated VC firewalls and gateways. All security aspects of VC services acquired from an external provider, are under responsibility of the respective PSSO. These type of services shall meet at least the security level of the on-site VC services or better. ESA users shall not deploy their own video conferencing services on the ESA networks The video conferencing units deployed in meeting and video conferencing rooms shall be deployed on a separate security zone in the I-CSN networks. Video conferencing clients that participate in an ESA initiated video conference can be located at any network, even the Internet. All users shall be invited by the ESA VC meeting host. The VC participants shall be managed by a team appointed by HFI, who shall have the possibility to disconnect participants at any point in time.



ESA VC units shall be able to dial in to a video conference that is hosted by an external party. Likewise, external VC units shall be able to dial in to an ESA VC conference. The VC shall be encrypted by default. All traffic will be routed via an ESA managed VC gateway located at a dedicated security zone on the ICN. In case of malicious or abusive activities are notified, the connection shall be dropped. VC attendees who connect from their client device such as a tablet, laptop or smartphone, shall always be authenticated before they can participate in an ESA hosted video conference. All authentication traffic shall be encrypted. Their VC stream shall be proxied in a secure way to the corporate video conferencing services. The secure video gateway shall be located on a dedicated security zone on the ICN. Clients shall never interface directly with the video conferencing servers. Only HFI approved VC infrastructure shall be connected to the ESA networks. All VC services shall be configured according to authoritative and up-to-date security guidelines. Instructions on how to securely set up and connect to the corporate VC service shall be made available to the ESA user community on the Corporate IT Service Portal. Consumer grade VC services available through many public services such as Skype, Facebook, MSN, Google etc., are allowed from I-CON, E-CYN and E-LAB networks, as long as they are in line with the security baselines (see [AD-03]), do not cause security incidents or affect other services running over the ESA networks.

IX - 7 TELE-PRESENCE SERVICES

While Video Conferencing technology is already in use for several years at ESA, FCI-I is now investigating and planning the use of Telepresence for end users. The latter are not operational yet. As far as network security aspects are concerned, the same security best practices as the ones stated for Video Conferencing apply until further updates are released.

IX - 8 VIDEO STREAMING SERVICES

Corporate Video Streaming (VS) services for ESA are under the single authority and responsibility of FCI-I. These Video Streaming services shall be deployed on their own security zones on an E-CSN, I-CSN or an equivalent in the Cloud. (See also [AD-02] Section “Default Security Zones”.)



If not physically separated at ISO Layer 1, these security zones shall at least be separated logically at ISO Layer 2. The security policy on these security zones shall be enforced on VC firewalls and/or gateways. Departments or projects that run their own VS services are required to meet these same security requirements as the corporate VC and VS services. However, they shall deploy their VS servers on an E-PSN, I-PSN or an equivalent in the Cloud. Clients of the VS services can be located on any network, even the Internet. In the latter case, the VS services need to be accessible on a server located on an E-CSN or E-PSN security zone or preferably on a VS server deployed in the cloud. Authentication to participate in a VS session is recommended but not mandatory. The VS services shall be managed and ensure that participants or the entire VS session can be disconnected on the spot in case of security issues. Only PSSO approved VS infrastructure shall be connected to the ESA networks. All VS services shall be configured according to authoritative and up-to-date security guidelines. Instructions on how to securely participate to the corporate VS services shall be made available to the ESA user community on the Corporate IT Service Portal. Likewise, entities, responsible for their own VS services, shall make similar instructions available to their target audience via their own chosen channels.

IX - 9 BACKUP SERVICES

Corporate backup services are offered to clients and servers. Corporate backup services may be deployed on-site and/or off-site :

• When deployed on-site they shall be deployed on an I- or E-CSN backup security zone and shall be segregated from other security zones. (See also [AD-02] Section “Default Security Zones”.)

• When deployed off-site, they shall be hosted in the equivalent of a CSN security zone

and shall be segregated from other possible customers.



In all deployment scenarios, backup traffic shall be encrypted end-to-end using state of the art encryption algorithms, keys and transport protocols – see [RD-04]. Authorization to back up on the corporate backup services is to be requested to the Site Manager. All backup services shall be configured according to authoritative and up-to-date security guidelines. Instructions on how to securely use the corporate backup services shall be made available to the ESA user community on the Corporate IT Service Portal. Project specific backup services can be set up on an I- or E-PSN. The same security requirements as for the corporate backup services apply. When SAN technology is used for the backup services, the policy stated in section VII applies.

IX - 10 WEB SERVICES

A very common deployment on ESA networks are web based services; i.e. the services are accessible to the target community via a web browser. The server side may be as simple as a single server or may be a multi-tier server complex with distribution of tasks, logic and data across multiple systems with load balancers, proxies, web security gateways etc. This section addresses the network security requirements for the deployment of web services of the following types :

• Single server based web services • Multi-tier web services

Other security requirements such as operating system, application, data, physical security etc. are to be addressed in dedicated guidelines and are to be made available on the ESACERT web pages. See [RD-07].

IX - 10.1 “SINGLE SERVER”-BASED WEB SERVICES This type of web services refers to simple single system based web services. They are typically using popular web servers like Apache or Microsoft’s IIS with static or dynamic web pages. In the latter case they may be using one of the popular Content Management Systems such as Wordpress, Joomla or Drupal, Mircosoft Sharepoint, Oracle CM, IBM Websphere and possibly one or more databases such as Oracle, MySQL, PostgreSQL or SQLServer. All these components are combined on one system and connected to an ESA network.



The reference architecture for a typical scenario is shown in Figure 11.

Figure 11 - Reference architecture for a typical single web server deployment

Note that when the single web service is deployed on an ISN network subtype, the upper part in Figure 11 is not applicable; i.e. users from the Internet or systems on one of the ESA DMZs are not allowed to access web services deployed on ESA ISNs. The network security requirements are as follows :

• These types of web servers can be deployed on a PSN, CSN, CAN ESA network subtype. When access is confined to the local user community, they can also be deployed on a MGT or LAB network subtype. They cannot be placed on the ICN, CYN or I-CON.

E-PSN

MGTSRV

Jump Host MGTSRV

I-MGT

I-CON

Internet

MGT ClientESA Users

SingleWeb Server

External Users

Service Interface

MGTInterface



• These systems shall be placed in a “Single Server Security Zone”, meaning that they are isolated from all other systems on the same ESA network sub-type, but are accessible for their target community.

• These systems shall be covered by a security plan when deployed on an E-PSN, E-CSN, E-CAN, E-MGT network sub-type.

• The operating system and all software components on the system must remain supported by the vendor for as long as the system remains online; i.e. the vendor needs to release security patches until the web service is decommissioned. If the vendor ceases support for the product, it needs to be replaced or the web service is to be decommissioned.

• All software components shall be patched to the latest security update available.

• Service related traffic shall be run over a different network interface than management related traffic. (Note that also updates to the content and patches are considered “management related traffic”.) The former network interface is connected on the service network (e.g. PSN, CSN, CAN, LAB) while the management interface is connected on the management network (MGT).

• The system and web services shall be managed from an ESA MGT network. If the owner does not have a management system on a MGT network, an account on an FCI-I management jump host on the “Corporate IT Services Management Security Zone” shall be used. See [AD-02] Section “Default Security Zones”. Interactive management sessions directly from an end-user’s computing platform to the web server are not allowed.

• Only the intended traffic shall be allowed to and from the system. All other traffic shall be blocked on the network interfaces. Note that this holds for both the service and the management interfaces. Usually this is accomplished easiest by a host based firewall.

IX - 10.2 “MULTI-TIER” WEB SERVICES This type of web services refers to a more complex type of web service. As soon as the web services are composed of components that are distributed across two or more systems, it is considered a multi-tier web service. The typical components found in a multi-tier web service are :

• User web interface(s) • Prox(y)(ies) • Authentication server(s)



• Middleware • Application server(s) • Database server(s) • Management system(s)

All these components are to be connected to an ESA network and communicate with each other in order to make the entire web based service functional. The network security requirements are as follows :

• This type of web based services requires a PSSO.

• The correct security level for each system is to be defined – see [AD-02] section “ESA Network Classification”

• The web service functions are to be organized in tiers; usually 2 or 3 tiers are defined. Connectivity restrictions are to be taken into account when defining the number of tiers and allocating the functions to a tier :

Figure 12 - Web Service tiers and applicable traffic restrictions

• When the multi-tier web services are intended for the ESA user community only, the tiers can be deployed on an I-PSN or an I-CAN. It is recommended that the tiers are deployed on separate security zones that are protected by a firewall.

• When the multi-tier web services need to be accessible by non-ESA users, the web service tiers are to be spread over different networks; e.g. :

Users

Tier 1

Tier 2

Tier 3

Management



o Tier 1 on an E-PSN or E-CAN o Tier 2 on a separate security zone on an E-or I-PSN, E- or I-CAN o Tier 3 on a separate security zone on an I-PSN, I-CAN or ITN

In this case, the tiers must be deployed on separate security zones that are protected by a firewall

• The Font-End (FE) and Back-End (BE) firewalls are part of the web service. See Figure 13.

• Service related traffic shall be run over a different network interface than management related traffic. (Note that also updates to the web content and patches are considered “management related traffic”.) The service traffic network interface is connected on the service network (e.g. PSN, CAN) while the management traffic interface is connected on the management network (MGT).

• All systems that do not need to be accessible by the users shall use private IPv4 addresses, Link or Site Local addresses in IPv6 – see also section VIII - 2.

• Systems connected to the individual tiers are grouped in their own security zone (VLAN)

• When using a virtualized environment, virtual switches shall only be used for connectivity within the same tier and security zone.

• Routing between the tiers shall be performed on a router or Firewall. Routing shall not be performed on any other system. Routing in a virtualized environment shall be performed on an external router or firewall

• Only the intended traffic shall be allowed to and from the system. All other traffic shall be blocked on the network interfaces. Note that this holds for both the service and the management interfaces. Usually this is accomplished easiest by a host based firewall.

• The operating system and all software components on the system must remain supported by the vendor for as long as the system remains online; i.e. the vendor needs to release security patches until the web service is decommissioned.

• All software components shall be patched to the latest security update available within 2 weeks of the release.

• All systems must have a host based firewall enabled and configured to meet above requirements



• The system and web services shall be managed from an ESA MGT network. If the owner does not have a management system on a MGT network, an account on an FCI-I management jump host on the “Corporate IT Services Management Security Zone” shall be used. See [AD-02] Section “Default Security Zones”. Interactive sessions directly from a user’s computing platform to the web server are not allowed.

• Network components and Firewalls shall be managed by a dedicated (network) team; e.g. teams who are responsible for the web content, web applications, the operating systems or the hypervisor shall not manage the switches, routers or firewalls.

• In case a virtualized environment is used, the following additional requirements apply :

o Service, management and kernel traffic shall be separated in different security zones and remain separated from each other

o the service console is to be hardened and placed in the web services MGT security zone

o each security zone shall be clearly labelled in the hypervirsor o Layer 2 security options on virtual switches need to be set o separation of duties is mandatory o The virtualized configuration need to be audited periodically according to the

agreement with the PSSO. The reference architecture for a typical scenario is shown in Figure 13.



Figure 13 - Reference architecture for a typical multi-tier web service deployment

Tier 1 Tier 2

MGT

Tier 3• User Interface• Proxy

MGTSRV Jump Host MGTSRV

• Middleware• Application• Authentication

• Databases• Directory Services• Mail• Etc.

FE Firewall BE Firewall

Users

Corporate FE or BE Firewall



X Technical Network Security Controls X - 1 PHYSICAL NETWORK SECURITY

The ESA Security Directives sections on physical security are to be considered an integral part of [AD-02], [AD-03] and these “Network Security Best Practices”. See [AD-01]. All network devices shall be protected against theft, unauthorized access, use or damage. Only authorized personnel shall have access to ESA network infrastructure, equipment and services. All network equipment and cabling shall be secured with locking mechanisms. Except for specific network edge devices, agents, probes and wireless Access Points, all network and network security equipment shall be kept in a Security Zone 3 area where access is restricted to authorized personnel only. For networks of security level 5 physical location and security measures are to be agreed with the SAA. Unused ports on network switches, routers, firewalls etc. shall always be shut down. Where possible, a physical cap shall prevent connecting cables to the port. For servers, make sure that the BIOS/UEFI is protected with a non-default password. Disable and physically lock network interfaces, ports and bays not used (caps and locks). Assure that other communication channels than the wired network interface are disabled; e.g. bluetooth, WiFi, IrDA. Special attention shall be paid to the management interfaces (IPMI, ILO, DRAC, IMM, etc.). See also section X - 8. Server covers shall be locked with key. There shall be no displays, keyboards or mice attached to servers. Server cabinets and racks shall be protected with a physical or electronic lock and key. All equipment connected to the ESA networks shall be listed in an inventory list that is always kept up to date. All network equipment shall be labelled and identifiable through this label. The name on the label shall not reveal sensitive details like configuration, service etc. All vendor specified environmental and power conditions shall be met and monitored to assure proper functioning of ESA’s network infrastructure and avoid hazards. All network equipment and cabling shall meet European and county specific physical security legislation. The network infrastructure used for Level 5 networks shall be accredited by the SAA.



X - 2 NETWORK INFRASTRUCTURE

The PSSO shall authorize all site-local network equipment prior to its connection to the ESA networks. Equipment that may jeopardize any network(ed) service, shall not be authorized to connect to the ESA networks. In case of doubt, the IT/NSM or in escalation the SAA shall decide on the connection of such equipment. Examples of such equipment can be, but are not limited to : network hubs, network probes, wireless access points, BYODs, etc. Especially BYODs deserve attention as these devices may have a number of services enabled that conflict with the rest of the ESA network services without the owner realizing it; e.g. its own default DNS, DHCP, IP addressing, VLAN tagging, routing etc. This may bring down entire sites if not screened prior to connecting such a device. All network equipment shall be configured according to authoritative up-to-date security (vendor specific) guidelines. The PSSO shall always verify compliance to such guidelines. Note that this is also required for network cabling. Al configurations shall be stored in a change management database, always accessible in a readable form to authorized security staff and site managers and shall always be kept up-to-date. The physical security policy for all network infrastructure is stated in section X - 1.

X - 3 FIREWALL SERVICES

X - 3.1 SCREENING FUNCTIONALITY The firewalls screening functionality can be addressed in several ways; e.g. :

• Firewall rule compliance logging • Firewall rule compliance enforcement • Application traffic compliance logging • Application traffic compliance enforcement • User authorization compliance logging • User authorization compliance enforcement • Intrusion detection • Intrusion detection compliance • Intrusion prevention

Any combination may be applied as long as the core firewall service is not affected. It is at the discretion of the IT/NSM or PSSO to decide which firewall screening approach will be applied on the firewalls for which they are responsible – see below.



X - 3.2 OWNERSHIP By default, FCI-I is responsible for design, deploying, managing, operating, monitoring and auditing the ESA corporate network firewall services. It is also responsible for implementing and enforcing the corporate Firewall Security Baselines and SDSRs. Under specific conditions, FCI-I may delegate firewall service responsibilities to a confined community. This requires an agreement with FCI-I, signed by departments heads, and an SSRS, agreed by the PSSO. Note that in some cases, FCI-I in its role of ITSOA, will require a service or project to deploy its own Firewalls. Also in these cases the former holds. All firewall services shall be covered with an SSRS, SECOPS, and corresponding guidelines. These documents shall be kept up-to-date. They shall be stored in the ISMS and audited according to the ISMS governance policy. The user guidelines shall be made available to the ESA community on the Corporate IT Service Portal.

X - 3.3 CORPORATE FIREWALL SERVICES The Corporate Firewall Services shall implement the security model and reference architecture as described in [AD-02]. They shall also implement the security baselines as described in [AD-03]. The Corporate Firewall Services may be outsourced to a trusted third party. They may be provided on-or off-site. When implemented as an off-site Managed Firewall Security Service, the services shall be dedicated to ESA only and shall not be shared by other tenants or customers. Independent of the firewall services delivery model, it shall be assured that all firewall hardware, operating systems and firewall related software components are up to date. Firewall refresh activities shall be completed prior to End-of-Life or End-of-Support, whichever comes first. Operating Systems and firewall software shall always be updated to the latest security patches and to the latest version of the vendor. These aspects are to be contractually confirmed with the service provider and/or operational entity. All network traffic shall be screened according to the security baseline policy at the choke-points, which mark the transition from one security zone to another – see [AD-02], section “Choke Points”. Traffic shall be screened in both directions when transitioning from one security zone to another; i.e. ingress and egress traffic shall be screened for compliance with the security baselines. All network connections shall be checked for legitimate sessions; e.g. by using stateful inspection firewalls, application screening firewalls and/or authorized user screening



firewalls. Also the use of Next Generation Firewall features that allow sessions to be granted based on the authentication and authorization of the users may be leveraged from. For security and cost reasons, firewall security policies shall remain as stable as possible. I.e. the number of changes required for an implemented security zone shall be minimal. The security model and reference architecture as described in [AD-02] and the security baselines as described in [AD-03] – Annex II support this requirement. Users, projects, departments shall plan their connectivity requirements according to this security model, the reference architecture, the corresponding network security baselines; and best practices; e.g. when systems or services are deployed on a PSN security zone, a custom security baseline shall be defined. This security baseline shall be such that no SDSRs are necessary, that the firewall rules are based on the Principle of Least Privileges and do not require frequent updates. The Corporate Firewall Services may be audited periodically by an FCI-I appointed party. The scope of the audit shall be determined in order to increase security and optimize the service. The services and configuration shall be amended according to the audit findings. Examples of expected audit results can be to detect and eliminate stale, inappropriate or duplicates firewall rules, optimize firewall performance, identify imminent capacity issues, verify security policy implementation and compliance, identify new security baseline candidates, etc.

X - 3.4 PROJECT FIREWALL SERVICES When a project or limited user community has been authorized to run their own firewall services, they shall adhere to the same security policy and requirements as the corporate firewall services. The PSSO is responsible for these project firewall services when it concerns screening of inter-PSN and PSN-Internet related traffic. However, for other traffic, a request to the IT/NSM needs raised and IT/NSM approval is required.

X - 4 APPLICATION GATEWAY SERVICES

Firewall services are a default security control for many years. However, due to fact that attacks are performed not only at Layer 2, 3 and 4 of the OSI network model, but more and more above these traditional layers, up to applications at Layer 7, application gateways become more relevant to fill these gaps to mitigate these threats.

X - 4.1 SCREENING FUNCTIONALITY The same policy as for the firewall services applies – see section X - 3.1.

X - 4.2 OWNERSHIP



The same policy as for the firewall services applies – see section X - 3.2.

X - 4.3 CORPORATE APPLICATION GATEWAY SERVICES The same policy as for the firewall services applies – see section X - 3.3. In addition to this, the following applies.

• Application gateway services like web traffic (HTTP, HTTPS) and FTP shall always be enabled for all traffic that is initiated from all ESA networks. Exceptions for systems and services deployed on PSNs, CSNs, CANs and LAB networks can be granted.

• Additional gateway services for DNS, SSH, any type of traffic tunnelled over

HTTP(S) such as SOAP and XML/RPC, SQL, VoIP and Video Conferencing services etc., are recommended to be deployed, but are not mandatory, yet.

• The application gateway functionality may be embedded in the firewall services. FCI-I, in its role of ITSOA, continuously assesses the risks related to applications that are run and deployed on the ESA networks. When the risks related to specific applications is considered too high, the application may be banned from the ESA networks or an application gateway service may be deployed and the use be enforced.

X - 4.4 PROJECT APPLICATION GATEWAY SERVICES The same policy as for the firewall services applies – see section X - 3.4.

X - 5 NETWORK ACCESS CONTROL SERVICES

X - 5.1 STANDARD NETWORK ACCESS CONTROL All systems with a need to connect to an ESA network that is subject to Network Access Control, shall adhere to the “ESA Network Access Control Services - Acceptable Use Policy” [AD-04]. Network Access Control shall be applied on the ESA Networks as stated in Table 3 below.



Table 3 - 802.1X Network Access Control On ESA Networks

Notes to Table 3 :

(1) By default, all systems on this network are subject to the 802.1X NAC policy.

(2) Systems on these corporate networks that have a time criticality requirement to be on line before other systems come on line to serve them at boot time, may be exempt from the 802.1X NAC policy. Examples can be network equipment, boot servers, directory servers, logging and security infrastructure that need to be on-line without delay.

(3) Systems deployed on these networks do not need to authenticate to the network using 802.1X; they are confined to their own security zone. CYN, systems shall authenticate using a different mechanism before they can gain access to the network – see [AD-02] Section “Wireless Connectivity And Services”.

(4) Some WiFi profiles may require 802.1X NAC.

For any deviation from this “ESA Network Access Control Services - Acceptable Use Policy” [AD-04], the PSSO shall seek approval from the ESA Security Office through a waiver.

I. ISNsI-CON Mandatory (1)I-PSN Mandatory (1)I-CSN Optional (2)I-CAN Optional (2)I-MGT Mandatory (1)I-LAB No (3)

II. DMZsE-GPN Mandatory (3)E-PSN Mandatory (1)E-CSN Optional (2)E-CAN Optional (2)E-MGT Mandatory (1)E-CYN Optional (4)E-LAB No (3)

III. ICNs Optional (2)

NotesESA

Network 802.1X NAC



X - 5.2 NEXT-GENERATION NETWORK ACCESS CONTROL The network security policy segments the network in several security zones. They can be composed by several VLANs. See [AD-02] Section “Security Zones”. The following considerations are to be made :

• Not all users and systems need access to all VLANs. • Over time, network segmentation based on VLANs and network based screening

only may result in excessive VLAN proliferation, complex network and firewall configurations, performance impacts on the network devices

• Higher costs because of all the above.

• ESA has the strong desire to optimize the use of all installed infrastructure rather than add yet another service and corresponding infrastructure. This is also a way to reduce costs

Therefore, the Standard NAC can be enhanced with role based access control features where users are grouped according to their network services access needs. When they access the network they obtain a security tag and based on these tags, they will be able to access specific resources and networks. A practical example clarifies :

• ESA users can be categorized according to their role in the organization (e.g. IT, scientists, engineering, finance, human resources, facilities, quality control, management, security, medical, contracts, etc.)

• All these users need access to a subset of services that are general purpose and common to all users; (e.g. DNS, DHCP, NTP, Internet, mail, collaboration services, corporate applications etc.)

• But the majority of the users require only access to a limited subset of systems and services on the ESA network to perform their day-to-day work; e.g. HR, contracts, finance, medical staff have no need to access applications specific for the science or technology department and vice versa.

• By allocating a security group tag to the users when they access the network and apply the corresponding dynamic ACLs on the network switches, users will only have access to the network resources that matter to them.

This is an important network security control that goes together with network segmentation, network screening, Data Leak/Loss Prevention and results in cost reduction if implemented correctly.



X - 6 INTRUSION DETECTION AND PREVENTION SERVICES

The main purposes of the ESA IDS and IPS services is to detect non-compliances to the policy and reducing risks. I.e. anything that violates the security policies or increases the risk for the Agency to unacceptable level, shall raise a flag. Besides this, the services may also focus on other unauthorized behaviour, traffic, attacks etc. IDS and IPS services may be deployed at any choke point on the ESA networks where there is a transition from one security zone to another. They shall never disrupt normal and legitimate services. IDS and/or IPS services shall be deployed according to the risks and sensitivity of data; e.g. priority could be given to screening I-CON, ICN, CSN and CAN networks. Level 5 networks are best covered by an IDS service at their choke-points. Level 3, 2 and 1 networks may be covered according to their assessed risk or compromise profiles. Coverage can change over time. The ID(P)S services shall be deployed on their own security zone – see also [AD-02] Section “Default Security Zones”. The IDS and/or IPS services may be outsourced to a trusted third party. ESA traffic screened must be physically separated from traffic screened for other customers. All traffic and intrusion related data shall be treated as “ESA Unclassified – For Internal Use with Limited Distribution” IDS and/or IPS services may be deployed as an independent service, as an integrated part of the firewall and application gateway services or a combination of the former as long as they are compatible an d do not affect the service. Networks probes, by nature, shall be deployed at ESA network choke-points. Analysis shall be performed by an FCI-I appointed entity and security staff. All relevant results shall be reported to the ESACERT such that an incident handling process can be started if considered relevant. The IDS and IPS services shall limit the amount of false positives and negatives to a minimum. Life data and analysis results shall always be accessible to authorized ESA security staff. Retention of raw and processed data shall be in line with section X - 7. The ESA ID(P)S events shall be integrated also with the corporate SIEM service and be used for event correlation with other events from other log sources.



X - 7 LOGGING AND LOG RETENTION

X - 7.1 NETWORK AND SECURITY EQUIPMENT All network and security equipment deployed on ESA networks shall log events on the device, as well as on a central log server. The log data shall also be fed into the corporate Security Information and Event Management (SIEM) service. All network and security equipment shall be configured to capture and log all information relevant for security related events and analysis. All log data shall be transmitted over a secure channel – natively or via encrypted tunnel; e.g. SSL, SSH, SNMPv3 etc. between the device and the central log server. Devices that are not able to meet this requirement shall not be deployed. Legacy devices may be exempt from this requirement until they are end-of-life, if this feature is not supported by the vendor. The security requirements stated in section X - 7.3 and X - 7.4 apply.

X - 7.2 SYSTEMS CONNECTED TO THE ESA NETWORKS All systems deployed on the CSNs, CANs, PSNs and ICN shall log events on the system itself as well as on a central log server and make these log events available to the corporate SIEM service. The same requirements as stated in section X - 7.1 apply.

X - 7.3 CENTRAL LOGGING AND CORPORATE SIEM SERVICE The policy to be applied for central logging are stated in the former sections. FCI-I has a corporate Security Information and Event Management (SIEM) service that is able to collect log events from many types of sources and correlate all these events in order to discover security and service incidents. It can be used for central logging of corporate IT services. It can also be used as a central logging facility for other systems and services that are required to perform central logging in addition to their own logging capabilities. The PSSO shall discuss the use of the corporate SIEM service with the IT/NSM. If desired, projects may also deploy their own central log server under the following conditions :

• The central log server(s) shall be deployed on the project’s own MGT security zone. • The PSSO shall seek an agreement with the IT/NSM for feeding these logs in the

corporate SIEM service. • Only authorized and registered devices shall log their data on a central log server in

their own dedicated location on that log server.



• All systems shall be time synchronized (Stratum 2 or better – see section VIII - 6). They shall log all information in the Coordinated Universal Time (UTC) time zone.

• Access to log raw data stored on any central log server shall be limited to authorized staff only; e.g. the system administrators, ESACERT, PSSO, IT/NSM and IO or their appointed deputies.

X - 7.4 LOG RETENTION All data shall be archived and kept for at least 12 months. Legal log retention requirement take precedence over this baseline.

X - 8 IT INFRASTRUCTURE AND SERVICE MANAGEMENT

All IT infrastructure and service management tasks shall be performed from an E- or I-MGT network. These tasks cannot be performed directly from an end-user computing platform. Therefore, a management security zone shall be created on the E- or I-MGT network that is dedicated to the service, service provider or project. Management systems or jump host(s) shall be deployed in that security zone. See [AD-02] section “MGT - Management Networks” for a description of the MGT networks. FCI-I may provide centrally managed jump hosts for projects or users who do not have a dedicated management system deployed on a “Corporate IT Services Management Security Zone” on an E- or I-MGT network. See also [AD-02] Section “Default Security Zones”. To manage their systems and services, one shall use a personalized user account on a centrally managed jump host that allows to identify the individual performing the task. In case the management tasks are to be performed from a remote non-ESA network, the remote party shall use a VPN to connect to a management system on the E- or I-MGT network or perform the task from a trusted partner network. See also section III. Systems shall use a dedicated physical network interface on their systems for management tasks. This interface is to be connected to the appointed security zone on the E- or I-MGT network. Also IPMI, ILO, DRAC, IMM or similar interfaces shall be connected to a MGT security zone. Management traffic shall not be transmitted across the normal service network interface(s) and vice versa. E.g. one shall not manage a server via a SSH terminal connection or web browser connecting to the normal interfaces where all other users land to use the service. The use of secure protocols such as SSH, HTTPS, SNMPv3 etc. is mandatory for management related tasks; e.g. :



• One cannot use Telnet to log on to system, SSH is to be used instead. • One cannot manage a web service using plain HTTP, HTTPS is to be used instead. • Systems managed through SNMP cannot use the plain SNMPv1 or 2c, SNMPv3 is to

be used with all security features enabled. By default, IT management SECOPS are to be produced and implemented. The PSSO shall assure that these SECOPS are applied in the field, audited on a regular basis and kept up-to-date. The PSSO is responsible to assure that “separation of duties” is documented as a project requirement, is stated in the SECOPS and practiced in the field. E.g. it is necessary to separate responsibilities for network, operating system, web and applications security. This becomes particularly important when using Virtualized environments like VMware, Xen, Hyper-V etc.



XI Administrative Network Security Controls

XI - 1 SYSTEM (DE-)CONNECTION REQUIREMENTS

XI - 1.1 CONNECTING SYSTEMS Any system that connects to the ESA networks shall have a PSSO taking responsibility for the systems. All systems connecting to the ESA networks shall have a valid forward and corresponding reverse DNS entry in the ESA DNS prior to deploying the system.

XI - 1.1.1 CSN, CAN, MGT AND ICN NETWORKS The following networks require the owner to request an individual fixed IP address before systems can connect :

• E-GPN, E-CSN, E-CAN, E-MGT • I-CSN, I-CAN, I-MGT • ICN

ESANOC (ESA Network Services) is responsible for the IP address allocation. Systems connecting to DMZ type networks (E-XXX) require a Security Plan– see also section XI - 2. In order to prepare this security plan, the system shall be granted temporary limited connectivity to its target network. Unless the security plan is completed and approved network connectivity will be restricted. By default, systems on these networks shall pass the 802.1X NAC before gaining access to the network. See section X - 5. FCI-I shall provide the procedure and workflow to obtain network connectivity on the corporate service portal.

XI - 1.1.2 PSN AND LAB NETWORKS A PSN, LAB network or a security zone on these networks, obtains an IP address range when the Network Request Form (NRF) is approved – see section 0. All systems shall be configured with a fixed IP address (section VIII - 2), be registered in the ESA DNS services (section VIII - 4) and be time synchronized (section VIII - 6).



A PSSO is required for these networks and security zones. The PSSO shall be responsible to assure that all duties stated in [AD-01] and these “Best Practices” are addressed. For these networks, the PSSO decides by default whether a system can be connected to the network. This may be overruled by the Site Manager or the IT/NSM. For PSN networks, the PSSO is responsible for assuring that the connected systems are secured and patched to the latest security level for all software components installed. For LAB networks, the requirement for patching to the latest security level may not always be possible. However, the PSSO is responsible for the overall security of the LAB systems and shall demand disconnection and decommissioning as soon as the systems are not used anymore. Whenever a LAB system is not in use, it shall be switched off. When it comes back online, it is immediately to be patched to the latest security level for all software components installed. In case of security incidents, FCI-I may disconnect the system or entire PSN or LAB network. FCI-I may audit the networks or security zones and match the actual situation against the information provided by the PSSO. In case of non-compliances, updates will be requested or systems may be disconnected.

XI - 1.1.3 I-CON NETWORKS Client systems connecting to the I-CON networks shall be authorized :

• For centrally managed systems this is automatically the case. • For BYOD, this may require authorization from the Site Manager if not covered by

an automatic centrally managed admission policy (e.g. via an Mobile Device Management – MDM service.

• For all other systems, authorization is required from the IT-NSM after positive assessment of the SSRS and its corresponding SECOPS.

Client systems on I-CON networks shall receive their network configuration automatically via DHCP or it can be set manually by the system administrator after obtaining this information from ESA Network Services. This functionality is to be preserved for both IPv4 and IPv6. By default, these systems do not require a Security Plan. All systems connected to an I-CON network shall pass the 802.1X NAC before gaining access to the network.



XI - 1.1.4 E-CYN NETWORKS Systems on these networks shall be authorized before obtaining network connectivity and its automatic network configuration by following the procedure applicable for the different 802.11 wireless profiles – see [AD-02] and X - 5.

XI - 1.2 REPLACING OR RE-ALLOCATING SYSTEMS When a system is replaced by a system that is configured similarly as the replaced system and performs exactly the same functions as before, the replacement shall be transparent to the users as well as concerning security plan. In other cases where :

• a system reuses a network switch port and/or IP address of another system • the same system is reused for other purposes than it was originally intended

the replacing or re-allocated system shall be considered as a new system. This means that IP addresses and network switch ports that were allocated, cannot be reused without knowledge and approval of the PSSO. For networks that require a security plan, the PSSO shall assure that the IP addressing, DNS registration and time synchronization is addressed and that the new security plan for the replacing system is assessed and approved prior to accepting the system can reuse the IP address and/or network switch port.

XI - 1.3 REMOVING OR DECOMMISSIONING SYSTEMS When a system is removed or to be decommissioned,

• The PSSO shall assure that :

o The system is physically disconnected from the network o The IP address are released in its records o The DNS names are returned to the service desk with the request to release them

for reuse by others or remove them from the ESA DNS o A request is made to the services desk to disable the switch port o If applicable, the status Security Plan is updated in the ISMS and the ESACERT

is informed o If the system is considered End-Of-Life (EoL), it shall be securely wiped and

removed from the data center, rack, room. o A request is made to the Service Desk to remove all obsolete firewall rules

Systems that are removed from the network with the intention to reuse them for another purpose, shall be considered as a new connection to the ESA.



XI - 2 SECURITY PLANS

A security plan is a document for an ESA system or service connected to a network that allows FCI-I, the PSSO and the owner to understand which systems and services are supposed to be online as well as their expected owners, purpose and security baseline. A Security Plan can be required for systems and services deployed under an ESA DNS name on an ESA Network, in the Cloud or with a collocation hosting provider etc. See section XI - 2.1. As per the ESA Security Directives, FCI-I in its role of the ITSOA, shall specify the conditions under which a security plan is required. The effective security level of a system connected to these ESA networks is the responsibility of the owner, under the supervision of the relevant PSSO, who shall monitor and ensure compliance with the relevant Agency security policy and guidelines. ESACERT provides a Security Plan template that shall be used for all ESA systems that connect to a network and require such a document – see section XI - 2.1.

XI - 2.1 SYSTEMS AND SERVICES REQUIRING A SECURITY PLAN The system and services that require a security plan are described below. Note that this includes also blade systems and Virtual Machine hypervisors – see also section II - 6.1 and II - 6.2.

XI - 2.1.1 ON ESA NETWORKS Table 4 shows on which ESA networks a system, service or application requires a security plan :



Table 4 - Security Plan Requirements on ESA Networks

Notes to Table 4 :

(1) Systems on these networks do not require an individual security plan, for being too difficult to assess, manage and verify compliance. Centrally managed systems connected on the I-CON are already conform the security standards set by FCI-I. BYODs on the I-CON, E- and I-CYN are not manageable from a central point of view, but are confined to a well-known security zone. If they cause security issues, the Site Manager may demand disconnection from the ESA networks. Systems on an ESA LAB network are by nature quite volatile in terms of configuration and security level : these are test setups. However, the risks should be confined to the LAB network security zone only. In case of security issues with LAB network systems, also here, the Site Manager may demand disconnection.

(2) For systems and services connected on these networks, it is strongly recommended to maintain a security plan, but it is not mandatory. The decision is left to the PSSO who shall enforce its decision.

(3) All systems and services deployed on these networks shall be covered with a

(4) All systems and services deployed on these networks shall be covered with a reduced security plan; i.e. at least the administrative details are to be covered.

I. ISNsI-CON No (1)I-PSN Optional (2)I-CSN Optional (2)I-CAN Optional (2)I-MGT Optional (2)I-LAB No (1)

II. DMZsE-GPN Mandatory (3)E-PSN Mandatory (4)E-CSN Mandatory (4)E-CAN Mandatory (4)E-MGT Mandatory (4)E-CYN No (1)E-LAB Mandatory (5)

III. ICNs Mandatory (3)

ESA Network Security Plan Notes



XI - 2.1.2 ON NETWORKS OF PARTNERS These type of deployments refer to systems and services accessible via an ESA DNS name, but deployed on a non–ESA network; e.g. on a partner organization or a service provider network. All systems and services that are accessible through an ESA DNS name but are deployed at a non-ESA network shall be subject to [AD-01], [AD-02], [AD-03] and the Best Practices” in this document. These systems and services shall need to prepare and maintain an up-to-date security plan. Assessment, approval and management of the security plans follow the same approach as any other security plan.

XI - 2.1.3 IN THE CLOUD OR WITH A COLLOCATION SERVICE PROVIDER For these kind of deployments, the same approach as stated in section XI - 2.1.2 applies. In some cases, it will not be possible to provide the same level of detail as when the environment were deployed on an ESA network. In this case, at least the administrative part and the security scanning results shall be provided as part of the security plan. PSSOs are responsible to obtain as much detail as possible from the service provider and negotiate the most secure environment that matches the ESA policies as closely as possible.



XI - 2.2 SECURITY PLAN ASSESSMENT AND APPROVAL The ESACERT assesses the security plans. Until security plan is accepted, the system cannot be connected to the network for operations – see also section XI - 1.1.1.

XI - 2.3 SECURITY PLAN MANAGEMENT The ESACERT collects and manages the security plans. It also provides the procedures and tools to prepare them. They can be found on the ESACERT portal [RD-07].

XI - 3 SECOPS

The ESA Security Directives state the requirements for the SECOPS of systems, services and applications that are accessible through an ESA DNS name. See [AD-01].

XI - 4 SECURITY DELTA SERVICE REQUESTS

By default SDSRs shall be avoided. SDSRs are only applicable for individual client systems on I-CON networks that need non-baseline connectivity to a system on an ESA PSN, MGT or extern network. Connectivity requirements for other networks is addressed via the process stated in section 0 or XI - 6. SDSRs shall meet following requirements :

• Single end-points at both sides • Single protocol • Single destination port

FCI-I provides a template form to make SDSRs as well as the guidelines to complete it. SDSRs shall be requested from and sent to the Service Desk who will ask the IT/NSM for its decision. SDSRs shall be granted for a maximum period one year. After that period the SDSR is to be renewed or decommissioned. In the latter case the firewall rules related to this request shall be removed.



XI - 5 NETWORK REQUEST FORM

A Network Request Form (NRF), allows for requesting :

• a new instance of an ESA network subtype • a new security zone on an existing ESA network subtype • amendments to an operational ESA network subtype instance or security zone • decommissioning an instance of an ESA network subtype or security zone

This applies to all ESA network types.

XI - 5.1 NETWORK REQUEST FORM CONTENTS NRFs shall contain at least :

• An administrative section This part contains administrative details of the request. At minimum the following details shall be provided :

o The project or service name o The action requested (see above) o Names of the contact points; i.e. names of the project manager, the PSSO, the

system ad service owner(s), the subnet manager(s), the IT/NSM o A brief description and justification for the request o The intended user communit(y)(ies) and their intended access to the system(s)

and/or services o The security level of the network – see [AD-02]

• Network Diagram A network diagram showing the intended network architecture.

• IP Addresses The type and number of IP addresses required; e.g. 32 public IPv4 addresses

• Traffic Matrix The traffic matrix shall define the communication required. The traffic matrix template provided by FCI-I shall be used. This traffic matrix shall be annexed to the NRF. The traffic matrix shall avoid wildcards for networks, IP addresses, protocols and ports; i.e. it shall be as specific as possible. Only situations that cannot be addressed



otherwise shall make use of wildcards. Such wildcards shall be justified and require enhanced vetting by the PSSO and the IT/NSM. The traffic matrix is the basis for the firewall rule implementation and both shall match at any time.

• Traffic volumes This section shall state the expected traffic volume that will cross the security zone. The following estimates are to be provided : o Average traffic volume in Kbps, Mbps, Gbps o Burst traffic volume in Kbps, Mbps, Gbps o Active traffic period during 24 hours (e.g. between 8:00-18:00 hrs CET)

• Firewalls used This section shall state which firewalls will be used. In case, project specific firewalls will be used, all administrative and technical details of the firewalls are to be provided as well as the change management procedures and SECOPS. Contact details for both administrative and technical staff shall be included. The security plan shall be referred to, including its last revision and approval date.

• The central log server(s) used This section shall state the central log server(s) that will be used for which systems as well as the details required to integrate with the corporate SIEM service. See also section X - 7.3.



• Incident Action Plan This section shall state the Security Incident Action Plan for the requested network or security zone.

XI - 5.2 NETWORK REQUEST FORM ASSESSMENT AND APPROVAL The PSSO sends the NRF to the Service Desk. The latter forwards the NRF to the IT/NSM and Site Manager for assessment and approval. NRFs are approved for maximum 1 year after which it needs to be reviewed and possible be updated.

XI - 5.3 NETWORK REQUEST FORM MANAGEMENT The PSSO shall provide an update of the NRF to the IT/NSM on a yearly basis. The IT/NSM collects and manages the NRFs in the ISMS. Changes to the administrative part can be addressed during the yearly update. Changes to the technical part shall be addressed immediately when the change is planned. Networks or security zones for which the NRF has not been updated for more than 18 months will be considered non-active. The IT/NSM will inform the PSSO and the Site Manager and request the network(s) to be disconnected.

XI - 6 INTERCONNECTION SECURITY AGREEMENT (ISA)

An interconnection agreement is required whenever connection is required between an ESA partner network and an ESA network. See section III.

XI - 6.1 ISA CONTENTS The template to be used for an ISA can be found on the Corporate IT Service Portal and is referred to in [RD-06]. The ISA is to be produced by both interconnecting parties under supervision of the PSSO. Security authorities of both organisations shall sign the interconnection agreement.

XI - 6.2 ISA ASSESSMENT AND APPROVAL The ISA shall be assessed by the IT/NSM, validated by the IO and approved by the SAA and ITSOA.



The ISA is approved for maximum 1 year after which it needs to be reviewed and possibly be updated.

XI - 6.3 ISA MANAGEMENT The PSSO shall provide an update of the ISA to the IT/NSM on a yearly basis. The IT/NSM collects and manages the ISA in the ISMS. Changes to the administrative part can be addressed during the yearly update. Changes to the technical part shall be addressed immediately when the change is planned. Networks or security zones for which the ISA has not been updated for more than 18 months will be considered non-active. The IT/NSM will inform the PSSO and the Site Manager and request the decommissioning of the interconnection.

XI - 7 SECURITY GUIDELINES

Security guidelines are documents that support the actual implementation in the field such that the overall deployment and service is in line with the ESA Network Security Framework – see section [AD-02]. FCI-I provides unbiased, vendor independent security guidelines via the ESACERT web pages – see [RD-07]. The ESACERT keeps these guidelines current. These guidelines are considered authoritative for ESA systems and services, independent where they are deployed. For environments that are not covered by the security guidelines available on the ESACERT web pages, the PSSO shall identify and approve the security guidelines that shall be used for securing its environment.

XI - 8 AUDITING

HFI, in its role of ITSOA as well as the SAA are entitled to audit ESA networks and connected systems and services at any point in time. Non-compliances shall be corrected and improvements to be implemented in case increased security risks have been identified. Persistent violation of the security policies may result is disconnection of the networks, systems or services. In case, it concerns an environment managed by a service provider, persistent violations may result in penalties. This aspect is to be addressed in the contractual agreement.



XII Security Incidents The Security Directives discuss security incidents in general – see [AD-01]. Security incidents are to be addressed as stated on the ESACERT web pages – see [RD-09].