1. Final Conference in Paris WP6 – Protection Profiles Specification
Markus Engqvist and Staffan Persson
atsec information security AB

2. Security Requirements: Protection Profiles
The deliverable D6.1 is the specification of security requirements for network separation in the form of Protection Profiles
This deliverable consists of four parts:
An Introduction document Describes the background and context for the Protection Profiles, and the connection to the CYRail project
Base Protection Profile for Network Separation Mechanisms Describes the minimum security requirements of a network device that directs data transmitted over computer networks, such as for secure management and auditing functionality
Protection Profile for Network Separation Mechanisms, VLAN Module Defines the minimum security requirements for a device that provides Virtual Local Area Network (VLAN) separation. It is a module for the Base Protection Profile.
Protection Profile for Network Separation Mechanisms, VPN Module Defines the minimum security requirements for a device that provides Virtual Private Networks (VPNs) and/or secure communication channels over computer networks. It is a module for the Base Protection Profile.

3. ISO/IEC 15408 (Common Criteria)
ISO/IEC is a standard for specifying security requirements and evaluating IT security products against these requirements
The CC is intentionally flexible
A Security Target (ST) specifies security functionality of a product
A product claims compliance to an ST
A Protection Profile (PP) specifies security functionality for a type of product
No details regarding implementation
An ST can claim compliance to a PP or multiple PPs
A modular Protection Profile provides selectable sets of security functionality for a type of product
An ST which claims compliance to a Base-PP can also claim compliance to one or more of its PP-Modules

4. Introduction Document
Purpose
Describe the original security problem and how the security requirements solving that problem were derived
Describe the context of Protection Profiles
Describe how the Protection Profile can be used in the future

5. Introduction Document
Summary
Security problems relating to interconnectivity, shared resources and the use of standard components and protocols
Similar situation, problems and solutions in ICS/SCADA, automotive and aviation
The MILS solution with separation offers a solution. Monitoring and secure management is also required
The CYRail project is based on standards such as ISO/IEC 27000, NIST SP-800, ISA/IEC 62443, ETSI TS 102 and ISO/IEC (Common Criteria)
We also provide a description of ISO 15408, what it is and how it is used
Also describes the relation between ISO/IEC and ISA/IEC 62443

6. Protection Profiles Purpose Summary
The Protection Profiles describe a network device that provides separation
The Protection Profiles define the minimum necessary security functionality
It is intended to be able to support a MILS architecture in critical infrastructure
With Base PPs and PP Modules, users can choose their desired separation mechanism
Summary
The Protection Profiles are a Base PP together with PP Modules
We have chosen the EAL4 assurance level (augmented with ALC_FLR.2)
The next slides will summarize the different Protection Profiles

7. Base Protection Profile
The Base PP focuses on providing common functionality that is independent of the separation functionality
Secure management of security functionality
Protection of the device itself
Audit requirements (logging)
The Base PP are written in a general way, to be able to accommodate as many products as possible while still providing the necessary security requirements
The Base PP describes the separation mechanisms, and was written to be able to support the modules
We define that users must also use at least one module(!)

8. PP Modules The PP Modules are optional packages for the Base PP
They each add one separation functionality
VLAN Module
Traffic flow control
Separating (Data link layer) traffic between interfaces via Virtual LANs
This creates separate broadcast domains to devices directly connected
Also supports IEEE 802.1q for tagging and aggregation
Trusted Channel Module
Separates traffic through cryptographic channels
Cryptography also leads to confidentiality and integrity of the data
We specify IPsec (Network layer), TLS or SSH (Application layer)
The PP Module also points to well-established standards and guidelines for the cryptographic implementation

9. Applying the Protection Profile
In the following slides, we have created some visual examples of how the Protection Profiles can be used
We are not stating any requirements, but rather some examples regarding the situations in which the Protection Profiles can be used
They will be able to solve different problems in different ways, providing different results or properties
How flexible is the solution?
Does it require surrounding functionality (such as a PKI)?
How is it maintained?
The actual usage and implementation is up to, and will depend on, the specific requirements of the customer/user
The solution not only has to be secure, but also usable!

