Project Specification

Introduction

The project of the present course will aim to use a (very very) simplified operational technology environment and applying what learned in the lectures to a “real” use case. The definition of the exact environment is your decision so that you may tailor your expectations with

You are going to build a system composed by:

very small IT infrastructure^{1 and}² (this is defined upfront and not subject to changes) - represented by “Business Network” in the image below
very small OT infrastructure² - represented by “Site or Regional Supervisory” and “Plant or Field Site” in the image below
1 device that is outside of your perimeter but feeds data into it - within the “Internet” in the image below
different subnets

¹: it is a simple infrastructure but still representative
²: we do not like paying high infrastructure fees and consume energy for nothing thus the machine will be automatically shut down at night. Important note : this comment applies solely to the openstack implementation, not the conceptual work concerning your infrastructure.

_{(Source: https://www.sans.org/blog/introduction-to-ics-security-part-2/)}

Phases

The software will be implemented in several phases as listed below. The deadlines for delivering the deliverables of each phase are described in the plan. The deliverables must be made available as defined in the project organization section

The phases of the project are:

Definition of the environment the project will be in (Phase A).
Implementation of the project according to Phase A definition (Phase B).
Integration of Incident Response and IEC62443 (Phase C).

Info

Each phase of the project gives a total of 15 points. As a result, the 3 phases combined give you a maximum of 45 points. These points are then, proportionally, defining what bonus one gets thanks to the project results (see also Marking).

Phase A

The students are asked to describe the environment for their course project, considering the following points related to Operational Technology (OT) environments and potential impacts of security breaches, drawing on the sources seen during the course:

I. Describing the OT Environment

Type of Environment: you should define the specific OT environment their project will simulate. Examples include industrial, medical, power grids, water treatment facilities, or transportation systems.
Components: descriptions should include the basic components of their chosen OT environment:
- IT Infrastructure: a small IT infrastructure (the “Business Network”).
- OT Infrastructure: a small OT infrastructure (“Site or Regional Supervisory” and “Plant or Field Site”).
- External Data Source: a device outside the perimeter (“Internet”) that feeds data into the system.
- Subnets: different subnets within the environment.
Functionality: you should describe the primary function of the OT system, such as monitoring, control, or automation of physical processes.
Purdue Model (PERA): Use the Purdue Model to illustrate the different levels and interactions within the environment. This helps to understand the relationships between enterprise systems, control systems, and physical processes.

II. Potential Impacts of Security Breaches

Operational Disruptions: Security breaches in OT systems can lead to significant operational disruptions. For example, a cyberattack could halt production in a manufacturing plant or disrupt the delivery of essential services in a water treatment facility.
Safety Hazards: OT security breaches can create safety hazards, potentially leading to injuries, casualties, or environmental damage. For example, a compromised control system in a power plant could lead to equipment malfunctions and safety risks.
Financial Losses: Disruptions and damages resulting from security breaches can cause substantial financial losses. These losses may include the cost of recovery, legal liabilities, and reputational damage.
Critical Infrastructure Impact: Because OT systems often manage critical infrastructure, security breaches can have wide-reaching consequences for public health, national security, and economic stability.

III. Key Characteristics to Consider for Security

Unique Risk Profiles: OT risk profiles are distinct from IT, often involving critical infrastructure where security breaches can have severe consequences.
Availability: OT environments prioritize availability to maintain physical operations. Security measures should minimize latency to avoid productivity and safety concerns.
System Longevity: OT systems often have prolonged lifecycles, sometimes spanning decades. This contrasts with IT systems, which have shorter lifecycles.
IT/OT Convergence: The increasing integration of IT and OT systems exposes OT networks to cyber threats.
Legacy Systems: Many OT devices lack inherent cybersecurity mechanisms. This requires careful implementation of security controls.

Image title

Segment or not segment, this is the question

Warning

These pictures are solely to be used as examples, not the intended target (as none is actually excellent).

Phase A Deliverables

Based on the instructions in the Phase A, you must:

Expected Deliverables and Additional Requirements

Deliver a description of the infrastructure you are going to implement.
- Deliverable: the “README.md” file at the root of the project must contain chapters covering
  - introduction
  - a description of the environment of the system
  - the components that are contained within and outside the infrastructure
  - the functionality made available by the system
  - potential impact(s) in case of breaches
  - references used for defining the system
Deliver a sketch of the network segmentation you intend to implement.
- Deliverable: a corresponding chapter is added to the “README.md” file at the root of the project
Rules related to repository management.
- Requirement: all the work is done on a dedicated git branch named phase_a and merged once the tasks are completed. The merge shall happen through a Pull Request (PR) so as to ensure proper code review (so, do not forget to add a reviewer 😉)
- Deliverable: the description of your application present in your github repository is tagged with the tag/release “PhaseA”.

Phase B

The students are asked to implement the environment they chose during Phase A project, considering the following points related to Operational Technology (OT) environments and feedback from the Phase A (if any). They shall also reflect on the elements seen during the course to implement a sound yet small OT infrastructure.

I. Implementing the OT Environment Structure

As stated above, the internal infrastructure will be built using SWITCHengine. In order to get familiar with it, head to the related introduction.

Internal infrastructure:
- implement the infrastructure as per your design. Make sure to have :
- the corresponding networks
- clear separated OT and IT infrastructures
- a correspondance between the implemented infrastructure and the chosen Purdue Model
- follow the guideline of giving the least priviledges. That is, when you define access control rules, make sure they are the necessary ones but not more.
- you only have 2 floating IP addresses. That is, you likely need one for your externally facing application(s) and the second would thus need to be used on a jumphost. From that machine you should be able to access the rest of the machines within the infrastructure.
Tip

Should you need more than 2 IP addresses, please contact the professor timely so that he may help you out if justified.
External infrastructure:
- An external device shall send data to your infrastructure. In order to do so, in addition to finding a device that can inject data (can be real, like a temperature sensor, but can also be a simple program sending random - plausible - data), it needs to be connected safely to your OT infrastructure. As a result, choose a technology (wireguard, mqtt with tls, …) that enables this.
- An external service (e.g. commodity prices) shall also be used by your infrastructure. The service itself does not have to be a real one at all costs (as it may be hidden behind a paywall or have other limitations) but it shall be handled as it were a real one from a diligence standpoint.
II. Implementing the OT Environment Services:
- The proposed services shall be implemented as per your proposal.
- Should there be a need for changes, do remember to update the proposal accordingly. In addition, remember to add a corresponding high-level changelog (do not rely solely on git log and git diff).
- Add an of SBOM to your documentation related to the implemented services (be it through containers or else).
III. Granting access to the OT Environment Structure:
- The professor shall be able to access to your infrastructure with the publicly available key (see Introduction in class for details about it).
- No matter what User Interface your service does offer, make sure it is available (and a description is available on how to get to it).

Tip

Should you have any challenge in understanding the project scope and goals or in its implementation, do contact the professor (in a timely manner) to see whether he can be of assistance.

Phase B Deliverables

Based on the instructions in the Phase B, you must:

Expected Deliverables and Additional Requirements

Deliver a description of the implemented infrastructure.
- Deliverable: the “README.md” file at the root of the project must contain chapters covering
  - introduction
  - a description of the environment of the system
  - the components that are contained within and outside the infrastructure (including the corresponding SBOM)
  - the functionality made available by the system and a description (either light or referenced) about how to access it
  - configuration of the different elements (can also be a very short description linked to configuration script(s))
  - references used for implementing the system
Deliver a sketch of the implemented network segmentation.
- Deliverable: a corresponding chapter is added to the “README.md” file at the root of the project
Access to the different machines is granted to the professor.
Rules related to repository management.
- Requirement: all the work is done on a dedicated git branch named phase_b and merged once the tasks are completed. The merge shall happen through a Pull Request (PR) so as to ensure proper code review (so, do not forget to add a reviewer 😉)
- Deliverable: the description of your application present in your github repository is tagged with the tag/release “PhaseB”.