Technical notes on security

The public-key algorithms widely deployed today (RSA, elliptic curves) rely on mathematical problems that sufficiently powerful quantum computers could solve efficiently. In 2024, NIST finalized its first post-quantum cryptography standards (ML-KEM, derived from CRYSTALS-Kyber, for key exchange, and ML-DSA, derived from CRYSTALS-Dilithium, for digital signatures), marking a decisive step toward widespread adoption.

The risk isn't limited to a theoretical future scenario: encrypted traffic intercepted today can be stored and decrypted retroactively once sufficient quantum computing power exists — the so-called "harvest now, decrypt later" strategy. Data that must remain confidential over the long term (trade secrets, health records, sensitive government data) is directly at risk, which is why preparation should start now rather than after the threat materializes.

Preparing doesn't mean migrating in a rush, but rather adopting a crypto-agility approach: mapping existing cryptographic usage, identifying data with long confidentiality horizons, and designing architectures able to integrate new algorithms without a complete overhaul.

The vast majority of security incidents affecting IaaS cloud environments result not from a flaw in the provider's service, but from a configuration error on the client side — a reminder of the cloud's shared responsibility model: the provider secures the underlying infrastructure, while the client remains responsible for configuring their own resources.

The most common gaps found in audits: overly permissive network rules that expose administrative services directly to the internet, IAM roles accumulating excessive privileges due to a lack of periodic review, storage volumes left publicly accessible by default, and missing or non-centralized logging that delays incident detection.

Regular configuration reviews, a least-privilege policy applied to identities, and clear network segmentation between production and test environments already reduce a large part of this exposure — even before considering more advanced detection tools.

An automated vulnerability scanner remains a valuable tool for quickly covering known, well-signatured flaws — classic injections, outdated components, missing security headers. It quickly reaches its limits, however, against business logic flaws: bypassing a checkout flow, privilege escalation through manipulating a resource identifier, or chaining several minor weaknesses together to produce a critical impact.

This type of vulnerability can only be found by understanding how the tested application actually works from a business standpoint, actively manipulating its flows, and thinking like a motivated attacker rather than applying a list of generic signatures. That's precisely what a manually conducted penetration test covers — as a complement to, never a replacement for, automated tooling.

A useful pentest report goes beyond a list of technical flaws: it prioritizes findings by their real impact on the business, with remediation recommendations that technical teams can act on directly.