Incident Findings and Recommendations for Data Exposure through the “Resource Guide” for the 63rd Legislative

Assembly Dick Jacobson, IT Security Officer, North Dakota University System 4/18/2013

Incident Summary Student data, including some potentially identifiable information, was exposed through an NDUS informational document prepared for the ND Legislature. The “Resource Guide” for the 63rd Legislative Assembly (http://www.ndus.edu/uploads/reports/114/2013-resource-guide.pdf), in which the data was exposed, was compiled over a period of months during the fall of 2012 and the PDF was created and made available the second week of January for the Legislative session. Background Information The data that was exposed was used to create several charts in the “Resource Guide” and referenced in the guide as “underlying data” on those charts. The specific charts where the data was exposed are in Section 5 on pages 10.1 through 10.4 and included as Attachment E on this document. The application used to create these charts was from Tableau Software. The evaluation of this application was begun on October 23, 2012 with Linda Baeza Porter, the NDUS Reporting Liason Officer and the report creator for this section of the “Resource Guide”, evaluating Tableau Desktop, and Cameron Battagler, an IT Specialist for NDUS SITS, evaluating Tableau Server. Two Tableau Desktop licenses were purchased on November 15, 2012 in order to develop the information for the “Resource Guide.” In addition, 10 Tableau Server licenses were purchased for an unrelated project in the Chancellor’s Office. Linda Baeza Porter, as the report creator, did not discuss the method to use to publish the materials in Tableau Desktop, for the “Resource Guide”, prior to publishing the report. The materials were eventually published to the Tableau Public service, using Tableau Desktop without the report creator being aware that the “underlying” materials were being made publicly available. The FAQ for the software (http://www.tableausoftware.com/public/faq) states that the data is made public when published, but Linda Baeza Porter stated that when publishing the report, no warnings about the data were noticed by her. There is a Tableau service (Public Premium) that can be licensed that would allow the report creator to keep the underlying data confidential; but Linda Baeza Porter said she was not aware of that at the time. The timeline between when usage of Tableau Desktop started and the actual publishing occurred was somewhat compressed. In preparation for publishing the “Resource Guide”, Linda Baeza Porter developed the materials (charts and text) for inclusion in the guide. Other individuals involved with preparing this portion of the “Resource Guide” included Linda Donlin, Director of Communications and Media Relations, who provided editing of the “Resource Guide”, and Deanna Dailey, Secretary, whose responsibility was to cohesively merge the materials into the document for publication. 1

On Tuesday, March 19, 2013, Rosi Kloberdanz, the Assistant CIO for External Relations, and Dick Jacobson, the NDUS IT Security Officer, were advised by the NDUS CIO, Randall Thursby, that some of the background data that was used to create portions of the document were being exposed. The CIO had been alerted to this by the NDUS Director of Internal Audit and Risk Assessment, Bill Eggert. Dick Jacobson, Rosi Kloberdanz and Cameron Battagler began to determine what data was exposed and how to remove the exposure. This was complicated somewhat because a portion of the Tableau Public infrastructure was experiencing problems and unavailable at the time. Cameron Battagler grabbed a copy of the data he was able to find, in order to document which data was exposed, but did not have the necessary permissions to delete the data. The same morning, about 10:00 am, Rick Anderson, the Director of Infrastructure and Operations, had been made aware of the issue by Linda Baeza Porter, who had been earlier contacted by Michael Kubisak, an Institutional Research Analyst from Bismarck State College. Rick Anderson contacted Rosi Kloberdanz and Dick Jacobson around 12:30 pm. After a brief conversation to merge our knowledge at that time, we determined who would take what steps to make the problem data unavailable. Dick Jacobson contacted Tableau Software to have them block what they could and Cameron Battagler assisted Linda Baeza Porter in removing data, finishing about 3:00 pm. By the end of the workday on March 19, all public access to the data had been removed. On Friday, March 22, Linda Baeza Porter submitted an “After Action” report to Josh Riedy and Rick Anderson. After being advised of the report on March 28, Dick Jacobson asked for and received a copy of the report from Rick Anderson. That report is included as Attachment D Subsequent scans/searches have not turned up any additional data exposed in the ”Resource Guide”. Nor have we found any data cached on the Internet by search engines. The NDUS CIO convened a meeting on the afternoon of March 26 to begin the discussions as to what happened and what is needed to avoid this in the future. On that date Dick Jacobson requested all the datasets exposed in order to determine the scope of the exposure and what follow up actions would be necessary. What began as a single dataset on March 26 expanded, by the evening of April 2, to four datasets that were exposed either in their entirety or in part. Because we cannot say for certain how much of the data was exposed, we must assume these were exposed in their entirety and proceed accordingly. Data Elements Exposed The data elements exposed are listed in Attachment A, grouped by dataset; definitions for the individual elements are listed in Attachment B; and the NDUS Directory Information definitions required by the Family Education Rights and Privacy Act, and listed in NDUS Procedure 1912.2, are included in Attachment C. Dataset 1 contains Name, Address and Emplid, as well as other data. While not all the data items are Directory Information, many of them would not be classified as personally identifiable. Even putting together the fields Ethnic Descr, Gender and Institution, we could probably not identify an individual without the Name and Address or the Emplid.

2

Datasets 2 and 3 each contain Emplid and Institution among their data fields, but no other personally identifiable information. Again, while much of the data is not Directory information, it probably cannot be put together to identify an individual. Dataset 4 contains Emplid but no other information specific enough to an individual to be able to uniquely identify a person. While the Name and Addresses of students are listed as Directory Information in NDUS Procedure 1912.2, Emplid is not defined as Directory Information. Thus each record exposed is a release of nonDirectory Information from an individual’s Student Record. Questions arose about how many of these students had expressed the desire to have their Directory Information also not released, as allowed for under FERPA, and how many of the students were also employees of the University System institutions, and therefore possibly subject to privacy laws and policies specific to employees. From each of the datasets those numbers are: Students requesting additional protection Dataset 1 Dataset 2 Dataset 3 Dataset 4 29 0 22 6 Students also employees 7919 18 2819 777

Of the 57 total students requesting non-release of their Directory Information there are 32 nonduplicated records. For those students that are also employees, the 11,533 records represent 8087 individuals. Note that emplids 0315052 and 0276646 exist in both datasets 3 and 4. We were unable to identify these students in the “current” student data we used to extract some of the other information for this report. Upon further examination, 0276646 was last enrolled at UND in Spring of 2005 and 0315052 was enrolled at LRSC for Fall of 2010 but dropped before the semester started and was enrolled at MaSU for Summer of 2010. Neither appears to be a “current” enrolled student and because neither person exists in our search of current data, we have no indication if they have requested additional protection under FERPA or if they are also employees. For those students that are also employees, we do not have an indication of their employee-related request for privacy or whether they have their employment as a result of their student status. Since these exposed datasets are populated with student data, and some employees exist there because of their student status, there could be an argument that we do not need to be concerned about the employee status and declarations when considering our follow-up actions.

3

However, in looking at specific policies and procedures for employees, from Procedure 1912.3, if an employee requested privacy in HRMS, then the address cannot be released, and from Policy 1912 and Procedure 1912.3, the employee’s emplid is not declared exempt so that information may not be exposed. Likewise, for students, the emplid is not defined as Directory information in Procedure 1912.2 so it cannot be exposed. And according to Policy 1912 and Procedure 1912.2, the students can declare their desire that the Directory Information not be released, as 32 students have done, meaning additional restrictions on some of the information exposed. Data Exposure and Notification Exposure of the emplid itself could be interpreted as requiring notification to all those individuals affected. However, FERPA does not mandate notification to the students in this incident. The Federal Register at http://www2.ed.gov/legislation/FedRegister/finrule/2008-4/120908a.html [[Page 74844]] says: “ Finally, if an educational agency or institution has experienced a theft of files or computer equipment, hacking or other intrusion, software or hardware malfunction, inadvertent release of data to Internet sites, or other unauthorized release or disclosure of education records, the Department suggests consideration of one or more of the following steps: Report the incident to law enforcement authorities. Determine exactly what information was compromised, i.e., names, addresses, SSNs, ID numbers, credit card numbers, grades, and the like. Take steps immediately to retrieve data and prevent any further disclosures. Identify all affected records and students. Determine how the incident occurred, including which school officials had control of and responsibility for the information that was compromised. Determine whether institutional policies and procedures were breached, including organizational requirements governing access (user names, passwords, PINS, etc.); storage; transmission; and destruction of information from education records. Determine whether the incident occurred because of a lack of monitoring and oversight. Conduct a risk assessment and identify appropriate physical, technological, and administrative measures to prevent similar incidents in the future.

4

Notify students that the Department's Office of Inspector General maintains a Web site describing steps students may take if they suspect they are a victim of identity theft at http://www.ed.gov/about/offices/list/oig/misused/idtheft.html; and http://www.ed.gov/about/offices/list/oig/misused/victim.html. FERPA does not require an educational agency or institution to notify students that information from their education records was stolen or otherwise subject to an unauthorized release, although it does require the agency or institution to maintain a record of each disclosure. 34 CFR 99.32(a)(1). (However, student notification may be required in these circumstances for postsecondary institutions under the Federal Trade Commission's Standards for Insuring the Security, Confidentiality, Integrity and Protection of Customer Records and Information (``Safeguards Rule'') in 16 CFR part 314.) In any case, direct student notification may be advisable if the compromised data includes student SSNs and other identifying information that could lead to identity theft.”

