Imagine writing a piece of networking software.

• It needs to enable two neighbouring (i.e., directly connected) devices to communicate.
• It also needs to enable two devices separated by multiple hops to communicate.

The Open Systems Interconnection (sometimes Open Systems Interconnect or simply OSI) model 1️⃣ enables networking software to be built in a structured manner; 2️⃣ provides an interoperability framework for networking protocols.

History: The OSI model was introduced in 1983 by several major computer and telecom companies; and was adopted by ISO as an international standard in 1984 [Imp22].

• The second and latest edition of the international standard is ISO/IEC 7498-1:1994 [ISO94].

Watch the following video for a quick overview:

Learning the seven layers from Networking Foundations: Networking Basics by Kevin Wallace

More details follows.

The OSI model is a logical (as opposed to physical) model that consists of seven nonoverlapping layers (going bottom-up, opposite to Fig. 1):

1. Layer 1 (L1), physical layer [TW11, p. 43]: This layer transmits and/or receives raw bits (see Fig. 2) over a communication channel (e.g., coaxial cable, optical fibre, RF channel).

   This layer deals with mechanical, electrical, and timing interfaces, as well as the physical transmission medium, which lies below the physical layer.

   For example, the IEEE Standard for Ethernet [IEE22] specifies several variants of the physical layer and one data link layer.

2. Layer 2 (L2), data link layer [TW11, p. 43]: This layer transforms a raw transmission facility into a line that appears free of undetected transmission errors, by masking the real errors so the network layer above does not see them.

   Input data is encapsulated in data frames (see Fig. 2) which are transmitted sequentially.

   For example, the Challenge-Handshake Authentication Protocol (CHAP, see RFC 1994 and RFC 2433) is a link-layer protocol.

3. Layer 3 (L3), network layer [TW11, pp. 43-44]: This layer controls the operation of a subnet (see Fig. 2), by determining how packets (see Fig. 2) are routed from a source to a destination.

   For example, the Internet Protocol Security (IPsec) is a network-layer protocol.

4. Layer 4 (L4), transport layer [TW11, pp. 44]: This layer accepts data from above it, split it up into smaller units, called transport protocol data units (TPDUs, see Fig. 2), if need be, passes these to the network layer, and ensures that all pieces arrive correctly and efficiently at the other end.

   For example, the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are transport-layer protocols (see Fig. 1).

5. Layer 5 (L5), session layer [TW11, pp. 44-45]: This layer enables users on different machines to establish sessions between them.

   Sessions offer various services, including dialog control (keeping track of whose turn it is to transmit), token management (preventing two parties from attempting the same critical operation simultaneously), and synchronisation (checkpointing long transmissions to allow them to pick up from where they left off in the event of a crash and subsequent recovery).

   For example, SOCKS5 (see RFC 1928) is a session-layer protocol.

6. Layer 6 (L6), presentation layer [TW11, p. 45]: This layer manages the syntax and semantics of the information to be transmitted.

   For most protocols however, the distinction between the presentation layer and application layer is blur. For example, the HyperText Transfer Protocol (HTTP) is commonly classified as an application-layer protocol although it has clear presentation-layer functions such as encoding, decoding, and managing different content types [FNR22].

7. Layer 7 (L7), application layer [TW11, p. 45]: This layer implements a suite of protocols for supporting end-user applications.

   For example, HTTP is a stateless application-layer protocol for distributed, collaborative, hypertext information systems [FNR22]. HTTP supports eight “methods”, including the GET method for requesting transfer of a target resource in a specified representation [FNR22, Sec. 9.3.1].

Both models use 1️⃣ the transport and lower layers to provide an end-to-end, network-independent transport service; and 2️⃣ the layers above transport for applications leveraging the transport service.

Most real-world protocol stacks are developed based on a hybrid of the OSI and TCP/IP models, consisting of these layers (from bottom to top): physical, data link, network, transport, application [TW11, Sec. 1.4.3].

MITRE ATT&CK® is a knowledge base of adversary tactics (capturing “why”) and techniques (capturing “how”) based on real-world observations.

There are three versions [SAM+20]: 1️⃣ Enterprise (first published in 2015), 2️⃣ Mobile (first published in 2017), and 3️⃣ Industrial Control System (ICS, first published in 2020).

Fig. 1 below shows the fourteen MITRE ATT&CK Enterprise tactics:

