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 a similar 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 networks.
The Security Team is responsible to ensure regular auditing of this policy and automates this when auditing where possible. However, responsible does not always mean executing every audit on their own. This is a group endeavor among all the NCSA service providers and requires coordination and cooperation between ADS, ITS and Security.
Violations of this policy may result in immediate disconnection of systems by the Security Teamsecurity team, especially in critical and sensitive zones. Failure to obtain prior approval for installations based on zone policies or attempts to circumvent these policies will be reported to senior management at the NCSA.
This is the zone for production systems in the data center and consists of most machines in 2020 NPCF. It includes both public and private networks.
Systems requiring high availability, physical security and high performance networking are hosted here. This includes not just HPCssupercomputers, but core storage, security, networking equipment, and more. These systems are first 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 A vulnerability and patch management plan must be 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 log 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 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 in and out of this zone are monitored by the network IDSNIDS. 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 IDSNIDS, but netflows are collected.
These systems must:
- Use secure, non-default passwords.
- Be protected by a stateful, network firewall that only accepts connections from non-NCSA hosts on port 22.
This zone supports a variety of systems from including desktops, laptops, portable devices and research systems with . This zone is the most flexibility flexible and has the fewest security controls. While firewalled subnets are encouraged by default, the only policies that apply broadly to every host are campus and NCSA employee security policies and the requirement to register hosts using an NCSA ID before accessing the network.