The Security Office will review this policy annually with the leadership of ADS and ITS to see if changes are needed. It will also be updated as needed for new network environments that are needed.
NCSA Network Zones
The following zones and their accompanied policies are described logically as specific subnets are subject to change.
High Performance Datacenter (HPDC) Zone
This zone hosts all of the hardware that still resides within ACB. This is a temporary zone, needed only until NCSA's external connectivity is switched over to the NPCF and all NCSA systems are moved out of ACB. The general deadline for this is June 30, 2011.is the zone for production systems the data center and consists of most machines in 2020 NPCF. It includes both public and private networks.
Types of Systems:
The variety of systems in ACB is extensive, but there should be no new systems added to this zone, the exception being replacement of failed hardware on systems still running production services out of ACB. It is requested that teams notify the Security Team when/if production systems are moved from ACB to another building.
- Following best practices (laid out by the NCSA Security Policy) for system security is still necessary as systems that are scheduled to be retired are often overlooked.
- Systems must be updated with all relevant security patches in a timely manner.
- Systems providing production services in ACB must forward their syslogs to the central syslog server, unless impossible, in which case an exception must be requested.
- Retired systems are to be powered off and disconnected from the network.
The NCSA network border is currently at ACB, though ACB will become a stub before July 1, 2011. Traffic into Zone 0 from the outside world is monitored by security taps within ACB with the exception of the 3 dedicated TeraGrid links. Additionally, during the transition, the 10G links between ACB and NPCF will be monitored as an entry point into Zone 1.
Zone 1: High Performance Datacenter
This is the primary zone within the NPCF data center with direct access to significant external bandwidth and no external firewall. The High Perf DC Zone is not appropriate for building new systems and/or configurations until those systems have been fully hardened because most network filtering will be impractical due to sensitivities regarding performance expectations.
Types of Systems:
It is expected that systems within this zone will generally be large HPC systems and their associated data storage hardware, which either require data transfer rates greater than 10 Gb/s or have a sizable physical footprint. While not all systems selected for this zone may match this description, to beplaced in this zone, systems must be approved by the NPCF RAF Space Committee and vetted by the Security Team.
Auditing to ensure systems adhere to these policies will be performed regularly. Given the importance of ensuring each system in this zone is pre-approved to be there, the Security Team will maintain an approved list of systems for this zone and they will be periodically audited.
The Security Team will provide assistance hardening systems; examples include syslog/syslog_ng configurations, Samhain installation, and the building of an instrumented ssh daemon that will be required on most systems. Systems may be removed from the zone if they develop a history of security related issues. Project/administrator history and criticality will be considered with the possibility of a probationary period before systems are reconnected to this zone.
Systems will not be given external network access from this zone until vetted by the Security Team. (1. Group asks RAF committee to house a system in NPCF. 2) They ask neteng for connections and IPs. 3) Neteng gives them access to the test/install zone and refers them to us.) A vetting period of up to one week must be planned for. Systems in this zone and administrators of those systems must:
- restrict network access for unvetted machines;
- Goal: The purpose of this is to prevent new systems from coming up on the network without having been vetted by the Security Team first. MAC registration could actually interfere with failover/redundancy in some cases and may not be ideal for this zone.
- adhere to any service specific requirements spelled-out in the project-specific security plans, such as those developed for Blue Waters;
- follow industry best practices, such as: timely installation of security updates, running minimal services, and removing unnecessary setuid/gid binaries;
- provide a list of expected services to be monitored by the Security Team;
- Goal: This will allow us to define IDS alerts when traffic is seen on an unexpected port or a new service shows up in a network scan.
- provide and maintain an up-to-date list of authorized administrators and/or users to the Security Team;
- Goal: We audit .k5login/sudoers access on a regular basis and this provides a starting point.
- be administrated by full-time employees who have received security training;
- forward logs to the central syslog server;
- Goal: This serves dual purposes. It provides a central location to monitor syslogs as part of our IDS infrastructure, but also serves as a secure backup of syslog data than an attacker cannot modify.
- be configured with the Samhain Host Intrusion Detection System (HIDS) by the Security Team if the machine is publicly addressable;
- Goal: Provides centralized file integrity checking.
- utilize the administrative bastion host with two-factor authentication for access to management interfaces and/or system consoles;
- Goal: Prevent compromised administrator credentials and isolate management services from the public network.
- use strong, non-default passwords or keys for authentication for administrative or service accounts; and
- give access to the system(s) to each security operations user's account in order to quickly investigate security alerts.
- Goal: We investigate alerts 24/7/365. It's inefficient and impractical to wait for system administrators to get back to us given the time sensitivity of most incidents.
All external links into this zone will be monitored, including internal sub-zones and those links to/from other NCSA buildings. Due to financial and physical limitations, traffic completely within this zone cannot be monitoredSystems requiring high availability, physical security and high performance networking are hosted here. This includes not just HPCs, but core storage, security, networking equipment, and more. These systems are built in a firewalled subzone until fully vetted by the security team, which is responsible for regular auditing of systems against the security requirements below.
- Until vetted, these machines are firewalled to only accept connections from NCSA hosts or to port 22 (SSH).
- Have a vulnerability and patch management plan in place.
- Disable any unnecessary service and accounts, and enforce with host-based firewalls where possible.
- Inform the security team if the list of services changes.
- Utilize the security team's host-based IDS if possible.
- Forward system logs to the security team's collector.
- Utilize non-local accounts for remote access unless otherwise approved.
- Require two-factor bastions, jump-hosts or VPNs for access to administrative interfaces.
- Disable IP-forwarding and do not bridge networks without approval from Security & Networking.
- Maintain and enforce an up-to-date list of authorized administrators, and keep records up-to-date so that the Security team can quickly determine responsible parties for the system. At least one responsible party must be a full-time employee working at the NCSA.
- Provide the security team with accounts on the system or a way to quickly get access 24/7 for emergencies.
All external links into and out of this zone are monitored by the network IDS. New hosts that appear on this network but have not been vetted may be automatically or manually blocked at the border gateway until investigated and vetted. Network traffic entirely within this zone is unmonitored by the IDS, but netflows are collected.
Zone 1b: Installation
This defines a type of system-specific zone for systems that are physically located on the floor in 2020 NPCF, but which have not yet met all of the security requirements to be part of the High Performance DC Zone. In most cases, router ACLs would be sufficient for protecting these systems while they are brought online and secured before being moved into Zone 1. These connections will be limited to the extent than they can be monitored via temporary taps or SPAN ports.
Types of Systems:
Systems in this zone may be in the process of initial configuration, but have reached the point of requiring network access to download updates and additional software. As always, to be physically located in the NPCF, systems must be approved by the NPCF RAF Space Committee.
As the purpose of this zone is to provide network access to systems as they are being configured, it's unrealistic to expect them to have a full suite of security tools already configured and working. Packet filtering will allow minimal incoming services to help protect systems that may come with vulnerable software out of the box. These systems must:
- restrict network access until systems are vetted
- use secure, non-default passwords; and
- be hardened according to the requirements for Zone 1 as quickly as possible if the intent is to move the system to that network.
- Systems transitioning to Zone 1 must still be vetted by the Security Team
Zone 2: Testing
NPCF room 2016 is for testing and installing new systems and will reside behind a 1G Firewalled network link. Systems requiring more than 1G bandwidth, but unable to meet a sufficient level of system security to be moved to the High Performance Datacenter zone must provide and connect to the network through a firewall, which must be vetted by security. (In some cases, router ACLs or a NAT could be deemed sufficient.) The firewall(s) will limit traffic both in and out of the test zone and traffic from this network will be monitored. Requests for changes to any firewall configurations should be directed to networking and coordinated with the Security Team.
Types of Systems:
Systems in this zone may be in the process of initial configuration or semi-permanent test systems.
Systems in this zone have the same requirements as those in Zone 1b.
Zone 3a: NCSA Building
The NCSA Building houses the majority of NCSA staff, but also has several small server rooms. With staff and guests moving systems in and out, the networks within this zone are not highly trusted.
It is the goal of the Security Team to eventually be able to separate the NCSA Building into several sub-zones based on logically or physically separate networks. At this time those changes are not feasible and are beyond the scope of this document.
Types of Systems:
A large variety of systems includes staff laptops, workstations, test systems, and may include machines providing production services that, for whatever reason, do not merit or require placement in the NPCF data center.
Traffic within this zone should be regarded with suspicion as these networks are only nominally more trusted than general Internet traffic. As a result, traffic between this zone and the others will be monitored. The Security Team provides assistance with hardening hosts and can provide additional monitoring if requested.
Generally, these systems will be laptops, tablets, and/or smart phones owned by NCSA employees or guests.
Guest laptops are likely candidates for victimization by malicious network traffic, email/web client attacks or viruses. Therefore, the preferred way for guests to obtain Internet access is through the EDURoam, UIUC Public Wifi (where available) or by getting a guest account on UIUCNet, which has good coverage all over campus. These networks are run by CITES and traffic is tunneled outside the NCSA network. Therefore, guest systems would not logically be a part of the NCSA network and would be treated as external Internet traffic.
Zone 7: Physical Security Systems
This is an island zone only for the NPCF physical security systems.
Types of Systems:
All NPCF physical security systems, and only those systems, are part of this zone. This includes the camera DVRs, the badge readers, the iris scanners, the ACMS workstations (for badging, control and enrollment), and the ACMS database server.
- Devices on this network are on their own physical network, but they are bridged-together private VLANs on shared routers and switches;
- This VLAN is completely private and does not allow for access to or from the outside world, except for occasional VPN access into this zone that is provided to allow the physical security contractors (ITG) to perform maintenance. This VPN access is turned off unless maintenance is being performed; and
- VPN access is also restricted to a small number of remote IP addresses and requires a strong authentication for access.
Zone: Island / PSP (Private Sector Program)
This defines a type of zone rather than a specific zone itself. An Island zone has its own, unmonitored external bandwidth either provided by a 3rd party or too large to be monitored by the border NIDS. The island may have an additional, smaller bandwidth connection directly into NPCF zones that will be monitored with the NIDS and treated as external traffic. This includes site-to-site VPN traffic traversing NCSA's external links. This traffic must not be routed inside the NCSA network without also being monitored by a NIDS, and it will be trusted no more than other Internet traffic.
Types of Systems:
These are systems (typically servers) for special projects or private sector partners that bring in their own systems to physically reside in NPCF, but that also require their own external connectivity. Other large systems that have their own pipes, but do not wish to pay for monitoring, can opt for an island zone.
- These zones have their own outside connectivity (preferably non-NCSA IPs), and no direct connection to our network. For the purposes of security monitoring they are treated as external systems;
- If the owners/administrators of systems on this network require security monitoring beyond that provided if/when traffic from these systems crosses into an NCSA network, that monitoring must be coordinated with the Security Team and any additional costs of that monitoring borne by the owners/administrators of the systems.