Skip to main content

Enterprise Digitalization and AI/ML Challenges

Enterprise Digitalization and AI/ML Challenges

Device to Cloud Challenges

  • Certificates issued to devices with unprotected private keys are unreliable.
  • Using asymmetric keys with unprotected private keys is insecure.
  • Session key exchange using insecure device credentials is not trustworthy.
  • Untrusted session keys used for data authentication and encryption pose threats.
  • Cloud-hosted services trusting “access tokens” issued by authorization servers using unprotected derived keys for device authentication are vulnerable.
  • Designing a zero-trust Enterprise or cloud networking architecture without quantum resistant key exchange and protection for shared session keys is doomed to fail.
Operational Risk Management in the Post Quantum Era

Device Manufacturer’s Challenges

  • No local secure element for key protection on brownfield and low-cost greenfield devices
  • No ubiquitous solution for resource constrained and resource slack device families
  • Inadequate resources (compute, memory, storage) for PKI key and certificate life cycle management on resource constrained devices
  • No writable storage to renew and persist keys/certificates on flash/HDD
  • Long-tail engineering and maintenance cycles for integration with PKI services, security protocols, and crypto engines
  • Managing cross-PKI systems from manufacturing (at factory) to onboarding (in the field)
  • Increase in software bill of materials (SBOM) cost and supply chain risk without revenue gain

End-User’s Challenges

  • High cost of PKI buildout and sustenance (NRE services and recurring annual charges)
  • High TCO to manage the supply chain of device identities, and key/certificate lifecycle
  • Dichotomy between IT/OT workflows poses challenges for NOC/SOC/field operators
  • Unclear return on investment (ROI) for device owners without extensive application re-engineering to use operational certificates broadly (from onboarding to provisioning and field operations)
  • Lack of in-house resources with requisite technical knowhow for IT/OT convergence
  • The build versus buy decision: “R&D with open-source” or “evaluate and buy a commercial solution”

Device Manufacturer and End-User Impasse

  • Major decision forks in the road for stakeholders
    – Certificate (PKI) versus Key (PKI less) based identity for device authentication
    – Agent versus Agent-less solution for ubiquity
  • Original Equipment Manufacturer (OEM) pushback on installing and supporting certificates and third-party/aftermarket agents
  • Application engineering for certificate-based authentication over secure transport protocols (e.g., TLS, IKE/IPsec, EAP) and use of cryptographic libraries for tokenized access controls (e.g., JWT, SAS)
  • Support for heterogeneous device platforms and OEMs
  • Pricing for device certificates expensive despite SaaS models
  • On-premise fulfillment is a challenge and requires solution engineering by end-users for integration with ecosystem services and interoperability between brownfield and greenfield devices
  • Cloud platform lock-in with vendor specific SDKs that requires extensive engineering by OEMs on GPOS & RTOS platforms
  • Quantum-safe PKI is a major implementation challenge on resource constrained devices (with multi-schema signatures and large certificates)

Device Risk Model

The risks in the operational technology (OT) ecosystem are different from threats in the information technology (IT) ecosystem because the means and methods employed are fundamentally different. Cyberattacks aimed at OT weaponize cryptography, exploit gaps in supply chain provenance, absence of identification and authentication, and insecure communications.

The risks in the operational technology (OT) ecosystem are different from threats in the information technology (IT) ecosystem because the means and methods employed are fundamentally different. Cyberattacks aimed at OT weaponize cryptography, exploit gaps in supply chain provenance, absence of identification and authentication, and insecure communications.
 
The risk model in OT is based on compliance, security and safety considerations. Every risk, unlike threats, has a tangible cost and benefit metric.
For example:

  • A cyber attack on cyber physical systems may incur a high cost of forensic investigations and recovery (device replacement) procedures
  • A long-lived device without instrumentation for cryptographic agility may require major in-field updates to remediate exposures to post-quantum threats
  • A device onboarded without explicit and verifiable trust for registration and remote updates may pose threats to the converged IT/OT infrastructure
  • A factory key (or default password) compromise may require a device recall or truck roll to remediate
  • A compromised operational key or access token may be exploited for device and/or data tampering
  • A device may be infected through supply chain content tampering (e.g., breach of the supplier’s secure continuous integration and content delivery processes)
  • A device with an expired certificate may cause long duration service outage
  • A device bricked by a ransomware attack may cause long duration service outage
  • A root kit or boot kit infection may require manual intervention with a factory reset to recover

