Support Center

Definitive Disclosure Risk

Last Updated: May 01, 2018 12:46AM PDT
This article explains SSProtect :Respond Definitive Disclosure Risk details associated with Disclosure Analysis Reports.

This article details concepts that motivate Definitive Disclosure Risk Ratings associated with Disclosure Risk Analysis execution, described in the article, Using :Respond.

Conceptual: KODiAC Cryptographic Offloading
Definitive Disclosure Risk Analysis is available as a result of cryptographic offloading realized by the KODiAC Architecture. This is the process of moving sensitive cryptographic operations (associated with protecting host content) to an isolated and highly secured cloud facility that minimizes exposure to host malice. KODiAC uses secure cloud services to manage encryption/ decryption keys and insure that only those with proper authorization can access plaintext materials. This requires identifying users, authenticating that identity, then authorizing usage through policy controls - all hidden and automated for non-intrusive operation.

Conceptual: Application-Independent, Secured Access
Through coordination with the host-based SSProtect software's :Foundation Client, your protected content remains continuously protected, even while being manipulated in third-party applications (and independent from which applications you use). This couples constant protection with ongoing insight into the use of sensitive materials, which forms an historical data record that is then the foundation for determining relative disclosure risks.

:Respond Analysis
Disclosure Analysis, as described in the article, Using :Respond, requires that you specify a target Timeframe for the Analysis, at which point a Report is generated to reflect the relative risk of data items based on use in (and before) the specified Timeframe. The Report enumerates each data item, optionally includes usage details, and always includes the resulting Risk and Reason for each analyzed entity. These reflect the amount of skill required for an attacker to utilize malware to acquire plaintext content throughout the history of managed use.

Example Relative Disclosure Risk
For example, if on Day 1 you receive protected FileA and FileB, and on Day 2 you securely access FileB, the relative risk to unauthorized disclosure of FileB is higher, simply because plaintext was available to some managing application in computer memory on Day 2. The barrier of entry for an attacker is still relatively high for FileB, specifically due to the patented mechanism SSProtect uses to provide continuous protection even while accessing content in third-party software (i.e. Microsoft Word, Adobe Acrobat, etc).

That being said, the risk that an attacker was able to acquire plaintext for FileA remains exceptionally high - at least with respect to this single host computer. Because FileA was never opened in plaintext, and also because decryption keys were never present on the host computer, the attacker would have to either a) break AES-128 or AES-256 encryption, b) find a critical/ fatal flaw in the software's security implementation, or c) steal keys from another host at another time when they were available, i.e. if FileA was accessed somewhere else (which requires intercept of re-encrypted content, since keys are changed each time - a concept the software was purposely built to refute). This would of course be reflected in Analysis dynamics for that other host - which then means the Analysis provides a complete and overall view of all actions associated with target Files/ Hosts over the given Analysis Timeframe (see below).

By the same token, if you also received FileC on Day 1, and subsequently Released Protection, meaning you removed FileC from protective scope and converted it back to plaintext, then FileC would be available to any attacker paying attention. This of course doesn't mean an attacker acquired plaintext - it only means that an attacker would be able to without a great deal of skill.

As such, Definitive Disclosure Risk Insight provides you with a worst-case scenario, allowing you to respond to breach dynamics, perform Analysis, and prioritize forensic investigation to determine what may have actually been disclosed.

Host Disclosure Risk Realities Outside the Analysis Timeframe/ Period
An Analysis always considers events prior to the given Timeframe at a low priority. If, for example, FileD was received on Day 1, securely accessed on Day 2, and you later learned an attacker breached the host on Day 3, it's not impossible that remnant plaintext exists somewhere on the host as a result of Operating System and/ or Host Application deficiencies unknown to the authors/ vendors (Zero-Day Vulnerability). As a result, in this case, the file is still considered a Low risk, and not theoretically secured, because it was at some point in the past on the give host accessed, and plaintext did exist at some point in time prior to the attacker's arrival. Forensic Analysis is not perfect by any means - and may not even uncover the ultimate reality. However, SSProtect will as a result provide you with a highly accurate level of true - Definitive - Disclosure Risk (especially when considering highly-capable attackers, i.e. well-funded nation states).

Due to its' importance in considering Definitive Risk Disclosure Ratings, and for additional clarity, this concept is repeated, below, using different examples.

Severe Risk - Accessing Encrypted Data
On any host computer, accessing protected content puts plaintext information at risk of being stolen by an attacker. Different actions lead to different levels of risk depending on the level of skill required to obtain the information.

