Attachment_3_-_NIH_PII_Spillage_Procedures.pdf

Personally Identifiable Information (PII) Breach/Spillage Incident Procedures for ISSOs Definition: ‘PII Spillage’ is the intentional or unintentional release of personally identifiable information (PII) without the appropriate consent of the originating source. Spillage can occur via (1) theft or loss of equipment containing PII, (2) the theft or loss of paperwork or reports that contain PII, or (3) electronically via unauthorized access, copying, e-mailing, or downloading of a set of data (i.e., file, application/system database, etc.). The unintentional digital release of PII can be caused by a vulnerability (unpatched or misconfigured system, bad/unsecure application code, etc.) or a threat (hacker, etc.).

Note: The following procedures are not intended to cover instances of criminal intent but only PII spillage that are unintentional. They apply to government and personally-owned computers used in the performance of NIH related work.

Summary: The disclosure incident shall be identified as the direct or indirect loss of any object containing PII material. Upon discovery, the incident should be reported to the System Administrator as well as the IC ISSO responsible for the information security posture. The System Administrators should make an initial determination of the potential compromise.

Network personnel may be required to assist in the spillage recovery process.

Step 1: Identification and Notification The IC ISSO should initiate, at a minimum, the following actions:

Evaluate the extent of the spillage.

Determine the origin of the spillage.

Identify the account(s) that the email arrived from/to (if applicable).

Identify the potential organization(s) and/or network(s) affected (if applicable).

Identify the type(s) of file formats involved in the incident (email, web posting, database, etc).

Document all actions taken, and gather any evidence processed.

The Network and System Administrator(s) or other organizational staff assigned to the PII incident should take the following actions:

Scan (i.e., examine/search drives, directories, e-mail, etc.) system(s) for actual data/document(s) and the presence of PII information.

Scan (i.e., examine/search) network elements (email servers, content cache servers, backup media, etc) using ‘due diligence1’ for possible spillage and the presence of PII information.

Evaluate the existence of interconnected systems for additional possible spillage in partner networks.

When email is involved in the incident, additional potentially contaminated systems may be identified by analyzing the email server logs. Data from the Exchange Administrator Track Message tool and information from the ISSO and users familiar with the incident can help identify the following:

Who received the message?

1 Due diligence is defined as the attention and care legally expected or required of a person.

Who sent the message?

Was the message replied to or forwarded?

Were there any auto-forwarding, auto replies, or auto archive rules?

What system(s) did the information pass through?

What system(s) is the information stored on?

Were any backup tapes contaminated?

When HTTP or FTP is involved, server audit logs may help identify the recipients of the downloaded files. Computer data-storage devices, such as memory and disk drives, should be assumed to be contaminated. Backups made since the PII spillage occurred may also be contaminated.

Step 2: Containment.

Rapid notification to the downstream recipients of the spillage by telephone or email significantly reduces further spread of the PII information and reduces the cleanup costs. The contaminated media must be handled as sensitive and protected by appropriate security measures2. In addition, since the media is potentially vulnerable to access by unauthorized on-line users, the contaminated systems must be taken off-line.

If a workstation is contaminated, the following actions should be taken immediately:

Disconnect workstation from the network immediately by removing the physical network connection (e.g., RJ-45 Cable, fiber, etc.).

Do not shut workstation down; the workstation would remain in an operational mode, unless directed otherwise.

If the Network System Administrator determines that a network server(s) has been contaminated, the following procedures should be followed:

Determine the severity of the spillage.

Isolate the server from the network upon consultation with management and taking into consideration feasibility, reasonableness, and due diligence such as the affect on other servers, if part of a group or server farm.

Make a copy of the contaminated files.

Collect all backup tapes, CD-ROMs, and/or disks of the contaminated systems. They may be needed for further investigation (i.e., forensics) and/or clean-up.

Step 3: Eradication.

Incident responses will focus on eradication of all PII data on affected assets to protect the information. Incident response can be based on sensitivity of data content.

Purging of information requires elimination of files and trace remnants from all affected, transient, and storage devices or systems to prevent reconstruction or access of data through technical reconstruction methods.

Purging efforts to permit system reuse or operations within access constraints will be conducted when approved, and when the technical solutions exist to minimize the associated risks.

2 Security protection should be commensurate with the applicable impact level (low, moderate, high) as defined in FIPS 199 and the controls defined in the system’s security plan. E.g., ‘High Impact’ requires the highest level of containment effort such that it may be necessary to quarantine the affected servers from continued access. The PII Spillage checklist at the end of this document contains a list of items and areas to check.

Procedures for deletion of various types of data

Eradication procedures can apply to general files, e-mail, and other files and should be performed in line with the appropriate risk impact level (low, moderate, or high).

General Files:

Delete file, file attachments, or “Saved As” file from all local systems and/or file storage areas.

Delete file, file attachments, or renamed files(s) from all affected email user’s mailboxes, and the server information stores or email queues.

