Disclosure Risk Example

his article offers a glimpse into use of :Respond Disclosure Risk by example. 

---

Introduction

:Respond Disclosure Risk Analysis is an on-demand service that analyzes :Assess audit information to determine the degree to which managed content gets exposed when in the presence of malicious activity. The ability for :Respond to draw objective conclusions rests on the KODiAC Architecture, the collection of services that utilize patented cryptographic offloading to isolate sensitive operations and resources.

This article shows you how to use :Respond Disclosure Risk Analysis by way of example. We first configure several test Accounts/ Organizations, protect baseline materials, then carry out simple but common activities with this protected content. The remainder of the article focuses on how we can use SSProtect to gain insight into the Disclosure Risk realities associated with these dynamics.

For more information on :Respond capabilities and use, start with the article, :Respond Introduction.

Organizations and Demonstration Baseline

We created two SSProtect Organizations, as follows:

• RDemo with the Privileged Account rdemo@definisec.com
• SDemo with the Privileged Account sdemo@definisec.com

We also utilize our Support Organization, though it does not have Third Party Trust policies for data sharing with these Accounts.

Most activity was carried out with rdemo@definisec.com, working with its' managed content while accessing shared content from SDemo (and attempting, but failing, to access Support data).

Truncated Report Fields

In this article, we use :Assess and :Respond reports, though there is no easy way to present each in full form. As a result, we remove fields that are either static or of secondary importance (with notes).

Sample Event Progression

Let's start by looking at RDemo activities using a File Sequence report:

Each row includes additional field content, such as Username and IP Address. For each of these rows, the Username is rdemo@definisec.com. Other fields are not significant for our focus.

Working from the bottom up, we can follow the progression:

1. 11:34pm/ 11:35pm, the selected rows: added protection to several text files
2. 11:37pm/ 11:38pm, securely accessed access.txt, modifying content then saving/ closing
3. 11:40pm, released protection from release.txt
4. 11:42pm/ 11:44pm, securely accessed sdemo.txt, a Third Party Trust from SDemo
5. 11:45pm, failed to release protections from support.txt owned by the Support Organization
6. 11:46pm, re-protected release.txt
7. 11:47pm/ 11:49pm, copied base-2.txt to base-2cpy.txt then securely accessed its' content

Now let's look at some different perspectives on this progression.

File ID and Filenames

The last action, copying base-2.txt to base-2cpy.txt, is reflected in the File Sequence Report: Notice that the two files have the same File ID. Analysis scopes these as versioned instances of the same file.

This is the case when vChain Policy is not enabled. When it is, however, the resulting files would be treated independently. To illustrate, we enabled vChain Policy, created a new file, base-vChain.txt, then renamed it to base-vChain-cpy.txt before securely accessing it. We can see the creation of the new instance in both a File Detail Report and an Integrated Admin Report (shown here):

As before, we've truncated fields that are of secondary importance to the discussion.

The selected row shows, "Trans To:" for the new file, base-vChain-cpy.txt with a references to the old and new File IDs. Remember that the resulting Report may not have event activity associated with the source file immediately before the copy/ access operation, which makes the transition much less obvious.

As noted, :Disclosure Risk Analysis will treat base-vChain.txt and base-vChain-cpy.txt as two separate files. For activities in the rest of this article, we executed without vChain Policy (the default setting).

Simple All-Encompassing Analysis

Let's start with a simple Analysis for all activities. Navigate to the SSProtect notification icon's context menu and choose Disclosure Risk Analysis for the UI, then set a timeframe for the last few days:

The resulting (truncated) Report provides us with a summary of Disclosure Risks for scoped items:

Truncation is as follows:

1. Date - the date always carries a month/ day/ year designation, removed to save space
2. HostUUID - the unique, static ID assigned to an SSProtect host, is the same for these entries
3. Username - this report's content is associated with our rdemo@definisec.com Account
4. Local/ Public IP - values can change for a single host, though they are not relevant to our focus
5. FileID - not relevant here, but shown in the previous output: correlation to the filename is the same

We've also removed the Report Header, which shows the requesting Username (Account), the associated Organization, and more importantly, the target timeframe.

Simple All-Encompassing Analysis Results

Results are perhaps as expected: 6 - Exposed for most items. This is the result of recognizing that content was in plaintext format during the target timeframe. And though files progress through improved protective states, the report shows activity specific to the worst-case result.

This tells us that an attacker with a presence on the associated host(s) would have had unfettered access to the noted materials.

Attacker Presence After Protecting Content

Consider a slightly different hypothetical: What if an attacker gained access to our target host computer after content was protected? Let's execute another Analysis starting at 11:36 PM, immediately after we finished protecting our test files:

Results, truncating fields as noted above, show a very different Risk Proposition:

First, note that we now have two entries for many files as a result of, "Pre-Period" Risk. Also note that externally-owned content is listed.

Pre-Period Risk

Pre-Period Risk represents the reality of residual plaintext - or fragments of plaintext - being exposed to an attacker. Though at first it may seem that plaintext is always available at some point, that isn't the case when receiving a protected file from another user, or acquiring content already protected with automation (for example with a SharePoint Server or with Document Automation). The checkbox, Suppress PrePeriod, allows you to forego these details in the result, recognizing that Pre-Period Risk isn't always a straightforward matter and may be addressed independently.

Copied Content

You may also notice that, absent Pre-Period Risk, base-1.txt does not list any risk. base-2cpy.txt, however, not only shows the subsequent Managed Access activity, but is paired with base-2.txt. From previous discussion, you already know that's as a result of matching File ID; they are different instances of the same file, and as such viewed as a progression rather than independent items.

Objective Results, Subjective Classification

