Spirion (Identity Finder) - Effective Remediation Strategies with Identity Finder

Effective remediation strategies for the Identity Finder Console and managed client installations.

Overview

Spirion makes it easy to locate and secure sensitive data, but in a large environment like UW-Madison, managing remediation can still be a difficult task. We will look at a few strategies for performing remediation in manners that will save you time, give you more control over your results and ultimately make you a more successful user of Spirion.

Choosing an Approach

This document will cover remediation from the Console as well as a few different ways to perform remediation in the client. While all of these methods will work, one strategy may work better in your environment than another. We recommend you experiment with different options and see which suits your needs best--it may be the Console-centered approach, one of the client-centered approaches, or a combination of both. Below are some points to consider when choosing a method (or methods):

  • Using the Console may work better for smaller departments where remediation will be handled by a single person
  • Using the client with a saved results file may work better for larger departments where end users will be performing remediation, rather than unit IT staff.
  • Consider the search context of your searches when choosing an approach: System versus locally logged-on User
If you are working with Spirion for the first time or haven't developed a preferred remediation style yet, consider using the Console-centered approach before using one of the client-centered approaches.


Contents

  1. Console-centered Remediation
  2. Client-centered Remediation


Console-centered Remediation

Using the Console to perform remediation is very straight forward. From the Results tab, you have the ability to perform the following actions:

  • Shred Location - Securely delete the identified location. Shred Location uses DOD 5220.22-M, a U.S. Department of Defense secure file deletion standard.  This is irreversible, and should only be done by a personal authorized to delete the data.  One downside of a single person managing and acting on scan results is the person will not always know what a file contains or rather it is needed, and will need to communicate with the end user before shredding anything.
  • Quarantine Location - Quarantine Location will copy the file to a new location and securely delete the original. It is important to quarantine your files to a secure location.
  • Ignore - Ignore allows you to ignore a specific identity match (i.e., result) or an entire location (i.e., file). Ignore can be used to prevent false positives or files with 'acceptable risk' from being scanned in the future.
  • Globally Ignore - Globally Ignore will add your identity match or location to a Global Ignore List. Global Ignore Lists are used by every endpoint in your policy which makes them useful for ignoring files that may exist across many machines in your network--for example, sample template forms that may be distributed with applications like Adobe Acrobat or Microsoft Excel.
  • Classify - This option allows the user to define the level of security a file requires.  At present, this feature should be considered experimental and used with caution if at all.  However, it is an option that is being considered for future security plans.


In the following example, we will Ignore a false positive from the Console to illustrate the action process.

Our endpoint has been selected in the Endpoint List and its results are visible in the Results tab. The display of the data in the Results tab has been changed to group by location. This gives us a more compact view of the results and quickly shows us the location of the file we want to ignore. To group your results by location, you can select "Display > Group By > Location". The file we want to ignore has already been selected.




Next, will we click "Ignore > This Location". Because we have grouped our results by location, we aren't given the option to ignore "This Match". Should you want to ignore a specific match from a file but still have Identity Finder scan the file for other strings, you can change your display settings to show individual matches and choose "Ignore > This Match".




We are now prompted to provide a reason for ignoring the file. Identity Finder provides three reasons for us: "False positive", "Acceptable risk" and "Manager approval". A fourth reason, "Other", can be used to provide your own reason for ignoring the file. This location was a false positive, so we will choose "False positive".




After clicking "OK", we are shown a dialog box telling us that the action has been scheduled. The next time this endpoint polls, it will receive the "Ignore" action and respond accordingly.




This process is not immediate and your actions will not be reflected in the Console immediately. You can verify your action has been done by the endpoint in two ways. The first way is to simply refresh the endpoint's results in the Results tab--the icon for the result will change from the "No Action Taken" icon to that of the action it performed after it has completed. The second way is to view the endpoint's uploads in the Uploads tab of the Status tab. With your endpoint selected in the endpoint list, navigate to the Status tab of the Console. Select your endpoint from the list in the Status tab and choose the Uploads tab in the bottom pane. Once the endpoint has communicated back to the Console that the action has been performed, you will see an upload of type "Locations Actions". The Uploads tab of the Status tab will be cleared periodically so refreshing the Results tab is the preferred method of verification.




This Console-centered strategy works well in many types of scenarios. Because the Console is a web application, you can perform remediation either right from your office or from an end user's computer, if you choose to meet face-to-face with each identified individual. It will also work across all of your scans, whether they're run as the System user or the Local Logged on User.


Client-centered Remediation

