PCI Compliance and the Intel AMT Vulnerability

By David Gamey - 15 May 2017.

Tags:

blog
pci
x

On May 1st a critical new and possibly unprecedented vulnerability was announced. The flaw in Intel's Active Management Technology (AMT) firmware will be difficult to deal with, in part, because most organizations are not setup to rapidly deploy firmware updates across large numbers of systems. The feature is supported by almost a decades worth of Intel chip sets, firmware, and OEM customization. We expect the vulnerability will have significant impact on organization's security and compliance programs. It is imperative for organizations to ensure they carefully manage the risk from AMT.

We've been closely monitoring developments with this and are including reference links to articles and resources. We highly recommend a number of Must Reads (below) that include Intel's guidance and SSH's tracking page that contains a wealth of information relating to this.

Understanding this Vulnerability

Systems that are most at risk have a) vulnerable chip set and firmware; and b) the AMT functionality provisioned on the hardware. Intel's diagnostics answers part a). There are a number of diagnostic tools available to assess part b) including commercial vulnerability scanners such as Nessus, Rapid 7, and Qualys. Even Nmap can identify systems that may be at risk.

We were curious about the vulnerability and set out to demonstrate it so that we could get the feel of it. We selected a laptop with a vulnerable chip set that had not been provisioned for AMT. Next we set out to provision it for testing. Once enabled, we were able to easily reproduce the exploit and observe it in operation. As expected, host based firewalls provided no protection and we were able to remote into running systems. We were also able to remote into systems that had been shutdown. This last capability is both powerful and disturbing. Even though this functionality is documented, on a gut level it is still somewhat unexpected.

Because the vulnerability lives in the firmware and chip set, organizations must assess the risk more broadly than they are used to with most software bugs. Additionally because patches will need to come from the OEMs, organizations will have a more complex task of coordinating, prioritizing, and implementing updates which may not be available for weeks and may not be available for all systems. Many organizations will need to consider interim mitigation measures. Affected systems could include VM Host systems, non-windows systems, and even some appliances in addition to Windows servers, workstations, and laptops. Organizations that under estimate these characteristics could be in for some unpleasant surprises.

What to do Now

Organizations need to immediately asses their exposure and risk and then follow-up with a prioritized plan.

Undertake a focused discovery exercise to identify all of your vulnerable and potentially vulnerable systems. Don't exclude systems based on assumptions.
Analyze and prioritize the results based on risk factors such as visibility (internal/external), system sensitivity, etc. Perform this exercise for both the vulnerable and potentially vulnerable groups.
Develop specific remediation/mitigation strategies for each group and risk factor. Roll these out on a priority basis. Ensure you loop back to further investigate systems that show signs of potential vulnerability.
Consider stop-gap measures including specific IDS monitoring and additional network firewall level firewall rules.
Monitor and confirm remediation.
Keep records of these activities.

Don't Worry About the Future

We'd be surprised if this is the only security bug in the Intel Management Engine. And we're certain that this will be the focus of much new security research. Going forward, organizations should

Make sure AMT and ME are on their vulnerability management radar
Strongly consider turning AMT off and putting in place processes to ensure it doesn't creep back in
If AMT is needed, implement best practices to secure it and consider other mitigation to limit risk

Will Systems Need to be Replaced?

While this is possible, for most organizations we wouldn't expect this drastic an action will be required for most of their systems. The specifics will depend on many factors including equipment age, OEM, exposure/risk of individual systems, and mitigation applied. You should expect that your mileage may vary.

What about PCI Compliance?

Do NOT try and explain AMT away by arguing that PCI doesn't apply to server hardware just because it it doesn't explicitly call it out. Nor should you justify lack of action by assumptions. These approaches will not hold up to scrutiny. If AMT leads to a breach, the forensic investigation will conclude the organization was not compliant.

Do have an active risk management plan active and in play supported by evidence (e.g. inventories/discoveries, analysis, decisions, recommendations, progress, etc.). The plan needs to be risk based and prioritized. If there are constraints on patch availability or patching logistics, implement other mitigation. Preventative controls are great if they're available, if not, ensure you can detect and react. And lastly, if you need this functionality going forward, you will need to figure out how to ensure it's compliant with applicable requirements (e.g. changing default credentials). This is the best response.