The Mobile tactics and ICS tactics are summarised below. Note a tactic in the Mobile context is not the same as the identically named tactic in the ICS context.

Among the tools that support the ATT&CK framework is MITRE CALDERA™ (source code on GitHub).

• CALDERA is a cyber security platform built on the ATT&CK framework for 1️⃣ automating adversary emulation, 2️⃣ assisting manual red-teaming, and 3️⃣ automating incident response.
• CALDERA consists of two components:
  1. The core system: This includes an asynchronous command-and-control (C2) server with a RESTful API.
  2. Plugins: These are repositories that expand the core framework capabilities. Examples include Pathfinder, a plugin for automating ingestion of network scanning tool output.

A (blurry) demo is available on YouTube:

A complementary model to ATT&CK called PRE-ATT&CK was published in 2017 to focus on “left of exploit” behavior [SAM+20]:

• PRE-ATT&CK documents adversarial behavior during requirements gathering, reconnaissance, and weaponisation before access to a network is obtained.
• PRE-ATT&CK enables technology-independent modelling of an adversary’s behaviour as it attempts to gain access to an organisation or entity through the technology it leverages, spanning multiple domains (e.g., enterprise, mobile).

ATT&CK is not meant to be exhaustive, because that is the role of MITRE Common Weakness Enumeration (CWE™) and MITRE Common Attack Pattern Enumeration and Classification (CAPEC™) [SAM+20].

• Both CWE and CAPEC are related to Common Vulnerabilities and Exposures (CVE®).
• CVE provides a list of common identifiers for publicly known cybersecurity vulnerabilities called “CVE Records” that are assigned by CVE Numbering Authorities from around the world and are used by individuals and within products to enhance security and enable automated data exchange [MIT20].
• Based in part on the CVE List, CWE is a community-developed list of common software and hardware security weaknesses that serves as 1️⃣ a common language, 2️⃣ a measuring stick for security tools, and as 3️⃣ a baseline for weakness identification, mitigation, and prevention efforts [MIT20].
• Developed by leveraging CVE and CWE, CAPEC is a comprehensive dictionary and classification taxonomy of known attacks that can be used by analysts, developers, testers, and educators to advance community understanding and enhance defences.

The field of adversarial machine learning (AML) is concerned with the study of attacks on machine learning (ML) algorithms and the design of robust ML algorithms to defend against these attacks [TBH+19, Sec. 1].

ML systems (and by extension AI systems) can fail in many ways, some more obvious than the others.

AML is not about ML systems failing when they make wrong inferences; it is about ML systems being tricked into making wrong inferences.

Consider three basic attack scenarios on ML systems:

Black-box evasion attack: Consider the most common deployment scenario in Fig. 1, where an ML model is deployed as an API endpoint.

• In this black-box setting, an adversary can query the model with inputs it can control, and observe the model’s outputs, but does not know how the inputs are processed.
• The adversary can craft adversarial data (also called adversarial examples), usually by subtly modifying legitimate test samples, that cause the model to make different inferences than what the model would have made based on the legitimate test samples — this is called an evasion attack [OV23, p. 8].
• This technique can be used to evade a downstream task where machine learning is utilised, e.g., machine-learning-based threat detection.

White-box evasion attack: Consider the scenario in Fig. 1, where an ML model exists on a smartphone or an IoT edge node, which an adversary has access to.

• In this white-box setting, the adversary could reverse-engineer the model.
• With visibility into the model, the adversary can optimise its adversarial data for its evasion attack.

Poisoning attacks: Consider the scenario in Fig. 1, where an adversary has control over the training data, process and hence the model.

• Attacks during the ML training stage are called poisoning attacks [OV23, p. 7].
• A data poisoning attack is a poisoning attack where the adversary controls a subset of the training data by either inserting or modifying training samples [OV23, pp. 7-8].
• A model poisoning attack is a poisoning attack where the adversary controls the model and its parameters [OV23, p. 8].
• A backdoor poisoning attack is a poisoning attack where the adversary poisons some training samples with a trigger or backdoor pattern such that the model performs normally on legitimate test samples but abnormally on test samples containing a trigger [OV23].

Watch introduction to evasion attacks (informally called “perturbation attacks”) on LinkedIn Learning:

Perturbation attacks and AUPs from Security Risks in AI and Machine Learning: Categorizing Attacks and Failure Modes by Diana Kelley

Watch introduction to poisoning attacks on LinkedIn Learning:

