Meltdown and Spectre: when the CPU layer became a security problem

In the first days of January 2018, details emerged about two vulnerabilities - Meltdown and Spectre - affecting virtually every modern processor made in the last twenty years. Not a specific product, not a specific OS, not a specific application. The processor itself.

For people who think about IT at the business level, this is a non-trivial moment. Until now, the security model rested on an assumption: if the perimeter is configured correctly, the code is written correctly, and access rights are properly separated - the system is secure. Meltdown and Spectre say that assumption is incomplete.

What happened technically, briefly

Both vulnerability classes relate to a mechanism called speculative execution. For decades, processors have been predicting which code will run next and executing it in advance - to avoid idle time. This improves performance. Researchers found that through this mechanism it is possible to read data from memory you formally have no access to - including from other virtual machines on the same physical server.

This is not a hole in an application. It is a hole in the isolation model that was considered reliable.

Why this matters for business, not just IT

Cloud platforms operate on the principle of sharing physical resources between customers. Virtual machines belonging to different companies run side by side on the same hardware. Meltdown and Spectre in theory make it possible to read a neighbour's data - not with 100% certainty, not easily, but in principle.

This changes more than the technical conversation. It changes the question of what "isolation" in the cloud actually means - a concept that underpins the entire compliance discussion when working with sensitive data.

There is also the patching story. OS and cloud platform vendors released updates quickly. But some patches reduced processor performance by a few percent for certain workloads. For heavily loaded systems, that is not an abstract number.

What this means for infrastructure decisions

Several conclusions worth checking:

First - patch management at the firmware and microcode level. Most companies have a process for software updates, but far fewer track server firmware versions and processor microcode updates. After Meltdown/Spectre, this is a separate line item in vulnerability management.

Second - cloud providers and transparency. If the company stores sensitive data in the cloud, it is worth requesting confirmation from the provider that patches are applied and that next-generation isolation mechanisms are in use. Most major platforms have done this, but written confirmation is worth having.

Third - on-premise servers. If the company has its own infrastructure, the question of timely firmware and OS updates becomes more pressing. This is not a "someday" task.

What changed in the threat model

Until now, most companies built their threat models bottom-up: physical data centre security is treated as a solved problem, then we work with the network, OS, applications and data.

Meltdown and Spectre add a layer below the OS - the architecture of the processor itself. This is not a reason for panic, but it is a reason to revisit assumptions. If a system's security relies on virtual machine isolation guarantees - those guarantees now need to be verified more specifically than before.

Practical questions to check

If you are an executive and want to understand whether your company is in order:

1. Are Meltdown/Spectre OS patches applied to all servers - including on-premise and rented virtual machines?
2. Has server hardware firmware been updated to versions with corrected microcode?
3. If the company uses a public cloud - is there confirmation from the provider that the infrastructure is protected?
4. Has the performance impact of the patches been measured on critical systems?
5. Are firmware and microcode included in the regular vulnerability management process?

This is not panic and not a reason to rebuild all infrastructure. It is a set of checks that now make sense to run regularly - because the lowest layer of computing has become part of the security agenda.