The information exposed in this incident does not appear to require notification under the Safeguards Rule mentioned. Even though notification is not required by FERPA, we could choose to notify all the exposed individuals or we could choose to notify those individuals that have expressed the desire to protect their Directory Information. Also, for employees, since the data was derived from the individual’s student record, rather than the individual’s personnel record, ND Century Code section 44-04-18.1 would seem to indicate notification would not be mandated because of an individual’s incidental status as an employee. In any case, any decision to notify individuals of this incident should be made by the NDUS legal and compliance officers after consultations with the NDUS CIO. Recommendations We need to examine our policies, procedures and processes in order to avoid a recurrence of this issue moving forward. We need to look closely at all processes and procedures, at the NDUS level as well as internal to SITS, that address data protection and confidentiality issues. Education of all staff with regard to security of information and individual responsibility for the same must be a part of future projects and plans. The NDUS should also review policies and guidelines for the preparation of materials for publication -- with a special focus on data protection, individual responsibility and project oversight.

5

Attachment A Dataset 1
Acad Career Acad Group Acad Level Acad Plan Acad Program Address Admit Term Admit type Appl Grad Dt Appl Last Sch Attend Appl Number As of Date Citizenship City Citzn Country Country County Emplid Ethnic Descr Gender Group Descr Inst Institution Level Descr Military Status NDUS Grad HS NDUS HS Grad Dt Name Number of Records Plan Descr Postal Program Descr Res Addr County Res Addr State Res Addr Type Res Country Res State Residency State Term Total Credits Type