:Respond Disclosure Risk Analysis Reports enumerate the, "highest risk" associated with a managed item on a specific host. The mapping between potential disclosure risk and the Risk Categories is subjective, though the input to the mapping is objective (based on :Assess secure auditing in KODiAC Cloud Services). These mappings are more fully described in the article, Definitive Disclosure Risk.

Overall, :Respond Analysis aims to help you understand what an attacker encounters when he/ she gains access to managed resources. By aligning an Analysis period with what you learn about a potential breach, you can work through results to prioritize investigation.

Global Scope

Though our Report shows two entries for many of the files we used, you would see two more if the same file was used on another host. As you have seen, Reports also include activities performed against externally-owned content. By the same token, you'll see external User activity associated with your managed content. This provides as much information as possible about your content, your activities, and your potential liabilities to empower you to more properly Respond and Recover - which of course includes notification to peers (vendors, customers, partners) when their content has been put at risk.

Reviewing Results

Now that we have more insight on the way Analysis works, we can return to our most recent results to look at a few examples. First, we notice that two items carry more than Moderate risk:

• 4 - High for support.txt
• 6 - Exposed for release.txt

For the file release.txt, File Sequence (and Detail) reports will show that we protected, released, then re-protected content. That the Summary shows re-protection rather than Release is somewhat arbitrary, since both carry the same maximum risk. By reviewing Sequence/ Detail Reports, we will see the associated events and know the exact time that plaintext was made available. By correlating this with what we learn about attacker presence, we can make a final determination about the disclosure of this file's content.

Investigating Errors

The other item is specific to an Error, which is concerning only when the unexpected occurs. If attacker activity is able to break the software, we have to look further to determine what happens as a result of failure. Though the software is designed to challenge an attacker attempting to exploit the In-Place Encryption mechanism, for example, we want to be certain content isn't inadvertently made available.

In this case, File Sequence/ Detail Reports won't provide much insight since related activities don't exist. However, looking at configuration or speaking to related Privileged Users - and also from the Error associated with the failure - we know this failure results from authorization: We don't have access to Support materials.

Third Party Disclosure

When responding to the potential presence of an attacker, the value of a target file carries as much significance as the potential risk of plaintext exposure. Some files are fairly meaningless with respect to attacker acquisition - while others are of the highest importance.

The file support.txt carries significance because we may be liable for disclosing content sourced from a peer. But our procedure included access of an authorized Third Party Trusts - the file sdemo.txt. Why isn't this in the resulting Report?

Automatic Third Party Disclosure Reports

The content we seek to review is stored in a separate, independent Report that can be shared with the owning Organization, though Release must be authorized by one of your Privileged Users.

Generate Third Party Reports by checking, 3rd Party Reports in the UI, then Starting the desired Analysis. Select the resulting Analysis Report from the list at the bottom of the display, then choose, Report List. This display will show all Third Party Analysis Reports. In our case, there is only one:

In this form, the line-item isn't very interesting but as you can see, the Approval, Review, and any action to rescind visibility (Remove) gets audited.

Choose View Report to see activity your Organization Accounts have carried out on content managed by the noted target Organization. In our case, there is only one single event for SDemo content:

At that moment, the Report wasn't visible to SDemo, and nobody in their Organization knows that an Analysis has been performed. Choose Approve to release the Report - at that instant, the team of Privileged Users for SDemo receives email notification and, from that point on, the same Report you reviewed will be available from their Disclosure Risk UI (in the primary Reports List on the main page).

Once a member of their Organization accesses the Report, you will see it reflected in your line-item:

You can, if so inclined, rescind the visibility of the Report by choosing Remove, though as you can see, your activity will be audited and displayed for your Organization's Privileged Users to see.

You cannot modify this Report - it is delivered by KODiAC and will be identical to the instance you can reviewed from your UI. Remember that you will have a list of Reports for any involved Third Party Organization - and you can also Approve them individually - some or all or none.

Managed Access

3 - Managed Access represents the act of securely accessing content using native workflows, calling In-Place Encryption into play. Remember that this provides continuous protection to isolate plaintext such that it is only available to the managing application (and only one instance of it). Whether or not an attacker has the technical prowess to extract plaintext content from the application software depends on many things, but mostly on a) the software being used, and its' relative security, and b) the ability of the attacker(s).

Again, you can generate related File Detail or Sequence Reports to gain insight into the exact software used for the noted transaction (and others related to it). Because SSProtect uses the default registered application for a given file type, you can temporarily assume that a .txt file was modified with Notepad. This can be changed, though, and the File Detail/ Sequence Reports will show the exact file and path of the managing software.

Lead-In to Response and Recovery

 Though SSProtect was designed to be secure, remember that this information comes from the host computer. If that same host is compromised, an attacker may be able to find a way to, "trick" the system into thinking different software was used. The attacker might also have temporarily replaced Notepad.exe with his/ her own version that steals plaintext on the side (though remember, you can configure Accounts to preclude Secure, Managed Access when managing applications are not digitally signed).

Ultimately, you can use the information available to you as inputs to determining if the attacker had the ability to extract plaintext. If the target file is unimportant, this may be deferred - if critical, you may want to access the host computer and perform deeper investigation. This is the purpose of :Response Analysis.

:Recover/ :xRecovery to Coordinate Continuity

In our scenario, we'll find that Notepad was used. But as you iterate through SSProtect details and work toward final conclusions, don't forget that you can use :Recover and :xRecovery capabilities to maintain operational capability - if a host computer needs to be analyzed, the associated User can Remote Deploy his/ her Profile to a replacement host, allowing you to investigate without disrupting end-user pursuits.

Additional Resources

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 support@definisec.com, 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