The ICPSR Virtual Data Enclave (VDE) is a secure, virtual environment in which a researcher can analyze sensitive data, create research products, and then take possession of those products and analysis. And while he VDE is not a substitute for a physical enclave and the types of security protocols it facilitates, the VDE is very much a potential substitute for the traditional practice of distributing confidential data via removable media, such as CD-ROMs.
The VDE uses much of the same technology that ICPSR uses internally for its Secure Data management Environment (SDE) which we have described a few times. In brief, we use a virtual desktop environment that is operated by the University of Michigan's central IT shop and connect it to what we call our Private Network Attached Storage (NAS) appliance. Both the virtual desktop and NAS are behind a firewall, and we use the firewall and Windows group policies to restrict what actions one pay perform. Download? Nope. Cut-and-paste between the virtual desktop and the real desktop? Uh uh. Capture screenshots by taking a picture of your monitor? Well, ......
The virtual environment keeps sensitive datasets under lock and key at ICPSR, but makes it available to researchers. The environment contains the usual array of applications used in the social sciences (but no email!), exactly the same sort of stuff we might set up for a visiting scholar or OR.
The researcher accesses the environment through a small, easy-to-download and -install client based on VMware View Client. Authentication takes place using standard University of Michigan credentials which we (ICPSR) and others at UMich can issue to "friends." Access between the real desktop and the virtual desktop is encrypted, and we are in the process of adding IPSEC encryption between the virtual desktop and the NAS. (This latter traffic passes over UMich's data backbone, and access to those routers is limited to UMich central IT network engineers.)
The virtual machine is completely ephemeral and can be wiped after each use. Any intermediate research or results are stored on the ICPSR NAS. Our NAS is backed up weekly, and tapes are cycled off-site quarterly. Once the research has been completed ICPSR retains a "just in case you need it" snapshot for up to three years.
Showing posts with label restricted data. Show all posts
Showing posts with label restricted data. Show all posts
Monday, September 17, 2012
Wednesday, October 19, 2011
The RCS becomes the DARS
ICPSR first launched its Restricted Contract System (RCS) more than two years ago. Since that initial launch we've learned a lot: who actually uses the system to apply for access to data; how they experience the system; how ICPSR contract administrators use the system; and, how to build in workflow to make it a smoother experience for all parties.
We relaunched the RCS last week, but with a new name: the ICPSR Data Access Request System (DARS). I suspect a lot of us will continue to call it the RCS, but it is the same system, but with a very different look and flow.
The DARS home page is the same as the old RCS system, and the most typical access method for initial use is from the home page of a study. If a version of a study is available through a data-use agreement, then a link appears on its home page, and clicking that link navigates the visitor to the DARS.
Once there the visitor can initiate the data-use agreement process, going through the same general steps as before. However, it is now much clearer when the agreement process has been completed, and the ball is now in ICPSR's court for review. We've also worked hard to distinguish between essential elements of the agreement (e.g., if it changes, then the agreement must be reviewed and signed again), and which are more tangential (e.g., if it changes, ICPSR will be notified, but the agreement need not be signed off on again).
One element of the redesign is an explicit acknowledgement that this system may be used for any data-use request, and is not limited to only restricted-use requests. We based this change on feedback from an internal team of reviewers who thought that the system should be able to work for any type of content that requires an agreement, even if it isn't particularly sensitive or confidential.
This design also recognizes that the applicant using the system may not necessarily be the PI who is requesting access to the data. (In fact, we suspect that most applicants are not the PI.) We therefore built views and rules to make it easier for, say, a population center data coordinator who may be working on several request for several PIs to get a better view of status across all requests.
We relaunched the RCS last week, but with a new name: the ICPSR Data Access Request System (DARS). I suspect a lot of us will continue to call it the RCS, but it is the same system, but with a very different look and flow.
The DARS home page is the same as the old RCS system, and the most typical access method for initial use is from the home page of a study. If a version of a study is available through a data-use agreement, then a link appears on its home page, and clicking that link navigates the visitor to the DARS.
Once there the visitor can initiate the data-use agreement process, going through the same general steps as before. However, it is now much clearer when the agreement process has been completed, and the ball is now in ICPSR's court for review. We've also worked hard to distinguish between essential elements of the agreement (e.g., if it changes, then the agreement must be reviewed and signed again), and which are more tangential (e.g., if it changes, ICPSR will be notified, but the agreement need not be signed off on again).
One element of the redesign is an explicit acknowledgement that this system may be used for any data-use request, and is not limited to only restricted-use requests. We based this change on feedback from an internal team of reviewers who thought that the system should be able to work for any type of content that requires an agreement, even if it isn't particularly sensitive or confidential.
This design also recognizes that the applicant using the system may not necessarily be the PI who is requesting access to the data. (In fact, we suspect that most applicants are not the PI.) We therefore built views and rules to make it easier for, say, a population center data coordinator who may be working on several request for several PIs to get a better view of status across all requests.
Monday, October 3, 2011
All Things Confidential
Tech@ICPSR will be at the University of Michigan's Michigan Union this Thursday to participate in the 2011 biennial meeting of our Organization Representatives from across the world of higher-education. We'll be batting lead-off for the All Things Confidential session at 9am EDT.
If you cannot attend the meeting in person, you can still attend virtually.
If you cannot attend the meeting in person, you can still attend virtually.
Wednesday, September 1, 2010
ICPSR launches the Restricted Contract System portal
The ICPSR Restricted Contract System (RCS) portal is officially open for business. We launched the new portal late in August, making the National Survey of Parents and Youth available through the system.
The portal is the researcher-facing piece of the system, and we use it to guide the researcher through the contract process of applying for access to restricted-use data. The system is highly configurable which allows us to collect information through traditional web forms and document uploads (e.g., proof of IRB approval, where required).
One key innovation with the new system is an attempt to make the IT security portion of the process as painless as possible. Historically ICPSR and other data providers have required researchers to submit detailed IT security plans for protecting the data, a process which often required a great deal of labor, but which did not actually make any actual measurements about security. In the RCS we've replaces the IT security plan with three new components.
One, we pull questions from our "Question Bank" that are tailored to the specific IT environment of the researcher (e.g., Windows machine connected to the Internet) and to a specific person: the researcher or the researcher's IT person. For example, one question might ask the researcher to confirm that s/he will lock the office door when the data are unattended. And another question might ask the IT person to confirm that the data will be kept in a place where they will not be backed up to tape for disaster recovery purposes.
Two, we ask the researcher to install and run an audit utility which inspects the computer for common security problems. The software does NOT require administrative access for installation or to run, and we limit its checking to a small number of essential areas, such as checking to see if a screen saver with password has been enabled.
Three, we also partner with the University of Michigan to run a remote vulnerability scan of the computer(s), looking for common problems which can be exploited remotely by attackers.
If the questions are answered appropriately, and if the audit and scan do not reveal any problems, then the researcher has completed the IT security portion of the process, and no written IT security plan is required. (We do, however, give researchers the option of writing an IT security plan if they would rather not submit to the scan and audit.)
The goal of the new portal is to lower the barrier for accessing restricted-use data, but still collecting enough information to ensure that the data will be safe.
The complete RCS suite of software also includes internal utilities to automate the contract administration process, such as generating reminder emails about contract renewal.
The portal is the researcher-facing piece of the system, and we use it to guide the researcher through the contract process of applying for access to restricted-use data. The system is highly configurable which allows us to collect information through traditional web forms and document uploads (e.g., proof of IRB approval, where required).
One key innovation with the new system is an attempt to make the IT security portion of the process as painless as possible. Historically ICPSR and other data providers have required researchers to submit detailed IT security plans for protecting the data, a process which often required a great deal of labor, but which did not actually make any actual measurements about security. In the RCS we've replaces the IT security plan with three new components.
One, we pull questions from our "Question Bank" that are tailored to the specific IT environment of the researcher (e.g., Windows machine connected to the Internet) and to a specific person: the researcher or the researcher's IT person. For example, one question might ask the researcher to confirm that s/he will lock the office door when the data are unattended. And another question might ask the IT person to confirm that the data will be kept in a place where they will not be backed up to tape for disaster recovery purposes.
Two, we ask the researcher to install and run an audit utility which inspects the computer for common security problems. The software does NOT require administrative access for installation or to run, and we limit its checking to a small number of essential areas, such as checking to see if a screen saver with password has been enabled.
Three, we also partner with the University of Michigan to run a remote vulnerability scan of the computer(s), looking for common problems which can be exploited remotely by attackers.
If the questions are answered appropriately, and if the audit and scan do not reveal any problems, then the researcher has completed the IT security portion of the process, and no written IT security plan is required. (We do, however, give researchers the option of writing an IT security plan if they would rather not submit to the scan and audit.)
The goal of the new portal is to lower the barrier for accessing restricted-use data, but still collecting enough information to ensure that the data will be safe.
The complete RCS suite of software also includes internal utilities to automate the contract administration process, such as generating reminder emails about contract renewal.
Monday, November 2, 2009
Confidential Data and the Cloud
I have a new post on our NIH Challenge Grant project, but it's in our project blog rather than here.
So for you loyal readers who follow this blog, but not our Challenge Grant blog, here's the link: http://enclavecloud.blogspot.com/2009/11/high-level-system-architecture.html
I'll also be giving a talk on this at the Fall 2009 Coalition for Networked Information (CNI) Membership Meeting. If you're there, please drop by to say hello!
So for you loyal readers who follow this blog, but not our Challenge Grant blog, here's the link: http://enclavecloud.blogspot.com/2009/11/high-level-system-architecture.html
I'll also be giving a talk on this at the Fall 2009 Coalition for Networked Information (CNI) Membership Meeting. If you're there, please drop by to say hello!
Tuesday, July 14, 2009
Restricted Contract System
Later this year ICPSR will be releasing a major new service: the RCS or Restricted Contract System. This is a suite of several software systems that enable researchers to download restricted-access data. We'll use this for content that is too sensitive for the conventional download system on the web site, but not so sensitive that it needs to reside in a real (or virtual) data enclave. It will replace the current mechanism whereby researchers download user agreements, fill them out in ink, and fax or mail them back to ICPSR, receiving a CD in the mail a week or so later. Instead researchers will complete the contract online, and then be able to download the data to their workstations via a secure download mechanism, using two-factor authentication (2FA) when required.
For very sensitive data where a written security plan would ordinarily be required, our system will instead make use of three components: (1) a network scan of systems that will be used to store or analyze the data; (2) a self-conducted audit of the same systems using freely available software tools; and (3) an on-line survey asking basic, non-technical questions. Our intent is to streamline the system significantly, but at the same time raise the bar on the level of system security actually achieved.
We expect to wrap primary development at the end of the summer, and then test the system with specific projects in the fall. We'll then open it up for a bit more testing late in the year, and then perhaps launch the product officially in early 2010.
For very sensitive data where a written security plan would ordinarily be required, our system will instead make use of three components: (1) a network scan of systems that will be used to store or analyze the data; (2) a self-conducted audit of the same systems using freely available software tools; and (3) an on-line survey asking basic, non-technical questions. Our intent is to streamline the system significantly, but at the same time raise the bar on the level of system security actually achieved.
We expect to wrap primary development at the end of the summer, and then test the system with specific projects in the fall. We'll then open it up for a bit more testing late in the year, and then perhaps launch the product officially in early 2010.
Subscribe to:
Posts (Atom)