5.4.1 General computer security

• High speed internet connections are secured by requiring connection to the Ann Arbor VPN with the Windows firewall enabled.
• Wireless Internet connections are secured by requiring connection to the Ann Arbor VPN using a password protected wireless connection or a “known” public connection (hotel, Starbucks, etc.), and with the Windows firewall enabled.
• Wireless broadband connections are secured when connected to the Ann Arbor VPN.
• Passwords for applications used by field employees are randomly generated passwords. Depending on the project requirements, password changes may be required periodically to provide even greater security. A secure password includes numbers, punctuation, and capitals in a password with 8 or more characters.
• Data collection hardware is password protected and locked when closed. It is also locked if left open with no action after fifteen minutes.
• Data encryption software is installed on interviewer laptops to protect databases from intrusion. Details of this system are tightly controlled. Only a small number of staff in Survey Research Operations and in Computing and Multimedia Technologies know the rules for this software. This strict control enhances this software.
• Survey and sample information for completed cases is removed at regular intervals from laptops when specific criteria have been met.
• Individual desktop PCs are password protected and are locked when the employee is away from the machine.  Users should also take the following steps to protect their PCs and personally identifiable information:
• Run Microsoft updates the same day they come out. The normal schedule is the second Tuesday of the month.
• Make sure virus protection software is installed and up-to-date. ISR uses the University of Michigan supported software MS Forefront.

Password Protecting and Locking Your Computer
Virus Protection from U-M

• Do not use administrator rights for normal day-to-day operation.  For those using Windows 7, always stop and think when the User Account Control dialog requests your credentials in order to elevate your rights.
• All SRO areas in the Perry Building have 24-hour key card controlled access. Staff lists are regularly reviewed for changes in access to building locations.

5.4.2 Cell phone security

• Interviewers are not to use the University of Michigan issued cell phone to conduct interviews.
• If the University of Michigan cell phone is lost or stolen, interviewers are instructed to immediately report it. The number is then disabled and the interviewer is asked to provide details regarding the missing equipment, as well as any messages that may be on the phone and the call history. [Note: Phone messages can still be checked after the number has been disabled.]
• University of Michigan cell phones are password protected.
• Interviewers are instructed to clear the call history and voicemail whenever there are calls to or from respondents. 
• University of Michigan issued cells phones are expected to be kept in a secure location when not being carried by the interviewer or staff member on SRO business.

5.4.3 Email security

• ISR email accounts are used only for University of Michigan business.
• Respondent’s names and/or addresses are NEVER used ANYWHERE in an email written by SRO staff.
• When email is used in tracking activities (i.e., email sent to respondents), no study-specific details or respondent information is included anywhere in the email. The purpose of such emails is to establish contact and request information needed for telephone or face-to-face contact to discuss the study and/or conduct an interview with the respondent or resident. All correspondence follows IRB guidelines.
• Once the information needed is obtained and recorded in the appropriate sample management system, all emails are deleted. Emails are routinely backed up at the server level, but are permanently deleted after 14 days.

5.4.4 GPS security

• When using a GPS device to locate a respondent’s home, interviewers are advised to program only the nearest cross streets, if known, instead of the exact address.
• The history on the GPS unit is deleted at the end of each trip.  This includes clearing out the address from all memory storage locations on the device such “Favorites” and “Recently Found”.
• GPS units are expected to be kept in a secure location when not in use by an interviewer.

5.4.5 Tracking security

• A third party vendor (currently the LexisNexis Accurint web-based product) is sometimes used for tracking purposes. Access to these sites is limited to the Internet trackers, the tracking coordinator, and the production manager.
• Training is provided to all trackers in the use of online resources and on where and how to appropriately document all sources and record information.    
• All printed materials generated in the course of tracking are destroyed — typically shredded by the tracker, whether centrally located or decentralized.
• LexisNexis, the third party vendor which supplies the Accurint product, takes steps to protect against the loss, misuse or unauthorized alteration of personally identifiable information through their website. Information regarding searches launched is used by LexisNexis only for auditing purposes and to learn more about the needs of its customers. Access to personally identifiable information is limited to only those employees who require access to carry out their job responsibilities.
• The LexisNexis statement of security and privacy is as follows (directly from website):

“LexisNexis has systems security intended to ensure the availability, confidentiality and integrity of data. We have multi-layered systems for IT, IS and physical security.

“We use industry-standard access control software and methods that include vulnerability analysis, rigorous intrusion detection systems and regular penetration testing. Our information and system security professionals continuously refine these processes as threats evolve.

