Identity Finder - Effective Remediation Strategies with Identity Finder

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

Overview

Identity Finder 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 Identity Finder.

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-centric approach, one of the client-centric 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 Identity Finder for the first time or haven't developed a preferred remediation style yet, consider using the Console-centric approach before using one of the client-centric approaches.


Contents

  1. Console-centric Remediation
  2. Client-centric Remediation


Console-centric 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.
  • 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.

In the following example, we will Ignore a false positive from the Console to illustrate the 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-centric 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-centric Remediation

Using the client to perform remediation requires more setup and planning than the Console-centric 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.
  • Scrub - Redact the identified match, replacing it with a series of characters of your choosing (the default being "X").
  • 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-centric remediation strategies. Identity Finder 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, Identity Finder 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, no action you take in the client will persist through your next System context scan--the file will be identified once again. However, if any standard user files were identified 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 had an action taken previously), and the "twisted" nature of the two contexts can make it difficult to replicate a particular scenario.

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


Saving results locally

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 Identity Finder 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 Identity Finder 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, Identity Finder 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 Identity Finder 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 Identity Finder client.

Steps 13-15 may be repeated for the Identity Finder Console keys Settings\ScheduleTask\AutoSaveSecureResults2, Settings\ScheduledTask\CreateFolderLocation2, Settings\ScheduledTask\SaveKey2 and Settings\ScheduledTask\SaveLocation2 for saving results locally on OS X. Identity Finder supports OS X environment variables in addition to Windows environment variables, so you can use $HOME to save results in the locally logged on user's home directory, like %USERPROFILE% in Windows. If your environment is made up of a single platform, you can use these settings to add a secondary save location so your results file is saved to both.


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. We will double-click the file to open it with Identity Finder.


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


Identity Finder 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 Identity Finder 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.


Identity Finder 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.
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-centric approaches. The problem and the solution this provides are explained below:

When a location or match is ignored in Identity Finder, 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 Identity Finder 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 Identity Finder 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", Identity Finder 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:Andy S.Group:Office of Campus Information Security
Created:2015-01-16 17:07 CDTUpdated:2015-03-18 16:38 CDT
Sites:DoIT Help Desk, Office of Campus Information Security
Feedback:  0   0