Initial emphasis on UW-Madison Social Security Numbers (SSN’s)

1. During the initial period from January 1st 2015 through December 31st 2020 the Restricted Data Security Management policy will only apply to UW-Madison SSN’s. The initial period may be extended. For clarity and simplicity, the implementation procedures and other supporting documentation will initially be written to address only SSN’s.

2. A threshold value of ”more than 100 unique UW-Madison SSN’s” indicates there is significant use that requires action at an increased priority level to locate and protect the data. A UW-Madison unit may choose to use a lower threshold value. A higher threshold value may be used with the consent of the leadership of the unit and Office of Cybersecurity.

Priorities for discovery of UW-Madison SSN’s

1. At high priority, (i.e. higher than “routine administrative operations,”) check UW-Madison-owned or -operated systems where data on the system can be scanned with Identify Finder and:

   1. At least one user of a desktop or laptop system is a person whose role at the institution has made them a direct user of the Integrated Student Information System (ISIS), the Shared Financial System (SFS), the Human Resource System (HRS), or the UW-Madison data warehouse (InfoAccess).

      Scanning of enterprise systems has shown that the vast majority of UW-Madison SSN’s are located in one of those four systems. The direct users of those systems are likely to have SSN’s.

      For assistance identifying those users contact: cybersecurity@cio.wisc.edu.

   2. At least one user of a desktop or laptop system is a person who has been a recipient of data or reports from the direct users of ISIS, SFS, HRS, or InfoAccess.

      Many direct users of these enterprise system are providing data or sending reports to others. The recipients are also likely to have SSN’s.

      To identify those users:
      • People who have sent reports to others may be able to identify who received them.
      • Those who have received reports may be able to self-identify.

   3. On a server, check areas used for data storage by users identified in (i) and (ii) above, unless the only use of the server by those users fits one of the exceptions listed in procedure (7).

      Rather than attempting to narrow the area scanned, it might be simpler to scan an entire server. It might be simpler to scan all servers that could contain data from such users.

      All checks done at high priority involve UW-Madison-owned or -operated systems where the data can be scanned with Identify Finder. Use of Spirion (formerly Identity Finder) is not required. When using Spirion, if Spirion cannot be run on a system, it may be possible to make the data accessible to a system on which Spirion can be run. For more information see the list of all KB articles related to Identity Finder (now known as Spirion).

2. At moderate priority (i.e. similar to “routine administrative operations,”) check:

   1. Desktops, laptops, portable devices, cloud services, or other data storage locations that are used by a person for whom Spirion (formerly Identity Finder) scans (or manual checks) described in (2)(a) above have discovered more than 100 unique UW-Madison SSN’s associated with that person’s server, desktop, or laptop use.

      Some checking may need to be done manually either by:
      1. examining the device, service or other storage location, or
      2. interviewing the user to determine what UW-Madison SSN’s (if any) might be present in such locations.

   2. Other storage locations of any kind where the pattern of usage or other prior experience make it reasonable to believe that there may be more than 100 unique UW-Madison SSN’s present.

      Some checks done at moderate priority may involve personally-owned devices or privately-contracted services that are used for UW-Madison business. See procedure (6) below for how to handle this in a manner that respects the privacy of individuals.

3. At low priority, as workload or circumstances allow, check other storage locations that are used for UW-Madison business, unless the only use of the location fits one of the exceptions listed in procedure (7) below. See procedure (6) below for how handle personally-owned devices or privately-contracted services in a manner that respects the privacy of individuals and non-university entities.

   There are several hundred thousand locations where a UW-Madison SSN might be located. It is not practical to check every one of them. Priority should be placed on high and moderate risk locations such as those described in (2)(a-b) above. Nevertheless, other plausible locations should be scanned or manually checked when it is practical to do so.

Annual discovery and reporting of UW-Madison SSN’s

Provisions (1)(a) and (1)(d) of the policy mandate the annual discovery and reporting of the presence of UW-Madison SSN’s. Details for reporting are published in the DoIT Knowledge Base (KB).

The use of Spirion (formerly Identity Finder) is recommended, but is not required by the policy. The recommended configuration of Spirion will be tuned to find SSN’s while minimizing the number of false positives. There will inevitably be some false positives. For more information see the list of all KB articles related to Identity Finder (now known as Spirion).