Attachment A - 1

Dataset 2
Acad Career Emplid CIP Code CIP Code Category CIP Code Description CIP Code Category Description Completion Term Degree Nbr Degree Degree Level Institution Plan description Program Description Program New Program Inactive

Dataset 3
Acad Career CIP Code CIP Code Category CIP Code Category Description CIP Code Description Completion Term Degree Nbr Degree Emplid Institution Plan Description Program Inactive Program New SOC Code SOC Code Description SubPlan Description Term

Attachment A - 2

Dataset 4
Acad Career CIP Code CIP Code Category CIP Code Category Description CIP Code Description Completion Term Degree Degree Class Degree NBR Emplid Institution Institution Name Institution Tier Number of Records Plan Description Program Description Program Inactive Program New Term Description

Attachment A - 3

Attachment B Field Definitions Acad Career - A grouping of students by academic level, such as Undergraduate and Graduate. Valid Values UGRD - undergraduate GRAD - graduate PROF = professional LAW - Law MED - Medical School CNED - Continuing Education Acad Group - Academic Subdivisions of the Institution. Some examples are: College of Business Division of Vocational Education Department of Health and Wellness Acad Level - A grouping of students within a career defined by credit hours earned and institutional policy. Valid Values 10 - Freshman 20 - Sophomore 30 - Junior 40 - Senior GR - Graduate P1 - First Year Professional P2 - Second Year Professional P3 - Third Year Professional P4 - Fourth Year Professional Acad Plan - Academic Plans are majors and minors. Plans are approved by SBHE, and are located in the Academic Plan Table referenced in the navigation below. Some examples are: Associate of Arts - Liberal Arts (AA-LAT) Bachelor of Science - Biology (BS-BIOL) Master of Science - Aviation (MS-AVIT) Doctor of Philosophy - Chemistry (PHD-CHEM)

