Protecting Host/ Endpoint Application Data
For well over 20 years, data security providers have been developing ways to protect, “unstructured content” – application data files, end-user documents, and email messages. Solutions have included desktop data encryption, document tracking, Data Loss Prevention systems, and other techniques delivered in various forms.
Though nation-state sponsored Intellectual Property theft is not new, recent public awareness has increased, perhaps due to the growth of high-visibility doxing and ransomware campaigns. This has motivated renewed interest in endpoint data protection, previously set aside due to cost, complexity, and marginal effectiveness.
In 2014, DefiniSec set out to create a solution that would allow IT to maintain protective control over sensitive host application data, reducing the frequency, scope, and impact of data breaches from nation states, hackers for hire, electronic crime groups, hacktivists, and other Advanced Persistent Threat sources. We combined lessons learned, emerging technologies, and IT trends to create Simple Security: Protect (SSProtect).
SSProtect/ KODiAC
SaaS Architecture
SSProtect uses a SaaS architecture comprised of the :Foundation Client (Client) and KODiAC Cloud Services (KODiAC). The Client is a small, 7.5 MB desktop application that uses a self-service deployment model compatible with common Enterprise deployment and management facilities. KODiAC runs in the cloud, deployed and maintained by DefiniSec, though it can be deployed by others in isolated and hybrid settings as well.
The Client exposes the context-specific SSProtect UI based on an authenticated User Role and the active set of SSProtect component services configured for the Account. The Client also monitors and controls activity associated with sensitive content, protecting and managing data through coordinated execution with KODiAC.
KODiAC implements patented cryptographic offloading methods as a service (KODiAC Encryption). SSProtect, as a system, leverages this core to layer optional Incident Response and Recovery service components on top. This delivers a platform that corporate IT teams can use to maintain Business Continuity before, during, and after a breach.
Minimizing Impact
Developing SSProtect in SaaS form presents numerous challenges, and the unique aspects of KODiAC Encryption demand specific innovation to achieve commercial viability at scale. In this article, we will focus on the need to non-intrusively apply controls to host application data without detrimental impact to users, administrators, software, services, and infrastructure.
Though encryption is a subset of protection, let’s take a look at traditional offerings. Most have required manual end-user encrypt/ decrypt execution, which includes the need to manage keys so that encrypted content can be shared with intended recipients. Over the years, providers have attempted to automate and/ or wrap these details, and results have often limited flexibility, effectiveness, or both.
This has not been well-received since end-user intrusiveness remains one of the greatest barriers to adoption of host-based security technologies. At the same time, imposed changes to end-user workflows are not only counterproductive, but also error-prone. This increases training, deployment, and administrative costs while motivating users to find ways around limitations and inefficiencies. End-Result: Expensive, Intrusive, Ineffective.
Applying Protection Directly to Application Data
Monitor and Intercept File I/O
To realize a practical solution, we need a way to monitor and intercept end-user access to sensitive data so we can enforce/ add/ remove/ modify protections without impact to native application use. But, for starters, how can we differentiate between host-local service operations and interactive end-user activity?
Option: Application-Specific Programming Tools
We could consider the idea of building specifics into the :Foundation Client to recognize common end-user operations, leveraging programmatic toolkits/ APIs associated with popular business software like Microsoft Office and Adobe Acrobat. We’d then have to also consider File Sync and Sharing technologies from Box, Citrix, Dropbox, Google and Microsoft. There are still others who build document management solutions using AWS S3.
The list grows rapidly, which is why this approach is best suited for markets that utilize common technologies for many related tasks. Results, however, tend to be fractured in that one vendor offers advanced support when another does not. This turns into a race to keep up with changes, which toolkits complicate by lagging product updates. It also requires additional spending to find and hire developers with expertise in specific areas.
This was never a serious consideration for us given our primary goal of Unifying data protection and management across disparate applications, technologies, and architectures both today and tomorrow.
Option: Use a Specific File type for SSProtect’d Content
We could protect application data files and place results in a new Windows Filetype, for example changing the file TargetFile.docx to TargetFile.docx.ssprotect. Access to this .ssprotect file would invoke our :Foundation Client handler which could be extended to determine the intended managing application to launch (as a proxy).
We knew this wouldn’t work, since our first prototype used this approach at the beginning. After reviewing options to address the shortcomings noted in this section, we quickly recognized it for the non-starter it was.
The loss of contextual rendering in File Explorer has a greater impact than expected: Word documents, for example, were no longer interpreted as .docx files. This robbed us of the familiar icon in browser views, sorting by filetype, and in some cases we weren’t sure what file we were looking at because we used the same Filename with different extensions to represent related data in different formats (thus holding different details). Though we can extend File Explorer to address some of these issues, we’d always fall short. It just doesn’t work.
More importantly, we lose the ability to access content using anything other than a double-click from File Explorer. The Backstage View in Microsoft Office, for example, would not be usable for accessing protected content. Other application, “File/ Open” operations would fail as well. This also removes our ability to right-click in File Explorer and see context-specific operations, for example, Convert to Adobe PDF, for supported file types (when Acrobat DC is installed). This applies to other third-party software that’s used to improve productivity.
The mechanism we chose, below, works for these – and many other – familiar and necessary end-user workflows.
Decision: Use a Filesystem Driver
We could us a filesystem driver to achieve our goals, eavesdropping on File I/O to apply our constructs and at the same time enforce desired Policy without unintended impact to the calling application. This is exactly what we needed, and we chose to leverage a proven, robust, secure and cost-effective offering from Callback Technologies.
However, as you shall see, our needs require tremendous ingenuity in order to leverage FIle I/O callbacks and notifications to create a generic and reliable mechanism…
Detecting Access to Application Data
Navigation to Monitored Content
To illustrate our challenge, let’s use FileMon, a sample application delivered with CBFS Filter, to show File I/O associated with simple operations against a single test file, c:\_test\TestFile.docx.
In this trace, we’ll start FileMon, open File Explorer, and navigate into and out of our target, c:\_test:
By simply perusing the target in File Explorer, we encountered seven separate Open operations by two different processes. If we had more than one file in the target folder, we’d see something similar for each.
Open, Modify, Save/ Close
Let’s look at another progression, this time a simple Open, Modify, Save/ Close operation. As before, we’ll start FileMon then navigate to the target with File Explorer. We’ll double-click to Open, follow with a simple change, then terminate the application (Microsoft Word) and Save on the way out.
The resulting progression contains over 700 File I/O operations across five processes and several new temporary files inside the c:\_test folder. The progression includes multiple instances of Open/ Cleanup/ Close by Explorer, scattered throughout and against all files except the backup .wbk (see below). SmartScreen executes a few access operations on the target, while MsMpEng.exe (Windows Security) operates on ~$stFile.docx and TestFile.docxZone.Identifier. The set of files associated with these scattered Open/ Close operations includes:
Read/ Write and Save/ Close operations are similarly scattered/ interleaved with non-Word operations. Save/ Close includes Delete to remove temporary files, while Read/ Write aspects of the progression include several RenameOrMoveFile operations on the target document. Part of a Read sequence is shown here, on a temporary file:
This progression is specific to Word on our host: Progression on other hosts will yield different results.
In-Place Encryption
Conversion and Managed Access
When operating on SSProtect’d content, the target file is encrypted. We’re looking for a means of identifying the application’s Open operation that’s followed by Read to pull in data file content so we can Pause File I/O and carry out SSProtect Conversion. We use the Conversion moniker because we aren’t unprotecting a secured file, we’re executing a Managed Access operation to controlled Plaintext. This requires SSProtect to do the following:
1. Pause the pending Open and (on occasion) prompt the end-user for SSProtect Account (login) credentials
2. Dispatch Authentication credentials to KODiAC (cloud services), then process resulting Account details
3. Prompt the end-user for fine-grained 2FA credentials (or calculate/ provide software-based OTP details; required)
4. Dispatch 2FA credentials, together with the decrypt request, to KODiAC for cloud authentication/ authorization
5. Start and coordinate patented KODiAC Encryption, providing Integrity assurance and data isolation
6. Execute multiple 2-phase commit operations to securely replace Ciphertext with resulting Plaintext
7. Unblock the pending Open operation to permit subsequent Read requests that pull in Plaintext
8. Monitor ongoing File I/O to block other external processes from accessing Plaintext, instantiating Managed Access
SSProtect reverses this on Save/ Close then unblocks subsequent File I/O for normal file use. We call Conversion to Plaintext, subsequent Managed Access, and Conversion back to Ciphertext, In-Place Encryption. For further clarification, refer to the Glossary of Terms at the end of this article.
Finding the Proper Open/ Read Instance
If we scroll through FileMon Open/ Modify/ Close output to find WINWORD.EXE, we’ll see multiple successive Open operations on the target (and a temporary file), partially selected here:
There are other aspects to NotifyOpenFile not presented in the UI, though they don’t shed much light on what Word is actually doing. Does it matter? Only if it helps us understand what we need to do.
As we continued to investigate with other applications, we of course encountered a great deal of variety in how data files are managed. For example, some software maintains Open handles for data files while other software Reads data file content then Closes the file – even as you continue to work in their editor. in this case, subsequent Save operation executes yet another Open progression.
This of course begged the question: Is it even possible to do what we’re attempting, and if so, is the required effort justified by the end-results?
In pondering feasibility, it’s worth recognizing and noting that the Conversion summary leaves out more than a little information. SSProtect, the system, needs to concern itself with ongoing activities – perhaps the host is executing concurrent Conversion operations while KODiAC, on the other hand, processes requests from thousands of global users. KODiAC must also concern itself with availability, global replication, DDoS mitigation…
Key Separation and Isolation
Why Not Use On-The-Fly Encryption?
Back to our original questions, maybe there’s another way to get there? In fact, why are we looking for a specific Open operation instead of waiting for a Read operation, then transforming to plaintext on the fly? This is known as On-The-Fly Encryption (OTFE), and it isn’t sufficient for our needs.
OTFE allows an application to work with a ciphertext file by intercepting Read requests, decrypting to plaintext, “on the fly”, then delivering plaintext results for the Read response. This process is seamless to the application, which is reversed for Write operations.
This requires symmetric keys to be held in memory while the file is being used. This is diametric to the core value delivered using KODiAC Encryption, the patented offloading scheme we’ve referred to a few times before.
Operating System and Programming Framework Leaks
Despite all (proper) efforts to securely manage in-memory keys and properly dispose of them when finished, OTFE still risks more than a few opportunities for mistakes, defects, and attacker-coerced dynamics that expose these resources. This is most often the result of Operating System shortcomings, programmatic framework defects, and/ or application weaknesses. With continuous updates, what’s secure today may not be tomorrow.
SSProtect avoids the use of programming frameworks in all critical processing, and elsewhere as much as possible.
KODiAC Key Separation
KODiAC Encryption ensures that the host and the cloud do not, independently, have sufficient material to decrypt to plaintext. This is not the result of arbitrary limitations or program logic; the required materials haven’t been made available in one place. In fact, if someone could acquire every single KODiAC resource available to it, over time, then manually combine details in every possible way, it wouldn’t satisfy requirements to render plaintext.
This holds true at the host until someone or something authorizes Plaintext access. Re-encryption of course uses new keys.
This is a fundamental requirement that not only defines KODiAC, but also powers other SSProtect capabilities.
Multi-Party Consent Requires Host and Cloud Compromise
KODiAC key separation (and the underlying multi-party consent trust model) requires an attacker to breach both the host and the cloud in order to gain access to decryption keys that can render plaintext content. OTFE violates this premise by using keys on the host with stored ciphertext. This is insufficient in today’s landscape.
Protecting Against Covert Surveillance
KODiAC cannot, by design, access end-user plaintext as inferred by previous text. OTFE, alone, does not enable this type of key isolation and separation. Any attempt to substitute OTFE for In-Place Encryption runs the risk of violating core tenets required to maintain this model. When such principles are violated, recognition is often driven by investigating the reality of its’ consequences.
By adhering to key separation requirements, customers maintain protection from covert surveillance resulting from subpoena of KODiAC Service Provider decryption keys. As such, legal proceedings would have to include some form of customer contact, which then offers data owners the opportunity to seek remedy.
Central Control and Visibility
KODiAC Encryption requires KODiAC (cloud) service contributions, for example, the as-noted cloud-specific keys. The associated process is, by design, tightly coupled to data access auditing. This creates a precise and reliable usage record isolated from potential host compromise. SSProtect Reporting relies on these details.
At the same time, KODiAC Encryption offers the opportunity to securely store version-based instance data, which delivers reliable Backup/ Restore. SSProtect uses this for additional Continuity, Recovery, and productivity service component offerings.
Objective Disclosure Risk Reporting
Because KODiAC operates with central visibility and control, and because KODiAC contributes to the decryption of all managed content, and because KODiAC binds auditing directly into cloud transaction processing, SSProtect holds precise, reliable records that show exactly how, when, by whom, from where, etc. content was used.
This permits use of the protective promises from KODiAC Encryption to generate Objective Disclosure Risk Reports that provide the, “worst-case” potential disclosure scenario, at the press of a button. This is invaluable when responding to a data breach, supporting Incident Response and Recovery task prioritization based on Definitive insight into potential data disclosure. This facilitates effective notification to customers, partners, and vendors.
Effective Error Recovery
KODiAC Encryption provides more than the multi-party consent trust model anchoring layered SSProtect services, it also provides a means for rendering Plaintext content in a controlled, stepwise fashion. This empowers SSProtect to recover from incremental disruptions quickly, reliably, and almost seamlessly using numerous instantiations of something called a 2-phase commit.
If however an OTFE process was disrupted by attacker DoS, it would not have sufficient resources to maintain Data Integrity without reverting to backups – backups that would have to be generated independently.
This is yet another critical SSProtect requirement for effectively protecting and managing end-user data.
Bringing it Together with Adaptive Filtering
Performance Challenges
As we continued to better understand low-level application File I/O behavior, we had to keep performance at the forefront of our mind. Remember that we need to manage content stored almost anywhere, “on the host” i.e., in host-attached mass storage. If our processing takes too long when looking at – and discarding as unrelated – normal Windows activity, we won’t have a viable solution.
Take for example a folder with 100 files in it, 50 of them SSProtect’d. If we refer back to the File I/O progression when navigating into and out of a folder, then apply results to 100+ files, it’s not hard to recognize the challenge.
Remember that our progression was generated on a, “clean” host. Corporate desktops often have utilities that tend to involve themselves in the types of things we’re doing. This introduces more processing overhead.
If, as a result, we need 4-5ms to determine that we’re seeing normal, everyday behavior unrelated to Conversion, and we have 50 protected files in a single target folder that we cannot, “ignore” as a result, we’re instantly adding 250ms of processing to a simple File Explorer operation, and that’s a relatively, “idle” consideration.
Expand this to the potential for thousands of SSProtect’d files while considering all the other things occurring on a desktop throughout the day. We almost instantly run out of headroom, and as such, have to be more than careful about how we detect, interpret, and process every single File I/O event.
Final Consideration: Is In-Place Encryption Worth the Effort?
We’ve talked about the challenges developing the generic mechanism to apply SSProtect controls to application data. We’ve considered the Performance impact of Managing files anywhere on the host. We’ve even looked at the value offered by KODiAC Encryption’s offloading and resulting Key Separation (which we’ll have more to say about in related articles).
We had to ask ourselves, well into our R&D efforts: Is continued pursuit justified, or should we punt and use the types of manual end-user procedures that we see with encryption/ decryption products? Is automatic Workflow integration that important? Some told us it was not, still others insisted it could not be done, and a few simply stated that it wouldn’t be worth the effort.
But the value of In-Place Encryption isn’t limited to reducing end-user workflow impact, it also supplements the need for KODiAC to maintain key separation and isolation. In-Place Encryption is also the critical component delivering continuous, in-use Plaintext data protection, in native application software.
As an integrated aspect of SSProtect, the value of In-Place Encryption is hard to quantify in concise terms. In general, it holds the potential to play a critical part in applying protective control across disparate systems. This helps IT consolidate administration and maintenance efforts while leveraging unique Incident Response, Recovery, and Continuity capabilities.
For these and other reasons beyond the scope of this article, and despite the seemingly insurmountable challenges in identifying a way to integrate with the noted Open/ Read File I/O progression, we chose to push forward with ongoing R&D when, in almost any other situation, we would have thrown in the towel.
Optimizing Performance w/ Adaptive Filtering
After seemingly endless engineering efforts, investigating, adjusting, re-iterating, and even in a few cases starting over, we were finally successful in developing a generic, reliable In-Place Encryption mechanism to maintain native end-user application workflows.
Performance was, as expected, the final challenge. The first real, functional mechanism was only capable of Managing a handful of documents/ data files before degrading mass storage performance to unacceptable levels.
After recognizing we needed to further separate processing into multiple stages, we created File I/O filtering logic to achieve the breakthrough we were looking for. The resulting technology, Adaptive Filtering, allows us to protect thousands of assets on a single host/ endpoint with almost no discernible performance impact.
Success, at last.
Practical, Unified Data Protection and Management
Adaptive Filtering and In-Place Encryption are Trade Secrets, whereas KODiAC cryptographic offloading (KODiAC Encryption) is patented. The integrated combination of these facilities allows us to deliver Unified Data Protection and Management, independent from applications and infrastructure, using a single system that’s easy to deploy, administer, and use: SSProtect.
Native Workflow Examples
In this final section, we’ve documented the details specific to a couple very basic use cases that highlight In-Place Encryption. For a video demonstration, head on over to our Demonstration Videos and scroll down to In-Place Encryption w/ 2FA.
Protect Content
There are many ways to add content to the protective scope SSProtect, and in this example, we’ll use the most simple process for a test file in a Dropbox (or other sync/ sharing solution) folder, TestFile.docx.
1. Open File Explorer and navigate to the Dropbox folder.
2. Right-click TestFile.docx then choose, SSProtect Activate.
3. SSProtect will display its Login dialog; choose your Profile and enter your Account Password and log in.
4. If presented with a 2FA prompt, insert your USB token and touch its sensor to proceed.
5. Observe that the File Explorer icon includes a new, red circle overlay indicating the file is SSProtect’d.
Securely Access Content
There are several ways to access content. Here’s one of them:
6. Double-click TestFile.docx from File Explorer.
7. If presented with a 2FA prompt (you’ve already provided Login credentials), insert/ touch your USB token.
8. Word will open and render TestFile.docx plaintext.
9. Observe that the File Explorer icon overlay is no longer present.
10. Try to copy the resulting plaintext file, TestFile.docx; SSProtect forbids it.
11. Change the contents of TestFile.docx then Exit Word: Save the file in the process.
12. If presented with a 2FA prompt, insert/ touch your USB token.
13. Notice that the File Explorer red circle overlay is again displayed.
14. Try to copy the resulting ciphertext file to another folder, for example c:\TestFolder; it will work.
15. Observe that the File Explorer icon for the new file is a yellow circle, an alternate SSProtect indicator.
Once SSProtect completes re-encryption to Ciphertext, it releases the secure channel enforced between Plaintext and the managing software application. As such, if you navigate to your Dropbox (or other sync/ sharing solution) version history (where available), you will only find plaintext for the file’s content prior to being SSProtect’d.
Application and Workflow Independence
Finally, let’s try a different workflow on the copied file (which assumes you have Acrobat DC installed):
16. In File Explorer, navigate to the new location, C:\TestFolder.
17. Right-click TestFile.docx and choose, Convert to Adobe PDF.
18. If presented with a 2FA prompt, insert/ touch your USB token.
19. Watch File Explorer and observe that the yellow icon overlay disappears.
20. Choose the name of your new PDF file to continue.
21. If presented with a 2FA prompt, insert/ touch your USB token.
22. Notice that the icon overlay associated with the copied target file reappears.
SSProtect doesn’t have logic for this activity, though it works fine. How? When Word attempts to access the SSProtect’d file, you as the SSProtect Data Owner asserted your physical presence and acknowledgment of the operation by USB token touch. This allowed Word to continue forward with plaintext, rendering the PDF.
This is in perfect alignment with SSProtect’s philosophy of supporting Trusted User activities. The software was designed to focus on inhibiting unauthorized access and/ or attempts by unauthorized disclosure. The result, though it requires manual follow-up to protect the new plaintext file format, maintains flexibility while carrying out related activities such as :Confidential integrity protection, :Assess Auditing, :Recover storage, and so on…
Glossary of Terms
The following terms are specific to DefiniSec and/ or SSProtect, and are used in this article.
:Foundation Client
The :Foundation Client is a small, 7.5 MB Windows application that runs in the context of the active Windows User, without elevated privileges. The :Foundation Client is responsible for presenting a context-based User Interface for the Authenticated SSProtect User. The :Foundation Client also coordinates File Explorer Icon Overlays that indicate SSProtect protection state. , and finally is also responsible for Adaptive Filtering, Conversion, and all Secure Communications to /from KODiAC Cloud Services.
Adaptive Filtering
Adaptive Filtering is a Trade Secret that innovates methods for accelerating and optimizing subscriptions to and processing of filesystem events such as Open, Read, WRite, and Close. Adaptive Filtering is, to most, a, “black box” technology that makes it possible for SSProtect to manage thousands of protected files on a single host computer at a time, without significant impact to host storage execution or perceptible latency when carrying out basic and certain operations, such as accessing SSProtect-managed content.
Adaptive Filtering adjusts on-the-fly, “adapting” to changes in the scope of Protected materials, to maintain consistently optimized performance that is essential when protecting/ managing thousands of assets on a single host computer.
Conversion
SSProtect Conversion is the act of transforming SSProtect’d content to/ from Plaintext from/ to Ciphertext, and encompasses encryption/ decryption, integrity protection, and the application of high-availability assurances that are part of SSProtect’d content.
In-Place Encryption
In-Place Encryption is a Trade Secret, and represents the user-centric view and experience associated with normal application access to SSProtect’d content. In-Place Encryption is carried out by the :Foundation Client coordinating KODiAC service execution, which includes end-user Identification, Authentication, 2FA, and Authorization followed by KODiAC Encryption to Convert Managed content to Plaintext that is then utilized with Managed Access. In-Place Encryption automatically, “completes” when the target data item or file is closed, carrying out the same noted activities though Converting from Plaintext to Managed Ciphertext.
In-Place Encryption utilizes KODiAC Encryption as part of its’ Conversion to/ from Ciphertext/ Plaintext (and vice-versa).
KODiAC
KODiAC is an acronym for Key Oriented Distributed Application Cryptosystem, and represents the system that implements (cloud) services delivering core SSProtect functionality – including the patented cryptographic offloading technique at the core of protection.
KODiAC Encryption
KODiAC Encryption is the patented (cloud) cryptographic offloading methodology that utilizes host- and cloud-specific keys to protect data. KODiAC Encryption includes Encryption and Decryption, i.e. can be part of Converting to Plaintext or Converting to Ciphertext. KODiAC Encryption is a subset of activity that makes up In-Place Protection.
Manage
SSProtect Managed data is Protected content within the known scope of an SSProtect Account or Organization.
Managed Access
SSProtect Managed Access is the act of working with Plaintext content under active control of the :Foundation Client, isolating Plaintext from Windows resources whlie permitted an application, launched by an authenticated and authorized user, to view and modify content.
Protect
SSProtect Protected data is content that’s been encrypted using KODiAC Encryption, which includes AES Encryption, HMAC Integrity protection, and other protective primitives that identify content without direct correlation to an SSProtect Data Owner.
SSProtect’d
SSProtect’d is an abbreviation for (the redundant) SSProtect Protected state, meaning content that has been Protected using KODiAC Encryption (and related cryptographic and supplementary protective facilities).