This is the second in a series of Insights articles that detail challenges associated with proper Host/ Endpoint Data Management.
This is our second in a series of articles discussing host-based data management. In our first entry, we introduced challenges with traditional file encryption, as a starting point. In this article, we examine a number of existing techniques that aim to address the problem, with an eye on issues related to operating on a compromised host - a widespread threat that can no longer be ignored.
But first, we'll stop and take a look at the always-important aspect of properly applying technology, and how perception plays a role in false security. We'll use TrueCrypt and its' reputation prior to EOL in 2014, and explain how a, "typical" deployment offered little more protection than any other file encryption.
From there, we'll look at solutions using On-the-Fly Encryption, Rights Management, caveats of Hardware Isolation, and finally we'll investigate improper use of 2-factor authentication.
This is a complex topic, and our goal is to provide the insight required to fully vet and qualify existing solutions to meet a variety of needs - all the while keeping in mind the reality of host threats.
Proper Utilization of Technologies
For quite some time, TrueCrypt was touted as the most secure endpoint encryption solution available. This open-source offering provided some pretty powerful capabilities, to be sure - and also deployed them correctly. Few offered such powerful potential - but in typical use, most of it was unrealized.
This is very important: A standard, simple, straightforward deployment of TrueCrypt offered no intrinsic value beyond any other standard host encryption solution. Though it focused on encrypting volumes and provided some (many actually, at the time) advantages over other disk encryption technologies, a simple/ straightforward deployment did little to inhibit host intrusion realities. As evidenced in our coverage of the Hacking Team breach, the attacker simply chose to wait for end-user login then heist unlocked data. Though it may have been unnecessary, it remains a valid technique in many situations.
More aggressive protection using a Smart Card, however, had the potential to achieve much more effective results (inhibiting password theft, another option). But to the less-informed, this wasn't the standard deployment, and thus a technology with strong potential was often deployed in minimal fashion.
Misperceptions and Misunderstandings
There's more to this issue when we consider communications and claims from vendors. During the course of our industry investigation prior to forming DefiniSec, we met with a number of sales representatives from large corporations selling encryption technologies. Our goals were to a) validate our own perception that there was a huge gap in coverage, which remains to this day, and b) learn more about why.
The reality: Many were (and many still are) unfamiliar with how host-local threats operate and/ or what's required to stop them. We'll talk more about this as we go along, but it's important to realize that well-meaning individuals, selling well-known solutions, were unaware of the underlying truth.
Each was, however, seasoned enough to recognize the probability that a high-end nation-state attacker could bypass their controls, and each also recognized that nothing was perfect about disk and/ or file encryption. In discussion, they started admitting to us that they didn't realize the impact of host-local attackers and how their systems worked (or more importantly, did not work) to inhibit data disclosure, leaks, and theft.
In our experience - and in their defense - this was a matter of training and/ or miscommunication. Nobody was happy to recognize the disconnect. This is very important: Most are truly motivated to do the right thing, and sometimes they simply don't know. Though not as widespread today as it was even 5+ years ago, due to rising awareness, it's still a major issue. Together with those that will tell you everything you want to hear, knowledge becomes critical.
On-The-Fly Encryption provides a translation layer between stored ciphertext and application plaintext. As software reads/ writes data from/ to localhost storage, a filesystem driver or other service uses (typically symmetric) encryption to convert ciphertext to plaintext and vice versa.
This results in an encrypted file that is harder to work with when pilfered from a host - but still, the encryption key is relatively exposed during this procedure. This allows local attackers with continuous visibility an opportunity to find problems with the implementation and built exploits to acquire the encryption keys. When done properly, an attacker can monitor On-The-Fly Encryption and acquire plaintext content over time - and in some cases, find ways to acquire files that aren't being actively worked and discover ways to offload then decrypt to plaintext.
This is the greatest risk to such systems: The ciphertext and decryption key(s) are present on the host at the same time, and thus exposed to potential local attackers. Though this can be done in a fashion that makes exploitation difficult, once breached, all information passing though this system becomes available to the attacker. Nation-states and high-end security practitioners are rather adept at finding and exploiting implementation shortcomings, and also then have the ability to overwrite any local audit entries that, because of the nature of execution, are almost always locally sourced and at least momentarily stored if not permanently. This inhibits proper response insight to attacks, and provides little in the way of knowing which parts of protected content have been compromised. The best, "guess", then, requires the assumption that all content has been subject to disclosure, complicating response.
This approach, alone, is insufficient to inhibit even moderately skilled attackers from acquiring what they want.
Rights Management solutions run the gamut in capability, and these variations have a significant impact on the overall effectiveness of the solution. These seeks to utilize Access Control as the primary weapon against attackers. Without proper access control permissions, content is unavailable.
The challenge comes with managing these permissions. First, localhost impersonation - the act of pretending to be someone you aren't by stealing a password, for example - offers limited protection given most malware can steal locally entered keyboard input. Second, many of these Rights Management systems are rooted in Enterprise Active Directory solutions, and for some time, the first and primary target of an intruder is the all-pervasive Domain Controller rights that are associated with those that maintain the system.
These issues can be addressed with proper 2FA, which is rare (see below), and also with a well-partitioned Access Control hierarchy. But still, and as always, there are variations of complexity inside this central theme. Some Rights Management solutions employ custom, secure viewers that host plaintext content in an attempt to isolate it from local attacks, closely managing the encryption/ decryption process. If, however, this is carried out locally - and with local keys - then the solution becomes considerably less robust.
Perhaps more importantly, audit information is often locally managed, and also locally stored. This will be called into question when the endpoint is compromised, which then makes it impossible to know what could have been - and what was - taken. As such, this calls into question exposure of all protected content, all at once. There may be suitable solutions that get this right with recent developments, and if you can verify this to be the case and live with the restricted coverage and compatibility of secure viewers/ editors, it may be a suitable solution for your needs.
Hardware-Isolated Encryption - TPMs, Smart Cards, SGX
Hardware isolation (minimally) seeks to inhibit sensitive resource exposure by maintaining isolation in specialized devices. You can submit requests to the hardware and obtain results - but you can't get to keys, for example, and operations aren't always carried out on the host (you only see the result).
TPMs don't perform encryption, though SGX and Smart Cards can. SGX in fact allows you to isolate more than just encryption since you can author code that executes in a trusted, secured enclave. Smart Cards were the first implementation of this reality, offloading cryptographic operations to isolate operations and keys. They were, and remain, somewhat challenging to deploy and administer. Though USB has helped in this arena, complications remain.
But what stops a localhost attacker from submitting the same request, on the behalf of an authorized, local user, once he/ she logs into to the local host?
Also note that a TPM and SGX cannot be decoupled from the host computer, whereas a Smart Card can be removed. This provides significant value in making certain the reality of authorized execution is physically asserted by the person holding the Smart Card. That, in the greater reality of a secure solution, becomes more than a little significant.
As such, these are largely supplemental solutions that greatly contribute to the realization of a secure solution overall. Though Smart Cards can offer a great deal of isolation, they aren't powerful enough to provide additional data management services like data sharing authorization, enterprise usage auditing, and other primitives that we'll later find to be critical to the realization of a complete secure data management solution.
Insufficient Application of Two-Factor Authentication
Before we conclude this entry, we have to address the reality of two-factor authentication. This brings us full-circle, back to the first principle we discussed regarding proper utilization of technologies and the following misperceptions associated with limited knowledge.
Two-factor authentication (most often) serves to provide assurances regarding one's identity. It requires the use of two mechanisms from three distinct classes: 1) something you know, 2) something you have, and 3) something you are. This provides multiple levels of protection and more importantly, can provide a physical presence associated with the actual resource carrying out some action with an identity.
In general, 2FA is deployed using either a) insufficient technology, and/ or b) used as a Login Gate, opening up access to a far-reaching degree of content that can then be acquired by an attacker lying in wait. We referred to this at the start of our article, but let's take a quick look at each before finishing.
First, fine-grained 2FA is required if you really want to maintain control over individual actions. When used as a Login Gate, you are opening access for an extended period of time, to a large amount of protected content. Attackers who wait for this event, then quietly offload content (or decrypt or what have you) are not sufficiently inhibited. It slows them down, and most breaches don't operate on a fixed timeline.
Second, when 2FA uses insufficient technology - such as the 2nd-factor via SMS that uses Google Authenticator - it's perhaps much more dangerous since it creates the false sense of security. Mobile devices typically share the same local Wi-Fi network as the host, and recent exploits have been developed to both trick end-users into giving up their 2nd-factor SMS passcodes if not bypass the mechanism altogether.
The best - and most appropriate 2FA solution - gets applied with each highly-sensitive operation, such as a decrypt/ access request, or re-encrypt/ save operation. This is also more effectively realized when using something like FIDO or even the old HMAC-based OTP USB keys. The latter suffer greater problems with deployment, administration, and properly protecting and validating the secret, which can be done with cloud crypto-offloading (see future articles) - but in general, they are still far superior to mobile SMS passcodes. FIDO of course, today, with a hardware component (rather than a phone), represents the more complete solution.
On this front, there are great strides being made that combine facial recognition, biometric fingerprint readers (which aren't hard to bypass just now, but they will improve), and the combination of heuristic detection to gain insight into the presence of an authorized user at a console. As these become more mature and improve in their ability to detect the physical operations of a user vs. malware, they may eventually offer realtime, continuous authentication of a user, which together with a data management solution, would offer a wholly non-intrusive method for authorizing sensitive operations.
We're probably not there today, but we're getting better, as a community. Stay tuned as FIDO and related technologies continue to improve.
As noted in our first entry, the primary goals of a secure host data management solution are to reduce exposure to a breach while maintaining constant, deterministic insight into what's been exposed. This allows you to both reduce losses from intrusion while minimizing the cost of recovery. Hopefully by now it's becoming increasingly clear that a fully integrated solution is required before one truly holds any semblance of control over managed content during localhost compromise. It can be done - and this is the nature of our ongoing series. And though we have yet to present diagrammatic or visual clarification, we will do so in upcoming entries.
So for now, going back to our anecdotes related to misperception, and taking these realities into consideration, it should be clear that it's important to verify, where you can, all claims, firsthand - or find someone you trust, who has validated systemic knowledge. No single technique or silver bullet will address the problem, and with complexity comes opportunity - but also with properly implemented components, a real chance at reducing breach impact.
This article was published January 21st, 2019