“LexisNexis serves many high-level U.S. government agencies and other customers that have extremely stringent data security requirements and share our concern for data protection and individual privacy. LexisNexis continues to set the standard for serving these customers.”

A key element in ensuring survey data security is a project’s data collection staffing plan, which is the basis for:

• Creating a data collection staffing timeline that takes into consideration:
• Number of staff;
• Time to recruit and hire new staff; and
• Time to prepare hardware for training, certification, and production.
• Creating a project staffing table using the Project Staffing List Template. Data Collection Operations (DCO) and Technical Services Group (TSG) staff will use this to track interviewers and their hardware, and remove staff sample lines to and from sample management databases and hardware.
• Create a production, training, or certification project using the staffing table.
• A minimum of two weeks prior to data collection training, TSG will start preparing hardware.
• During this period, report staffing changes (adding or removing staff) to both DCO Inventory and the TSG Help Desk.

Project Staff List Template

5.5.1 Adding and removing staff from a data collection project

As shown in Figures 5.1 and 5.2, there are several units involved in adding and removing staff from production projects.

Following are the steps taken when adding staff to a production, training or certification project (Figure 5.1). The process typically takes two weeks. Therefore, to initiate adding staff to a production project, the staff list must be completed and submitted a minimum of two weeks prior to training.

Tasks Involved in Adding Staff to a Project 

Interviewers and other staff should be removed from projects as soon as they terminate employment or leave the project. Figure 5.2 below outlines the key decision points and tasks related to removing staff from projects.

To remove a large group of staff as a project closes, a master file may be used to notify DCO and TSG.  As individual interviewers move on and off a project on a flow basis, whenever a production manager makes staffing changes, separate automated emails are sent to both DCO and TSG. As this occurs, it is critical to make sample transfer decisions (as needed) prior to removal.  Close communication with the Help Desk at this stage is imperative.

Tasks Involved in Removing Staff from a Project

Figure 5.1. Adding Staff to a Project

Figure 5.2. Removing Staff from a Project

5.5.2 Removing a nonresponsive terminated employee

Removing a terminated staff member from a project involves a more complex set of considerations. Note that this should not be done without understanding the possibility of lost data. In addition, typically there are other items that are due from the staff (i.e., travel advance money, equipment) and effort must be made to communicate to the employee before this process is started.  The steps below and Figure 5.3 outline these key decision points and related tasks.

Tasks Involved in Removing a Nonresponsive Terminated Employee  

Figure 5.3. Removing a Nonresponsive Terminated Employee

5.5.3 Removing production sample from hardware

Prior to the beginning of production, the project team should define the data security procedures for removing finalized production data from interviewers’ laptops. These security procedures should be part of the project management plan and should be reviewed with the SRO Administrative Group (as most projects do not follow “standard” procedures).

Standard procedures include the following:

Tasks Involved in Removing Production Sample from Hardware
(interviewer returning hardware) 

Removing Lines from Hardware — Current Procedures

Figure 5.4. Removing Production Sample from Hardware

5.5.4 Monthly audit of removal of lines from hardware

Each month TSG runs three audit reports for reviewing lines still on interviewers’ laptops.  Data Managers review these reports and resolve issues if needed.  These three reports provide details about the following:

• List of Survey Services Lab CATI and SAQ projects with sample assigned to interviewers in the field (with active remote databases);
• Inactive projects with SIDs assigned; and
• Active projects with sample having “finalized” result code status and result date more than 6 months prior (due to the complexity of some projects, this may be OK). 

These reports are located here:

SID_Assignment_Reports

5.5.5 Removing staff from a project without retrieving hardware

When an interviewer has finished work on a project and is currently assigned to another project, or will be assigned to another project in less than one month, it is the responsibility of the Production Manager (PM) to make arrangements for the SurveyTrak project and project data to be removed from the laptop (see Figure 5.4). 

Tasks Involved in Removing Production Sample from Hardware
(interviewer not returning hardware)

5.5.6 Shipping hardware

Interviewers may need to send hardware back to Ann Arbor during or after data collection. To ensure that the hardware is not lost or broken, shipping instructions are provided to all interviewers at the start of a project. They are to be used each time hardware is shipped to Ann Arbor, whether for repair or when a project closes.

Hardware Shipping Instructions