Using the client to perform remediation requires more setup and planning than the Console-centered strategy but can be very valuable if your end users are going to be doing their own remediation. There are a few different client strategies that will work and they will be discussed in order of convenience.

From the client, you have the ability to perform the following actions:

  • Shred - Securely delete the identified location. Shred uses DOD 5220.22-M, a U.S. Department of Defense secure file deletion standard.  Remember that this is an irreversible step and should be performed only by a person authorized to delete the data.
  • Redact - Replace the identified match with a series of characters of your choosing (the default being "X").  Although it leaves other parts of the file intact, redacting is also irreversible in that the content of the redacted elements can't be recovered.  Only a person authorized to modify the data should take this step.
  • Secure - Encrypt the file using the password of the current Identity Finder profile.
  • Quarantine - Quarantine will copy the file to a new location and securely delete the original. It is important to quarantine your files to a secure location.
  • Recycle (Windows) - Move the identified file to the Recycle Bin. It is important to note that this will not actually delete the file--it will only move it into the Recycle Bin.
  • Ignore - Ignore allows you to ignore a specific identity match (i.e., result) or an entire location (i.e., file). Ignore can be used to prevent false positives or files with 'acceptable risk' from being scanned in the future.

Before Starting

It is important to consider the context of your searches before attempting to use the client-centered remediation strategies. Spirion operates under one of two "search contexts": the Locally Logged on User and the System user. The Locally Logged on User context respects the permissions and configuration of whoever is currently logged on to a particular endpoint. To this end, actions taken on a result only apply to- and persist with the currently logged on user. It is important to note that the client, when run interactively (i.e., is opened on an endpoint), is always going to be running under the Locally Logged on User context.

The System context, on the other hand, represents the "super user" of an endpoint--Administrator on Windows and root on OS X. Because the super user accounts can access all files and parts of the file system, the System context must be used if scans will be done on system-owned directories, like C:\Windows or /System. However, because the super user accounts can access all files, System context scans can and will identify matches for files owned by "standard" users, if those user directories are specified in the scan (for example, files in the directories C:\Users\myusername or /Users/myusername).

As mentioned earlier, Spirion will only operate under one of these two contexts and the client will always run under the Locally Logged on User context. In practical terms, this means that it is not possible to do remediation from the client when scans are run under the System context. As soon as the client is opened, whether it is to open a saved results file or to perform a new scan, the System context is lost and the Locally Logged on User context takes effect. Since actions taken on a result do not persist through context switches unless the file itself has been changed, most actions you take in the client will persist through your next System context scan.  If you ignore a file as the Local Logged on User, the file will be identified again in System scans. However, if any standard user files were identified by a system scan and had an action taken on them, the next Locally Logged on User scan will not identify those files. As such, this can lead to confusion over "missing" results (i.e., known matches that should have been identified) or results that shouldn't have been identified (matches that should have been ignored), and the "twisted" nature of the two contexts can make it difficult to replicate a particular scenario.  

This does not apply to the Shred or Redact actions, as the file itself is destroyed or irreversibly changed.  Local users are the ones who should perform those actions as they are familiar with the data and authorized to modify or delete it.  

Please see the Console-centered remediation strategy for performing remediation of System scans. Using the client will result in unexpected and unpredictable behavior.

Saving results locally on a Windows machine

