This article explains SSProtect :Respond Definitive Disclosure Risk details for associated Reports.
This article details concepts that motivated Definitive Disclosure Risk Ratings associated with Disclosure Risk Analysis execution, described in the article, Using :Respond.
When you finish reviewing the content in this article, visit the article, Disclosure Risk Example to see how results can be interpreted and used in Response and Recovery operations.
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 ensure 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.
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 patented protections and SSProtect In-Place Encryption that maintains protection even while working with 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 (all) 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 (to expose very specific cloud materials; unlikely), or c) steal keys from the cloud and also another host at another point in time when content was being accessed.
Such activities would of course be reflected in Analysis dynamics for other hosts - 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 only need to compromise the host computer to do so.
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
A Disclosure Risk Analysis always considers events prior to the given Timeframe, though at a lower severity. 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 and/ or Information Disclosure Vulnerabilities).
In this case, the FileD is still considered a Low risk, though not, "theoretically secured", because it was, at some point in the past, on the target host, in plaintext form. 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.
Theoretically Secured Content - Acquired But Not Accessed
Taking matters to the furthest extreme, it may be that you've acquired a protected file from a peer, stored it on your host computer, but never accessed it in any way. This file, for reasons explained above, would in theory remain secured unless the attacker has figured out how to recover plaintext from AES-encrypted data without keying material. It's unlikely anyone would be able to stop someone with that knowledge.
To acquire content, then, an attacker would have to impersonate your User (hijack your Account) and also, somehow, find a way to trick you into touching your USB token that serves as a 2nd-factor authentication mechanism (when deployed; highly recommended). This however of course results in a cloud-audited event showing that the file's keys were delivered for access, indicating that the file's plaintext was then exposed to some level of risk (as noted in previous sections).
An attacker could of course compromise KODiAC Cloud Services, but that alone isn't sufficient to steal plaintext content from any User - he/ she would have to also exploit one or more host computers. This is an unlikely scenario, increasing the probability of reality aligning with the (noted) theoretical goals.
Significance Of Dual-Compromise Attacker Requirement
KODiAC was designed, specifically, such that host plaintext content does not get exposed to cloud resources. This limits government/ legal intervention: With most cloud providers, legal action calling for cloud decryption keys exposes end-user plaintext content. With SSProtect, as noted, this is not the case, and as a result, legal action would have to be extended to you, requesting your associated SSProtect Host content. This gives you an opportunity to respond through the legal system, before plaintext materials are disclosed.
Multiple Hosts, Different Resulting Risk
It's critical to note, however, that theoretical protections are very specific - with respect to Disclosure Analysis, specific to your Host and the Analysis Time Period.
For example, if a coworker protected a file from plaintext then emailed it to you, the attacker may have had visibility into that process on his/ her host computer. That exposes the original plaintext - but on your coworker's host computer. Disclosure Risk of course provides a summary for items on all target hosts. The resulting Report would show disclosure risk on your peer's host computer, but not yours (if you didn't access plaintext content after receiving it).
Of course, this allows your Response team to zero in on your peer's host computer for further investigation (when required; perhaps the file is determined to be of little significance and thus ignored or low-priority in the greater scheme of a Breach).
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 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 (in-period) error condition results in a High Risk rating, even though more thorough review may prove otherwise.
Putting It All Together with Third Party Reports
If you believe you have been compromised - or get the dreaded call from the FBI (or other agency) indicating that you may be compromised, 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.
You can, when executing a Disclosure Analysis, indicate that you wish to generate Third Party Reports. These are independent Disclosure Risk summaries specific to content your Organization Users accessed in the Analysis scope (in-period timeframe and pre-period considerations). You can review these Reports and choose whether or not you wish to share them with the Third Party or not, and upon Approval they are notified and can access content independently, to review. This fulfills notification liabilities included in almost every legal agreement - with a repeatable set of results that cannot be changed, only Approved for release (or Removed even).
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 - ensuring 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.
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; This rating is no longer displayed in Reports - items that are not listed are assumed to hold the TSecure rating, and are not at-risk in any known way.
- 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 ensure 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 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. Such cases generally inspire 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. This can be suppressed for clarity, and re-enabled in a follow-up Analysis. Execution utilizes pre-processing for efficiency, thus subsequent Analysis on your content proceeds quickly.
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.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.8.0 of the :Foundation Client