The annual discovery and reporting process does not preclude checking systems more frequently. Results from checks that are less than one year old can be used when preparing the annual report.

When Spirion (formerly Identity Finder) is not used:

1. If it is reasonable to believe that UW-Madison SSN’s are present, the storage location must be reported as a location that contains UW-Madison SSN’s. For example, an analysis of business processes might indicate that a device or service is likely to contain SSN’s. It is not necessary to confirm that SSN’s are present. Simply report the device or service as a location that contains SSN’s. There is no practical distinction between the likely presence and the confirmed presence of UW-Madison SSN’s. Either way, the storage location needs to be managed as one that contains UW-Madison SSN’s.

2. If it is reasonable to believe that UW-Madison SSN’s are not present, that storage location need not be reported as a location that contains UW-Madison SSN’s.

   For example, an analysis of the pattern of usage might indicate that it is unlikely that UW-Madison SSN’s are present. A report of this is not required. The intent of the reporting requirement is to locate UW-Madison SSN’s. It is not the intent to create an inventory of all storage location.

   There is no practical distinction between a location that is unlikely to contain UW-Madison SSN’s and one where the absence of SSN’s has been confirmed. Either way, the location need not be managed as one that contains UW-Madison SSN’s.

   Exercise caution when deciding that a computing device or service is unlikely to contain SSN’s. People often do not realize SSN’s are present. UW-Madison employee and student ID numbers previously included the same digits as the person’s SSN. Research proposals prior to 2006 sometimes required the SSN’s of the collaborators. Certain UW-Madison business processes currently require the use of SSN’s. Email is particularly prone to contain unexpected or forgotten collections of SSN’s.

3. If neither (a) nor (b) applies, the presence or absence of UW-Madison SSN’s is considered sufficiently uncertain to warrant reporting the storage location as a location that contains UW-Madison SSN’s. The degree of protection required is uncertain, but some additional protection may be warranted, depending upon the circumstances.

   Example reasons why a location may be a possible location of UW-Madison SSN’s include:

   • An analysis of business processes or patterns of usage is unable to determine that it is likely or unlikely that SSN’s are present.
   • It is not practical to scan the location using Spirion (formerly Identity Finder), and the data in that location is too large, complex or otherwise difficult to evaluate using other methods.
   • It is not practical to inspect or assure that a device or service does not contain or process a significant number of SSN’s.

4. When the presence of encrypted UW-Madison SSN’s is known, likely or suspected, the location must be reported as one that contains UW-Madison SSN’s.

   While encrypted data is generally more secure than unencrypted data, encryption does not provide protection against attacks that can access the data when it is presented to the user or application in decrypted form. This is not an unusual scenario, because data can only be viewed or changed while decrypted.

   For example, “full disk” encryption of a laptop or other computing device usually requires entering the password or other key when the device is started. While the data on the physical storage media remains encrypted, the data is automatically presented to the operating system and applications in decrypted form. Any attack that compromises the running device will evade the encryption.

   While encrypted, it might not be possible or practical to use Identify Finder or other checks to locate UW-Madison SSN’s within the data. This will depend upon how the data is encrypted. In such cases, it may still be possible to deduce that UW-Madison SSN’s are likely or possibly present, based upon the type or use of the data.

Reducing the Presence of UW Madison SSN’s

Provisions (1)(b), (1)(c) and (3) of the policy require that the presence of UW-Madison SSN’s be reduced to the extent practical. What is practical to accomplish is a question of professional judgment guided by appropriate risk management.

The requirements for discovery and reporting of SSN’s are distinct from the requirements to reduce the presence of SSN’s. The people responsible for finding SSN’s are not necessarily the same people responsible for reducing their presence. If SSN’s are discovered by someone who is unable to reduce their presence, the recommended course of action is to simply report the location of the SSN’s as described in procedure (3). The Office of Cybersecurity will follow up and work with people to help them reduce the presence of SSN’s.

The following are examples of ways to reduce the presence of UW-Madison SSN’s:

1. During the annual discovery and reporting process, instances of SSN’s may be found that are no longer needed for immediate operations. (See provisions (1)(b) and (1)(c) of the policy.) When this occurs:

   1. Some instances of SSN’s may be disposed of. Examples include SSN’s that are not part of a UW-Madison record, or are included in other data that is not needed for future operations.

      Whenever possible, disposal is the preferred approach. Be careful to retain UW-Madison records according to the approved records management schedule. Records management training is at http://www.library.wisc.edu/archives/records-management/training/

      If you have questions about UW-Madison records or record retention schedules, please contact Records Management at recmgmt@library.wisc.edu.

   2. Some instances of SSN’s must be retained. Examples include SSN’s that are part of a UW-Madison record, or are part of data that is needed for future operations.

      When retaining SSN’s, the preferred approach is to move the data to any offline or online storage location that is approved by The Office of Cybersecurity for the long-term storage of UW-Madison SSN’s.

      Only the minimum number of UW-Madison SSN’s necessary for immediate operations should be retained in other storage locations. How much to retain is a matter of professional judgment guided by appropriate risk management.

      Approved locations for the long-term storage of UW-Madison SSN’s will be published in the KB as they become available. To get started:

      • Offline storage of media in a locked cabinet or other physically secure area is acceptable.

      • Strong encryption of the data is acceptable. For guidelines, see the "Interim Recommended Procedures for Faculty, Staff and Student Employees" at https://kb.wisc.edu/itpolicy/cio-encryption-standard.

      • There are approved storage locations in the UW-Madison Data Center. For more information see https://it.wisc.edu/services/storage-file/.

      • Any location that is substantially compliant with the following standards is approved for the long-term storage of UW-Madison SSN’s:

        • The Payment Card Industry Data Security Standard (PCI-DSS)
        • The Health Insurance Portability and Accountability Act Security Standard (HIPAA Security Standard).
        • The Federal Information Security Management Act (FISMA) implementing the moderate or higher security controls documented in the most recent revision of the National Institute of Standards and Technology Special Publication 800-53 (NIST SP 800-53) and related publications.
        • A variety of other security standards used in other locations where UW-Madison SSN’s might be stored. For more information contact the Office of Cybersecurity.

2. There are opportunities to reduce the presence of UW-Madison SSN’s in forms, files, data records, data sets, databases, applications, processes, and other similar storage locations. The data stewards, data custodians, process owners, and others with similar data management responsibilities are responsible for reducing the presence of UW-Madison SSN’s to the extent practical. (See provision (3) of the policy.) Examples of ways to accomplish this include:

   • SSN might no longer be needed. Use of SSN was more prevalent in the past.
   • Use a partial identifier such as the last for digits of SSN.
   • Use a different identifier such as student or employee id. When the SSN is needed, use a separate and secure data service to lookup the person’s SSN.

Protecting SSN’s that are not in locations approved for the long-term storage of UW-Madison SSN’s.

It is usually necessary to apply appropriate security controls when more than 100 unique UW-Madison SSN’s are present in a location that is not approved for the long-term storage of UW-Madison SSN’s. These controls are currently specified in the Departmental IT Security Baseline and the CIO IT Policies that apply to sensitive information. If some of the specified controls are impractical, other compensating controls may be applied.

The policy does not mandate that the Departmental IT Security Baseline be followed in its entirety. Like most standards, some parts are mandatory and other parts are recommended.

Some of the controls in the Departmental IT Security Baseline are mandated by other policies. Examples include:

• UW System - Acceptable Use of Information Technology Resources
• IT Compliance Agreement
• Electronic Devices Connected to the Network Policy
• Encryption Policy and Procedures
• Incident Reporting Policy and Incident Reporting Procedures
• Password Policy and Standard

Having 100 or fewer unique UW-Madison SSN’s does not exempt a location from other policy requirements. The threshold value of "more than 100 unique UW-Madison SSN’s" indicates that security controls of all kinds need to be applied at higher priority.

Discovery and reporting for personally-owned devices or privately-contracted services

The policy applies to personally-owned devices or privately-contracted services that are used for UW-Madison business. Both university and non-university data may be mixed together in such locations.

• Business use of personally-owned devices or privately-contracted services

  UW-Madison employees, contractors and associates who are required to use or choose to use their own devices or contracted services for UW-Madison business are obligated to either:

  1. allow the device or service to be inspected, or

  2. provide satisfactory assurances that either:

     1. there are 100 or fewer unique UW-Madison SSN’s present on the device or service, or
     2. if more than 100 are present, either:
        • the number of unique UW-Madison SSN’s present will be reduced in a timely manner to 100 or fewer, or
        • the UW-Madison SSN’s are or soon will be protected as described in the mandatory portions of the Departmental IT Security Baseline and the CIO IT Policies that apply to sensitive information, or if not protected in that manner, other compensating security controls will be implemented in a timely manner.

  The university respects the privacy of employees, contractors and associates. Attempting to force an inspection of non-UW-Madison owned computing devices or services is inconsistent with respect for the privacy of the individual or non-university entity. The option to provide satisfactory assurances respects their privacy while at the same time allowing the UW-Madison to meet its obligations to locate and protect UW-Madison data.