Sensitive data that is to be transmitted electronically must be adequately protected.  The most common method for protecting such data is to encrypt them prior to transmission. To save on transmission times, these files are also typically compressed. A program such as WinZip is ideal for performing the compression and encryption. WinZip allows for the use of strong passwords for the encryption key.

5.6.1 Password creation

In order to be effective, a password must be strong. A strong password should contain at least 12 characters (letters, numbers, and symbols), upper and lower case letters, at least one number, and at least one symbol. Users should NOT re-use passwords since there is no control over the password once it is shared.

5.6.2 Password sharing

Once the password is created it must be shared with the recipient. Passwords should never be shared via the same communication method as the file. If you e-mail the encrypted file, you should not also e-mail the password. If an unintended recipient can obtain the file from an e-mail transmission, it must be assumed they can retrieve the password, even if it is sent in a separate message.

The safest method for sharing password is with a phone call, or postal mail. If sent via post, call the recipient to alert them to the passwords impending arrival. Be sure to provide minimal context as to the password’s purpose in the post. This will prevent unintended recipients from understanding its purpose.

5.6.3 Password storage

Just as important as safely transmitting the data and password is storing the password.  If the password needs to be retained then store it in a locked cabinet or in a “password safe” on your computer.

Here are some acceptable password storage utilities:
LastPass
Password Safe

If you have any questions about the process, contact Computing and MultiMedia Technologies (CMT).

5.6.4 Protecting data during receipt and delivery

A data protection plan can include:

• The data transfer process;
• Data storage location(s) and encryption;
• Physical protection;
• Staff certification;
• Access controls;
• The data destruction plan;
• ISR/SRC public network description; and
• ISR/SRC private network description.

Data Protection Plan Example

ISR follows the incident management and reporting procedures of the University’s Information Security Incident Management Program, as outlined in the Standard Practice Guide (SPG). Examples of information security incidents include (but are not limited to):

• Computer security intrusion;
• Unauthorized use of systems or data;
• Unauthorized change to computer or software;
• Loss or theft of equipment used to store private or potentially sensitive information;
• Denial of service attack;
• Interference with the intended use of information technology resource; and
• Compromised user account.

This includes lost or stolen data collection hardware. Due to the potential for unauthorized access to survey data, immediately report lost or stolen data collection hardware immediately to the Director of Data Collection Operations, the Manager of Production Management, the Inventory Control Supervisor, and the project Production Manager.

In SRO, potential data collection security incidents are reported directly to the ISR Information Security Coordinator by the Director of Data Collection Operations. Members of the SRO Operations Team are responsible for reporting other potential information security incidents. It should be noted that information incidents as defined in the policy apply to all information and data and are not restricted to computing storage or processing.

SRO also follows SRC procedures for the handling of security incidents in ISR facilities, working closely with Computing and Multimedia Technologies (CMT). If SRO operations staff suspect an information security incident, it is important to immediately and quickly notify CMT and to:

• Restrict network access (CMT);
• Disable all remote access;
• Keep the machine out of use; and do NOT connect to the network;
• Run anti-virus software;
• Power down the machine; and
• Attempt any kind of unilateral mitigation process.

CMT will then proceed to implement SRC procedures for responding to an information security incident.

ISR Information Technology Incident Management
SRC Information Security Incident Response Procedure

SRO database administrators (DBAs) audit user access to SRO network servers, sample management and reporting systems and databases, and various other databases, on a quarterly basis—on or about July 15, October 15, January 15, and April 15 of each year.  They also audit users’ rights to confirm users have correct privileges, those no longer employed are removed, and those who have changed units or job functions have their rights modified appropriately.

A database is maintained of all actions taken to add, remove or adjust user rights (T:\projects\User Access Actions Log\User_Access_Actions_Log.mdb).  This includes:

• DBA initials;
• Change date;;
• User Name; and;
• Action Taken (Add, Remove, or Change Access).

In some cases, updates are made to the user access actions database as needed between quarterly audits (e.g., for individual requests for access to a particular database). Minimally this will be done for each quarterly audit. After an audit, DBAs note that the audit was done by adding a record and placing a note in the “Change Access Notes” field (e.g., “Quarterly audit of FRED and TENROX”).

See the “SRO Quarterly Audit Policy” document for greater detail on the servers and databases monitored by each unit.

Please note, while many topics related to data and hardware security have been covered in this section, some studies will require additional security systems. This may include secure environments and protocols such as FSEC and the consideration of Federal Information Security Management Act (FISMA) guidelines. Additionally, there may be other security concerns that must be addressed for school or web-based studies.