| Category (Group of requirements around a major function provided by NGN) |
Description (Requirements statement) |
|---|---|
| Network Visibility | NETFLOW, SFLOW - Yale’s NGN network MUST record ALL network traffic (even between 2 devices on the same VLAN or subnet) flow metadata (NetFlow, SFLow,etc), collect and store it for a time to be determined between one month and one year and supply it to Yale Information Security within a reasonable amount of time. |
| Network Visibility | Syslog - Yale’s NGN devices/systems MUST send syslog to a (1) remote syslog server (Yale ITS Event Monitoring System) and/or (2) Yale Information Security’s SIEM/Pipeline. |
| Network Visibility | Network Event Info, Warnings, Errors - Yale’s NGN devices/systems MUST forward all events to the Yale ITS Event Monitoring System and forward selected important events to the Information Technology Service Management tool such as ServiceNow. |
| Network Visibility | NGN Packet Capture MUST Use Change Control - Yale’s network packet capture hardware and software must NOT be disabled or bypassed without consultation and/or notification to Yale Information Security. Yale Information Security MUST be provided with notification of any changes in a timely manner. |
| Network Visibility | NGN Network Diagrams Marking Packet Capture & Inspection MUST be available and current - Yale Information Security MUST be provided with current correct network diagrams of Yale’s Network and Packet Capture infrastructure and advised of any changes to the diagrams in a timely manner. In addition to the diagrams there MUST be lists of what networks (VLANs, Subnets, etc) are covered by each diagram so that we can see where there are gaps in packet inspection coverage. |
| Network Visibility | Stealthwatch IPFIX – Yale’s NGN Stealthwatch system MUST generate, collect, and analyze “IPFIX” enhanced netflow from mirrored traffic via packet capture solutions (SPAN, TAP, etc.) at important “choke” points and must provide the ability to set up new ad-hoc packet capture locations quickly on request. |
| Network Visibility | Stealthwatch NGN IP Asset Classes - Yale’s Stealthwatch MUST classify IP assets by location based upon the location data provided by Yale University. This classification by Yale IP assets (and asset groups) MUST be maintained and kept up to date. |
| Network Visibility | Stealthwatch NGN Enrichment via User Attributes from AD - Yale’s Stealthwatch MUST include user attributes (including Yale AD NetID identities at the least) by integrating with ISE via PxGrid to obtain user attributes). |
| Network Visibility | Cisco Service Delivery Platform AD OU Data – Yale’s Stealthwatch CSDP (Cisco Service Delivery Platform) MUST gather and analyse data from Active Directory OUs. |
| Network Visibility | Cisco Service Delivery Platform IPAM/DNS/DHCP Data – Yale’s Stealthwatch CSDP (Cisco Service Delivery Platform) MUST gather and analyse NGN data from BlueCat DNS, DHCP, IPAM. |
| Network Visibility | Stealthwatch use of CMDB/IT Asset DBs – Yale’s Stealthwatch CSDP (Cisco Service Delivery Platform) MUST gather and analyze NGN data from CMDB or any other sources of data regarding IT assets and users (in order to automate the use of this data for risk classification). |
| Network Visibility | Stealthwatch Use of VN & SGT data – Yale’s Stealthwatch MUST classify NGN IP assets by VN and Security Group (Tagging) when it is possible to do so based upon analysis of network telemetry and data from IT infrastructure systems in use. |
| Network Visibility | Stealthwatch Auditing of SGTs & Micro-Segmentation Rules – If/when micro-segmentation ( Security Group (Tag) to Security Group (Tag) ) communication rules are enforced, Stealthwatch MUST audit/verify and report on violations of the rules in practice. |
| Network Visibility | Stealthwatch data intake by ISO SEIM/Pipeline - Yale’s StealthWatch data MUST be ingested, processed, indexed, correlated, stored and available in the Yale Information Security SIEM / Pipeline. |
| Network Visibility | NGN - IPv4 & IPv6 MUST BE Equal in Yale Network Visibility – Yale’s NGN Network visibility MUST cover both Yale’s IPv4 and IPv6 IPs in scope. |
| Network Visibility | NGN’s ISE & DNA-C MUST Provide 1 Year Historical Data on IP/MAC Address & ID, Location Data (Switch/AP) –Yale’s NGN ISE (Identity Services Engine) plus DNA system MUST provide immediate and timely access to query MAC or IP address anywhere on campus for historical (12 months) for info on location & Identity as well as the local connected Access Point or network switch. |
| Network Visibility | Yale’s NGN Network MUST keep historical ARP data (IP address to MAC address mappings) from routers/switches for one year and make it available to Information Security via a query interface. |
| Network Visibility | Yale NGN DNS PTR records MUST point to Yale AD YU.YALE.EDU hostnames for YALE AD “Joined” computers. The NGN network MUST configure Yale’s DNS service such that Yale AD joined computers have a DNS PTR record pointing to a hostname in Yale’s AD DDNS (Dynamic DNS) that is the same fully qualified domain name as provisioned by the Address record in Yale’s AD DDNS domain (YU.YALE.EDU). This is needed for Microsoft Azure Threat Protection (and detection) to work effectively. The NGN network MUST provide authentication for users and devices (and begin to enforce it after the pilot and foundational release) and make the identity (users & devices) available to authorized staff and processes. Given session details it should be possible to obtain the internal IP address, MAC address, identity (NetID/other) and physical location of any device, user or session on the NGN network. |
| Network Visibility |
Yale NGN MUST be able to provide a description for each source of network information (e.g. DHCP logs, ARP tables, etc), provide evidence that it is a source of truth and test/verify that the information is correct on a regular basis. Yale needs to be able to explain exactly what is happening on the network and, in particular, what is happening when different sources of information do not appear to be in agreement or do not appear to be accurate. |
| Network Visibility |
Yale NGN MUST log all traffic between devices on the same network. Yale needs completely visibility on the network and this includes within the same network (VLAN, Subnet, VN, etc). This would include the ability to log intra VN traffic via netflow or sflow records. |
| Authentication - User/Device Identity | NGN DNA-C MUST USE ISE - Yale’s DNA Center MUST integrate with Cisco’s Identity Services Engine (ISE). ISE MUST be used to Authenticate users and identities. |
| Authentication - User/Device Identity | NGN ISE MUST USE AD for IDM - Yale’s ISE MUST support and use LDAP and AD as sources of identity management. |
| Authentication - User/Device Identity | ISE/RADIUS, 802.1X and CTS MUST BE USED by NGN Edge Nodes – Yale’s NGN Network Edge nodes MUST be configured with Cisco TrustSec (CTS), dot1x authentication, and dynamically deploy SGACLs to access ports according to user’s policy. ISE will be the radius server and controller for the above authentication and dynamically deploying the CTS SGACL policies. |
| Authentication - User/Device Identity | NGN SHOULD LOAD BALANCE RADIUS - Yale SHOULD install and use a load balancer (planned for later in the project after the pilot) to load balance RADIUS traffic. A RADIUS account MUST be used to check the health of each ISE PSN to ensure that each PSN continues to have a healthy Active Directory connection. |
| Authentication - User/Device Identity | NGN MUST SUPPORT MAB - YALE MUST implement MAB for printers and other devices that do not support a dot1x supplicant. Implementation should not involve or include MAB Lists. |
| Authentication - User/Device Identity | Yale NGN SHOULD USE MFA (Multi-Factor Authentication) for 802.1X 0. Investigate/research if two-factor (Multi-Factor) authentication can be implemented with 802.1X authentication for supplicants used in pilot (native Windows, MacOS as well as Linux, ChromeOS). Answer the following questions for Paul Rivers (CISO): |
| Authentication - User/Device Identity | YALE NGN MUST PERFORM A THREAT MODEL ANALYSIS on MFA (Multi-Factor Authentication) for 802.1X to answer the questions: Is MFA significantly helpful in improving security posture when authenticating to the network? What are the specific threat scenarios it addresses? Assuming it is helpful, is it possible? |
| Authentication - User/Device Identity | YALE MUST Re-EVALUATE EAP-PEAP vs EAP-TLS DECISION – to answer the question “assuming it is both helpful and possible, why would we ever need the additional complexity of EAP-TLS over EAP-PEAP?” |
| Authentication - User/Device Identity | YALE MUST Re-EVALUATE the EAP-TLS EFFORT ESTIMATE – to answer the question “If we have reason to be interested in EAP-TLS in the long term, what is a very high-level sketch of how that transition would work, with an estimate on level of effort for the overall campus?” |
| Authentication - User/Device Identity | SecureW2 – Can we protect against spoofing Yale SecureW2 download site? DONE |
| Authentication - User/Device Identity | Yale NGN MUST re-evaluate and review the “fail open” vs “fail close” AUTHN approach on NGN. When does the question about the fail-open process properly fall here, or is this deferred to later? This topic can’t get lost/dropped. |
| Authentication - User/Device Identity | Yale MUST Profile (& Control?) Devices on Yale NGN networks (particularly restricted networks) – YALE MUST have a method of regularly profiling and identifying make, model of devices on the network (as well as potentially the OS and other software running on the device by version(s)). Yale MUST be able to use ISE to PROFILE to ID (to block or move?) new or previously undiscovered unidentified devices so that they are placed on the appropriate virtual network without requiring MAB (Mac Address Bypass) – for example, Solstice devices, Display monitors. |
| Authentication - User/Device Identity | Yale MUST maintain an inventory of devices (known & unknown but seen) on Yale’s NGN network. This inventory may be Yale’s IPAM, CMDB, something new/else or a combination of these. |
| Authentication - User/Device Identity | Yale MUST determine a standard list of network device attributes to track & store – Yale MUST investigate and decide upon the list of attributes we are capable of identifying about end-points, with their possible values. Yale MUST understand how the attribute values are identified, so we have a good understanding of the confidence level we should assign to these values. These end point attributes MUST be stored in the devices on the network inventory. |
| Authentication - User/Device Identity | ALL devices MUST be Assigned a meaningful SGT Tag - YALE Must use SGT Tagging to provide each device in NGN a ‘meaningful’ SGT tag based on the device and/or user on the device. |
| Authentication - User/Device Identity | SGT Tags MUST be reliable – YALE MUST be able rely on the initial SGTs as these will just be informational and not used for any decision-making. They will only be read as a test. |
| Authentication - User/Device Identity | Initial SGT for MAB devices MUST be the VN default - Yale devices placed on VNs based on MAB MUST have an SGT showing them in the default group for the VN they’ve been placed in as their initial SGT. |
| Authentication - User/Device Identity | Devices authenticated by 802.1X MUST USE user-based SGTs - Yale devices where users have successfully identified via 802.1X MUST have a default SGT tag identifying the user as either a part of the ‘Default User’ group initially, or – if they’ve been identified further as a member of a specific user group – a more specific group tag if one exists that they are a member of (this is in the NEXT PHASE Advanced Security release). |
| Authentication - User/Device Identity | Devices authenticated by MAB MUST USE device-based SGTs - Yale devices where users have successfully identified via 802.1X MUST have a default SGT tag identifying the user as either a part of the ‘Default User’ group initially, or – if they’ve been identified further as a member of a specific user group – a more specific group tag if one exists that they are a member of (this is in the NEXT PHASE Advanced Security release). |
| Authentication - User/Device Identity | More Security Group Design & Advanced Standards Needed - YALE MUST define what SGT tags we’ll need in the longer term based on machine ‘groups’ and user ‘groups. WE NEED TO DEFINE SGT Groups in order to do this thoughtfully. |
| Authentication - User/Device Identity | NGN MUST implement via ISE and AD (or other mechanism) the capability to identify and place users into specific VNs (e.g Macro-Segmentation) by specific NetID, Role (based on groups) and other groups (organized around attribute membership criteria). NGN must define, design, test and plan how to do this for a specific netid as well as well defined groups of netids (role-based or other based groups). This may require work involving IAM. |
| Authentication - User/Device Identity | NGN MUST implement via ISE and AD (or other mechanism) the capability to identify and place networked devices into specific “security groups” (e.g. via Scalable Group Tags - SGTs) by specific MAB (MAC address Bypass) or Profiling. NGN must define, design, test and plan how to do this for a specific netid as well as well defined groups of netids (role-based or other based groups). This may require work involving scripting. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Posture Checking - Yale’s NGN MUST support to capability to enable posture checking of endpoints. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Network Access Control - Yale’s NGN MUST support to capability to enable Network Access Control (NAC) of endpoints. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Yale’s NGN Network Access Control MUST provide the capabillity to use a combination of Location-based model and a User/Application based model, whereby regardless of the location or access methodology users will be able to access the systems, services and/or data that they have validated authorization to use via 802.1x |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Yale’s NGN Network Access Control MUST provide the capabillity to allow enforcement through a policy-based mechanism, whereby users, systems and services will be grouped and assigned access policies, which establish the requisite technical controls for those users, systems and services within the network infrastructure. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Automation - Yale’s NGN combined Stealthwatch and ISE solution MUST provide the capability to analyze, detect and block anomalous network behavior by users or endpoints in the network. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Automation - Yale’s NGN Network’s automated solutions must include API access by information security, so that high-confidence alerts detected by anything we do within the visibility pipeline may also trigger quarantine or blackhole. I am also concerned that we give proper thought to how we control and audit the use of such access. Auditing is mandatory for any use, including network engineering and operations. – Paul Rivers (CISO). |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Automation - Yale’s NGN Network’s automated solutions must provide the ability to quarantine and block applies to all of Yale address space: wired, wireless and VPN, and must cover IPv6 (if deployed). This also means termination of active sessions, such as on the VPN. – Paul Rivers (CISO). |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Automation - Yale’s NGN Network’s automated solutions (ISE, DNA-Center, Stealthwatch) must provide the ability to profiling and identifying make, model of devices on the network (as well as potentially the OS and other software running on the device by version(s)). |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Automation - Yale’s NGN Network’s automated solutions (ISE, DNA-Center, Stealthwatch) MUST provide the ability to Block, Restricting and Removing from the network all/any known obsolete, vulnerable or malicious devices. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Public IP Address Migration to Private IP - The NGN Project MUST agressively attempt to migrate public IP addresses to private IPs during building migration to the NGN Network. To move any Public IP addresses to Private IP addresses in the NGN Fabric (e.g. to the Default User VN or other VNs) while providing an exception process for business purposes requiring Public IP addresses. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Both IPv4 and IPv6 “positive control” - Yale’s NGN Network “positive control” mechanisms MUST be able to cover both IPv4 and IPv6 IPs in scope: Yale’s IPv4 and IPv6. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Sole Central Block/Quarantine Process – There MUST be just one (1) Yale Information Security SecOps approved process to quarantine and block on NGN which is used by all of ITS. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | NGN BLOCK Information MUST Be Available – There MUST be a query for the Yale NGN “Block” process to provide the current & 12 month history Who/What/Where/Why/etc and reason with all information about the block - - this will use the InfoSec PipeLine/SIEM log enrichment. This information will include: (1) Who authenticated to applications (e.g web) using the item? – via CAS, Shib, etc. (2) Who authenticated the device onto the network? – via user/machine auth or MAB? (3) Who was that device attributed to at the time? E.g. via SCCM, BAM, etc. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Block Recividism detection - Yale’s NGN Network MUST have a Recividism detection process which is scheduled and automated – to Identify and alert us to devices that have been blocked and/or quarantined, but which then appear back on any Yale network. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | NGN “BLOCK” Process MUST Respect the “DO NOT BLOCK LIST” - The Yale NGN Network Block/Quarantine process MUST respect the single central “DO NOT BLOCK LIST” of IP addresses and integrate with our system/data classification tools in order to provide identification to prevent critical pieces of infrastructure from being blocked (e.g. DNS servers, AD servers, approved scanners). |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | NGN “BLOCK” Process MUST Have Audit Log - The Yale NGN “Block/Quarantine” process must include an audit log of the quarantine / blocking actions for all devices - Who blocked each device and when as well as their NetID, MAC and IP address on wired and wireless networks. This capability needs to log this on EduRoam and all guest and event networks also. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Block any device on any Yale NGN network MUST be provided to Information Security Yale must provide the capabiility to Information Security (& designees such as the Service Desk) to block any device immediately on any and all devices on any Yale network (WiFi/VPN/Wired/etc). The process should work in the following manner once the Information Security staffer or designee enters the MAC address (physical Ethernet or WiFi address) of the device to block) : Identify the device Disable the network access for the device on the network Prevent the device from reestablishing connectivity to the network. Prevent the device from reestablishing a connection. Notify the Security Contact for the device that the device has been blocked from the network for “X” reason and they should call X for help. Captive Portal: Notify the device owner that the device has been blocked from the network for x reason and they should call X for help. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Block capability for an individual’s current Yale sessions from any device on any Yale network MUST be provided to Information Security. Yale must provide the capabiility to Information Security (& designees such as the Service Desk) to block an individuals current Yale sessions on any and all devices on any Yale network (WiFi/VPN/Wired/etc). The process should work in the following manner once the Information Security staffer or designee enters the identity (Yale NetID) of the individual to block) : Identify the user Break the connection Prevent the device from reestablishing a connection. Notify the Security Contact for the device that the device has been blocked from the network for “X” reason and they should call X for help. Captive Portal: Notify the device owner that the device has been blocked from the network for x reason and they should call X for help. |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Information Security MUST approve a Block or QUARANTINE on a device or on an individual’s current Yale sessions on any Yale NGN network. Anyone at Yale who wishes) to block a device or a NetID or an individual’s current Yale sessions on any and all devices on any Yale network (WiFi/VPN/Wired/etc) MUST contact Information Security Operations and receive formal approval (which MUST be followed up with a ServiceNow ticket). |
| Positive Network Control (Blocking, Automation, Posture Checking/NAC) | Information Security MUST approve the removal of a BLOCK or QUARANTINE on a device or on an individual’s current Yale sessions on any Yale network. Support providers at Yale who wish to remove the block on a device or NetID or an individual’s current Yale sessions on any and all devices on any Yale network (WiFi/VPN/Wired/etc) MUST contact Information Security Operations and receive formal approval (which MUST be followed up with a ServiceNow ticket). |
| Segmentation - Macro( Virtual Networks), Micro, Nano | MACRO-SEGMENTATION: Multiple YALE NGN Virtual Networks (VNs) for users and/or devices MUST be provisioned for the network segmentation of the previousl Yale legacy separate physical networks and some additional virtual networks (VOIP, PCI, etc). The design principles, policies and security requirements for entry and qualification to the different Yale NGN VNs must be formally documented and maintained. |
| Segmentation - Macro( Virtual Networks), Micro, Nano | MICRO-SEGMENTATION: Multiple YALE NGN SGT’s for Virtual Networks (VNs) as well, micro segmentation using Security Group Tags (SGTs) within the VNs MUST be provisioned to allow the further segmentation of users and device communication within VNs. The design principles, policies and security requirements for entry and qualification to the different Yale NGN SGT’s for VNs must be formally documented and maintained. |
| Segmentation - Macro (Virtual Networks), Micro, Nano | Yale NGN VNs MUST be a Least-Trust and/or Zero-Trust Networks – Users, services and data are segregated and technically isolated to establish a least-trust environment. In such an environment, visibility and access to systems, services and data are restricted to only those entities that require such access. On NGN networks where no authentication is required or provided (Guest / Quarantine / etc) the network MUST be regarded as a Zero Trust environment. |
| Segmentation - Macro (Virtual Networks), Micro, Nano | Yale’s NGN Edge nodes MUST be configured with Cisco TrustSec (CTS), dot1x authentication, and dynamically deploy SGACLs to access ports according to user’s policy. ISE will be the RADIUS server and controller for the above authentication and dynamically deploying the CTS SGACL policies. |
| Segmentation - Macro (Virtual Networks), Micro, Nano | MICRO-SEGMENTATION: Yale’s NGN network MUST be further segregated to limit the exposure to network congestion, as well as the horizontal )”East-West” propagation of network breaches and/or malware infection. The NGN network MUST support Cisco’s micro-segmentation and service insertion technology, within both the physical and virtual domains. |
| Wireless Security | NGN Wireless guest access. Guest users on a Guest wired or wireless networks MUST be presented with either a hot spot, self-registered or sponsored-guest portal. |
| Wireless Security | A current playbook/test plan MUST exist and be improved for known NGN failure scenarios. A standard playbook/test plan for testing the known various failure conditions (e.g. ISE infrastructure failures, firewall failovers, etc.) in the NGN network MUST be created and updated on a regular cadence (yearly) to ensure adequate monitoring and for Disaster Recovery plans/drills and IT incident response playbooks. |
| Guest & Event Networks | Timely Decommission NGN Event Networks – All Yale NGN Event SSIDs, Aps and wired network jacks should be removed or disabled ASAP after an event. |
| Guest & Event Networks | NEW Guest network - Yale’s NGN MUST implement a NEW Guest network for both wired and wireless use separate from both the campus network and the NGN Quarantine / Remediation network (so that compromised or infected devices are not sharing the same network). Traffic from this network must exit directly onto the Internet. |
| Guest & Event Networks | MORE Functional NGN Guest Network - The new Guest network MUST be more functional than the current (legacy network), provide complete access to the Internet’s programs, protocols and ports while being protected via a network security firewall. It must also be treated by NGN and the campus network just as if it is an extension of the hostile Internet. |
| Guest & Event Networks | NEW NGN Guest Wired Network – The NEW Guest Wired Network MUST use a “Captive Portal” (which should be the same captive portal as the Guest Wireless network). Traffic from this network must continue to exit directly onto the Internet and not on campus. |
| Guest & Event Networks | NGN Department Guest Networks – Yale NGN SHOULD discourage separate Department Guest Networks or handle this need via Security Group Tags in Advanced Security Releases. |
| Guest & Event Networks | Yale Rep Theater WiFi - Yale Rep Theater should be configured to use the New NGN Yale Guest Network - as should any other Yale networks specifically provisioned for the general public. |
| Guest & Event Networks | NEW NGN Event network - Yale’s NGN MUST implement a NEW Event network for both wired and wireless use separate from both the campus network and the NGN Quarantine / Remediation network (so that compromised or infected devices are not sharing the same network). Traffic from this network must exit directly onto the Internet and not on campus. |
| Guest & Event Networks | ALL THE SAME Visibility & Blocking/Quarantining/Positive Network Control will be enforced in the NGN Guest and Event networks. |
| Guest & Event Networks | NGN Event Network Wireless Access Points and Switches - should be the same NGN Fabric Access Points and Switches with the same automatic and orchestrated by DNA Center configurations. These should only be set up if there is a capacity problem and special Event only WAPs or Switches should not be set up, particularly with an idiosyncratic configuration. |
| Guest & Event Networks | NEW NGN Eduroam network - Yale’s NGN MUST implement a NEW Eduroam network for both wired and wireless use separate from both the campus network and the NGN Quarantine / Remediation network (so that compromised or infected devices are not sharing the same network). Traffic from this network must exit directly onto the Internet. |
| Guest & Event Networks | MOVE NGN EDUROAM outside Yale Network – Eduroam traffic going into Yale’s campus network MUST enter and exit via Yale’s border firewalls just as if it arrived via the Internet. – the current Eduroam SSID at Yale has too much access – Yale’s operational process in Information Security MUST treat a non-response from a remote Eduroam institution to mean that the device should be either quarantined or blocked. |
| Quarantine/Blackhole/Remediation Networks | Make NGN Quarantine network - Yale’s NGN MUST implement a quarantine network (to be determine if a VN or an SGT ACL, etc.) for the following use cases after the NGN pilot : |
| Quarantine/Blackhole/Remediation Networks | NGN’s Quarantine Network MUST handle Compromised & AT Risk Devices - The Quarantine network MUST provide a place for computers found to be compromised or extremly vulnerable and “at risk”. This is in addition to any method(s) we may have for blocking devices. The Quarantine network must be suitable for placing computers on both manually and by automation. |
| Quarantine/Blackhole/Remediation Networks | NGN ‘Blackhole’ network – There MUST be a NGN ‘Blackhole’ network functionality into which we can immediately place devices (manually at first, then through automation as well) that should have NO ACCESS entirely (including no Internet access). |
| Quarantine/Blackhole/Remediation Networks | NGN Automation must provide auditing and controlled API access – Automated solutions (for NGN’s Quarantining, Blackholing and Blocking) must include API access by information security, so that high-confidence alerts detected by anything we do within the visibility pipeline may also trigger quarantine or blackhole. I am also concerned that we give proper thought to how we control and audit the use of such access. Auditing is mandatory for any use, including network engineering and operations. – Paul Rivers (CISO). |
| Privileged Account Management (PAM) Operational on all NGN Network components | All NGN Network Critical Infrastructure MUST use Privileged Account Management –Yale’s NGN Network Devices and Software Solutions (the management / monitoring platforms DNA-Center, ISE, etc) MUST use Privilege Account Management (PAM) for administration of privileged accounts, privileged access and privileged account/session control whenever/whereever possible. |
| Privileged Account Management (PAM) Operational on all NGN Network components | All NGN Network Critical Infrastructure MUST use proper Account Lifecycle Management –Yale’s NGN Network Devices and Software Solutions (the management / monitoring platforms DNA-Center, ISE, etc) MUST use proper Account Lifecycle Management for both privileged and non-privileged accounts creation, provisioning and decommissioning of privileges and “death”. |
| Privileged Account Management (PAM) Operational on all NGN Network components | Privileged Account Authentication - Yale’s NGN Network Devices and Software Solutions (the management / monitoring platforms DNA-Center, ISE, etc) MUST support RADIUS or TACACS+ authentication (AuthN) for administration and other privileged access. |
| Privileged Account Management (PAM) Operational on all NGN Network components | Privileged Account Authorization - Yale’s NGN Network Devices and Software Solutions ( MUST support Role-Based and/or AD and/or Grouper group based Authorization (AuthZ) for administration and other privileged access. |
| Privileged Account Management (PAM) Operational on all NGN Network components | Privileged Access “Break Glass” Accounts – Yale’s NGN Network Devices and Software Solutions (the management / monitoring platforms DNA-Center, ISE, etc) MAY use local Native) accounts but the MUST be controlled by the PAM solution whenever/wherever this is possible. |
| Privileged Account Management (PAM) Operational on all NGN Network components | All NGN Network Critical Infrastructure MUST use PAM with automation for provisioning –Yale’s NGN Network Devices and Software Solutions (the management / monitoring platforms DNA-Center, ISE, etc) MUST use Privileged Account Management with automation for creation, provisioning and decommissioning of privileges and “death” – and particularly for assigning AuthZ using groups (AD or Grouper). |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously meet Minimum Security Standards – The group or groups responsible for the Yale Network MUST continuously verify that all critical infrastructure tools, devices, servers MUST meet the Minimum Security Standards for critical infrastructure systems. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously meet vendor/industry access control best practices – Continuously verify that all critical infrastructure tools, devices, servers MUST employ vendor and/or industry recommended “access control” best practices. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously use Multi-Factor Authentication where supported – Continuously verify that all critical infrastructure tools, devices, servers MUST employ Multi-Factor Authentication (MFA) where supported. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously use IAM’s Grouper Groups where supported – Continuously verify that all critical infrastructure tools, devices, servers MUST utilize IAM’s Grouper Groups where supported (in some cases these may be provisioned via an staged in IAM’s Grouper Groups and synched to AD or local native group mechanisms). |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously keep current DR practices. – Yale MUST continuously verify that all critical infrastructure tools, devices, servers have current Disaster Recovery plans and that staff remain prepared for disasters via DR drills and regularly test network redundancy by scheduling and running network failover tests. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously keep up standard best Proper Account Lifecycle practices. – Yale MUST continuously verify that all critical infrastructure tools, devices, servers maintain and keep up standard best Proper Account Lifecycle practices. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously keep up Privileged Account Management systems and practices. – Yale MUST continuously verify that all critical infrastructure tools, devices, servers maintain and keep up the implemented Privileged Account Management (PAM) systems and practices. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously create, review, improve, validate and automatically configure security of critical infrastructure to standard security configuration – Yale MUST first create, then continuously improve and verify that all critical infrastructure tools, devices, servers are maintain secure configurations/settings and automatically (with orchestration management tool(s)) update devices and software with the implemented standard security configurations/settings established for these devices (switches/routers/APs/etc) and software. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously keep up the transmission of relevant security and network log data to Information Security – Yale MUST continuously verify that all critical infrastructure tools, devices, servers are sending production data feeds and sent to the Yale Information Security SecOps pipeline without gaps or errors. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously maintain the capability to query for active MAC and IP addresses, users and devices – Yale MUST continuously verify that all critical infrastructure tools, devices, servers are keeping updated information (physical locations, switch ports, AP associations, etc) on wired and wireless physical device addresses, IPv4 and IPv6 addresses, authenticated users (NetIDs) and devices (Yale AD Machine accounts). |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST periodically review and redefine required notification to Information Security of network changes – Yale MUST review and redefine the criteria used to triage notifications required to Information Security of all major network changes to the NGN network before changes are brought to the Change Advisory Board, scheduled, started and implemented. This should take place at regular scheduled meetings of ITS Networking and Information Security staff. |
| Operational Capabilities, Processes, Maintenance and Continuous Security | All NGN Network Critical Infrastructure MUST continuously ensure that proper Change Control Management and Notification are always used – Yale MUST continuously verify that all critical infrastructure tools, devices, servers are maintaining notification to Information Security of all major network changes to the NGN network before changes are brought to the Change Advisory Board, scheduled, started and implemented. |
| New Policies, Procedures | PRIVATE EXTENSIONS of YALE NETWORK - Need NGN Yale Network Policy on minimum security standards that anyone seeking to extend the University network with their own private network would need to meet, who can add a SOHO router or wifi access point, their own VPN or firewall, etc.? Vendor-managed networks and tunnels for remote access by vendors, etc.). |
| New Policies, Procedures | Security Contacts - Need NGN Yale Network Policy that each device attached to the network must have a responsible security contact to respond to queries and requests regarding the device and the management of the device. |
| New Policies, Procedures | PRIVACY - Need NGN Yale Network Policy regarding the privacy implications of being able to track the identity of users on the network and their location – policy? Who can request this information and what are the rules for approval of such requests? |
| New Policies, Procedures | Policy and Procedure for NGN campus network segmentation. Why do we have VNs? Are they for security (perimeter) control reasons? Administrative control reasons? Or both? Why do we put one individual or device on one versus another VN? Who gets to decide who goes on a particular VN and why? What policies would you apply to one VN versus another? What policies would you apply between VNs? What is the raison d’etre for ScienceNet? For the Research VN? How do we think about the definition of these VNs? How will they be used now and in the future? If we didn’t have separate physical networks currently, would we be creating VNs? What would we use to isolate a research lab or group that required segregation of their office or lab equipment from others on the network? And why? |
| New Policies, Procedures | NGN “quarantine/blocking” policy/procedure |
| New Policies, Procedures | Yale departments with their own NGN network or virtual network MUST have a responsible part to own and administer the network.”If you need and operate on a special Yale University network, some one must be ra esponsible party for the ownership, administration and operation of this network and the assets on it.” RACI chart?” |