• Satisfactory assurances

  Assurances are satisfactory if a reasonable person would perceive them as satisfactory. Management of the unit is accountable for compliance, and will determine what is sufficiently satisfactory. This may vary with the circumstances.

  Satisfactory assurances do not need to be onerous or invasive. For example, a simple oral assurance that 100 or fewer UW-Madison SSN’s are present may be satisfactory when typical patterns of use indicate that under normal circumstances few SSN’s should be present. When it seems likely that more are present, the owner might be asked to check some typical locations, and if any are found, delete unneeded copies of the data. Other criteria are possible, depending on the circumstances.

  As warranted, higher management, in consultation with the Office of Cybersecurity, can provide additional guidance to clarify what is considered satisfactory.

  If there is significant ongoing uncertainty regarding the presence of 100 or more unique UW-Madison SSN’s, the preferred course of action is to report the device or service as a location that contains UW-Madison SSN’s. See procedure (3)(c) above. Uncertainty increases risk. If the risk appears to be too high, the university may follow up to find ways to reduce the risk.

Exceptions and Exception Procedures

1. It is not necessary to scan, manually check, or report a storage location if:

   1. the location is a device or service that only stores data temporarily and under normal circumstances will automatically delete it after some reasonably short period of time, for example: printers, copiers, scanners, network devices, and other similar devices or services.

   2. the only SSN’s that are present or likely to be present are the result of minimal personal use (as permitted by UW System - Acceptable Use of Information Technology Resources.) Users are responsible for exercising discretion in where they store such SSN’s.

   3. the only UW-Madison SSN that is likely to be present is the user’s own SSN. The user is responsible for exercising discretion in where and how they store their own SSN.

   4. it is otherwise reasonable to believe that UW-Madison SSN’s are not present at the location.

      Be cautious in making an exception for this reason. Experience over the last few years has shown that people tend to underestimate the presence of SSN’s.

      • Email and email attachments tend to be an unexpected location of SSN’s. The sender or receiver may not realize or remember that SSN’s are present.

      • Some current UW-Madison business processes require use of SSN. It is not unusual for this to result in the retention of SSN’s. This is is easy to overlook or forget.

      • Other likely locations include instructional, research and financial data or reports created prior to 2006. SSN was more widely used as a personal identifier in past. Large numbers of SSN’s (more than 100) can be unexpectedly present in older data.

2. Circumstances may warrant other exceptions. Please contact the Office of Cybersecurity regarding other possible exceptions. Please see the contact information in (9) below.

Additional procedures

1. The Office of Cybersecurity will publish additional procedures in the DoIT Knowledge Base (KB).

2. If what you need is not present in the KB, please contact the Office of Cybersecurity.

Contact

• Please direct questions or comments on these procedures to Office of Cybersecurity by emailing cybersecurity@cio.wisc.edu or by using the contact forms at https://it.wisc.edu/contact-us/.

• For assistance identifying users of ISIS, SFS, HRS or InfoAccess, please contact: cybersecurity@cio.wisc.edu or by using the contact forms at https://it.wisc.edu/contact-us/.

• For UW-Madison SSN storage options in the UW-Madison Data Center, please see https://it.wisc.edu/services/storage-file/.

• For questions about UW-Madison records or records retention schedules please contact Records Management at recmgmt@library.wisc.edu.

References

• CIO IT Policies
• Records Management Training
• Departmental IT Security Baseline
• Electronic Devices Connected to the Network Policy
• Getting Started with Identity Finder (now known as Spirion)
• Identify Finder FAQ (now known as Spirion)
• IT Compliance Agreement
• Incident Reporting Policy and Incident Reporting Procedures
• List of all KB articles related to Identity Finder (now known as Spirion)
• Password Policy and Standard
• UW System - Acceptable Use of Information Technology Resources
• Encryption Policy and Standard