After file deletion(s) conduct a search on the system(s) for similar or potentially associated files with (e.g. same date/time stamp, dirty word search, word variations, etc.)

and delete all identified files. Verify that no files were saved to network storage devices.

Email:

Delete contaminated messages saved in Personal Folders (.pst) on workstations.

Contaminated messages saves as .pst files on the network can be deleted by the user, but the system administrator must take actions on the network drive containing the deleted file.

On Microsoft-Exchange systems [applies to CIT CES administrators], the post office administrator must permanently delete the message from each user's mailbox including the item's folder, the latest log file, and delete it from the Recover Deleted Items tool. The administrator must perform an off-line file backup and take the contaminated systems off-line, by going to Start | Settings | Services and turning off MSExchange Direction, MSExchange Event Service, MSExchange Information Store, Internet Email Service, and System Attendant. The administrator must pack the database by running eseutil /d /ispriv and/or eseutil /d /ispub fromC:\winnt\system32 or from the C:\exchange\server directory.

This is particular to Microsoft Exchange 5.5. Newer versions will have online restore and save features. If you have an earlier version (e.g. Exchange 4.0/5.0) it would be edbutil.

Also, the directory would be c:\exchsrvr\bin. The administrators must shutdown and power-off the Exchange server, then restart the server(s). All services will start normally.

The Exchange server is decontaminated.

Notes:

1. When a message is created, it is initially stored in the local Information Store.

2. The Internet Mail Service (IMS) temporarily stores messages in a folder in the Information Store specifically designed for the IMS.

3. During translation, the IMS temporarily places messages in a subdirectory of exchsrvr\usrvr\imcdata.

For email that has been courtesy copied (cc:), recipients must delete the PII message/file, (or the administrator must take ownership of their accounts and delete the message). The administrator must pack the database. On SMTP post offices and user workstations, the PII message/file must be deleted from each recipient's email file using the email tool.

Other Files:

For FTP, HTTP, and file servers, as well as workstations that were used to view, download, or save the PII material; server administrators and workstation users must find and delete the associated files.

For users that use Netscape client (ver. 4.X) on workstations, run the Netscape program and from the Edit menu, click the Preferences tab, select Advanced, then Cache from the Category menu. Record the user's memory and disk cache settings, change both to zero, and click the OK button. (Note: the Clear Memory Cache and Clear Disk Cache buttons cannot be used instead of resetting the memory and cache settings.) For the earlier versions 2.x or 3.x of Netscape, go to Options, Network Preference and again record the user's Memory and Disk Cache settings, change both to 0, and click the OK button. For the Internet Explorer client, launch the Internet applet in Control Panel, click on the Advanced tab, press the Settings button, and press the Empty Folders button.

For users of other Internet browsers (e.g., Opera, Mozilla, Firefox, SeaMonkey, AOL, etc.) similar cleaning procedures must be followed to ensure the removal of old and extraneous information.

Procedures for Wiping System Freespace:

Note that the following wiping procedures apply to both servers and desktops.

1. Several products exist that can assist in cleaning drive media. For example, the open source product ‘Mutilate3’ application can be used to clean up an unclassified server after sensitive data has been detected and deleted. Unallocated, free, and slack space on the workstation(s) system will be overwritten with Mutilate. Log on to the server with your admin account.

2. Download Mutilate and save the file on the affected system

3. Close all open programs and then execute the "SETUP.EXE" program. Follow the instructions presented by the installation program. You will have a chance to approve installation before any changes are actually made to the contents of your hard drive. The program will ask you for a destination directory, and will copy the Mutilate files to that directory. If you so direct it, the installation program will install executable programs and documentation in other directories of your choice. It will make no other changes;

specifically, it will not modify your autoexec.bat or config.sys files.

4. Within the Mutilate program Select Tools and then Wipe Free Disk Space.

a. Unless you are wiping a floppy disk, close all active applications.

b. Select the drive on which you wish to wipe the free space.

c. Press the "Change" button in the Security Level section. Select custom from the selection field. Change the pass numbers to 7 on all three entries. Although Mutilate is extremely fast compared to similar utilities, the process will still take a significant period of time to wipe large empty disk spaces at the High and Intense Security Level settings.

d. Select the “Wipe Free Space” button. Mutilate wipes up to 256 GB free space for Windows NT 4.0 and later.

3 http://mutilatefilewiper.com/download.html

e. Note: Lost allocation units are not free space. Run ScanDisk or an equivalent utility to convert lost allocation units to valid files. Wiping free disk space does not wipe the swap file currently in use by Windows. You can reduce the size of a non-fixed swap file by closing all applications. Clusters previously occupied by the larger swap file will be wiped when wiping free disk space.

5. The swap file is difficult to wipe because it cannot be written over during a Windows session and Windows deletes it when Windows closes. In the Windows default setup, the swap file changes size according to your system's needs. Unless you have a fixed swap file size, you can reduce the size of your swap file temporarily by closing all applications.

Wiping free disk space will wipe those clusters that previously contained the larger swap file.