Attachment B - 1

Acad Program - Designated major/program (area of study) in which a student is working. Address - The location where the student may be reached. This file uses the address usage of Permanent, Home, Mailing, Dorm, Campus. Admit Term - The Term associated with the students Application, admission and or matriculation to the institution. The term a student is admitted to a program. Admit type - Signifies a type of student that applies for admission to an institution. Values Vary by Institution and Career COL - Collaborative Student DC - Dual Credit Student ERE - Early Entry Student FYR - First Year Student NON - Non-Degree Student RDM - Readmit TRN - Transfer Student TRT - Transient Appl Grad Dt – Graduation Date associated with the last school attended on the students application for admission. Appl Last Sch Attend – The school the student declared as the last school (high school, college, university, etc.) the student attended prior to applying for admission to the institution. Appl Number - Automatically generated number assigned in CS to the specific application for that individual. As of Date - The date the data was extracted into the static history tables. CIP Code - Classification of Instructional Program codes are Federal codes used to support the accurate tracking, assessment, and reporting of post-secondary fields of study and program completion activity. CIP Code Description - Description of the classification code. CIP Code Category - Matrix of CIP area of study. CIP Code Category Description - Description of that Matrix. Citizenship (Citizenship Status) - This record provides a student's current citizenship status in the United States. This varies by country. Examples include: Native (1), Naturalized (2), Alien permanent (3); Alien Temporary (4), Permanent Resident (5); Employment Visa (6); Canadian Citizen (7); Other (8); Not Indicated (N), Unknown (U) City – The city associated with the address. Attachment B - 2

Citzn Country - The student's current citizenship country. Completion Term - Term degree was awarded. Country – The country associated with the address. County – The county associated with the address. Degree - An award conferred to a student signifying that requirements have been completed. Degrees are grouped within careers. Degree Class – Type of degree. Some examples are: Associate Bachelors Certificate Degree Nbr - Degree number awarded. Degree Level - The award level of the degree. Emplid - This is the unique identification number assigned to any person (student/employee) who has a record in PeopleSoft. Ethnic Descr - Ethnicity - The race group or groups with which a person identifies or having origins as identified as valid values for IPEDs reporting. Gender - The gender code indicates what the sex of the employee or student is. Valid Values These are consistent across the University System and State Government. F = Female M = Male U = Unknown Group Descr – The description associated with the Academic Group. Inst - The campus that is tied to the person and uniquely identifies the enrollment institution. Institution - The campus that is tied to the person and uniquely identifies the enrollment institution. Inst (from spreadsheet 1) appears to be the same as Institution (from spreadsheet 2) but Institution (from spreadshhet 1) is a derived field and looks to be, in some cases, an alternate way to address the institution. Institution Name - Full name of the institution. Institution Tier – Pathways tier. Some examples are: Attachment B - 3

Two year campus Research campus Level Descr - The description for Academic Level. Military Status - Military status is current. Status relates to the Federal Veterans Services Employment Reporting requirements. NDUS Grad HS – The high school the student attended and graduated from as determined by the high school pick created in Campus Solutions. The selection order includes: 1. GED completion; 2. K-12 graduation data; 3. External education page data; 4. NDUS High School application data; 5. Last School attended on the application for admission; 6. Last school attended on prospect data in Campus Solutions; 7. The high school declared on the previous PeopleSoft online application. NDUS HS Grad Dt – The date recorded in Campus Solutions as the day the student graduated from high school. The selection order includes: 1. GED completion; 2. K-12 graduation data; 3. External education page data; 4. NDUS High School application data; 5. Last School attended on the application for admission; 6. Last school attended on prospect data in Campus Solutions; 7. The high school declared on the previous PeopleSoft online application. Name - Consists of Last-name, first-name middle-name (if applicable). Number of Records – Number of records in this dataset for this emplid. Plan Descr – The description of the Academic Plan. Plan description - description of the student’s plan. Postal – The zip code associated with the address. Program Descr - The description of the Academic Program. Program Description - Description of the students program. Program New - Is the program New Y/N. Program Inactive - is the program inactive Y/N. Res Addr Country – The country associated with the students address type chosen in the following address usage order: 1. PE – permanent; PA – Parent; MA – Mailing; HO – Home. Res Addr State – The state associated with with the students address type chosen in the following address usage order: 1. PE – permanent; PA – Parent; MA – Mailing; HO – Home. Res Addr Type - The students address type chosen in the following address usage order: 1. PE – permanent; PA – Parent; MA – Mailing; HO – Home.