Saving scan results locally produces the easiest client-side remediation strategy, though it requires some setup and configuration. To setup locally saved results, you will need access to the Console, a Windows client, a Windows account that is password protected and the ability to edit the Registry of the system you're using. The process is described below:

  1. Open the Spirion client, making sure to use a user profile. The Guest profile cannot be used because it doesn't update values in the Registry.
  2. Navigate to "File > Settings > Scheduling".
  3. Check the "Schedule a search:" check box.
  4. Check the "Automatically save results securely with a password" check box.
  5. Enter %USERPROFILE%\Desktop\results.idf in the "File location" text box. This location is largely irrelevant--it only needs to be a location that your Windows user has write permissions to and will be changed in the Console later.
  6. In the "Enter password:" and "Confirm password:" text boxes, enter the password you would like to use to lock the results. This password will be used across all endpoints on your policy.
  7. Click "OK" to save the settings and close the Settings window. A dialog box will appear prompting you for your Windows user name and password. Enter your password and click "OK".
  8. Open regedit by going to the Start menu and typing "regedit" in the search box. Press Enter or click regedit to open the application.
  9. In regedit, navigate to HKEY_CURRENT_USER\Software\Identity Finder\Client\Settings\ScheduledTask.
  10. Double-click the SaveKey key and copy the generated password hash from the "Data" field. Click "OK" or "Cancel" to close the dialog box.
  11. In the Spirion Console, navigate to the Policy tab and select your policy.
  12. Open the "Settings" view of your policy and navigate to the Settings\ScheduledTask folder.
  13. Double-click the SaveKey key to open the editor and paste in the password hash you copied in step 10. Click "OK" to save the change.
  14. Locate the AutoSaveResults key in Settings\ScheduledTask. Double-click the key to open the editor, select the "Save as IDF" radio button and click "OK" to save the change.
  15. Locate the SaveLocation key in Settings\ScheduledTask. Double-click the key to open the editor, enter the location where the results will be saved and click "OK" to save the change.
    • You must also include the file name of the saved file--for example, results.idf.
    • Operating system environment variables can be used to specify the location. For example, you could use %USERPROFILE%\Desktop\results.idf to save the results file to the locally logged on user's Desktop.
    • By default, Spirion will not create new directories for the results file. If you wanted to save your results files in %USERPROFILE%\Identity Finder\results.idf, for example, you will also need to edit the policy setting Settings\ScheduledTask\CreateFolderLocation to be "Enabled". When Spirion creates this directory, it will ignore capitalization and create the directory with all lowercase letters.
    • Be aware of your searches' context (System versus Locally Logged on User) when specifying the location of the saved results file. If you attempt to save the file in a location that the search context doesn't have permission to write to--for example, a Locally Logged on User search trying to save to the root C:\ folder--the write will fail silently and the results will not be saved.
  16. Close regedit if it is still open and return to the Identity Finder client.
  17. Navigate to "File > Settings > Scheduling". Uncheck the "Schedule a search:" check box. Click "OK" to save the change. Exit the Spirion client.

Saving results locally on a Mac machine

Saving scan results locally produces the easiest client-side remediation strategy, though it requires some setup and configuration. To setup locally saved results, you will need access to the Console, a Mac client, and a Mac account that is password protected. The process is described below:

  1. Open the Spirion client, making sure to use the profile of an authorized user.
  2. Navigate to "File > Preferences > Scheduling".
  3. Check the "Schedule a search:" check box.
  4. Check the "Automatically save results securely with a password" check box.
  5. Enter $Home\Desktop\results.idf in the "File location" text box. This location is largely irrelevant--it only needs to be a location that your Mac user has write permissions to and will be changed in the Console later.
  6. In the "Enter password:" and "Confirm password:" text boxes, enter the password you would like to use to lock the results. This password will be used across all endpoints on your policy.
  7. Click "OK" to save the settings and close the Settings window. A dialog box will appear prompting you for your Mac user name and password. Enter your password and click "OK".
  8. In the Spirion Console, navigate to the Policy tab and select your policy.
  9. Open the "Settings" view of your policy and navigate to the Preferences\ScheduledTask folder.
  10. Locate the AutoSaveResults key in Preferences\ScheduledTask. Double-click the key to open the editor, select the "Save as IDF" radio button and click "OK" to save the change.
  11. Locate the SaveLocation key in Preferences\ScheduledTask. Double-click the key to open the editor, enter the location where the results will be saved and click "OK" to save the change.
    • You must also include the file name of the saved file--for example, results.idf.
    • Operating system environment variables can be used to specify the location. For example, you could use $Home\Desktop\results.idf to save the results file to the locally logged on user's Desktop.
    • By default, Spirion will not create new directories for the results file. If you wanted to save your results files in $Home\Identity Finder\results.idf, for example, you will also need to edit the policy setting Preferences\ScheduledTask\CreateFolderLocation to be "Enabled". When Spirion creates this directory, it will ignore capitalization and create the directory with all lowercase letters.
    • Be aware of your searches' context (System versus Locally Logged on User) when specifying the location of the saved results file. If you attempt to save the file in a location that the search context doesn't have permission to write to--for example, a Locally Logged on User search trying to save to the root C:\ folder--the write will fail silently and the results will not be saved.
  12. Navigate to "File > Preferences > Scheduling". Uncheck the "Schedule a search:" check box. Click "OK" to save the change. Exit the Spirion client.

Once results are being saved locally, remediation from within the client is as straight-forward as remediation through the Console. We will ignore a false positive in the client to illustrate the process.

First, we've located the saved results file on our machine. For this example, the file was saved in %USERPROFILE%\identity finder\results.idf on a Windows machine. We will double-click the file to open it with Spirion.  Note that the steps are identical on a Mac, but the user interface will differ.