6. To completely wipe the swap file, you must reduce the swap file size to zero. This can be accomplished in one of two ways.

a. First, if your system has sufficient RAM, your swap file may be zero after initially booting your computer. Check the size of your swap file (typically C:\Windows\Win386.swp or C:\Win386.swp) immediately after starting your computer. If the size of this file is zero, then wiping free disk space at this point will overwrite the swap file used in your previous Windows session. You should additionally check the size of the swap file while Mutilate is wiping the free space to determine that the swap file size is still zero.

b. The second and surest way to wipe the swap file is accomplished by disabling virtual memory (your swap file) and then wiping disk free space.

B1. In Control Panel first select System, then select the Performance tab.

B2. Select the Virtual Memory button.

B3. Check "Let me specify my own virtual memory settings".

B4. Select Disable Virtual Memory & press 'OK'. Windows issues a warning that you may not be able to restart your computer without virtual memory. If this option is grayed out then you definitely do not have enough memory to restart Windows. Be sure to have a Windows boot disk handy in case you run into problems restarting Windows. Restart Windows. Now start Mutilate and wipe the free space of the drive on which the swap file existed. If you receive an error message when starting Mutilate, your memory is insufficient. You may be able to proceed by quitting other programs, such as those that startup automatically. After wiping free space, return to the Virtual Memory settings in Control Panel as described above and re-select "Let Windows manage my virtual memory settings". Reboot (or just end your session for the day.

Restore/Defrag:

Delete or empty the contents of all temporary or cached items such as Internet Explorer or Netscape temporary files.

Empty any “Recycle Bin” or “Deleted Items” folder storage area.

After removal of suspect file, remove all additional configurations or files that are not operationally required.

Defrag the hard drive to reallocate the drive space.

After deleting the PII data, do a file backup of the remaining data, reformat the disks, and restore the data.

Reboot the system.

Administrators should mark the system case, and permanently mark the physical hard drive(s), that they contained PII information and were purged, the date, and the tool used to purge the drive.

Sanitizing/wiping/destruction of incidental storage media/systems

Individual file servers will be sanitized per the requirements above.

RAID Storage devices require specialized training and expertise, and administrators must consult individual vendor specifications and requirements to delete the original file(s), compact or re-allocate drive space, and wipe the available free space before re-initializing these devices.

Back-up storage servers will be checked by System Administrators and/or Information Assurance Managers (SAs/IAMs) who will verify that no suspect files were written to the device. The back-up server should remain off line until complete eradication measures have been taken. If affected, these systems should be completely wiped, overwritten, and re-installed using original software media.

NIH Personal Electronic Devices (PED), wireless devices, or text messaging devices that have been contaminated with PII will be given to the ISSO for re-initialization. Non-NIH owned devices need to be cleaned of PII information as well. Sanitization of NIH owned equipment must be performed according to the NIH Sanitization Policy and Guidance.

Step 4: Reporting

All personnel involved with the identification, notification, purging, rebuilding, and verification will sign a Non-Disclosure Agreement if required. Federal government staff are not required to sign this agreement since they are bound by the non-disclosure form signed at time of hire. Contractors and other support staff also would not need to sign a non-disclosure form if it was part of their contract and they had signed one. Those who are not bound by some existing non-disclosure agreement would be required to sign a non-disclosure form4.

Prepare a report of all activity, notifications, and actions taken during the incident and report it to the IRT. The ‘PII Spillage Checklist’ that follows can be used when submitting the initial report.

4 A sample non-disclosure form can be found at http://www.nichd.nih.gov/stand/security/forms/Non- Disclosure_Form.pdf

PII Breach/Spillage Checklist – Initial Report

[This form is to be completed by the ISSO or alternate. A copy is to be sent to the IRT.]

What is the Category of Information? _____________________________

How was the PII information distributed/received/identified?

Email □ Attachment □ Desktop File □ File Server File □

Web Posting □ Other media □ _______________________________________

Who reported the spillage?

POC Name: _______________________________ Phone Number ______________________

Email: ____________________________________________________________

When was the incident first identified? _______________________________________

List the names of the potential networks that were affected.

PII /Breach/Spillage Checklist � Contacted ISSO and IRT � Identify extent of spillage � Identify the source of spillage � If workstation is contaminated, disconnect workstation from network but do not shut down � If server has been contaminated, isolate the server from network � Identify all the potential business units and/or networks that were affected.

� Identified all “to” recipients � Identified all “cc” recipients � Identified all “bcc” recipients � Delete File from all local systems.

� Delete File from file storage areas.

�Delete File from user’s mailboxes � Delete File from email queues (sent, draft etc) � Delete messages saved in Personal Folders � Conduct a search for similar files � Delete all identified files from search � Verify that no files were saved to network storage devices � Delete contents of all temporary files/folders � Delete contents of cached items � Empty “Recycle Bin” folder storage area � Empty “Delete Items” folder storage area � Backup the system � Prepare a report of the incident and submit it to ISSO and IRT