Post Quantum and AI/ML Era

The White House (US)

By December 31, 2023, agencies maintaining National Security Systems (NSS) shall implement symmetric-key protections (e.g., High Assurance Internet Protocol Encryptor (HAIPE) exclusion keys or VPN symmetric key solutions) to provide additional protection for quantum-vulnerable key exchanges.

National Cyber Security Centre (UK)

In contrast with PKC [public-key cryptography], the security of symmetric cryptography is not significantly impacted by quantum computers, and with suitable key sizes, existing symmetric algorithms – such as AES – can continue to be used. It is also possible to mitigate the threat to key agreement by using pre-placed symmetric keys in addition to key agreement with conventional PKC. However, this approach brings key management and usability challenges, and is not suitable as a general-purpose solution for Internet communications.

GSMA

Both symmetric and asymmetric methods require pre-established, secure, authenticated communication channels either for pre-sharing secret keys or root certificates for PKI. Using pre-shared keys, to avoid the quantum threat, may be feasible in certain use cases. Indeed, SIM-based mobile communications already rely upon pre-shared keys to achieve key agreement and authentication between user equipment and the network. In Internet standards, the TLS1.3 protocol supports key establishment based on pre-shared keys. Additionally, the IKEv2 key establishment scheme used in IPsec typically uses pre-shared keys for authentication and allows pre-positioned keys to add quantum safety to key exchanges. … Systems (ERP) … To provide best security, symmetric key methods are recommended (e.g., pre-shared keys). … IETF … the Crypto Forum Research Group of the Internet Research Task Force (IRTF) is tasked with providing long-term advice to the IETF on cryptographic algorithms for communication protocols such as TLS, SSH or IPsec. In particular, the design of hybrid key exchange (i.e., a protocol mixing a time-tested standard cryptographic algorithm with a post-quantum one) for TLS is discussed, and several drafts have been published [108,109]. Mechanisms based on symmetric pre-shared keys have also been proposed to authenticate the communication parties in TLS 1.3 or to perform a key exchange in IKEv2.

Microsoft

As the first step and highest priority, we are ensuring the compliance of our existing symmetric key encryption and hash function algorithms. Symmetric algorithms, such as Advanced Encryption Standard (AES), and hash functions, such as Secure Hash Algorithm (SHA), are resilient to quantum attacks, and can therefore still be used in deployed systems. At Microsoft, we are already using protocols based on symmetric encryption, such as Media Access Control Security (MACsec) point-to-point protocol.

EU Artificial Intelligence Act

Cybersecurity plays a crucial role in ensuring that AI systems are resilient against attempts to alter their use, behaviour, performance or compromise their security properties by malicious third parties exploiting the system’s vulnerabilities. Cyberattacks against AI systems can leverage AI specific assets, such as training data sets (e.g. data poisoning) or trained models (e.g. adversarial attacks), or exploit vulnerabilities in the AI system’s digital assets or the underlying ICT infrastructure. To ensure a level of cybersecurity appropriate to the risks, suitable measures should therefore be taken by the providers of high-risk AI systems, also taking into account as appropriate the underlying ICT infrastructure.

IT versus OT

The risks in the operational technology (OT) ecosystem are different from threats in the information technology (IT) ecosystem because the means and methods employed are fundamentally different. Cyberattacks aimed at OT weaponize cryptography, exploit gaps in supply chain provenance, absence of identification and authentication, and insecure communications.
  • IT-OT Dichotomy (IT  ≠ OT, the inconvenient truth)
  • Complexity (PKI buildout, cross-domain, post quantum risks, high velocity key rotation)
  • Operational Cost (certificates, PKI management, truck roll for field services, operator training)
  • Resource Constraints (memory, storage, battery life, network bandwidth)
  • Low Latency (real-time)

Categorical Trust in Digitality

Categorical trust in digitality
  • Cyberspace Today (is a scary place)
  • The Evolution of Things
  • Top 5 Emerging Industry Trends in IoT/IIoT
  • Threats versus Risks (knowing the difference)
  • Protection versus Detection (understanding the difference)
  • Information Technology (IT) versus Operational Technology (OT))
  • Post Quantum (threats and innovation opportunities)
  • Digital Transformation (modernization challenges and pitfalls)