Loading...
The URL can be used to link to this page
Your browser does not support the video tag.
Home
My WebLink
About
CORRESPONDENCE - RFP - 8329 SURVEY SERVICES - MISCELLANEOUS PUBLIC OPINION SURVEY (9)
Proposal for the City of Fort Collins TRAVEL BEHAVIOR SURVEY DATA COLLECTION PROGRAM 2017 Resident Travel Survey Submitted February 2017 2955 Valmont Road Suite 300 Boulder, CO 80301 T: 303-444-7863 F: 303-444-1145 www.n-r-c.com 1 Contents 2017 Resident Travel Survey ........................................................................................................... 2 Proposed Scope of Work ....................................................................................................................................... 2 1. Project Communications ............................................................................................................................. 2 2. Development of Data Collection Tools ................................................................................................. 3 3. Survey Distribution ....................................................................................................................................... 6 4. Survey Results Analysis ............................................................................................................................... 9 Timeline (2017) ..................................................................................................................................................... 11 Cost Estimate ........................................................................................................................................................... 12 2018 Employee Travel Survey ...................................................................................................... 12 Appendix A: NRC Security Information ...................................................................................... 13 Introduction ............................................................................................................................................................. 13 Data collection ........................................................................................................................................................ 13 Online ..................................................................................................................................................................... 13 Paper ....................................................................................................................................................................... 13 Data transfer ............................................................................................................................................................ 14 Retention policy ..................................................................................................................................................... 15 Backups ...................................................................................................................................................................... 15 Breach policy ........................................................................................................................................................... 16 Security testing ....................................................................................................................................................... 16 Appendix B: DV Mobile Scope of Work and Security Information .................................... 17 2 2017 Resident Travel Survey Proposed Scope of Work NRC understands that the City of Fort Collins (the City) would like to conduct a trip diary study to understand the modal share and trip-making behavior of residents. The information gained from such a project can be used to assist transportation planning and evaluation. Specifically the City would like (at a minimum) information on: Trips by mode (biking, walking, transit, driving, etc.) and purpose (work, shopping, school, etc.) Telecommuting trends Trip characteristics by mode Vehicle occupancy Vehicle ownership and availability Trip distance Trip start times Traveler demographics (age, occupation, gender, etc.) Below we describe the steps we would take to complete this project. 1. Project Communications Sonya Wytinck will serve as the primary contact at NRC, but Fort Collins staff are welcome to contact Erin Caldwell in Sonya’s absence. NRC will meet with City staff in Fort Collins on February 17th for a kick off meeting to begin to craft survey questions. During the survey development phase (Feb 17 to Mar 24) we propose to communicate primarily via email, as we find email is generally most efficient for editing of documents. However, we will be available for telephone (or go-to-meeting) consultation whenever it is most effective to discuss the pros and cons of question choices or issues that arise. Because of the nature of the process, we expect that we will be communicating several times a week. When the study materials are finalized NRC/DVmobile will program the diary and household survey in the App (and possibly also in a Web version). We will provide City staff with the opportunity to test these versions. NRC will share final PDF proofs of all the paper study materials for approval before printing. Once the materials are sent for printing and mailing, NRC will provide updates each Monday via email on the project status (printing, mailing, numbers completed and returned, analysis phase, report writing, etc.). If there are any problems in the 3 implementation process, NRC will notify Fort Collins staff immediately. We expect to respond to queries and requests within 24 hours. Public Outreach NRC recommends that Fort Collins lead the public outreach efforts in advance of the survey to boost response among selected households, with the added benefit of boosting residents’ trust in local officials. This trust will accrue by conveying Fort Collins leaders’ interest in listening to its residents. Survey publicity is especially important among those harder-to- reach populations, particularly those with whom the City may not have an established relationship. NRC will support the City’s communications effort by giving feedback on your plan, press releases and other publicity wording, if your communication team so desires. We have samples of communications plans our clients have developed that we can share with the City. Generally, we recommend publicizing the survey three to four weeks prior to data collection. This can include posts on social media, a feature on the City’s website, articles in the local newspapers, 3-1-1 announcements, press releases, radio addresses or a video on the City’s YouTube channel. All City staff should be made aware of the upcoming survey so they can communicate to residents about it. The key to these communications is to get the word out about its importance, raise interest in participating, communicate how the City intends to use the results and to increase the credibility of results. 2. Development of Data Collection Tools We will use the materials we have developed for the City of Boulder as our starting point, and will confer with you to determine what additional data elements may be needed, and if any could be deleted. We will then create a draft of the survey materials for your review and continue revising through an iterative process between NRC and Fort Collins Transportation Master Plan team. All final materials will be branded with the City of Fort Collins name and logos. There are several data collection tools that will be created. The most important piece is the travel diary itself, where each trip made during the 24-hour period is recorded. In addition, a “household travel survey” is included, in which other information about the survey participant is captured, such as demographic information, household vehicle and bicycle ownership, other behavioral or demographic characteristics and perhaps some opinion questions. Other materials will accompany the data collection tools, including a cover letter explaining the importance and purpose of the study, as well as instructions on how to participate in the study. 4 Website A website will be created as the entry point for completing the survey. The website will include: Instructions on using the App, Paper and Online Surveys Troubleshooting FAQs with contact information for further questions (NRC email/voicemail) Contact information for the City of Fort Collins, if residents have non-technical questions or concerns (e.g., why are you doing this survey? is it legitimate?) Links to the Apple App Store and Google Play PDFs of the paper surveys to download and print Link to the online survey (if provided) Paper materials The list of materials to be developed include: Two notification postcards to inform selected recipients of the study. o One will invite half the sample to complete the survey via a website where they can download the app, download and print paper materials, or complete the tasks via web survey o One will invite half the sample to complete the survey via a website (as described above) or to wait a week for paper materials to arrive in the mail. The trip diary survey packet, including: o A cover letter signed by an elected official or senior staff member, o Instructions on how to complete the materials, o A trip diary to record each trip taken during a 24-hour period, o A “household” survey to capture demographic and other respondent characteristics, and o A business reply envelope in which to return the survey materials. o Instructions for accessing and using app via a dedicated website. Each selected household will have a unique ID that will match to their home address. This will be ink-jetted on the diary and invitations and will be used as a passcode at the start of the App. We would recommend that the City provides a telephone number and email of a staff member that recipients can use to contact you with any questions or concerns they may have about completing the assignment. We can help you with what might be the most common questions, or you can refer questions to us to respond. 5 Email invitations Notification emails to be sent to selected CSU students in dormitories. These will provide a link to the website. We will rely on the City to assist in communicating with the University to facilitate gaining access to CSU dormitory student emails to solicit participation in the study. App Further information on the App can be found in Appendix B, which contains the agreement between NRC and DV Mobile for use of their App platform. Here we present a short summary. We will work with the City and DV Mobile to modify the apps (iOS and Android) already developed for other projects for use in the Fort Collins survey effort. The app will be able to capture the same data elements to be gathered through the hard copy version of the study materials. Additional geolocation data (route) will also be able to be collected, such as the route traveled. If a participant chooses to complete the study by app they be asked to download the app, agree to tracking and then be tracked starting with the acceptance and until the end of the next full 24 hour day. There trips will then be imputed and they will be prompted to fill in details (mode, purpose, number in car, etc.) for each completed trip. On opening the app they will also be asked to enter their unique code (ink-jetted on invitation) and then to answer all the household survey questions. Data will be recorded on completion of each section and of each trip. As such, partial data will be collected. We will not know what day they received their invitation, but will be able to impute their home location from the tracking and their recording of purpose (e.g., go from home to work) and will know the diary day from the tracking of time for the trips. The data will be exported into a csv file and imported into ArcGIS by our GIS partner. Home location will be “blurred” by replacing the address and latitude/longitude with the census block. DV-Mobile has been honing the app to ensure it minimizes impact on battery life while continually collecting trip information for the 24 hour period. The tracking is automatically ended after the appropriate period. We note that it is The City’s preference that app users be able to opt in or out of using the GPS tracking. However, the way the app has been developed, the GPS tracking is an integral part of the app, recording trips in the “background.” Thus, recipients of the invitation to participate in the travel diary will be told that the app will require use of the GPS tracking, and will have the option to use the app or to use the hard copy version of the travel diary. Spanish We will mail out Spanish language versions of the survey, cover letter, instructions and envelope (envelope is addressed to: “Residente Actual/Current Resident”) to a subset of 6 the sample, identified by the City staff to be in areas that are more likely to have Spanish speaking residents. Follow-up post survey During the survey development phase, we will discuss the efficacy of including an option for respondents to provide contact information, if they are willing to participate in follow- up research. For example, joining a panel to receive future surveys or agreeing to be contacted for a focus group. We can discuss the merits of having residents provide contact information through a question on a household survey or possibly signing up separately at a website. If names and contact information are collected on the survey we will separate this information from the survey responses for privacy and provide a list of interested participants to the City. 3. Survey Distribution Sampling Plan We will work with City staff to determine the appropriate boundaries for the study area. Once the study boundaries have been determined, an address listing service would prepare a list of addresses using a database containing all USPS customers in the study area. We will geocode the list to ensure only addresses within the areas of interest are included in the sample. We can further subdivide the study area into regions, if the City is interested in comparing results by geographic subarea. Shape files provided by the City will ensure the addresses are geocoded properly into the desired subareas. We have traditionally had very poor response by students in on-campus housing (dorms) and as such would not recommend taking on the expense of mailing to students, but would recommend requesting a sample of email addresses from University housing to email invitations to complete the survey via app. We will need to work with City staff to try to obtain contact information for University students in group quarters, if they are to be included. Universities are reluctant to share this information, but may work with City staff for the purposes of this study. Systematic sampling of addresses would be used to select study participants. Systematic sampling is a procedure whereby a complete list of all possible items is culled, selecting every Nth one until the appropriate amount of items is selected. We will oversample attached housing units within these lists to account for the tendency of those living within these type of housing units to respond at a lower rate than those in detached single family housing units. The travel diary sample would be split by 5 mailing days (there is no business mailing on Saturdays or Sundays). We expect a one to two-day delivery timeline, and each mail out would be split as such: 2/7th of the sample mailed on Thursdays (arrive Fri/Sat for Sat/Sun diary target) 2/7th of the sample mailed on Fridays (arrive Sat/Mon, for Sun/Mon/Tues diary target) 1/7th of the sample mailed on Mondays (arrive Tue/Wed for Wed/Thurs diary target) 1/7th of the sample mailed on Tuesdays (arrive Wed/Thu for Thurs/Fri diary target) 7 1/7th of the sample mailed on Wednesdays (arrive Thurs/Fri for Fri/Sat diary target) Respondents would be asked to complete the diary on the next day, if possible or the soonest thereafter (within a week) if the next day is not possible. Mailing Plan The mailings to residents would include: 1) Postcard announcements, informing the household members that they have been selected to participate in the trip diary survey. This would explain that they could: a) Go to the dedicated travel diary website to download and use the app immediately b) Or, for part of the sample, that they can wait for the paper version to arrive the following week. 2) A week later, the trip diary survey packet materials, with a cover letter explaining the importance of the study, and instructions to complete the survey on the next day, preferably, or soonest possible day. *As non-travel days are also important to capture we will need to highlight that they can participate by indicating that they did not travel anywhere on the day after receiving the invitation, and just complete the household survey. For the CSU dormitory students, emails can be programmed to mail out to an equal portion of the sample on each of 7 days. 8 Estimated Response The figure below shows the response rates to the 2015 Boulder Travel Diary Study. It should be noted that the app did not yet contain the ability to lay the GPS tracking “breadcrumbs” that the app now has, with the ability to separate the movements into trips, requiring less work on the part of the respondent Figure 1: Response Rates for the 2015 Boulder Travel Diary Study Type of Mailings Number of Recipients Returned with Undeliverable Address Eligible to Participate Returned a Usable Travel Diary Response Rate Hard Copy App Total “Regular” Hard Copy Travel Diary only 3,500 148 3,352 524 524 16% Hard Copy Travel Diary with Option to do Travel Diary App 3,500 168 3,332 446 32 478 14% Invitation to Travel Diary App 3,500 162 3,338 63 111 174 5% CU-Boulder Dormitories— Invitation to Travel Diary App 700 0 700 4 4 1% (Unknown) 0 6 46 1 47 Total 11,200 484 10,722 1,079 148 1,227 11% Based on previous conversations with the City and the resources allotted to this project, the recommended sample size along with our best estimates for response to the Fort Collins survey follows: Figure 2: Sample Size and Estimated Response for Fort Collins Travel Diary Study Residents Students* Total Postcard + Paper follow-up Postcard only Days 7 7 7 7 Number per day 600 300 100 1,000 Total to send 4,200 2,100 700 7,000 Estimated response rate 14.0% 4.0% 1.0% 10% Estimated completed surveys 588 84 7 679 *This assumes that CSU representatives will agree to provide a sample of 700 student email addresses. If CSU representatives are willing to provide a larger sample there would be no additional cost to increase the number of email invitations sent. Printing and Mailing As described above, a sample of addresses from within the study region will be selected to be invited to take part in the trip diary study. This database of addresses will be processed for certification and verification. NRC vendors use CASS™/NCOA software that relies on the USPS National Directory information to verify and standardize the address elements and assign each a complete, nine-digit zip code where possible. In addition, the software will sort and barcode the addresses, allowing significant postage discounts. We propose mailing all materials pre-sorted first class. This ensures a fast delivery time of the materials, but provides an opportunity for a discount on the full first-class postage rates. 9 Our mailhouse will oversee the printing and preparation of the prenotification postcards, survey packets, and reminder postcards. As a part of the quality control process, proofs of the survey materials are reviewed by NRC staff before the final job is printed. We will include a staff member from The City as a “seed” in the mailing list, so they will receive the mailing materials at the same time as the sampled recipients. Coding and Data Entry Once received, the diaries will be prepared for the analysis. Every diary will be examined to ensure that it was filled out correctly with accurate trip descriptions. A common mistake is to count round trips as one trip rather than two. For ease in data entry, the diary data will be transferred to coding sheets. We propose coding three additional variables during this process: 1) the type of trip made (home—work, home-other or non-home based) 2) if the trip was a “link” in the work commute, and 3) if the trip had both origin and destination outside the study region boundaries. Before coding commences, we will discuss the various coding issues, including geocoding, with The City to ensure that we capture all the necessary data. The individual and/or household surveys will also be prepared for data entry. Depending on the final format of these materials, information may be data entered directly from the forms as completed by the respondents (after cleaning by NRC staff), or also transferred to the coding sheets. Data entry is performed using a “key and verify” methodology, in which data are entered twice, and discrepancies between the two files compared and corrected. This eliminates almost all of the potential data entry error. In addition, range and logic checks are performed during the data analysis to look for incorrect responses that are then cleaned and corrected. The phone survey responses also will be data entered. Responses received via the Internet will not require data entry, as an electronic dataset is created of the responses. All the responses will be merged into a single dataset for analysis using the Statistical Package for the Social Sciences (SPSS® ). 4. Survey Results Analysis Data Analysis Generally for these types of studies, NRC creates two types of datasets: a trip-level dataset, where every record in the dataset represented a single trip, and a person-level dataset, where every record in the dataset represented a single person. For quantitative analysis, we rely on SPSS. Whether quantitative or qualitative, we believe that analysis must be replicable and leave a clear path. To this end, we keep every label and command run in SPSS in a syntax file available for audit and re-running, as necessary. We also have trained clients on SPSS analysis and, for small recurring analysis, how to use Microsoft® Excel. One of our early steps in data analysis will be to weight the data to reflect Fort Collin’s population. Weighting is one of two important measures to adjust for non-response bias. In general, residents with certain characteristics (for example: those who are younger or rent 10 their homes) are less likely to participate in surveying, whatever the data collection mode. Weighting allows us to look at the demographic profile of residents who returned the survey compared with the US Census profile of the Fort Collins area. We consider these disparities along with others and accordingly increase or decrease the weight of each respondent to mimic as closely as possible the demographic profile of the area. The weighting variables to be considered will be all those included on the survey, as well as the geographic variables used for sampling. NRC has extensive experience with complex weighting schemes required with stratification. In our reports, we present findings in both tables and graphs. We are careful to provide meaningful interpretation of the data, indicating where statistical differences between geographic subareas, demographic subgroups or to other survey data exist. Report Our reports typically include an executive summary, a report of results, and appendices, including a description of the survey methodology. The executive summary will synthesize the findings and the report body will be colorful, professional and well-organized. Appendices will include a detailed description of the survey methodology so that survey methods can be repeated and trends continued. We will prepare the report in Microsoft® Word. Benchmarking We will provide information at the trip level and individual level, making appropriate comparisons to Boulder and/or Flagstaff data, if desired, throughout, as well as any comparisons to available national level data. Data Visualization In addition to a traditional written report, NRC will provide The City an online portal to explore some of the survey results using the free, public version of Tableau, Tableau Public. Tableau is a leading business intelligence and analytics platform with an intuitive interface; Tableau does not require any programming skills, making the data accessible to anyone with an interest in digging deeper. The online interface will be available publically, and The City is encouraged to publish the link on its website, making the data available to residents. Because the entire system is web-based, there is no need for The City to invest in additional IT hardware or software. The City will need to create a free account in which NRC will develop the portal. An example of a survey results dashboard created in Tableau is available at the link below. This example is for a typical citizen survey, not a travel diary study, and is intended only as an example. Because The City will be the account owner, staff will be able to create and publish additional visualizations as desired. https://public.tableau.com/profile/lkt8027#!/vizhome/SurveyResultsABC/Dashboard1 Additionally, maps may be produced in-house by Fort Collins IT specialists using datasets provided by NRC. 11 GIS data analysis and sharing NRC does not do in-house GIS data analysis, but we have a GIS partner that we will use for one critical task. At the outset they will geocode our sample to ensure all selected addresses are in the boundaries of the city. They will also “blur” these addresses by matching them to their census block, in the data set we send to the City we will share the census block, rather than the latitude/longitude or address for the home, origins and estimations. Data Security Information about NRC’s data security policies can be found in Appendix A. Information about DVmobile’s data security policies can be found in Appendix B. Timeline (2017) Here is an approximate timeline for the 2017 resident travel diary study. We are happy to modify the timeline to best suit the needs of City staff. Task 1: Project Kickoff and Work Plan Finalization Finalize work plan Feb 10 Kick off meeting Feb 17 Task 2: Survey Development Develop household survey, diary card, instructions, postcards etc. Feb 17 to Mar 24 Purchase, geocode and select mailing address sample Mar 27 to Apr 14 Print materials Mar 27 to Apr 14 Program app Mar 27 to Apr 14 Task 3: Survey Distribution Postcard notification mailed to both samples Apr 14 to Apr 20 Paper diary/survey mailed Apr 21 to Apr 26 Data collection closes May 12 Task 4: Survey Results Analysis Clean and code returned surveys May 15 to 31 Data entry Jun 1 to 12 Data analysis and report writing Jun 13 to Jul 12 Draft report Jul 13 Review and comments from Fort Collins Jul 14 to Jul 19 Finalize report and provide final dataset Jul 31 12 Cost Estimate Below is the budget estimate based on scope described above for the resident travel study. Figure 3: Budget Options for Fort Collins 2017 Resident Travel Diary Study NRC Staff Costs Task #1 & #2: Project Kickoff, Work Plan Finalization and Survey & App Development $4,200 Task #3: Sampling, Printing, Mailing and Website Development $4,500 Task #4: Data coding, Analysis, Technical Report, Visualization Tools and Database $15,800 Hard costs App development and use $25,000 Survey distribution and data entry $18,900 Spanish translation and printing (for 500 households*) $2,700 Total Cost $71,100 *To mail Spanish language surveys to additional households would cost $1,200 per 500 households. 2018 Employee Travel Survey This resident survey is envisioned as part of a larger research effort that will include a survey of people who work in the city boundaries, planned for 2018. The proposal for that work is under separate cover, but because the budgets are related we include a draft budget for the 2018 Employee Travel Survey below. Here we assume we will randomly select 800 companies to contact and would encourage the City staff to recruit major employers to the survey, leveraging your relationships. If the City is contacting major employers, it will be important to understand who you are contacting (to not duplicate efforts) and also the nature of the relationship (for example, if you have a relationship because they have a transportation coordinator who actively works with the city to increase bus use.) Figure 4: Budget for Fort Collins 2018 Employee Travel Study NRC Staff Costs Task #1 & #2: Project Kickoff, Work Plan Finalization and Survey & App Development $5,200 Task #3: Sampling, Printing, Mailing $12,500 Task #4: Data coding, Analysis, Technical Report, Visualization Tools and Database $14,000 Hard costs App development and use $25,000 Survey distribution and data entry $10,500 Total Cost $67,200 13 Appendix A: NRC Security Information NRC’s security policies are outlined on the following pages. Introduction In accordance with social science research industry standards, NRC maintains responsible policies and protocols that protect its systems and data using standard physical and technical security controls, including secured building access with monitoring, user authentication, anti-virus and firewall protection, and backup systems with continuity planning. As a research company that does not provide software or cloud services, NRC relies on the controls, procedures and policies of well-established and appropriately vetted software and cloud services vendors. Data collection Online NRC’s primary tool for online data collection is via an application service provider called Qualtrics. Qualtrics uses Transport Layer Security (TLS) encryption (also known as HTTPS) for all transmitted data. Application security is provided through user password login controls and HTTPS encryption. Qualtrics’ security statement is available at http://www.qualtrics.com/security-statement. Surveys administered by NRC are typically taken anonymously; a unique passcode can be assigned to respondents to access the survey if desired (not recommended); no personally identifiable information is retained in the survey. Respondents completing surveys programmed in Qualtrics and administered by NRC are not required to create a user accounts. As respondents progresses through the survey, their responses are stored in cookie (locally, if cookies are enabled) until the surveys is submitted. This permits respondents to finish the survey at a later time should they need to step away from their desk or accidentally close their browser window. Paper As with online survey, our paper surveys are generally anonymous and contain no personally identifiable information. Hardcopy surveys are returned via postage-paid business reply envelopes to NRC, scanned electronically (in PDF format) and entered into an electronic dataset by the data entry firm ARDEM. Once all surveys have been scanned and data entered, the original paper survey are shredded and recycled. 14 When surveys do include personally identifiable information the paper surveys are stored in locked offices during data entry. Once they are entered into an electronic database the paper surveys are retained or shredded as described below. Data transfer The electronic scans of paper surveys are provided to NRC by ARDEM through secure FTP and stored on NRC’s servers in perpetuity and can be removed upon written request. These PDFs are accessed via a password protected portal that can only be accessed by ARDEM and NRC staff. Electron datasets are emailed as attachments to NRC for projects where the datasets do not include any information that is personally identifiable. When the data does include personally identifiable information, datasets are transferred via three possible ways: through a secure FTP site, through an encrypted email, or via a Dropbox set up so that only the NRC project manager and client or data partner have access to the Dropbox folder which is set up for that sole purpose of data transfer. The files are deleted from the FTP and dropbox folders on receipt of the data. Only authenticated domain users have access to data stored on NRC servers. Security can be further modified to allow only a designated subset of the domain user population to gain access. NRC’s data can only be accessed by domain-authenticated users. Currently, users access a single server. External access to the network is via VPN and SSL connections only. VPN access to the network is provided for remote desktop sessions, alleviating the need for data to traverse the Internet. The firewall handling all inbound VPN and SSL connections is updated and monitored regularly. Qualtrics Respondents submit data using HTTPS (TLSv1.2 with AES 128/256 depending on browser) to the front-end web server (usually customername.qualtrics.com). Data are processed by application servers and sent to database servers for storage. Web data are delivered to survey respondents in the form of survey questions, graphics and other content created in the survey design by NRC staff. If desired by the client, NRC can restrict access to surveys by password or location through the Qualtrics platform. NRC NRC connects to Qualtrics using HTTPS protocols and downloads datasets from Quatrics All data is saved to project folder on the NRC server which can only be accessed by domain users. NRC generally keeps a copy of the survey data, analysis syntax, and resultant reports on file in perpetuity. NRC does not use the data for any research, beyond the contracted work, that is not agreed upon in writing by the client. We generally keep the data to be used for 15 comparison when the survey will be repeated in subsequent years. Our clients also occasionally request copies of reports they have misplaced or for further analysis of the data when new questions arise. We have no specific policy on how long we maintain client data, and can outline in the contract a system for data retention (on a per project or client basis as desired). Additionally, we will delete all datasets or other documents within 30 days of a written request from the client (via email or letter). To ensure the data is not maintained on Qualtrics we will delete all responses from the Qualtrics site once the survey is closed and the data has been downloaded to NRC’s server. To ensure the security of email lists or address lists provided by clients (for employee or member surveys, for example), we delete the lists from our servers on completion of the project. Additionally, NRC maintains a database of responses from most of the resident and employee surveys we implement. This dataset is used to compare client results to other jurisdictions, when they ask the same questions. If a client wishes to have benchmark comparisons to other government employee surveys, we add a client’s data to this benchmark database. We do not include any demographic information in our benchmarks (no work unit, gender, age, race, etc. get added), just evaluative items. All data that get added to the benchmarking database are aggregated at the jurisdiction level (not case- level) so there is no risk of personally identifiable information getting added to that database. Retention policy Electronic data NRC retains all electronic data (datasets and PDF scans of paper survey) in perpetuity unless specified by the client. Clients may request deletion of data at any time for any project or time period. Such requests can be completed within 30 days and will include purging from backups. Paper surveys All paper surveys are recycled if all information is anonymous, or shredded if the survey includes information that could identify someone. This is done once the papers have been scanned to PDFs or on completion of the project. For some projects, storage of paper surveys maybe be required. If a client requires NRC to retain paper surveys, they are stored in a secure offsite facility in boxes labelled with the date they may be purged and the required method of destruction (shred or recycle). Backups A separate server handles backups of the NRC server with no accessibility by normal domain users (administrator access only). Backups managed via Veeam Backup and Recovery are deposited on a network attached storage (NAS) device. 16 Offsite backups are encrypted and can only be accessed by NRC administrators. NRC uses Spideroak One which provides us with unlimited versioning, recovery of deleted files, and protection against ransomware. More about this service is available here: https://spideroak.com/features/zero-knowledge. NRC’s backup program allows near instant recovery of servers (servers are replicated and can be activated anytime). Servers are exported once per month for offline testing. Breach policy Any suspected breach in security can be reported to any member of NRC staff. If a breach is detected and verified, the client will be notified as soon as possible and no later than 7 days. Clients will be informed of all actions taken as well as plans to mitigate future risk. Security testing All servers at NRC are Microsoft based. NRC scans all on-premises servers with the Baseline Security Analyzer (https://technet.microsoft.com/en-us/security/cc184924.aspx#current- version) on a scheduled monthly basis. This allows us to easily scan for missing security updates as well as common security misconfigurations. All of NRC’s Microsoft based systems have virus/malware protection. NRC currently uses a combination of ESET and Malwarebytes products. NRC’s firewall configuration and all logs are stored at Cisco/Meraki and are accessible by secure login only. All login attempts (success and failed) are logged. VPN connections are also logged. 17 Appendix B: DV Mobile Scope of Work and Security Information DVmobile’s agreement with NRC on the scope of work and their data security information are both included in this appendix. © 2017 DVmobile, Inc. All Rights Reserved. 1 of 11 DVmobile Smart Survey Security Policy 2017-02-16 Overview Unsecured and vulnerable resources continue to be a major entry point for malicious threats. Creating and implementing consistent policies, management and configuration are not only a best practice, but a great defense. Purpose The purpose of this policy is to establish standards for the base configuration of resources owned and/or controlled by Smart Survey (SS). SS is a platform, service, and application controlled and maintained by DVmobile Inc. (DV). Effective implementation of this policy will minimize unauthorized access to SS proprietary information and technology. Scope All employees, contractors, consultants, temporary and other workers at DV and SS must adhere to this policy. This policy applies to cloud (API, DB, Web) and application (Android, iOS) resources owned, operated, or leased by SS or registered under an SS-owned internal network domain. Cloud Overview Cloud computing provides a model for enabling on-demand network access to a shared pool of computing resources (for example: networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or cloud provider interaction. Cloud computing can be used to provide clients with access to the latest technologies without a costly investment in hardware and software. Due to the economies of scale associated with the delivery of cloud services, Cloud Service Providers (CSP) can often provide access to a greater range of technologies and security resources than the client might otherwise have access to. Client organizations without a depth of technically-skilled personnel may also wish to leverage the skills and knowledge provided by CSP personnel to securely manage their cloud operations. Cloud computing therefore holds significant potential to help organizations reduce IT complexity and costs, while increasing agility. Cloud computing is also seen as a means to © 2017 DVmobile, Inc. All Rights Reserved. 2 of 11 accommodate business requirements for high availability and redundancy, including business continuity and disaster recovery. Cloud Characteristics: On-demand self-service: The consumer can provision multiple computing capabilities as needed. The provisioning can be entirely online. Broad network access: The services are available over the network and access is supported through multiple platforms (e.g., mobile phones, tablets, laptops, and workstations). Resource pooling: The cloud service provider computing resources are pooled to serve multiple consumers at the same time, the consumers can be from anywhere in the world. Examples of resources include storage, processing, memory, and network bandwidth. Scalability: Cloud resources can be easily provisioned and released. To the consumer, the resources available for provisioning may appear to be unlimited and can be appropriated in any quantity at any time. Measured service: Cloud systems automatically control and optimize resource use. Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer. Cloud Service Models Software as a Service (SaaS): Capability for clients to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser, or a program interface. Platform as a Service (PaaS): Capability for clients to deploy their applications (created or acquired) onto the cloud infrastructure, using programming languages, libraries, services, and tools supported by the provider. Infrastructure as a Service (IaaS): Capability for clients to utilize the provider’s processing, storage, networks, and other fundamental computing resources to deploy and run operating systems, applications and other software on a cloud infrastructure. Cloud Deployment Models: Private cloud: The cloud infrastructure is operated solely for a single organization (client). It may be managed by the organization itself or a third-party provider, and may © 2017 DVmobile, Inc. All Rights Reserved. 3 of 11 be on premise or off-premise. However, it must be solely dedicated for the use of one entity. Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared requirements or concerns (for example, business model, security requirements, policy, or compliance considerations). It may be managed by the organizations or a third party, and may be on premise or off-premise. Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services. Public cloud infrastructure exists on the premises of the cloud provider. Hybrid cloud: The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by technology to enable portability. Hybrid clouds are often used for redundancy or load- balancing purposes—for example, applications within a private cloud could be configured to utilize computing resources from a public cloud as needed during peak capacity times (sometimes called “cloud-bursting”). With respect to understanding roles and responsibilities, this policy is largely focused on public cloud providing Software as a Service (SaaS) scenarios. However, many of the concepts remain applicable regardless of the deployment model. © 2017 DVmobile, Inc. All Rights Reserved. 4 of 11 Responsibilities for Different Service Models In all deployment models, and particularly in public cloud environments, it is important for all parties to understand the specific elements of the service model used and its associated risks. Any cloud deployment model that is not truly private (on premise) is by nature a shared responsibility model, where a portion of responsibility for the cloud service falls under the realm of the CSP, and a portion of responsibility also falls to each client. The level of responsibility that falls to the CSP or the client is determined by the cloud service model being utilized—that is, IaaS, PaaS, or SaaS. Clear delineation of responsibilities should be established as a prerequisite to any cloud service implementation to provide a baseline for the cloud operation. Layer Description Application Program Interface (API) or Graphical User Interface (GUI) The interface used by the client or their customers to interact with the application. The current most common API is RESTful HTTP or HTTPS. The current most common GUI is an HTTP or HTTPS based Web site. Application The actual application being used by one or more clients or their customers. Solution stack This is the programming language used to build and deploy applications. Some examples include Nodejs, .NET, Python, Ruby, Perl, etc. Operating systems (OS) In a virtualized environment, the OS runs within each VM. Alternatively, if there is no underlying hypervisor present, the operating system runs directly on the storage hardware. Virtual machine (VM) The virtual container assigned for client use. Virtual network infrastructure For communications within and between virtual machines Hypervisor When virtualization is used to manage resources, the hypervisor is responsible for allocating resources to each virtual machine. It may also be leveraged for implementing security. Processing and memory The physical hardware that supplies CPU time and physical memory. Data Storage The physical hardware used for file storage. Network This can be a physical or virtual network. It is responsible for carrying communications between systems and possibly the Internet. Physical facility The actual physical building where the cloud systems are located © 2017 DVmobile, Inc. All Rights Reserved. 5 of 11 Figure 1: Example of how control may be assigned between CSP and clients across different service models. © 2017 DVmobile, Inc. All Rights Reserved. 6 of 11 Policy General Requirements All resources deployed at SS must be owned by an operational group that is responsible for system administration. Approved configuration guides must be established and maintained by each operational group, based on business needs and approved by DV. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by DV. The following items must be met: Servers must be registered within the cloud service provider account established by DV for SS. At a minimum, the following information is required to positively identify the point of contact: o Administrator contact information o Resource identification information (IPs, CNAMEs, APP Names) o Main functional description (what the item is and how it is installed and used) o Private source control under the DV company and SS project Information should be kept up-to-date upon changes to resource allocations. Configuration changes for production servers must follow the appropriate change management procedures For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic at the discretion of DV. Configuration Requirements Operating System configuration should be in accordance with approved SS guidelines. Services and applications that will not be used must be disabled where practical. Access to services should be logged and/or protected through access-control methods such as a web application firewall, where possible. The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements. © 2017 DVmobile, Inc. All Rights Reserved. 7 of 11 Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient. Always use standard security principles of least required access to perform a function. Do not use “root” account access when a non-privileged account will do. If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec/VPN). Servers will always be located in an access-controlled environment. Monitoring All security-related events on critical or sensitive systems should be logged and audit trails saved to secure locations accessible to DV within the SS domain. Security-related events will be reported to DV, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to: Port-scan attacks Evidence of unauthorized access to privileged accounts Anomalous occurrences that are not related to specific applications on the host. © 2017 DVmobile, Inc. All Rights Reserved. 8 of 11 Policy Compliance Compliance Measurement The DV team will verify compliance to this policy regarding the SS domain through various methods, including but not limited to, periodic walk-throughs, monitoring, reports, internal and external audits, and direct feedback. Exceptions Any exception to the policy must be approved by the DV and SS teams in advance. Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. © 2017 DVmobile, Inc. All Rights Reserved. 9 of 11 Data & Access Requirements: Requirement: Install and maintain a firewall configuration to protect data. The network is wholly owned and managed by the CSP, and consequently, all firewall functions are typically managed by the CSP. However, using the tools provided by the CSP, SS defines, approves and reviews the services, protocols, and ports permitted into our environments. Requirement: Develop and maintain secure systems and applications. OS patching and updating occurs upon deployments. Application and API security is tested by third party security professionals to ensure compliance and best practices. Any vulnerability discovered is patched in a timely (if not immediate) manner. Requirement: Assign a unique ID to each person with resource access. Any and all users with access to cloud resources have a unique ID and access keys associated with their identity. Cloud console access is also protected by MFA for additional protection. © 2017 DVmobile, Inc. All Rights Reserved. 10 of 11 Breach Policy Any suspected breach in security can be reported to any member of DVmobile management staff. If a breach is detected and verified, the client will be notified as soon as possible and no later than 7 days. Clients will be informed of all actions taken as well as plans to mitigate future risk. Security Assessment The platform and services have been and will continue to be in an ongoing state of development. In an effort to promote a production ready platform, service, and set of applications, DVmobile will periodically complete an independently contracted security audit. Please see the most recent “DVmobile Smart Survey Platform Security Audit” document for the current identified risks, and the appropriate recommended resolutions that will be implemented where applicable. © 2017 DVmobile, Inc. All Rights Reserved. 11 of 11 Revision History Version Date of Change Responsible Party Summary of Change 1.0 02/06/2017 DVmobile Inc. Initial draft of policy 1.1 02/16/2017 DVmobile Inc. Add Breach Policy and separate recent security audit recommendations © 2017 DVmobile Inc. All Rights Reserved. 1 of 3 DVmobile Smart Survey Security Audit 2017-02-06 Conducted by Corenttoco LLC Security Audit DVmobile’s Smart Survey platform and services have been and will continue to be in an ongoing state of development. In an effort to promote a production ready platform, service, and set of applications, DVmobile will periodically complete an independently contracted security audit. The below sections identify the current risks and provide recommendations based on the recently completed security audit. DVmobile will implement the appropriate recommended resolutions where applicable. Identified Risk Areas and Recommendations Data Secure Storage Local: If applicable, local key/value data could be encrypted where the API would then decrypt the information and save it as plain text in the database. RDS (MySQL): RDS should only be accessible to the API server. Any additional direct access channels would be whitelisted to specific IP addresses only. Data could be encrypted at rest in RDS if applicable. SSL and HTTP: Load balancers should be put in place with SSL certificates. All traffic should be encrypted and pass through this single public entry point using HTTPS. Data Retention The retention policy should be simple. When an application lifecycle is complete, the API, Portal, and DB are all sanitized of any data. This process would be complete after the customer has stated that the study is over, they have downloaded all data they need, and they then request termination of the data and resources. Data/Resource Access EC2: Security group policy should be added to only allow access to on ports 80 and 443 from the Internet. Additionally, only developers needing direct SSH access should be whitelisted; closing open © 2017 DVmobile Inc. All Rights Reserved. 2 of 3 access to the endpoint and port 22. ELB should be placed in front of all incoming traffic. Then a domain name should be assigned to the instance and a SSL cert applied so HTTPS can be accepted to encrypt traffic to and from. MFA could also be applied to the instance(s) as an additional layer of SSH protection. Admins and developers accessing the resources would need a 6 digit code anytime they connected along with the key-pair and potential key-pair password. Docker: Many considerations can be made here for security, but the primary burden rests on the resource that has the Docker daemon and who can access it. If that access is secure and trusted, then Docker is generally secure on its own. API: Access keys should be used at a minimum to access the API. Basic Auth using a predefined header value would be the simplest implementation. It would be imbedded into the app and reused. Basic Auth could be created specifically for each app. OAuth2 could also be implemented if applicable and deemed necessary. HTTP Public Key Pinning (HPKP) could be employed if applicable. This is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates; basically pairing a web server/application to its API. RDS: Security group policy should be added to only allow access to RDS from the API's IP address. Additionally, only developers needing direct access should be whitelisted; closing open access to the endpoint and port 3306. Another good policy is to obfuscate the port to a non-standard high number (e.g. 8975, 8889, etc). Portal Access The admin portal should be given its own instance/container with its own domain and SSL cert. It should be pointed toward its APIs and data sources only. A proper user authentication system could be implemented via database/API where usernames and passwords are used to access information and communicated through an API. Also, roles could be applied if applicable; when decision makers do not what everyone to see everything. This would also isolate apps, data, and admin access into a defined namespace; a specific client would only be looking at their relevant information. As far as downloadable results go, perhaps the only security improvement there would be to package the file contents into a zip file on download and apply a mandatory password to encrypt them at rest on the device that downloads them. © 2017 DVmobile Inc. All Rights Reserved. 3 of 3 Revision History Version Date of Change Responsible Party Summary of Change 1.0 02/06/2017 DVmobile Inc. Initial security audit document