Introduction

With the new network infrastructure being deployed in the NPCF, the Security Team has taken the opportunity to start fresh and divide systems into different security zones in an effort to better monitor and protect the Center's high-value assets. In the past, the Network Intrusion Detection System (NIDS) was limited to monitoring traffic only at the NCSA border routers (and even here with some holes). It was very difficult to detect suspicious traffic between internal systems and other Teragrid systems, in particular malware infections or multi-stage incidents. With this new model, we will be able to monitor traffic between security zones providing for previously unavailable visibility into the internal networks. Traffic between zones will not only be monitored by the NIDS, but full network flows will be generated. As a result, we will be better able to contain a security incident, profile the expected traffic within our own networks and more quickly identify and respond to security incidents. Some of these zones are physically separate in different buildings, but others are separated by network topology and virtual networks.  The key distinguishing feature of a zone is that traffic between zones will be monitored, and hence all hosts within a zone must be trusted at the same level. The purpose of this document is to define the different security zones and outline requirements for vetting systems into each zone. 

It is important to note, however, that placement into a particular zone is not necessarily driven by the role or function of a particular system. That is, these zones were not designed to represent "tiers" of systems, either by value or function, nor are they intended as a "map" of recommended system placement.  While the security zones may serve as a guide for those tasked with assigning physical space for NCSA systems, the allocation of this space is not a security role and the Security Team does not dictate this placement.   Security's primary role with systems that have been recently assigned, or reassigned, to a given network zone is simply to ensure that the system meets the security requirements for that zone.

NCSA logically divides its network into several different trust zones. Traffic between these zones is monitored by a Network Intrusion Detection System (NIDS), but traffic within a single zone may not be visible to the NIDS. Therefore, systems within a single zone must be trusted and hence hardened to the same level.

These zones can vary significantly in how they are trusted: from networks trusted little more than the general Internet to networks that require stringent vetting and auditing. Most networks are public, but some are very isolated and not even routed. The common requirements across all zones are only that systems follow University security policies and that the Security and Networking teams can quickly identify the location and responsible party for all hosts on our networksAdditionally, it is critical to understand that while in many cases particular physical locations will map to particular security zones, physical locations and security zones are independent concepts.  As such, system owners/managers should likely use physical data center requirements to drive their requests for space for those systems, and not what security zone or zones are available in that space.  If a system cannot meet the requirements for the security zone generally available in the physical space to which it has been assigned, it will either have to be reassigned or the networking infrastructure modified to place it within a different security zone not previously available in its physical location.  Conversely, if a system's security requirements are not met by the security zone generally available in the physical space to which it has been assigned, the Security Team will work with the system owner/manager to ensure a proper level of security services are provided or that the system is reassigned to a more appropriate zone.

Auditing

The Security Team will be responsible for verifying that regular audits are performed for compliance with this policy, however the actual auditing may be performed by full-time system administrators, particularly for major production resources. Furthermore, approval from the Security Team is required prior to installation of any systems in Zone 1 (described below). Where possible, this verification and auditing will be done in an automated manner. For example, some policy compliance can be checked by the NIDS, and other components can be checked by security tools on the systems being protected, e.g., file integrity checkers and change control software.

...