In this article for SecurityWeek, Enveil CEO Ellison Anne Williams argues that Data in Use is the point of least resistance, outlining why it's critical to recognize this often-overlooked security gap and how organizations can lay the groundwork for protection.
If Left Unprotected During Processing, Data is Vulnerable to Various Attacks
No matter our pursuit, we’re all looking for opportunities to push the proverbial ‘Easy Button’ – to find a way to accomplish tasks in a timely, efficient manner while exerting the least amount of effort.
Attackers working to compromise networks and steal our data are no different; they are on the hunt for the most convenient point of entry. In security, the ‘Easy Button’ attack vectors are not always the most obvious as the well-known vulnerability points tend to receive a fair share of the security budget and are therefore reasonably (or at least adequately) guarded. The path of least resistance for an attacker is often an overlooked and unprotected portion of the enterprise environment such as the data processing layer – while it may take slightly more skill to access, knowing that such effort is highly likely to yield positive results makes it an open invitation for an opportunistic attacker.
Today, most organizations are aware of the need to secure their data while at rest and encrypt their data while in transit, but what about securing data as it’s being used or processed? Extracting value from data by performing actions such as search and analytics requires decryption, creating critical points of exposure. Of the three states of data within an organization that constitute the Data Security Triad (Data at Rest, Data in Transit, Data in Use), Data in Use has become a point of least resistance for an attacker. There is a major industry need to recognize this lapse and close the gap in data security by protecting data while it is being used to ensure sensitive assets such as Intellectual Property, PII, and other compliance-critical data are protected throughout the processing lifecycle.
The security industry is built on the basic assumption that there are certain fundamental protections computers promise, such as the belief that our core elements (like kernel memory) are safe. The chip flaw disclosures over the past year by Intel and others rattled this basic understanding, exposing a massive and pervasive memory attack surface. In a post on his popular Schneier on Security blog, security expert Bruce Schneier described the threat this way:
“Spectre and Meltdown aren't anomalies. They represent a new area to look for vulnerabilities and a new avenue of attack. They're the future of security – and it doesn't look good for the defenders.”
If left unprotected during processing, the data is vulnerable to targeted attacks such as RAM scraping, advanced persistent threats, perimeter and fencing attacks, insider threats, side channel attacks, and compromised data environments. While the chip flaws may be the most pervasive example of memory attack surface vulnerabilities we’ve seen to date, they won’t be the last. Memory exploitation is now ‘low hanging fruit’ for attackers. The exposure of these type of exploits, coupled with the near-daily headlines announcing massive data breaches around the globe, are shredding consumer confidence in the ability of major institutions to protect sensitive data. And since consumer trust may be the only company asset more valuable than the data an organization possesses, security teams need to act quickly.
It’s not that memory vulnerability or memory attack hasn’t existed up to this point, but we have typically seen it in more esoteric channels. For those of us who have spent time working in the national security space, this threat category is nothing new. But in the commercial world, it is shocking to comprehend such a broad and serious memory vulnerability across ubiquitous chipsets, which are inherent in almost every modern server or processor that is shipped out. Meltdown and Spectre introduced of a new class of security problems: the ability to exploit a vulnerability inherent in the foundation upon which our entire cyber security system is based. Naturally, this type of broad breach is appealing for attackers of all sizes and levels of sophistication.
What can be done to combat Data in Use as a point of least resistance for the attacker? Organizations should start by taking three steps to lay the groundwork for protection:
1. Know Your Data – Where is it? Why do you have it? Who has access? What is its value? Protecting your whole data environment should be the ultimate goal and not all data is created equal. Crown jewel data must be identified and prioritized. Basic data stewardship should be the first step to identifying potential challenges, ranking data according to level of security required, and allocating budget accordingly.
2. Evaluate Current Protections – What, if anything, is currently being done to protect data during processing? Are perimeter defenses in place? Basic access controls? Data in Use security solutions? Identify the strengths and weaknesses of your security posture as it relates to Data in Use in your overall security strategy. Ensure that protections for Data in Use are scheduled to be regularly evaluated as part of future risk assessments.
3. Recognize Your Options – There are a variety of technical methods being used to combat the Data in Use vulnerability including market-ready solutions supporting homomorphic encryption, secure multiparty compute, and secure enclave technologies. While some require systems changes, others are compatible with existing infrastructure and may be able to seamlessly integrate with your underlying environment.
Today’s security playbook is constantly changing and it is challenging to keep up with emerging threats and attack surfaces. Evaluating your security profile with a data-centric focus through the lens of the Data Security Triad can help eliminate commonly overlooked vulnerabilities such as those in the memory/processing layer. There’s too much at stake to continue business as usual.
Read the full article at SecurityWeek.