Spirion opens and prompts us for our Profile password. We enter our password in the text field and click "OK" or press Enter to continue.


Spirion prompts us for the result file's password. We enter the password that was chosen in step 6 of the saved results instructions and click "OK" or press Enter to continue.


The results are displayed in the Advanced view of the client. This view produces a list of locations and their matches, and closely resembles the Results tab of the Spirion Console. Our list has been flattened to aggregate our matches into a single line. You can do this by clicking "Collapse All Rows" in the Display section of the ribbon. The result that we have identified as a false positive has been selected and checked in the result list.



We will now click "Ignore > This Item Location" to ignore the entire file.


Spirion asks us to verify that we want to ignore this file location, and we'll click "Yes" to perform the ignore.


The result we ignored is removed from our list of locations and we can see in the bottom right corner of the client that our "Locations:" and "Matches:" numbers have decreased. After closing the client, the client will report back to the Console to update our result to reflect that it has been ignored. We can see in the Results tab that our file has been updated to its newly ignored status.


Rescan from the client

Some administrators have found rescanning an endpoint during a face-to-face meeting with an identified user works well for performing remediation. This provides a great opportunity to show end users how they can perform their own scans and remediation, and can be helpful for verifying that all identified files have been handled in an appropriate manner. Before using this approach, it is important to consider the following points:

  • Amount of data to be scanned - It is not always feasible to perform another complete scan in the amount of time a face-to-face meeting should take. If your scan is "My Documents" scoped (i.e., the locally logged on user's user profile), your scan will probably be short enough that this won't be a problem. Macs, however, will take longer to scan than Windows machines, and it is very possible that a My Documents scoped scan on a Mac will still take too long for this to be a viable option.
  • User context - As mentioned previously, scans done from the client are done as the Locally Logged on User. If your client-run scan is a followup to a System context scan, the actions you take in the Console will not be reflected on either the previous or future System context scans. The Console will report the action you took from the client--but it will have been for the Locally Logged on User context, not the System context unless the action removed or changed the file itself.
Rescanning from the client works well with the "Use User Databases/Ignore Files by Hash" setting which is described below.

Ignore StorageMethod - User Databases

This approach is more a helpful "tactic" rather than a full remediation strategy, and can be used with both Console- and client-centered approaches. The problem and the solution this provides are explained below:

When a location or match is ignored in Spirion, it is added to a list of files or matches to ignore in subsequent searches. By default, when the ignore action is performed through the client, this list is stored in the Spirion Profile that performed the ignore. This list is visible to the user in the application's settings (File > Settings > Ignore on Windows and Identity Finder > Preferences > Ignore on OS X) and contains plain-text locations or matches. Because Spirion Profiles are password protected and unique to the user currently logged on to a machine, they are not checked by Console-initiated scans and all files in the list will be searched. This can cause unexpected results to appear in the Console if, for example, an end user proactively performed her own scan through the client, found a false positive and chose to ignore it. While this file will no longer be identified in any scans she starts interactively through the client, any Console-initiated scan will still pick it up.

This behavior can be changed, and it is done by changing the policy setting Settings\Actions\Ignore\StorageMethod. When changed to "Use User Databases/Ignore Files by Hash", Spirion will create a database of ignored files and place it in the file system of the currently logged on user. Any Console-initiated scan, be it a Scheduled Task or on-demand search, will use this database, along with any ignores done through the Console, as long as they are Locally Logged on User scans. Scans done as the System user will not make use of the User Database because the System account is not the currently logged on user. These User Databases are unique to each user on the machine and Identity Finder respects that uniqueness, even at a System user level.

This change will affect how the ignore list is displayed in the Console. As mentioned before, the ignore list will display the full file path in the ignore list by default. When using the "Use User Databases/Ignore Files by Hash" setting, ignores will be displayed in the ignore list by their hash. It is still possible to manage the ignore list from the client but to view the file that has been ignored, the hash must be selected in the list and the "Show Path" button pressed.


This is a good change to consider making to your policy if you have end users who like to run scans on their own. It is also useful if your remediation strategy is to meet face-to-face with an identified user and then launch a new scan during your meeting. Once again, it is important to remember that this setting only works with Locally Logged on User scans from the Console.




Keywords:identity finder "identity finder" idf remediation strategy strategies "false positive" ignore console   Doc ID:46281
Owner:Oakes D.Group:Office of Cybersecurity
Created:2015-01-16 16:07 CSTUpdated:2020-05-05 11:44 CST
Sites:DoIT Help Desk, Office of Cybersecurity
Feedback:  1   0