Model checking is a method for formally verifying that a model satisfies a specified property [vJ11, p. 1255].

Model checking algorithms typically entail enumerating the program state space to determine if the desired properties hold.

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

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:

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):

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

Physical unclonable functions (PUFs, see Definition 1) serve as a physical and unclonable alternative to digital cryptographic keys.

Think of a PUF as a keyed hash function, where the key is built-in and unique due to manufacturing variations [GASA20].

• Given an input, which we shall call a challenge, a PUF outputs a response. The challenge-response pair (CRP) is unique to the PUF.
• Every CRP is used only once.

Types of PUFs include 1️⃣ optical PUFs, 2️⃣ arbiter PUFs, 3️⃣ memory-based intrinsic PUFs [GASA20].

• An intrinsic PUF is a PUF that is already embedded within a device at the time of manufacturing.
• The first intrinsic PUF was introduced in 2007 in the form of an SRAM PUF.
• Flash memory PUFs and DRAM PUFs were subsequently introduced.
• A memory-based PUF usually offers desired independence among response bits, so its primary application is on-demand derivation of volatile cryptographic keys.

Watch a high-level introduction to SRAM PUF:

Proximity-1 covers the data link layer [CCS20d] and physical layer [CCS13b].

Proximity-1 enables communications among probes, landers, rovers, orbiting constellations, and orbiting relays in a proximate environment, up to about 100,000 km [CCS13c].

These scenarios are devoid of manual intervention from ground operators, and furthermore, resources such as computational power and storage are typically limited at both ends of the link.

In fact, Proximity-1 has been field-tested in the 2004-2005 Mars missions; see Figs. 1-2 for illustration.

In contrast, the AOS/TC/TM Space Data Link Protocols are meant for Earth-deep space links, over extremely long distances.

Proximity-1 supports symbol rates of up to 4,096,000 coded symbols per second.

Designed for the Mars environment, the physical Layer of Proximity-1 only uses UHF frequencies [CCS13b, Sec. 1.2].

The frequency range consists of 60 MHz between 390 MHz to 450 MHz with a 30 MHz guard-band between forward and return frequency bands, specifically 435-450 MHz for the forward channel and 390-405 MHz for the return channel [CCS13b, Sec. 3.3.2].

Also known as asymmetric-key cryptography, public-key cryptography (PKC) uses a pair of keys called a public key and a private key for 1️⃣ encryption and decryption, as well as 2️⃣ signing and verification.

Digital certificates and public-key infrastructure (PKI)

Suppose 👩 Alice is somebody everybody trusts.

• When 👩 Alice signs 🧔 Bob’s public key, anybody can verify Bob’s public key using Alice’s public key.
• Successful verification means we can trust that the public key is Bob’s because we trust Alice.
• Essentially, 🧔 Bob’s public key with 👩 Alice’s signature on it serves a 📜 digital certificate (see Definition 2) certifying Bob’s identity.

Watch a quick introduction to digital certificates on LinkedIn Learning:

Digital certificates and signing from Ethical Hacking: Cryptography by Stephanie Domas

Digital certificates are only useful if we can trust their signatories.

To ensure signatories and hence certificates can be trusted, PKC relies on a public-key infrastructure (PKI, see Definition 3) to work.

Watch a quick introduction to PKI from an operational viewpoint on LinkedIn Learning:

Cryptography: Public key infrastructure and certificates from CISA Cert Prep: 5 Information Asset Protection for IS Auditors by Human Element LLC and Michael Lester

A PKI, as specified in the ITU-T X.509 [ITU19] standard, consist of certification authorities (CAs).

• One or more CAs are trusted to create and digitally sign public-key certificates in response to certificate signing requests (CSRs).

• A CA may optionally create the subjects’ keys.

• A CA certificate is a public-key certificate for one CA [ITU19, Sec. 7.4]

  • issued by another CA, in which case the CA certificate is a cross-certificate;

  • issued by the same CA, in which case the CA certificate is a self-issued certificate.

    If the signing key is the private key associated with the public key signed, the self-issued certificate is a self-signed certificate.

• Thus, CAs can clearly exist in a hierarchy, e.g., the two-tier hierarchy in Fig. 1, or the three-tier hierarchy in Fig. 2.
• In a hierarchy, the root CA serves as the trust anchor [ITU19, Sec. 7.5].
• Examples of CAs: IdenTrust, DigiCert Group, others.
• An example of a software solution that implements CA functionality is Cloudfare’s CFSSL.

A PKI also has registration authorities (RAs).

• One or more RAs are responsible for those aspects of a CA’s responsibilities that are related to identification and authentication of the subject of a public-key certificate to be issued by that CA.
• An RA may either be a separate entity or be an integrated part of the CA.
• CAs typically play the role of RA as well.
• An example of a software solution that implements RA functionality is PrimeKey’s EJBCA Registration Authority.

Public-key cryptosystems

Algorithmically speaking, there is more than one way of constructing a public-key cryptosystem.

Standard public-key cryptosystems: 1️⃣ Rivest-Shamir-Adleman (RSA) cryptosystem, 2️⃣ elliptic-curve cryptosystems.

These cryptosystems rely on the hardness of certain computational problems for their security.

The hardness of these computational problems has come under threat of quantum computers and quantum algorithms like Shor’s algorithm.

As a countermeasure, NIST has been searching for post-quantum cryptography (PQC, also called quantum-resistant cryptography).

As of writing, there are three PQC candidates.

See 👇 attachment (coming soon) or the latest source on Overleaf.

Not ready for 2023 but see reference below.

A safe programming language is one that is memory-safe (see Definition 1), type-safe (see Definition 2) and thread-safe (see Definition 3).

A significant percentage of software vulnerabilities have been attributed to memory safety issues [NSA22], hence memory safety is of critical importance.

Examples of violations of memory safety can be found in the discussion of common weakness CWE-787 and CWE-125.

Type safety ⇒ memory safety, but the converse is not true [SM07, Sec. 6.5.2], hence type safety is commonly considered to be a central theme in language-based security [Fru07].

Type-safe programming languages, e.g., Java , Ruby, C#, Go, Kotlin, Swift and Rust, have been around for a while. However, memory-unsafe languages are still being used because:

• Type-safety features also come at the expense of resource requirements. Most memory-safe languages use garbage collection for memory management [NSA22], and this translates to higher memory usage.

• Although most type-safe languages are supported on the mainstream computing platforms (e.g., Wintel), the same cannot be said of embedded platforms.

  It can be challenging to program a resource-constrained platform using a type-safe language.

• There is already a vast amount of legacy code in C/C++ and other memory-unsafe languages.

  The cost to port legacy code, including the cost of training programmers, is often prohibitive.

  Depending on the language, interfacing memory-safe code with unsafe legacy code can be cumbersome.

• Besides invoking unsafe code, it is all too easy to do unsafe things with a type-safe language, e.g., not checking user input, not implementing access control.

  Programmers often use this as an excuse to not use a different language than what they are familiar with.

Nevertheless, adoption of type-safe languages, especially Rust, has been on the rise [Cla23].

Thread safety rounds up the desirable properties of type-safe languages.

Watch the following LinkedIn Learning video about thread safety:

Thread safety from IoT Foundations: Operating Systems Fundamentals by Ryan Hu

Rust is an example of a type-safe language that is also thread-safe.