This article introduces you to :Respond Disclosure Risk and how to acquire Deterministic Risk Insight for managed content.
SSProtect not only protects data, but leverages the underlying architecture to deliver management services that facilitate Security Incident Response and Recovery tasks. One such facility is :Respond Disclosure Risk Analysis, which provides Definitive Insight into use of an SSProtect Organization's managed content. This is helpful when investigating a potential data breach.
Execution requires that you've Licensed :Respond as directed in this section's Overview.
Finally, STEP guidance uses Profiles created in the Walkthrough, Third Party Trust Sharing. This is a matter of convenience rather than a requirement; execution is straightforward and simple.
For those unfamiliar with Breach Dynamics, here's one typical high-level progression:
- IT gets a phone call from the FBI with specific information identifying a potential data breach.
- IT investigates to verify the information, and if there is a problem, assembles a team to respond
- IT begins their response by understanding the scope and breadth of the potential breach.
- Once IT understands the dynamics, they put together and execute a plan to remediate, repair, and cleanse affected resources.
:Respond Disclosure Risk Analysis addresses major aspects of the investigation by providing direct, objective insight into the way your managed content has been used.
Remember that KODiAC Cloud Services operates independent from your host computer and network, and that KODiAC is a critical component in cryptographic offloading. As such, the audit information stored in the cloud provides an accurate and precise record over ongoing activities.
:Respond Disclosure Risk Analysis uses this as input to provide a summary Report showing you the resulting Disclosure Risk, of all content, across all affected resources, in a configurable time range.
If you take this report together with the map of affected resources, you can very quickly gather a very good idea of what sensitive content may have been disclosed, and what remained protected.
This facility improves notification accuracy and efficiency, both key components to reducing the impact of a breach, if even only as a result of an elevated reputation for offering very specific details, very quickly.
Create Test Data
Let's use one of our Test Accounts to generate some new test data we can use in :Respond Disclosure Risk Reports.
STEP 1: With SSProtect, Login to your Org1_Admin Test Account.
STEP 2: Create a new text file, C:\TestData\BreachTest-1.txt, and edit the file to include the text, Breach Test Data 1. Save/ Close.
STEP 3: Make a copy of this file in C:\TestData\BreachTest-2.txt, and modify content to reflect, Breach Test Data 2. Save/ Close.
STEP 4: In File Explorer, select both files then right-click and choose, SSProtect Activate.
STEP 5: Right-click the SSProtect notification icon and choose Usage Reports\ File Detail Report to review the progression that protects both files.
STEP 6: Find the activity associated with the two files we just protected, and make note of both the earliest Report Date line item for either, and also the latest Report Date line item for either. Keep these UTC times since we'll them in subsequent steps.
Acquire Our First Disclosure Risk Report
Let's pull a :Respond Disclosure Risk Analysis Report for very recent activity, i.e. for the timeframe between the start of this article and now.
STEP 7: Right-click the SSProtect notification icon and choose Disclosure Risk Analysis. Check Suppress PrePeriod and Auto-Report, then click the Distinct radio button in preparation for setting the target timeframe.
STEP 8: Set the Start Time to match the earliest UTC time you saved in STEP 6, though back up one minute just to be certain we capture the time that includes both items in plaintext form (see below). Set your Start Date to the matching date UTC, then adjust your End Date. You may need to add a day to it if you're working close to midnight UTC.
STEP 9: Click Start to execute the Analysis and acquire the resulting Report.
The resulting Disclosure Risk Report should show the two files we created in STEPs 1-4, above, as follows:
We've hidden the following columns in an attempt to render information that's legible:
- Column B - HostUUID
- Column D - Local IP
- Column E - Public IP
- Column H - File Org (gmail-definisec_t1)
- Column I - File Owner (firstname.lastname@example.org)
- Column N - File ID
The results show two items, one for each of the BreachTest*.txt files we created, above, with a Risk of 6 - Exposed and Reason equal to Activated Protection.
Looking Deeper: Our First Disclosure Risk Report
Let's take a hypothetical situation where we'd been informed of a potential data breach and, in the course of our investigation, determined that an attacker had compromised our host at 9:00 PM (for our test purposes), 16 minutes prior to the creation and protection of BreachTest-1.txt and BreachTest-2.txt. Also remember that we have another dozen or so files we've previously worked with, managed by the same SSProtect Profile on the same host.
This report tells us that the two files, BreachTest-1.txt and BreachTest-2.txt, are Exposed in plaintext form, simply because they were protected after the start of our Analysis. This means any host-resident attacker would have had a clear opportunity to offload plaintext content.
It also tells us that the other files on the host - the other dozen or so - were not Exposed, in this case simply because they weren't accessed.
Recall that our patented cryptographic offloading was specifically designed to ensure that decryption keys aren't generated or stored on the host computer - some of the keys are, but others are generated and stored in KODiAC Cloud Services.
Because of this approach, the attacker would have been able to steal the ciphertext content for managed files, but unless he/ she were able to breach KODiAC Cloud Services, there isn't a way for him/ her to recover plaintext content - unless of course our crypto implementation is flawed or we suffer other issues they are able to exploit.
Let's expand on this idea to look at more common scenarios.
Generate Common Use Data
STEP 10: Dismiss the Risk and Remediation dialog we've been using then double-click BreachTest-1.txt in File Explorer. This will securely open plaintext content in Notepad. Add the line, Breach Test Line 2, then Save/ Close. SSProtect will re-encrypt the file.
STEP 11: Delete BreachTest-2.txt then navigate to the Hostlist from the notification icon's context menu by choosing Managed Files/ Restore. Find BreachTest-2.txt in the list, which should show, (Deleted), then click Restore.
STEP 12: Dismiss the dialog then Refresh Login. Choose the Profile Org1_User1, enter its' Password and Login.
STEP 13: Double-click BreachTest-1.txt to securely open in Notepad, add the line, Breach Test User 1, then Save/ Close.
STEP 14: Refresh Login and choose the Profile Org1_Admin, enter its' Password, and Login.
STEP 15: From the notification icon's context menu, return to the Risk and Remediation dialog by choosing the Disclosure Risk Analysis menu item.
Acquire and Review Common Use Data
STEP 16: Adjust your Start Time to reflect the most recent time you saved from STEP 6, and add a single minute to it. For us, this is the same time, 9:16 PM or 21:16 UTC. Click Start to execute another Analysis.
This report shows the recent activity, which you'll note displays a Risk rating of 2/ 3. Risk ratings are in fact subjective values attached to objective information, as a guide. They are more fully discussed in :Respond documentation.
Note however that we see a 3 - Moderate rating for BreachTest-1.txt, though two entries instead of one. Risk Reporting shows the, "worst risk" specific to a given managed item, for each Environment. Because the target file was used by two different users, as shown in the Username column, you'll see independent entries. This helps correlate investigation with reality, if for example you find that a particular User's credentials have been compromised.
We also see that Org1_User1 risks Version 1 and Version 2 (because you open Version 1 and create Version 2 when you Save) while Org1_Admin only risks Version 1. Because these are Managed Access operations, an attacker would have had to compromise the managing application to gather plaintext, which can be seen in a related File Detail report.
Finally, we see the Restore operation specific to BreachTest-2.txt. This isn't a high-risk operation since SSProtect acquires and saves ciphertext data. It does however represent an operation and opportunity for an attacker, so it's included and in this case, the highest risk operation associated with the given file.
:Respond Disclosure Risk Analysis provides the most significant, objective Disclosure Risk reality associated with end-user operations on managed ciphertext/ plaintext content. Because of the underlying system design, we can offer theoretical claims for ongoing security if items are not accessed and KODiAC Cloud Services isn't breached. This allows us to provide a summary report, for all managed data, to support Incident Response and Recovery operations.
Refer to the :Respond documentation for more insight, such as operations that provide Reports for Third Party Trust content affected by activities in the target Analysis timeframe. You can, as it turns out, review and, "Release" these Reports directly to Privileged Users in their respective Organizations to address notification requirements found in many of today's legal agreements.
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 email@example.com, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client