The recent high-profile “Meltdown” and “Spectre” security event did more than expose newly-discovered problems in processor architectures dating back decades. It also exposed gaps in the Security Lifecycle Program for many organizations, possibly even in your own.
Month: January 2018
How to approach KPTI remediation
If you are in I.T., you’ve heard about Meltdown and Spectre by now. So – what are you going to do about it?
- Don’t panic, follow your existing High Priority Security Patching processes.
- Start assessing, in your test environment, the performance impact of patches against your performance-sensitive workloads, especially those with heavy disk I/O or network I/O. (Red Hat customers – check out our assessment of performance impacts using our patches). Make sure you are aware of the new “nopti” kernel parameter, but be *very* judicious in it’s use.
- Prioritize multi-user systems, especially if any potential users are not trusted.
- Prioritize patching of shared compute resources, such as public or private clouds, especially where the host is carrying workloads (applications, VMs) from multiple security or compliance domains.
- This is not (yet) known to be remotely exploitable, so systems that are not sharing resources and are not accessed by multiple users can have a slightly lesser priority. Given the performance impact referenced in #2 above, and given that performance-sensitive workloads are often run isolated from other workloads, balance an appropriate amount of time in testing the impact of the patches to your workload.
So, don’t panic, follow process, understand the impact to your environment – just like you should in any security event.