The repository must show how it has dealt with its security requirements. If some types of material are more likely to be attacked, the repository will need to provide more protection, for instance.
Evidence: ISO 17799 certification; system control list; risk, threat, or control analyses; addition of controls based on ongoing risk detection and assessment.
Broadly speaking ICPSR has only two types of objects to manage: (1) those that have been reviewed and vetted, and are available for wide dissemination, and (2) everything else.
The first category of objects require relatively modest security controls. Because this content is freely available via our web site (albeit some only to members) there are relatively few concerns about its security. It's important that we know that the objects haven't been corrupted (unintentionally or otherwise), and it's also important to ensure that member-only content is accessible only to members.
The second category has grown considerably in the past few years, particularly as ICPSR receives more confidential data through government agencies, partners, and unsolicited via its deposit system.
To meet the rising challenge of confidential data ICPSR will be changing the architecture of its network, and will also be deploying a Secure Data processing Environment. (More on the SDE in a subsequent post.) Both of these steps supplement existing security controls that we discussed in the post The ICPSR Web Site and Security from September 2009.
Our current network architecture is very flat. All network-connected equipment is part of a single virtual local area network (VLAN), and items are protected at the border between ICPSR and the outside world via Cisco access-list policies. Individual systems may also be protected via local firewalls, such as iptables on a Linux server. And equipment located in Amazon's cloud is protected via similar mechanisms using AWS EC2 Security Groups.
Our new network architecture will look very different, and will consist of four separate VLANs. Here is the overall picture:
This new architecture makes use of a new security service provided by the University of Michigan's central IT organization, ITS. The service is called Virtual Firewall, and is based on the Checkpoint firewall product.
This architecture divides ICPSR's network-connected resources into four VLANs:
- Private (local to ICPSR)
- Private (local to ITS)
The Semi-private VLAN hosts the bulk of ICPSR's current systems: desktop computers, printers, storage systems, and so on. This equipment needs robust outbound access to the Internet, but inbound access should be restricted closely. For example, there is no good reason why ICPSR's printers need to be accessible from any arbitrary host on the Internet.
The Private VLANs will host our most secure systems. This will include the Secure Data processing Environment (SDE) we're building, and also a future Virtual Data Enclave (VDE). Access between these VLANs and the Internet will be highly, highly restricted, and more general access will be permitted only from our Semi-private VLAN.
We've just started the process of building out this future network architecture with ITS, and expect that we'll finish the deployment and transition before the end of the summer.