| A | B | C | D | E | F | G | H | |
|---|---|---|---|---|---|---|---|---|
1 | Security Control Information | |||||||
2 | R&E Routing Integrity Control Group | Security Control Name | MANRS | Security Control | Assessed Security Control Implementation (select one of the following) | Score | If partially implemented or not implemented, please describe what's deficient and why. | Utility of Control |
3 | Operations Capability | |||||||
4 | OC1 | 7 * 24 accessible NOC | The Network Operations Center is accessible 7 * 24 | Not Yet Answered | Frequently, troubleshooting network outages or impairments requires coordination of administrative domains. Network services in support of research and education are in use every hour of every day; therefore, there needs to be a 7 by 24 accessible NOC so that users can report problems and other networks can coordinate the troubleshooting. | |||
5 | OC2 | Technical community engagement | The network engineers regularly engage the broader Internet2 community to exchange best practices, relevant experience, ask questions, etc. | Not Yet Answered | Network operators within the Internet2 community are some of the best resources for solving technical problems, understanding best practices, and gaining insight into new network technologies. Network staff is encouraged to engage and participate in the community. You can send a note to Linda Roos (lroos@internet2.edu) to inquire about participating in various technical groups within the Internet2 community. | |||
6 | OC3 | Ability to check for route missing due to ROA Invalid | If the network is used as transit (e.g., a RON), the NOC has procedures for checking for routing problem due to a route being dropped via an Invalid ROA | Not Implemented | Most implementations of RPKI Routing Origin Validation drop routes that fail before including them in the routing information base. Unlike prefix filtering, there's no router configuration (such as the prefix filtering configuration) for an operator to inspect when determining if a route was dropped. There should be a method for the network operator to quickly identify routes that aren't accepted due to RPKI ROV invalid status. | |||
7 | OC4 | Maintain Internet number resource allocations (e.g., how prefixes/subnets and ASNs are assigned) | The Network Operations Center maintains detailed records of the use and assignment of IP number resources. For example: the assignment of subnets, ASNs, etc. | Not Yet Answered | Many R&E network operators have large networks that can span multiple buildings or even multiple campuses. To ensure effective troubleshooting, it can be important to have detailed records that associate IP addresses with specific sections of the network. | |||
8 | Resource Management RIR | |||||||
9 | RMR1 | Maintain Whois Records | X | Whois records for number resources are current | Not Yet Answered | Maintaining RIR whois records ensures that other networks are able to identify the relevant contacts when troubleshooting issues that relate to your network resources. Maintaining these records also helps fulfill MANRS Action 3, "Facilitate global operational communication and coordination." | ||
10 | RMR2 | Resources covered by current L/RSA | All numbered resources assigned by ARIN are covered by an L/RSA | Not Yet Answered | While ARIN provides basic whois services to legacy resources (not under an ARIN agreement), an agreement IS required to use ARIN's routing security services, including RPKI ROAs, authenticated IRR, and reverse DNSSEC. | |||
11 | RMR3 | ARIN authentication protected by MFA? | All authorized users of the ARIN portal use Multi Factor Authentication | Not Yet Answered | By default, ARIN's web portal doesn't require multi-factor authentication. Given the critical nature of the resources managed under ARIN, it's highly recommended that ARIN users enable MFA for their web portal access. It's also recommended that organizations adopt a policy that requires all Points of Contact (POCs) for their resources to enable MFA. | |||
12 | RMR4 | Create/Maintain ROAs for IP networks | All IP networks have supporting RPKI ROA records | Not Yet Answered | RPKI ROAs mitigate the risk of route hijacking by publishing the route's authorized origin ASN. | |||
13 | Resource Management IRR | |||||||
14 | RMI1 | Maintain IRR records for all Internet number resources | X | IRR objects for all Internet number resources are current | Not Yet Answered | Keeping IRR route, IRR as-set objects, and PeeringDB as-set current ensures that your network's intended routing announcement policy is published, so that other networks can use this information to determine if routes to your network are valid. This provides a level of protection from route leaks and route hijacks, which can cause outages for your networks. It also helps fulfill MANRS Action 4, "Facilitate routing information on a global scale." | ||
15 | RMI2 | Maintain Maintainer Objects for Organization | X | IRR maintainer objects are current | Not Yet Answered | |||
16 | RMI3 | Create/Maintain as-set that depicts routing intention | X | IRR as-set objects are current | Not Yet Answered | |||
17 | RMI4 | Create/Maintain PeeringDB network records, including as-set | X | The network's peeringDB record includes an as-set | Not Yet Answered | |||
18 | Information System Capabilities | |||||||
19 | IS1 | Route Hijack Monitoring | The Information System monitors for potential route hijacks | Not Yet Answered | Routing hijack monitoring (e.g., BGPalerter, BGP monitor for Cisco, etc.) ensures you can detect when another network is leaking or hijacking your network. Route leaks and hijacks don't always lead to a full network outage, and may therefore be difficult to detect. They can cause network performance problems, and even lead to reputational issues if the hijacker is "borrowing" part of your network for nefarious purposes. Without active monitoring, the effect of these activities can be difficult to detect and diagnose. | |||
20 | IS2 | DDoS Detection | The Information System monitors for DDoS attacks | Not Yet Answered | DDoS attacks, particularly against a large university or regional networks, can be difficult for the network operator to detect without systems in place to specifically detect them. It's common for DDoS attacks to go under the radar by being small or brief enough to not interfere with campus-wide access, while still being enough to impact a specific system or network block. Without DDoS detection capabilities, these attacks can continue to impact systems, sometimes seemingly randomly. Having DDoS detection capabilities also provides critical information that may be used to defend against the attack. | |||
21 | IS3 | PerfSONAR testing | The Information System includes well placed PerfSONAR performance testing nodes | Not Yet Answered | The international R&E community relies on perfSONAR node placement for diagnosing data transfer performance problems. Without strategic hosting and placement of perfSONAR nodes within an organization's network, there is limited ability to support users that require high-performance network service. | |||
22 | IS4 | DDoS mitigation | The Information System can mitigate a DDoS attack via scrubbing | Not Yet Answered | DDoS attacks can be crippling. To prevent outages due to DDoS attacks requires the ability to both detect and mitigate the attack. If the DDoS attack is broadly targeted, or if its volume is sufficient to cause outages beyond its target, then RTBH can be used to protect access to the non-targeted resources. Protecting targeted resources may require Flowspec or a DDoS scrubbing service. | |||
23 | IS5 | RTBH signaling | The Information System can mitigate a DDoS attack via blackhole routing | Not applicable | ||||
24 | IS6 | Flowspec signaling | The Information System can mitigate a DDoS attack via BGP flowspec blackholing | Not applicable | ||||
25 | IS7 | Looking Glass | The Information System allows interrogation of basic routing information to its downstream users | Not applicable | Looking glass servers or router proxies allow other networks to troubleshoot and better understand network behaviors along the end-to-end path. These servers are encouraged to be listed in an organization's PeeringDB page, under MANRS Action 3. | |||
26 | Network Configuration | |||||||
27 | NC1 | ANTI-Spoofing | X* | The network filters/prevents spoofed source packets from egressing the network | Not Yet Answered | Ensuring your network won't accept or forward IP packets with spoofed source addresses is critical to ensuring your network won't be used to attack other networks. While preventing IP source spoofing can be more challenging for transit providers (e.g., backbones such as Internet2 or other ISPs), it's straightforward for campus operators to ensure their end-system networks are unable to spoof IP source addresses. This supports MANRS's Action 2 and is detailed in BCP38 and BCP84. | ||
28 | NC2 | CAIDA | X* | The network hosts an CAIDA Spoofer client on at least two network segments | Not Yet Answered | Using the CAIDA spoofing tester can assist in validating that anti-spoofing configurations and measures are effective. This supports MANRS's Action 2 | ||
29 | NC3 | Multi-factor authentication for device access | Configuration of network devices requires Multi Factor Authentication (MFA) | Not Yet Answered | It's critical to ensure that only authorized individuals are able to configure network equipment. Given the inherent weakness of simple username & password credentials, it's highly recommended that MFA be required to configure these devices. | |||
30 | NC4 | BOGON filtering | X | The network filters BOGON routes | Not Yet Answered | BOGONs are considered IP networks that have no legitimate use over the Internet. Not filtering BOGONs can lead to being the source of unattributable attacks (similar risk to source address IP spoofing), as well as providing unintended access to local private networks from external networks. | ||
31 | NC5 | Multi-homed route leak prevention | X | The network filters/prevents route leaks among network peers | Not Yet Answered | Many default BGP configurations can easily lead to route leaks among a network's peers. The best practice is to tag all routes on ingress and use those tags to filter routes on egress. Good information can be found in BCP84. | ||
32 | NC6 | Mult-ihomed route optimization | The network selects the optimal path (e.g., local peering, regional peering, R&E national backbone, transit provider, or other selection criteria) | Not Yet Answered | Within the R&E network community, it's considered best practice to use BGP local preference to ensure traffic prefers routes that transit R&E infrastructure end-to-end. For example, it may be the case that two universities use the same full transit provider, resulting in the transit provider being the normally preferred path between these two universities due to the shorter length of the AS-PATH. Using local pref to override a shorter AS-PATH to keep the traffic on the higher-speed, less congested path is preferable. | |||
33 | NC7 | Customer Routes Authenticated | X | Routes from customer are checked for ownership and registration | Not Yet Answered | Before accepting customer routes, the network operator should verify the customer is the registered user of the route and origin ASN (via RIR), and that the customer is authorized to use the network. This is in support of MANRS Action 1 | ||
34 | NC8 | Route Origin Validation | X* | If performing Route Origin Validation checking, routes that fail are dropped | Not Yet Answered | If performing RPKI Routing Origin Validation, best practice is to drop routes in ingress that fail ROV, rather than mark these routes for later policy action. | ||
35 | Network Device Hardening | |||||||
36 | NDH1 | maintain software version | Network device software/firmware is periodically reviewed, and update when needed | Not Yet Answered | Network devices frequently require firmware/software updates to ensure they continue to address evolving vulnerabilities. The best practice is to review firmware versions periodically and when notified of a new vulnerability. | |||
37 | NDH2 | Log analysis/SIEM | Network device logs are collected and periodically analyzed | Not Yet Answered | Network device logs can capture instances of hardware failing, attacks against the hardware, new unusual activity, etc. Periodically reviewing logs is recommended to detect these attacks or other anomalies. | |||
38 | NDH3 | configuration management | Network device configuration changes are recorded and can be reviewed | Not Yet Answered | Network device configuration changes should be captured for review and future audits. | |||
39 | NDH4 | secure management plane | Access to network devices for configuration and monitoring is via a secure management plane | Not Yet Answered | Regardless of a secure management networks, best practice is to use authenticated and secure transports when configuring and monitoring network gear using protocols such as ssh and SNMPv3. | |||
40 | Cloud Access | |||||||
41 | CA1 | on-prem-like cloud connectivity | The network facilitates the accessibility of cloud resources by ensuring access is similar to on-premise resources | Not Yet Answered | As users migrate infrastructure to cloud-based platforms, it can be beneficial to preserve the local campus data center model by extending the data center into the cloud provider's infrastructure via services like Internet2's Cloud Connect service. | |||
42 | CA2 | resilience | The network provides resilient cloud connectivity in the event of the failure of one service provider | Not Yet Answered | R&E organizations are typically provisioned with multiple resilient paths to the Internet. However, in many cases, applications that rely on Internet2's Cloud Connect service may not have resilient paths. It's important that the application owners and local network operators understand this limitation and ensure they are able to provide the resiliency required by the applications. | |||
43 | IPv6 Deployment | |||||||
44 | IPv6-1 | IPv6 DHCP or SLAAC | The network can automatically assigns IPv6 addresses to client devices via DHCP and/or SLAAC | Not Yet Answered | Nearly every contemporary end-user device implements IPv6 by default. While campuses may have sufficient IPv4 addresses today to accommodate their basic needs, there is value in supporting IPv6 today. | |||
45 | IPv6-2 | services are assigned IPv6 addresses | Services (e.g., email, web, etc.) are accessible via IPv6 (must include AAAA DNS records) | Not Yet Answered | ||||
46 | * denotes MANRS recommended action, not MANRS required action | |||||||
47 | ||||||||
48 | ||||||||
49 | ||||||||
50 | ||||||||
51 | ||||||||
52 | ||||||||
53 | ||||||||
54 | ||||||||
55 | ||||||||
56 | ||||||||
57 | ||||||||
58 | ||||||||
59 | ||||||||
60 | ||||||||
61 | ||||||||
62 | ||||||||
63 | ||||||||
64 | ||||||||
65 | ||||||||
66 | ||||||||
67 | ||||||||
68 | ||||||||
69 | ||||||||
70 | ||||||||
71 | ||||||||
72 | ||||||||
73 | ||||||||
74 | ||||||||
75 | ||||||||
76 | ||||||||
77 | ||||||||
78 | ||||||||
79 | ||||||||
80 | ||||||||
81 | ||||||||
82 | ||||||||
83 | ||||||||
84 | ||||||||
85 | ||||||||
86 | ||||||||
87 | ||||||||
88 | ||||||||
89 | ||||||||
90 | ||||||||
91 | ||||||||
92 | ||||||||
93 | ||||||||
94 | ||||||||
95 | ||||||||
96 | ||||||||
97 | ||||||||
98 | ||||||||
99 | ||||||||
100 | ||||||||