With a traditional data encryption solution, you might receive an encrypted file and decrypt it to plaintext for use. When finished, you may re-encrypt it for storage or for further sharing. This procedure is prone to errors, and it also exposes plaintext content with little protection. Any attacker that has placed a trojan or other malware on your host computer has a strong chance of recognizing the procedure, detecting the file, and acquiring the plaintext content. Whether or not an attacker was present and/ or took action to acquire plaintext is a matter for further analysis. However, the worst-case potential for this scenario is Severe; a dedicated attacker will acquire his or her bounty as soon as information is decrypted to plaintext (and possibly not re-encrypted for ongoing protection).

Moderate Risk - Continuous Protection
When it comes to utilizing protected content, we can look at the opposite end of the use spectrum - In-Place Encrypted materials managed by SSProtect. When such content is accessed, SSProtect retains constant watch over plaintext content, limiting access to the one application that triggered User authentication and authorization before decryption keys were made available from secure, isolated cloud storage. Since other applications are locked out, attacker acquisition of plaintext data is significantly more complex, and ultimately the attacker is left to try and acquire plaintext through weaknesses in the protective scheme, or at the very least, from application heap memory. Since different files use different applications, and each application has its own method for managing in-memory content, this can be quite complicated if the goal is to engage in mass exfiltration. As a result, this scenario is considered to be of Moderate Risk, though in the greater scheme of things, has a profound impact on overall damage.

TSecure - Content that is Not Accessed
Taking matters to the furthest extreme, it may be that you've acquired a protected file from a peer but filed it away, never actually opening it to access plaintext content. This file would remain theoretically secured, or TSecure, since decryption keys for the instance have never existing on your host.

To acquire content, an attacker would have to impersonate your User and also, somehow, find a way to trick you into touching your USB token that serves as a 2nd-factor authentication mechanism. This however results in a secured event showing the file's keys were delivered for access, which precludes the file from a TSecure rating.

The other option is for an attacker to compromise KODiAC Cloud Services and also find a way to steal protected host encryption keys from SSProtect. This is an unlikely scenario, and would preclude the TSecure rating. So long as cloud services retain integrity, the file remains protected.

NOTE: It's important to understand that this also limits government intervention. In most other solutions, legal action calling for cloud decryption keys exposes your plaintext content. With SSProtect, this is not the case, and further legal action would be required to acquire Host Decryption keys. In this respect, you always know if your content has been exposed.

Multiple Hosts, Different Resulting Risk
It's critical to note, however, that this TSecure rating is specific to your host in this scenario, for a given Period of time. When your coworker created the file from plaintext and emailed it to you, the attacker may have had visibility into that process, which means he/ she saw the original plaintext. If you've reviewed Report article information, you'll know that each Report will have a Risk rating for each analyzed file on every participating host for the Analysis Period. As such, though TSecure on your host, the act of protecting content from plaintext means the plaintext information was exposed - Severe risk rating (if during the Analysis Timeframe, else Low as noted in preceding paragraphs), though on a different host, at a potentially different time. This kind of insight helps prioritize Incident Response priorities.

Analysis Period, Pre-Existing Conditions, and Low Risk
As noted in previous paragraphs, specific to the Analysis Timeframe, it's important to remember that you choose the Analysis Timeframe (Period) before execution. This determines the period of time over which information gets analyzed. But in reality, pre-existing conditions affect what an attacker may see. If you have been working with a set of protected data files over the course of a year, and find out that your network(s) were breached for 3 of those 12 months, you can go back to see exactly which content you used during that time, and how you used that content (did you Release Protections? Severe Risk).

But what happens if you used the protected In-Place Encryption to access content before the attacker was potentially present? Does this mean data is protected, given the keys are long-gone and new ones have been regenerated for the re-encrypted content - and more importantly, re-generated and encrypted in the cloud​, such that keys retained complete isolation from any host computer (the patent-pending mechanism for cryptographic offloading referenced throughout documentation)?

This is a Low Risk proposition, because in reality your host may still retain residual plaintext content. Whether this is as a result of third-party applications that used the plaintext materials, or as a result of using an SSD that doesn't allow you to immediately and deterministically overwrite on-disk data, content may be at least partially available. This has to be recognized and reflected in the Low Risk rating for these dynamics.

Note that the Reason field will include insight into previous Action that results in the Low rating.

