Cybersecurity

Available (269)

Showing 1 - 12 per page



IETF Supply Chain Integrity, Transparency, and Trust (scitt)

Body

The IETF has a security-related working group called Supply Chain Integrity, Transparency, and Trust (SCITT), whose charter reads:

"The Supply Chain Integrity, Transparency, and Trust (SCITT) WG will define a set of interoperable building blocks that will allow implementers to build integrity and accountability into software supply chain systems to help assure trustworthy operation. For example, a public computer interface system could report its software composition that can then be compared against known software compositions or certifications for such a device thereby giving confidence that the system is running the software expected and has not been modified, either by attack or accident, in the supply chain.

Problem Statement

Some of the fundamental security issues that face the supply chain ecosystem today are as follows:

  1. A single product is composed of multiple sub-products coming from different suppliers. There are several standards to compose supply chain information with different producers choosing different methods.

  2. There are no uniform APIs or services to publish supply chain information to third parties, nor are there ways to verify the integrity or date of publication of that information.

  3. There is a lack of decentralized, globally interoperable, transparent services to publish supply chain data.

  4. The lack of sufficient standards for independently verifying the presence of supply chain data in tamper-proof data stores.

  5. Fractured verification methodologies across software distribution ecosystems create inconsistent security guarantees for end users.

  6. Software consumers have no trustworthy way to verify that a software signature on a software package is legitimate.

A minimal, simple, and concise set of building blocks that interact in a standardized way will assure long-term accountability and interoperability for supply chain components throughout their lifecycles across architecturally diverse systems.

Goals

Based on an input document on the architecture (draft-birkholz-scitt-architecture), the WG will standardize the technical flows for providing information about a software supply chain, which also includes firmware, and covering the essential building blocks that make up the architecture."
 

WG Link: https://datatracker.ietf.org/group/scitt/about/

WG Documents: https://datatracker.ietf.org/group/scitt/documents/

WG Mailing List: https://mailarchive.ietf.org/arch/browse/scitt/


 

Groups

Cybersecurity for AI Systems

Body

According to the AI Standardization Request from the European Commission to CEN/CENELEC, European standards or standardisation deliverables shall provide suitable organisational and technical solutions to ensure that AI systems are resilient against attempts to alter their use, behaviour, or performance or compromise their security properties, by malicious third parties, exploiting vulnerabilities of AI systems. Organisational and technical solutions shall include, where appropriate, measures to prevent and control cyberattacks trying to manipulate AI specific assets, such as training data sets (e.g. data poisoning) or trained models (e.g. adversarial examples), or trying to exploit vulnerabilities in AI system’s digital assets or in the underlying ICT infrastructure. These solutions shall be appropriate to the relevant circumstances and risks. Furthermore, the requested European standards or standardisation deliverables shall take due account of the essential
requirements for products with digital elements as listed in Annex I of the EC proposed Regulation on horizontal cybersecurity requirements for products with digital elements (CRA proposal of 15 September 2022).

Discussion: identify existing standards and analyse the gaps (new standards) that still need to be developed to respond to the AI Standardization Request from the European Commission.

Groups
Tags

Standardisation of Trusted Execution Environments / Confidential Computing

Body

Until recently, data protection relied on two pillars: protection of data at rest and in transit. However, data remained unprotected during processing, leaving it vulnerable in shared computing environments, such as cloud computing. More recently, this shortcoming was addressed by Trusted Execution Environments capable of executing arbitrary code. Today, any user can leverage the capabilities of Trusted Execution Environments to protect data in use, closing the end-to-end data protection cycle.

Currently, all major enterprise server vendors have announced Confidential Computing solutions: AMD (with the SEV-SNP technology), ARM (with the CCA technology), IBM (with the PEF technology) and Intel (with its SGX and TDX solutions). Moreover, confidential computing capabilities have been announced for GPUs by NVIDIA. Alas, the architectures and approaches for confidential computing standardisation are diverse and often incompatible.

This growth in confidential computing deployments has led to a broad and diverse need in standardisation. Today, standardisation around software support for confidential computing is done in the Internet Engineering Task Force (IETF), namely the Trusted Execution Environments (TEEP) workgroup and Remote Attestation ProcedureS (RATS) workgroup (WG). Both groups already have adopted documents: Trusted Execution Environment Provisioning (TEEP) Architecture (RFC 9397) and Remote ATtestation procedureS (RATS) Architecture (RFC 9334). Moreover, there are 15+ additional documents under active development.

Along with IETF, the Confidential Computing Consortium and its individual member organizations are actively working on promoting the adoption of Confidential Computing. One such initiative is the CSA Confidential Computing working group, which recently started work on adding Confidential Computing considerations in the CSA Cloud Control Matrix.

The Confidential Computing technology will continue evolving and being adopted as more cloud deployments do hardware upgrades. This will in turn require further integration with existing standards and control frameworks both from international standards organizations (such as IETF), industry consortia (such as the CCC) and national or international regulators (ENISA in the EU or NIST in the United States of America).

Groups