10. Channels: IPsec
IPsec creates a Virtual Private Network, i.e. a logical connection between two remote networks. (Network tunnel)
The connection is secured cryptographically, and thereby separated from untrusted networks through which the channel is transmitted
Devices within the network will perceive the virtual configuration as the actual one, and behave as if on the same LAN
The cryptographic tunnels supports authentication, integrity and replay protection (along with confidentiality)
The tunnels will require devices on each network that support IPsec to establish the secure channel
In larger configurations there is also a need for supporting functionality such as key distribution and certificate management

11. Channels: IPsec
One use case would be to connect a trusted network of assets to a remote control center over the internet. E.g. control center and signalling networks
Another use case is to encapsulate untrusted traffic travelling via a trusted network. E.g. if the network connection passes through the internal network
Control Center
Signalling

12. Channels: TLS & SSH
Rather than connecting networks, TLS & SSH is used to connect applications or devices
It works in a client– server model, where one unit initiates a connection
For attackers located on the same network, they can observe the encrypted traffic but not access the data within
These channels can travel through the cryptographic tunnels of IPsec, as the separation is performed on the application layer
Application layer encryption is flexible, and offers a variety of possible uses and configurations
This might lead to a higher attack surface than components behind an IPsec connection, as attackers may be able to target the devices/applications that communicate (Only the traffic is separated)
Also, larger implementations require processes for certificate management

13. Channels: TLS & SSH
TLS will most likely be used in general for applications communicating on the network. E.g. traffic from CCTV cameras, so that no one can eavesdrop or change the footage
SSH will be used for management of devices, e.g. in the case of the CCTVs: a different channel from the footage, with more restrictive access controls
Client-server model, example:
An administrator’s client connects to a TOE server
A CCTV client reports its footage to a TLS server

14. Virtual LANs
VLANs should not be fully relied upon for security, as it offers no protection besides the separation of traffic through the device itself
It will most likely be used in three main scenarios:
To limit interference between services or reduce network congestion
To be used routinely in combination with cryptographic separation, providing an additional means of attack surface reduction
To prevent interference between untrusted services where security is not critical. I.e. we would not like internet users to be able to disturb each other, but this is not critical to operational security

15. Combinations
We expect that the technologies will often be combined, as the different separation mechanisms provide different results
While VLANs reduce the attack surface, SSH will most likely also be used for integrity and confidentiality in case an attacker could access the broadcast domain
When using wireless methods of communications (without any physical protection of the cables) we anticipate that channels will always be used to mitigate the larger attack surface

16. Application in Railway
AIRBUS has analysed the Protection Profiles and determined examples of use- cases in the railway.
SSH – Administration workstation and data server
IPSEC – Maintain and OCC
VLAN – Movement and command- onboard zone
TLS – Command-onboard and signal zone

17. Conclusions
Earlier work packages provided input by analysing the scenarios, the security risks and appropriate security measures for the railway. We could based on that specify appropriate and applicable security requirements.
The security problems as well as the security components are not unique to the railway, but a general problem to critical infrastructures. One of the main issue is separation and reduction of attack surface.
We have used ISO to specify security requirements in the form of a Protection Profile for network separation. It is a generic Protection Profile, that could apply to other sectors (e.g., the car industry) and technologies (e.g., the CCTV).
We have specified flexible, modular Protection Profiles (PPs) for the network separation. We have also identified other useful PPs and referred to them, such as separation kernel PPs and also other network component PPs.
The modular Protection Profile is public and available to the community, so it and can be used to assist in securing communication networks in railway systems as well as other critical infrastructures.
Finally, we have shown how Protection Profiles fits into the ISA/IEC standard used for the security of Industrial Automation and Control Systems (IACS) and the ETSI frameworks.