TRAC: C3.2: Security controls

C3.2 Repository has implemented controls to adequately address each of the defined security needs.

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:

1. Public
2. Semi-private
3. Private (local to ICPSR)
4. Private (local to ITS)

The Public VLAN hosts ICPSR's public-facing resources, such as the web server. This is a relatively small VLAN, and one can imagine resources moving from this VLAN into Amazon's cloud over time. (In fact, a multi-region delivery platform stretched across Amazon's international cloud, perhaps using AWS CloudFront to deliver especially high-volume objects is very compelling.)

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.