Mehran Farimani is CEO of RapidFort, one of the fastest-growing cybersecurity companies securing the global software supply chain.
getty
Financial institutions are under increasing pressure to prepare for post-quantum cryptography as global bodies like the G7 and Europol urge organizations to plan now for a complex, multiyear transition beginning toward the end of the decade.
This urgency follows the standardization of new quantum-resistant encryption algorithms by the National Institute of Standards and Technology (NIST), which provide a clear path forward but will take years to implement across modern stacks.
Considering the value and sensitivity of the data financial institutions hold and transmit, and the fact that attacks to steal information for future decryption are already underway via harvest now, decrypt later (HNDL) threats, the need to transition to post-quantum cryptography (PQC) standards is urgent.
However, too many institutions are working in the dark because most environments aren’t cryptographically visible. The challenge isn’t just adopting post-quantum algorithms; it's identifying where legacy cryptography lives across container images, third-party libraries and bloated software stacks.
You cannot migrate what you cannot see, and by the time you achieve that visibility and reduce your attack surface, the window to prepare will be much shorter than expected.
While organizations begin migration, adversaries aren’t waiting for Q-Day, which is when quantum computers will be able to break current public-key encryption. Bad actors are preparing now with HNDL attacks, which involve stealing encrypted information with the aim of cracking it once quantum capabilities arrive.
Financial data is particularly vulnerable to this tactic, which has become widespread among malicious actors.
The SEC has cited projections that Q-Day could arrive as early as 2028. Forrester has called a practical quantum computer “plausible” by 2030. Whether the timeline is two years or seven, the data being exfiltrated right now will still be sensitive when it arrives.
Containers are known to contain a range of vulnerabilities, making them a common entry point for adversaries when attempting to move laterally.
If containers are so often the first target for malicious actors, it stands to reason that they should be in the first line of defense. For security and DevSecOps leaders, they are also where cryptographic sprawl is most present and easiest to deal with.
Container images are built in layers, and each layer brings its own cryptographic dependencies and risks. A base image pulled 18 months ago might carry an OpenSSL version with known cipher vulnerabilities, and a third-party package added during a crunch might ship with its own dependencies, some of which implement legacy encryption standards.
During updates and continuous development, updated or added components can reintroduce deprecated components across dozens of services before it is noticed.
Without clear, continuous visibility into these hidden dependencies and unnecessary packages, organizations end up inheriting cryptographic issues they don’t realize are there.
The most important factor in the transition is visibility into and security of the software environment. A software bill of materials (SBOM) is easy to produce and provides the first step via a machine-readable list of software components that make up your software stack.
The Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA) and 19 international cybersecurity organizations are already promoting SBOMs as essential to securing the digital supply chain.
But for PQC readiness, the value of an SBOM is not the inventory; it is using that inventory to eliminate what is unused during runtime. An SBOM is only as useful as the reduction in scope it enables: The fewer components requiring migration, the smaller your attack surface becomes.
Unnecessary packages and redundant components don’t just expand the attack surface; they clutter your view. Before you can begin migration, you need to know that what remains is necessary for the system or platform to properly run. That means reducing software sprawl first: identifying and removing unnecessary components and ensuring the inventory reflects the real production environment.
Organizations that skip this step may end up implementing cryptography across unnecessary software, increasing operational complexity and expanding exposure.
Visibility efforts also need to extend beyond the container. Dependencies don’t stop at the container, but they extend into other components in the software supply chain, including third-party integrations, SaaS dependencies, shadow IT and the upstream registries containers ultimately rely on.
If a dependency your container pulls from upstream has a vulnerability, that exposure will be carried throughout your environment. PQC migration requires tracing those dependencies and updating the cryptographic libraries and protocols they rely on, not just the components where encryption is most visible.
Post-quantum migration is a multiphase effort and won't happen quickly. There are other steps involved in becoming quantum-ready, such as developing a clear implementation plan and testing PQC algorithms in a sandbox environment.
Organizations also need to ensure they can transition seamlessly from one set of algorithms (i.e., there are several NIST PQC algorithms and vendors) to another.
But it starts with visibility into your entire environment, including those components at the furthest reaches of the enterprise, such as containers. Transitioning to PQC standards requires that organizations establish a strong foundation. The key steps include:
● Gain SBOM-level visibility. Build a complete inventory of software components and dependencies across your environment.
● Remove unused software. Shrink the attack surface and reduce migration scope by identifying and eliminating unnecessary runtime components.
● Eliminate known security vulnerabilities. Introduce hardened and curated images that eliminate the common vulnerabilities and exposures (CVEs) in the stacks.
● Apply this process to development. Extend this process continuously to any new software introduced into the product, system or platform.
Finding the locations of every component that needs PQC algorithms is no easy task, but it can be done. Financial institutions that haven’t made progress on their own transitions should start now if they intend to meet the transition timelines already taking shape across the industry.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。