Poisoning attacks from Security Risks in AI and Machine Learning: Categorizing Attacks and Failure Modes by Diana Kelley

In response to the threats of AML, in 2020, MITRE and Microsoft, released the Adversarial ML Threat Matrix in collaboration with Bosch, IBM, NVIDIA, Airbus, University of Toronto, etc.

Subsequently, in 2021, more organisations joined MITRE and Microsoft to release Version 2.0, and renamed the matrix to MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems).

MITRE ATLAS is a knowledge base — modelled after MITRE ATT&CK — of adversary tactics, techniques, and case studies for ML systems based on real-world observations, demonstrations from ML red teams and security groups, and the state of the possible from academic research.

Watch MITRE’s presentation:

References

The National Institute of Standards and Technology (NIST) has an essential role in identifying and developing cybersecurity risk frameworks for voluntary use by owners and operators of critical infrastructure (see Definition 1) [NIS18, Executive Summary].

Definition 1: Critical infrastructure [NIS18, Sec. 1.0]

Systems and assets, whether physical or virtual, so vital that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.

One such framework is the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework for short), for which NIST is maintaining an official website.

As of writing, the latest version of the NIST Cybersecurity Framework is 1.1 [NIS18].

The Cybersecurity Framework provides a common language for understanding, managing and expressing cybersecurity risks to internal and external stakeholders [NIS18, Sec. 2.0].

The Cybersecurity Framework has three parts: 1️⃣ Framework Core, 2️⃣ Implementation Tiers, and 3️⃣ Framework Profiles.

Framework Core

This is a set of cybersecurity activities, desired outcomes and applicable references (industry standards, guidelines and practices) that are common across critical infrastructure sectors [NIS18, Sec. 1.1].

The Framework Core consists of five concurrent and continuous Functions that provide a high-level strategic view of the lifecycle of an organisation’s management of cybersecurity risks:

1. Identify: Develop an organisational understanding to manage cybersecurity risks to systems, people, assets, data and capabilities [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • identifying critical enterprise processes and assets;
   • documenting information flows (how information is collected, stored, updated and used);
   • maintaining hardware and software inventories;
   • establishing cybersecurity policies specifying roles, responsibilities and procedures in integration with enterprise risk considerations;
   • identifying and assessing vulnerabilities and threats;
   • identifying, prioritising, executing and tracking risk responses.

2. Protect: Develop and implement appropriate safeguards to ensure delivery of critical services [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • managing access to assets and information;
   • safeguarding sensitive data, including applying authenticated encryption and deleting data that are no longer needed;
   • making regular backups and storing backups offline;
   • deploying firewalls and other security products, with configuration management, to protect devices;
   • keeping device firmware and software updated, while regularly scanning for vulnerabilities;
   • training and regularly retraining users to maintain cybersecurity hygiene.

3. Detect: Develop and implement appropriate activities to identify the occurrence of a cybersecurity event [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • developing, testing and updating processes and procedures for detecting unauthorised entities and actions in the cyber and physical environments;
   • maintaining logs and monitoring them for anomalies, including unexpected changes to systems or accounts, illegitimate communication channels and data flows.

4. Respond: Develop and implement appropriate activities to take action regarding a detected cybersecurity incident [NIS18, p. 8].

   Applicable activities include [MMQT21]:

   • making, testing and updating response plans, including legal reporting requirements, to ensure each personnel is aware of their responsibilities;
   • coordinating response plans and updates with all key internal and external stakeholders.

5. Recover: Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired by a cybersecurity incident [NIS18, p. 8].

   Applicable activities include [MMQT21]:

   • making, testing and updating recovery plans;
   • coordinating recovery plans and updates with all key internal and external stakeholders, paying attention to what, how and when information is shared;
   • managing public relations and company reputation.

Each Function comprises Categories, and each Category comprises Subcategories, and for each Subcategory, Informative References are provided [NIS18, Sec. 2.1].

• A Category is a cybersecurity outcome closely tied to programmatic needs and particular activities.
• A Subcategory is an outcome of technical and/or management activities for supporting achievement of the outcomes in each Category.
• An Informative Reference is a specific part of a standard, guideline and practice common among critical infrastructure sectors that illustrates a method to achieve the outcomes associated with each Subcategory.

Fig. 1 shows Categories, and the Subcategories under the Category “Business Environment”, and furthermore the Informative References for each of these Subcategories.

Implementation Tiers

The four tiers in Table 1 provide context on how an organisation views cybersecurity risks and the processes in place to manage those risks [NIS18, p. 8].

Table 1: Implementation tiers [NIS18, pp. 9-11].

Tier	Risk management process	Integrated risk management program	External participation
1, Partial	Not formalised, ad hoc and reactive.	Limited cybersecurity awareness. Risk management is irregular and case-by-case.	Organisation does not engage with other entities, and lacks awareness of cyber supply chain risks.
2, Risk-informed	Formalised but not organisation-wide. Prioritisation of cybersecurity objectives and activities is directly informed by organisational risks, business requirements, or the threat environment.	Cybersecurity awareness exists at the organisational level, but risk management is not organisation-wide. Irregular risk assessment of assets.	Organisation receives information from other entities and generates some of its own, but may not share information with others. Organisation is aware of cyber supply chain risks, but does not respond formally to the risks.
3, Repeatable	Formalised and regularly updated based on the application of risk management processes to changes in business requirements and the threat landscape.	Risk management is organisation-wide. Organisation accurately and consistently monitors cybersecurity risks of assets. Organisation responds effectively and consistently to changes in risks. Cybersecurity is considered through all lines of operation.	Organisation receives information from other entities and share its original information with others. Organisation is aware of cyber supply chain risks, and usually responds formally to the risks.
4, Adaptive	Formalised and adaptable to experience and forecast. Continuously improved leveraging advanced cybersecurity technologies and practices, to respond to evolving, sophisticated threats in a timely and effective manner.	Risk management is organisation-wide. Decision making is grounded in clear understanding of the relationship between cybersecurity risks and financial risks / organisational objectives. Risk management is integral to organisational culture and is supported by continuous awareness of activities on systems and networks.	Organisation receives, generates and reviews prioritised information to inform continuous risk assessment. Organisation uses real-time information to respond formally and consistently to cyber supply chain risks.

Implementation tiers do not represent maturity levels; they are meant to support organisational decision making about how to manage cybersecurity risks.

Framework Profiles

A Framework Profile (“Profile”) is a representation of the outcomes that a particular system or organisation has selected from the Framework Categories and Subcategories [NIS18, Appendix B].

A Profile specifies the alignment of the Functions, Categories, and Subcategories with the business requirements, risk tolerance, and resources of an organisation [NIS18, Sec. 2.3].

A Profile enables organisations to establish a roadmap for reducing cybersecurity risks, that 1️⃣ is well aligned with organisational and sector goals, 2️⃣ considers legal/regulatory requirements and industry best practices, and 3️⃣ reflects risk management priorities [NIS18, Sec. 2.3].

For example,

• The NIST Interagency Report 8401 [LSB22] specifies a Profile for securing satellite ground segments.
• A Profile for securing hybrid satellite networks is currently under development.
• More examples of Profiles can be found here.

Watch a more detailed explanation of the Cybersecurity Framework presented at RSA Conference 2018:

MITRE D3FEND is a knowledge base — more precisely a knowledge graph — of cybersecurity countermeasures/techniques, created with the primary goal of helping standardise the vocabulary used to describe defensive cybersecurity functions/technologies.

• It serves as a catalogue of defensive cybersecurity techniques and their relationships to offensive/adversarial techniques.

The D3FEND knowledge graph was designed to map MITRE ATT&CK techniques (or sub-techniques) through digital artefacts to defensive techniques; see Fig. 1.

• Any digital trail left by an adversary, such as Internet search, software exploit and phishing email, is a digital artefact [KS21, Sec. IVE].

Operationally speaking, the D3FEND knowledge graph allows looking up of defence techniques against specific MITRE ATT&CK techniques.

• For example, looking up Data Obfuscation (T1001) returns this knowledge graph.

Watch an overview of the D3FEND knowledge graph from MITRE on YouTube:

NIST provides guidelines on engineering trustworthy (see Definition 1) and cyber-resilient (see Definition 2) systems through NIST SP 800-160 volumes 1 and 2 [RWM22, RPG+21], to be used in conjunction with

• ISO/IEC/IEEEE International Standard 15288:2015 [ISO15],
• NIST SP 800-37 [Joi18] and
• NIST SP 800-53 [Joi20].

A primary objective of NIST SP 800-160 volume 1 is to provide a basis for establishing a discipline for systems security engineering as part of systems engineering in terms of its principles, concepts, activities and tasks.

• Systems engineering is a transdisciplinary and integrative approach to enabling the successful realisation, use, and retirement of engineered systems [RWM22, Sec. 2.2].
• Systems security engineering is meant to provide complementary engineering capabilities that extend the concept of trustworthiness to deliver trustworthy systems [RWM22, p. 2].
• Without going into details, Fig. 1 captures the workflow in the prescribed Systems Security Engineering Framework [RWM22, Sec. 4].

A primary objective of NIST SP 800-160 volume 2 is to provide guidance on how to apply cyber resilience concepts, constructs and engineering practices to systems security engineering and risk management for systems (e.g., enterprise IT, industrial control systems, Internet of Things) and organisations.

The Aerospace Corporation created the Space Attack Research and Tactic Analysis (SPARTA) cybersecurity matrix

• to address the information and communication barriers that hinder the identification and sharing of space-cyber Tactic, Techniques, and Procedures (TTP);
• to provide unclassified information to space professionals about cyber threats to spacecraft.

The SPARTA matrix is a specialisation of the MITRE ATT&CK matrix for defining and categorising commonly identified activities that contribute to spacecraft compromises.

The nine SPARTA tactics shown in the top row of Fig. 1 are a subset of the tactics in MITRE ATT&CK.

Under each SPARTA tactic in Fig. 1, each of the main techniques accompanied by a double vertical sign, namely ⏸, can be divided into sub-techniques. For example, under tactic “Reconnaissance” (ST0001), the technique “Gather Spacecraft Design Information” (REC-0001) can be divided into 1️⃣ Software (REC-0001.01), 2️⃣ Firmware (REC-0001.02), 3️⃣ Cryptographic Algorithms (REC-0001.03), 4️⃣ Data Bus (REC-0001.04), 5️⃣ Thermal Control System (REC-0001.05), 6️⃣ Manoeuvre and Control (REC-0001.06), 7️⃣ Payload (REC-0001.07), 8️⃣ Power (REC-0001.08), and 9️⃣ Fault Management (REC-0001.09).

Example 1: Payload

The South Australian 6U CubeSat Kanyini has two payloads: 1️⃣ a hyperspectral imager called HyperScout 2 for earth observation, and 2️⃣ an Internet-of-Things communications module.

Example 2: Applying SPARTA to modelling a recent cyber attack

Watch a quick overview of the attack called PCspooF:

A mixed-criticality system (MCS) is an embedded computing platform in which application functions of different criticalities share computation and/or communication resources [EDN16].

A mixed time-criticality system is an MCS where the criticality is messaging timeliness.

Time-Triggered Ethernet (TTEthernet), as standardised in SAE AS6802, defines algorithms for clock synchronisation, clique detection, startup, and restart for switches and end systems to achieve fault-tolerant synchronisation in an Ethernet-based (IEEE 802.3) mixed time-criticality system.

TTEthernet is used in avionics, industrial control systems (including those for power systems) and automotive systems [LPDK23], so any security vulnerability in TTEthernet would have wide-reaching consequences.

• In avionics, TTEthernet is used as a bus service for a variety of spacecraft including NASA’s Orion capsule, NASA’s Lunar Gateway space station, and ESA’s Ariane 6 launcher [The22].

How TTEthernet works [LPDK23]

A TTEthernet network contains two types of devices: switches and end systems.

Fault-tolerance is enabled by network redundancy, and each redundant network is called a plane; Fig. 2 shows an example of a system using two planes.

Time-triggered (TT) design = All TTEthernet devices are tightly synchronised and the behaviour of the network is determined by a global schedule made offline and loaded onto each TTEthernet device before deployment.

The global schedule specifies when TT frames are forwarded and expected to arrive.

The latency and jitter of TT traffic can be reduced to below 13 μs and 1 μs respectively [Fid15, slide 12].

TTEthernet also carries best-effort (BE, i.e., regular) Ethernet traffic and rate-constrained Avionics Full Duplex Switched Ethernet (AFDX, as standardised in ARINC Specification 664 P7-1) traffic; see Fig. 3.

TTEthernet switches forward BE traffic around the pre-scheduled TT traffic when bandwidth permits.

Mechanisms exist to isolate TT traffic from BE traffic, e.g.,

• there are windows reserved for TT traffic only;
• TT and BE frames are stored in different switch buffers.

Central to TTEthernet is a synchronisation protocol, in which a device can participate as 1️⃣ a sync master, 2️⃣ a compression master, or 3️⃣ a sync client.

• Typically, a subset of the end systems serve as sync masters, while 1-2 switches per plane serve as compression masters.
• The remaining devices serve as sync clients.

Devices exchange protocol control frames (PCFs) every integration cycle.

• At the beginning of each integration cycle, every sync master sends a PCF containing its local clock value to the compression masters.
• The compression masters average the received clock values, then send out the average in a new PCF to the sync masters and clients, which then correct their local clocks.

Receiving certain PCFs from a compression master can cause sync masters and clients to lose synchronisation.

• An example of such PCFs is “coldstart acknowledgement”, which tells a sync master another sync master detected loss of synchronisation and is reestablishing it.
• Since a PCF can cause de-synchronisation, TTEthernet requires each compression master to be a self-checking pair, which only produces a PCF if two independent processors agree on the contents.

Attacker/threat model for PCspooF

The PCspooF attack is feasible provided:

• Attacker has access to at least one BE device, e.g.,
  • by supplying such a device (as a malicious supplier) for integration into the TTEthernet network before the network is deployed;
  • by connecting the device to the TTEthernet network after the network has been deployed.
• Attacker can control the BE device operating in one plane; see Fig. 4.
• Attacker-controlled BE device includes additional circuit components for conducting electromagnetic interference (EMI) through its Ethernet cable into a switch; see Fig. 5.

The PCspooF attack

PCspooF is a cyber-physical attack that attempts to disrupt the TTEthernet synchronisation protocol by spoofing PCFs, and thereby inflict denial of service on its victim.

The attack happens in two stages:

• Stage 1️⃣: This is the cyber stage, where the attacker fabricates a valid PCF.

  A PCF has the same structure as a standard minimum-sized Ethernet frame, but instead of a destination MAC address, it has a 4-byte Critical Traffic Marker (a special value used to identify all PCFs and TT traffic) and a 2-byte Virtual Link ID (also called Critical Traffic ID [Lov15], which identifies the source of a PCF); see Fig. 6.

  These two fields 👆 must match the values specified in the network schedule loaded onto the TTEthernet devices. These two fields happen to be the only fields that pose a challenge to spoof.

  Skipping the details [LPDK23, Sec. IIIA], an attacker can determine valid Critical Traffic Markers by abusing the Address Resolution Protocol and trying a maximum of around one billion possible values.

  Skipping the details again [LPDK23, Sec. IIIA], an attacker can try to use 4071 or 4070 as the Virtual Link ID, or in the worst case, try a maximum of 65536 values.

  The fabricated PCF is stored inside the payload of a benign BE frame, because TTEthernet switches drop PCFs from BE devices.

  The next stage is to trick a switch into forwarding the aforementioned BE frame as a PCF.

• Stage 2️⃣: This is the physical stage, where the attacker uses EMI to convert a BE frame into a PCF during transmission.

  This is an example of a link reset attack, which in turn is an example of a packet-in-packet attack [GBM+11].

  Scenario: a BE device is transmitting to a switch, but the PHY preamble becomes corrupted, and consequently the PHY layer of the switch resets itself.

  Attacker uses the opportunity to send packet below:

  In Fig. 7, the PHY layer and outgoing port of the switch recover during the transmission of the fake preamble.

  Result: Inner frame, which contains the fake PCF, gets sent.

  Corruption of PHY preamble can be achieved through EMI; see Figs. 8-9.

Applying SPARTA

Using the language of SPARTA, these attack stages can be identified [The22]: 1️⃣ Reconnaissance, 2️⃣ Resource Development, 3️⃣ Initial Access, 4️⃣ Execution, 5️⃣ Lateral Movement, 6️⃣ Impact

Table 1 and Table 2 map these attack stages to the attack steps in PCspooF.

Table 1: The first three stages of PCspooF.

Reconnaissance (ST0001)	Resource Development (ST0002)	Initial Access (ST0003)
Gather Spacecraft Design Information (REC-0001), and specifically, Data Bus (REC-0001.04): 😈 Attacker gathers information required for successful spoofing of TTEthernet frame fields (e.g., Critical Traffic Marker, Virtual Link ID) and design of EMI-injecting PCB. Gather Supply Chain Information (REC-0008), and specifically, Hardware (REC-0008.01): 😈 Attacker gathers information on the hardware in use, e.g., TTEthernet utilisation, EMI target. Eavesdropping (REC-0005): 😈 Attacker eavesdrops on the network to infer valid Critical Traffic Markers and Virtual Link IDs from devices’ responses or lack of response.	Stage Capabilities (RD-0004), and specifically, Identify/Select Delivery Mechanism (RD-0004.01): 😈 Attacker identifies the ideal BE device to use for executing the attack.	Compromise Supply Chain (IA-0001), and specifically, Hardware Supply Chain (IA-0001.03): 😈 Attacker sneaks the attacking BE device into the supply chain before or after the deployment of the targeted TTEthernet network. Auxiliary Device Compromise (IA-0011): 😈 Attacker investigates potential use of a USB/generic hardware vector instead of a BE device.

Table 2: The last three stages of PCspooF.

Execution (ST0004)	Lateral Movement (ST0007)	Impact (ST0009)
Time Synchronised Execution (EX-0008): 😈 Attacker implements a “ticking timebomb” trigger, which activates attack after a preset amount of post-deployment time. Flooding (EX-0013), and specifically, Erroneous Input (EX-0013.02): 😈 Attacker brute-forces ARP requests and emissions of EMI. Exploit Hardware/Firmware Corruption (EX-0005), and specifically, Design Flaws (EX-0005.01): 😈 Attacker exploits weaknesses permitting aggressive ARP polling of BE devices, gathering of information (e.g., Critical Traffic Markers, Virtual Link IDs), and link reset attacks for spoofing PCFs (see Fig. 7). Spoofing (EX-0014), and specifically, Bus Traffic (EX-0014.02): 😈 Attacker injects spoofed PCFs via EMI-based link reset attacks.	Exploit Lack of Bus Segregation (LM-0002): 😈 Attacker is enabled by the situation where critical (TT) and non-critical (BE) components share the same physical networking infrastructure to use a non-critical component (BE device) to disrupt the operations of critical components (TT devices).	Disruption (IMP-0002): 😈 TTEthernet synchronisation broken, critical operations not being performed, leading to disruption of critical spacecraft operations (e.g., manoeuvring, sensing, communications) and overall mission.

This is a student-friendly explanation of the hardware weakness CWE-1189 “Improper Isolation of Shared Resources on System-on-a-Chip (SoC)”, which is susceptible to

• CAPEC-124 “Shared Resource Manipulation”.

A system-on-a-chip (SoC) may have many functions but a limited number of pins or pads.

A pin can only perform one function at a time, but it can be configured to perform multiple functions; this technique is called pin multiplexing.

Similarly, multiple resources on the chip may be shared to multiplex and support different features or functions.

When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access assets authorised only for trusted agents.

Consider the generic SoC architecture in Fig. 1 below:

The SRAM in the hardware root of trust (HRoT) is mapped to the core{0-N} address space accessible by the untrusted part of the system.

The HRoT interface (hrot_iface in Fig. 1) mediates access to private memory ranges, allowing the SRAM to function as a mailbox for communication between the trusted and untrusted partitions.

• Assuming a malware resides in the untrusted partition, and has access to the core{0-N} memory map.
• The malware can read from and write to the mailbox region of the SRAM access-controlled by hrot_iface.
• Security prohibits information from entering or exiting the mailbox region of the SRAM through hrot_iface when the system is in secure or privileged mode.

This is a student-friendly explanation of the hardware weakness CWE-1191 “On-Chip Debug and Test Interface With Improper Access Control”, which is susceptible to

• CAPEC-1 “Accessing Functionality Not Properly Constrained by ACLs” and
• CAPEC-180 “Exploiting Incorrectly Configured Access Control Security Levels”.

The internal information of a device may be accessed through a scan chain of interconnected internal registers, typically through a Joint Test Action Group (JTAG) interface.

• The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on the device.
• Since almost all information contained within a device may be accessed over this interface, device manufacturers typically implement some form of access control — debug authorisation being the simplest form — in addition to on-chip protections, to prevent unintended use of this sensitive information.
• If access control is not implemented or not implemented correctly, a user may be able to bypass on-chip protection mechanisms through the debug interface.

Sometimes, designers choose not to expose the debug pins on the motherboard.

• Instead, they choose to hide these pins in the intermediate layers of the board, to work around the lack of debug authorisation inside the chip.
• In this scenario (without debug authorisation), when the debug interface is exposed, chip internals become accessible to an attacker.