What is Foreshadow, and How Can You Overcome this Vulnerability?
Earlier this month it was revealed that another vulnerability – the fourth – was discovered in Intel’s x86 chip architecture. Researchers in Belgium originally alerted Intel to this flaw, initially dubbed Foreshadow NG. Intel subsequently discovered an additional Foreshadow flaw in January 2018 but did not release that information publicly. The industry is just hearing about these vulnerabilities because organizations like Google, Microsoft, and others are now attempting to roll out patches to address them.
Security professionals are especially concerned about the Foreshadow vulnerability because it targets the data that resides in SGX. Fortunately, SGX is only found in a portion of deployed systems, such as workstations and low-end servers; however, it is still a sizable percentage of the market. All of this casts a cloud of uncertainty for technology providers. It is now inevitable that more vulnerabilities will be found, leaving enterprises and cloud providers to wonder how they can ensure application (data) security.
So far, the official word is that no attacks resulted from Foreshadow. However, given the length of time between its discovery and a proposed patch, it’s not possible to be sure that there were no Foreshadow attacks. Unfortunately, we are years away from a permanent fix in the x86 architecture, which leaves it open to these side channel vulnerabilities – following Intel’s tick-tock approach. Fortunately, there are alternatives that are better and more secure than SGX, and still work inside existing servers.
Gaining access to SGX is a big deal because it is the area of the chip that protects the data inside a system with a “virtual fortress,” making it inaccessible if the server becomes compromised. In short, Foreshadow enables an attacker to create a “shadow copy” of an SGX enclave and render the fortress useless. This allows for the unsealing of keys, enabling the modification of data, and then resealing it. With the extracted sealing key, the data owner cannot detect the modification. This cuts across not only on-prem server/system memory, but public cloud environments as well.
What can we learn from Foreshadow?
The good news is that Foreshadow was discovered by a friendly source, not the result of a malicious attack. There have been far too many times when data breaches were discovered long after high-value PII/PHI data was compromised and severe damage was done. Even so, Foreshadow further highlights a persistent problem with current breach approaches:
- No system is immune to breaches – so threat prevention and detection is not an effective approach.
- Patching can work, to certain degree, but only if you’re willing to take on the additional time risk between when the vulnerability is reported and when a patch is released.
- Storing keys or high-value data on an encrypted server, or storage device that is using that data, or encrypting with only one key is a single source of failure.
Current security approaches aren’t working
We’ve all come to the conclusion that every organization is a potential breach target. Why? Because the standard approaches are not working. Even large enterprise companies, like Target, Equifax, and Home Depot are not immune. They have large InfoSec teams to protect the data, yet even this isn’t enough to prevent the inevitable breach.
Patching is a common way and in most cases the only way of addressing vulnerabilities. Yet there is always a delay. For instance, Foreshadow was first reported in January 2018, with microcode patches that were available in the June timeframe and OS patches that are rolling out now (August). Luckily, in that eight-month span between discovery and “fix,” there hasn’t been a reported breach attributed to Foreshadow.
However, organizations were likely on pins and needles with their fingers crossed, hoping that they were not targeted in the meantime. In addition, since the x86 flaws are in the actual chip design – meaning the hardware – there is not a definitive fix. Any true fix would come in a future chip release, and since Intel follows its tick approach for chip releases, this means there would be typically years between those on a roadmap. Given the popularity of the x86 CPU, this leaves millions of servers at risk with the only possibility of a fix being a full rip and replace sometime in the future.
Perhaps the biggest challenge for the market to address is how and where high-value data is secured/encrypted, stored, and accessed. The industry has widely accepted solutions like SGX and encrypted drives. These, combined with the standard threat prevention and detection, have lulled the industry into thinking it is doing all it can, and they are certainly following best practices but clearly, it’s not enough.
The nearly nonstop breaches are proof of this, and it’s more important than ever to get a handle on the situation given the fact that more and more U.S. states, industries, and countries are implementing data privacy regulations such as GDPR, 23 NYCRR 500, California AB375, HIPAA, and more.
New challenges call for new security tools
At CSPi we have followed a different path. Our recently announced release of the ARIA Key Management Server (KMS) and ARIA micro Hardware Security Module (HSM) applications are specifically designed to address these issues.
- ARIA microHSM is a bundled solution consisting of a virtualized HSM application and a PCIe based Secure Intelligent Adapter (SIA). This solution:
- Securely caches keys away from the Intel CPU, ensuring that the encryption of critical application data or transactions involving PII/PHI is protected in the event of a breach.
- Handles close to one million operations per second – ten times greater than appliance-based HSM solutions.
- Generates encrypted traffic at up to line rates of 50 Gbps – ten times greater than its nearest appliance-based competitor.
- The ARIA Key Management Server (KMS) application serves and manages encryption keys associated with HCI deployments, including VMware® vSPHERE 6.5, enabling both VMware and vSAN encryption. ARIA KMS:
- Is based on the KMIP 1.4 standard and works with KMIP-based clients provided by VMware vSAN™ and other storage solutions.
- Deploys in minutes, and is FIPS 104-2 level 1 compliant.
- Is highly available where at least three KMS instances will act as one – providing back up to the primary key server if one should be disabled.
- Can be installed on the Myricom Secure Intelligent Adapter (SIA) for a solution that can provide keys locally or to the cloud.
- Myricom SIA is a 25/50G PCIe network adapter card that can be deployed in any cloud or on-premises servers. This solution:
- Provides a TrustZone that can generate and cache keys for rapid execution directly within a hardened compute environment.
- Meets FIPs 140-2 Level 3 compliance.
- Is powerful enough to offload the entire set of crypto-functions from the applications, encrypting and decrypting the data as required as it moves across the PCIe bus.
- Scales to serve up to tens of thousands of keys per second, which is a necessity for compliance requirements.
Interested in learning more, and what makes CSPi solutions different? Download our white paper, “How to Secure DevOps Across Any Environment,” visit our security solutions web page, or contact us today.