Attachment B - 4

Res Country – The country associated with the address reported on the Official Residency record in Campus Solutions. The data from the row associated with the reported term is used. Res State – The state associated with the address reported on the Official Residency record in Campus Solutions. The data from the row associated with the reported term is used. Residency - The official residency for tuition purposes. This is determined by State and Institution policy. SOC Code – Standard Occupational Classification code as supplied by the U.S. Bureau of Labor Statistics. SOC Code Description – The occupations in the SOC are classified at four levels of aggregation to suit the needs of various data users: major group, minor group, broad occupation, and detailed occupation. Each lower level of detail identifies a more specific group of occupations. SubPlan Description – (Academic Subplan) - A group of courses within an approved academic plan which is identified in an institutional catalog. State – The state associated with the address. Term - The post-secondary academic year and term the data is tied to. The first two-digits represent the academic year while the last two-digits identify a specified term. Term Description – More readable term. Example: Fall 2011. Total Credits - Displays the total number of units taken for progress. This total is used in Student Records to determine academic load. This field excludes audits. Type - type of address field in Address. Address type used in the priority of Permanent, Home, Mailing, Dorm, Campus

Attachment B - 5

Attachment C Directory Information defined from Procedure 1912.2 1. Name (all names on record) 2. Address (all addresses on record) 3. E-mail address (all electronic addresses on record 4. Phone number (all phone numbers on record) 5. Height, weight and photos of athletic team members 6. Date of birth 7. Place of birth 8. Major field of study (all declared majors) 9. Minor field of study (all declared minors) 10. Class level 11. Dates of attendance 12. Enrollment status 13. Names of previous institutions attended 14. Participation in officially recognized activities and sports 15. Honors/awards received 16. Degree earned (all degrees earned) 17. Date degree earned (dates of all degrees earned) Photographic, video or electronic images of students taken and maintained by the institution.

Attachment C - 1

Attachment D Linda Baeza Porter After Action Report After Action On TuesdayMarch 19, 2013 I received an IM from Michael Kubisak at Bismarck State telling me that there was student information to include emplids connect to the interative graphs in the Legislative Report published at the beginning of the session. This document and it linked interactive charts through the tableau software. I had tested the charts prior to release but missed a link that Mr. Kubisak found. I took the following actions      Notified both Josh Riedy and Aimee Copas. Called Deanna Daily and Asked her to remove the document containing the links to the website. Contacted Tableau to ask for assistance. Then with the help of Rick Anderson began to trouble shoot and ensure rest of the information was taken down. Mitigating as much as possible. At this time the risk of student information actually being compromised is low. This report had very specific audience, Legislators. The level of drill down that needed to happen to get to the information was significant. The only report of this information in my purview was from Mike Kubisak. Subsequent conversations revealed that Randall Thursby CIO was working from a different angle but has not provided me with any information. The information was still in many ways directory but did include units enrolled. The only outlying information would be that if someone down loaded the actual student breakout into a paper or electronic spreadsheet on their computer. All data connections have been severed.

  

Future Actions.  Discontinue interactive graphs on any published documents  Get further training on Tableau Software  Incorporate testing protocols  Use RFP process on purchases
Attachment D - 1

SLOW DOWN,.

Please find attached the screen shots of the process of publishing

Attachment D - 2

Attachment D - 3

Attachment D - 4

Sign up to vote on this title
UsefulNot useful