Errors and Unknowns, High Risk
In some cases, data conversions - transitions from ciphertext to protected plaintext and back - fail, or report partial success. SSProtect has been designed to utilize a fail-safe mechanism, retaining a lockout on a file even if it remains in plaintext format. This allows Users to re-apply protections to the item, retaining the chain of continuous protection. This doesn't necessarily expose plaintext outside the context of an authorized application, but one can't be entirely sure for every possible error condition. As a result, any error condition, double-decrypt, or unexpected progression, results in a High Risk rating, even though more thorough review may prove otherwise.

Putting It All Together
If you believe you have been compromised - or get the dreaded call from the FBI indicating that you are, you can very quickly determine which items are at-risk, to what extent, where, and why. This allows you to rule out certain data items very quickly and focus on those that are of greater concern to an Organization - or perhaps more importantly, to a Third Party.

In fact, as we continue to roll out more advanced features, you will soon be able to generate Reports specific to Third Party content shared into your networks and consumed by your Users. This will provide instant insight for your partners, vendors, customers, and others who have a need to know how their information has been affected by a potential breach. This also allows you to do the opposite - determine how your information may or may not be exposed in their networks during trying times.

Prove That You Are In Control
:Respond was designed to help you determine where and how to spend your time responding to critical security incidents. By protecting content with KODiAC and SSProtect, you dramatically reduce the damage from an attack. With Automatic Saborage Remediation, Users retain access to important and sensitive materials, avoiding the pains of addressing a Ransomware threat. And with Definitive Risk Analysis, you know exactly where the next steps need to be taken, and can engage immediately - insuring that you retain control of your information at all times, greatly reducing the impact, disruption, uncertainty, and cost of ongoing security threats that continue to make it past other barriers.

For More Information
Refer back to the :Respond Introduction for additional links to related content, or send questions to



Risk Ratings
Risk Ratings in resulting Analysis reports use the monikers noted below. Because data is provided in .csv form and displayed in Excel as a matter of convenience, these specific text values can be changed to reflect your own needs. It is worth noting, however, that these ratings represent very specific circumstances and are based on historical data. By adding additional, custom logic with other third-party tools, you can add circumstantial dynamics into the equation and draw more specific conclusions that are custom-tailored for your environment(s).

  • Unknown - Something in the Analysis failed, and results could not be determined
  • TSecure - Theoretically Secure; The noted item has been stored, and has never been accessed in plaintext form on the given host - for any time prior to or during the Analysis Period. Events after the Analysis Period are not taken into consideration in this case.
  • Low - Low Risk results from potential plaintext exposure prior to the Analysis Period, though does not differentiate between protected and unprotected plaintext exposure. These dynamics are only relevant when determining risk for Actions that occur during the Analysis timeframe. Subsequent events are not relevant for this rating.
  • Moderate - Any protected access to content during the Analysis Period is considered a Moderate Risk. This is specific to In-Place Encrypted content accessed with continuous protections afforded by SSProtect. Releasing Protections to plaintext results in a Severe Risk rating. Note that insight into post-Period actions is required to insure accessed items are properly re-protected if they remain open when the Analysis Period ends. See below for more.
  • High - Any error condition during the Analysis Period results in a High Risk rating. See below for information on considerations that are included after the Analysis Period, and how it affects results.
  • Severe - Any unprotected plaintext exposure during the Analysis Period results in a Severe Risk Rating. This requires insight into events beyond the Analysis Period to determine whether or not accessed content was properly re-protected after the Period expires. For example, if you access protected content using the continuous protection mechanism and the Analysis Period ends before you close the managing application, there is no way to know if the content was exposed. Exposure in this case could come from events specifically carried out by an attacker during the Analysis Period. As such, unless a proper re-encryption action is see after the Analysis Period, the access is determined to be at least High Risk and problematic, or more often Severe as noted here.

Risk Reasons
Risk Reasons are straightforward, though it's worth noting that two successive encryption or decryption events are unexpected and as a result, seen as an error condition that leads to High Risk. The cited Reason will be Double Encrypt or Double Decrypt. This will never happen in normal operating circumstances, however does not mean materials have been exposed. This requires further investigation into detailed proceedings.

Actions Outside the Analysis Period
As previously noted, data access actions prior to an Analysis Period are analyzed to determine whether or not the potential exists for plaintext remnants to be exposed.

As for post-Period review, the analysis must determine if content that is opened at the end of the Analysis Period was successfully and securely re-protected. If not, the resulting rating will be either High or Severe. Refer to previous text for details.


This article was updated w/ v6.3.2 of the :Foundation Client

Contact Us
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found