Core CS & Core PS Network High-Level Security Requirements

Core CS & Core PS Network High-Level Security Requirements

Document Properties Title Mobile Network Security/CSPS/Telecom Core Network High-Level Security Requirements Version 1 Owner Author Reviewers Approved By Jamie Fisher Jamie Fisher Removed Jamie Fisher Pages Total number of pages : 163 Classification Public Version control Version Date Author Description 0.1 June 25, 2006 Jamie Fisher Draft 0.2 July 11, 2006 Jamie Fisher Updated 0.3 July 17, 2006 Jamie Fisher Updated 0.4 July 18, 2006 Jamie Fisher Release Release control Version Date Release Group Action 1.0 7 August, 2006 Removed Information 2 105 CLASSIFICATION: Public

File Properties Filename Last Printed Last Saved Creation Date Mobile High-Level Security Requirements.v.4 (1).doc 1/12/2007 1:04:00 AM 15/12/2006 02:47:00 AM 7/26/2006 12:00:00 PM 3 105 CLASSIFICATION: Public

Index 1. Introduction...9 1.1. General...9 1.2. Protection at the network layer...9 1.3. Security for native IP based protocols... 10 2. Security Domains... 10 2.1. Security domains and interfaces... 10 3. Security Gateways... 11 4. Key Management and Distribution Architecture for IP Networks... 11 4.1. Security services afforded to the protocols... 11 4.2. Security Association (SA)... 12 4.3. Security Policy Database (SPD)... 14 4.4. Security Association Database (SAD)... 14 5. Profiling of IPSec... 14 5.1. Support of ESP... 15 5.2. Support of AH... 15 5.3. Support of tunnel mode... 15 5.4. Support of ESP encryption transforms... 15 6. Profiling of IKE... 17 7. Security policy granularity... 18 8. Network Domain Security Key Management and Distribution Architecture for Native IP Based Protocols... 19 8.1. Network domain security architecture outline... 19 8.2. Interface description... 21 9. Filtering routers and firewalls... 21 9.1. Firewall controls... 22 4 105 CLASSIFICATION: Public

9.2. DMZ controls... 26 9.3. Audit controls... 27 9.4. Network controls... 30 10. IDS/IPS Deployment for GTP and IP Networks... 31 11. DNS Security... 32 11.1. Generic Requirements... 32 11.2. Internal DNS Security (DNSi)... 33 11.3. External DNS Security (DNSx)... 34 12. Core CS and Core PS Network Infrastructure... 37 Layer 2 and Layer 3 Security Requirements... 37 12.1. Scope (example)... 37 12.2. Release... 38 12.3. References... 38 12.4. Technical Requirements... 38 12.5. Hardening the Core... 39 12.6. Removal of Services Cisco Routers... 39 12.7. Removal of unrequired interface services Cisco routers... 40 12.8. Receive Access Control Lists (racls)... 41 12.9. Selective Packet Discard... 43 13. Hardening Core network protocols... 43 13.1. IS-IS... 43 13.2. IBGP... 43 13.3. EBGP... 44 13.4. HSRP... 44 13.5. LDP... 45 13.6. VTP... 45 13.7. Spanning Tree... 45 5 105 CLASSIFICATION: Public

13.8. CLI Transport... 46 13.9. Null 0... 47 13.10. Cisco Discovery Protocol... 47 13.11. Remote Management Security... 47 13.12. User accounts... 48 14. Securing Access to the Core Infrastructure... 49 14.1. Port Security... 49 14.2. Access to the CLI... 49 14.3. Core AAA System... 51 14.4. Audit... 52 14.4.1 Logging... 52 14.5. Core Syslog System... 54 14.6. Security Monitoring... 54 14.7. SNMP... 55 14.8. NTP... 55 14.9. SFTP... 56 14.10. Miscellaneous... 56 14.10.1 Warning (Login) Banners... 56 14.11. Traceroute across the Core Network... 57 14.12. ACL Processing Optimisation... 57 14.13. Global Routing... 57 15. RADIUS... 58 15.1. RADIUS Requirement... 58 15.2. RADIUS Basics... 58 15.3. RADIUS Packets... 60 15.4. RADIUS Deployment... 60 15.5. RADIUS Shared Secret... 61 6 105 CLASSIFICATION: Public

15.6. RADIUS Billing... 62 16. Border Gateway... 64 16.1. Border Gateway (GRX) Security... 65 17. Security of Gom, Gn, Gch, Gi and Gp... 68 17.1. GGSN Board categories... 69 17.1.1 Gn Application board (GnA)... 70 17.1.2 Gn Router board (GnR)... 70 17.1.3 Node internal networks... 70 17.1.4 Node internal IP subnetwork... 70 17.1.5 Internal Gn network (IGn)... 70 17.2. Traffic over the Gn, Gp and Gom interfaces... 71 17.2.1 GTP... 71 17.2.2 DNS... 71 17.2.3 NTP... 71 17.2.4 HTTP... 71 17.2.5 SFTP... 72 17.2.6 TELNET... 72 17.2.7 SSH... 72 17.2.8 IPSec... 72 17.3. IP Addresses... 72 17.4. IGn network... 72 17.5. OM VIP... 73 17.6. GnR IGn IP addresses... 73 17.7. GTP VIP(s)... 73 17.8. Gn IPSec IP address... 74 17.9. GnR external IP addresses... 74 17.10. The GPRS Tunnelling Protocol (GTP)... 74 7 105 CLASSIFICATION: Public

17.11. The Signalling Plane... 75 17.12. Path Management messages... 75 17.13. Tunnel Management messages... 75 17.14. Location Management messages... 75 17.15. Mobility Management messages... 76 17.16. Transmission Plane... 76 17.17. Routing Protocol Security... 76 17.18. ROUTING PROTOCOLS... 76 17.18.1 DNS... 78 17.18.2 IPSec... 78 17.19. Security... 79 17.20. IP Packet Filters... 79 18. GTP Security... 80 19. MPLS BackBone... 80 20. About Mobile Network Security... 82 21. Conclusion... 83 Appendix 1... 86 8 105 CLASSIFICATION: Public

1. Introduction The scope of this document is to outline cellular network operator requirements on basic principles for Core network security architecture and to provide security requirements for core network elements. A central concept introduced in this specification is the notion of a security domain. The security domains are networks that are managed by a single administrative authority. Within a security domain the same level of security and usage of security services will be typical. Typically, security domains are be identified by resources that are required access various network elements. These resources are then segregated into security zones enforced by access control lists, authentication, firewall rules, operating systems or Network Elements (NEs) and security protocols. 1.1. General This document was produced as an action taken from a meeting with a telecommunication vendor where high level security issues were being discussed. The outcome of that meeting produced this document. This document therefore states generic security requirements for core network elements within GSM and 3G networks. 1.2 through 8.2 are taken from various RFC, ETSI and 3GPP documents. The content of Appendix 1 is directly taken from www.cisecurity.com 1.2. Protection at the network layer For IP based protocols, security shall be provided at the network layer. The security protocols to be used at the network layer are the IETF defined IPSec security protocols as specified in RFC-2401. 9 105 CLASSIFICATION: Public

1.3. Security for native IP based protocols The network domain control plane of an IP-network is sectioned into security domains and typically these coincide with compartmentalized zones. The zone between the security domains is protected by Security Gateways. These can be proxies, firewalls, routers or circuit level gateways. The Security Gateways are responsible for enforcing the security policy of a security domain towards other Security Gateways in the destination security domain. A Security Gateway may be defined for interaction towards all reachable security domain destinations or it may be defined for only a subset of the reachable destinations. The network domain security of an IP-network does not extend to the user plane (Over the Air Interfaces) but does extend as far as the BSS. This does however cover off the Gi VPN up to and including the Internet gateway of the PE firewall. A chained-tunnel/hub-and-spoke approach is used which facilitates hop-by-hop based security protection. All IP traffic shall pass through a Security Gateway before entering or leaving the security domain. 2. Security Domains 2.1. Security domains and interfaces The network domain of an IP-network shall be logically and physically divided into security domains. These control plane security domains may closely correspond to the Core Packet switched network up to and including the IP backbone (IPBB) and MPLS backbone (MPLSBB) and shall be logically separated by means of VPNs and compartmentalized by means of security gateways. 10 105 CLASSIFICATION: Public

3. Security Gateways Security Gateways are entities on the borders of the IP security domains and are used for securing native IP based protocols. The Security Gateways are defined to handle communication over various interfaces. All IP traffic shall pass through a Security Gateway before entering or leaving the security domain. Each security domain can have one or more Security Gateways. Each Security Gateway will be defined to handle IP traffic in or out of the security domain towards a well-defined set of reachable IP security domains. The number of Security Gateways in a security domain will depend on the need to differentiate between the externally reachable destinations, the need to balance the traffic load and to avoid single points of failure. The security gateways shall be responsible for enforcing security policies for interworking between networks. The security may include filtering policies and firewall functionality, access control lists appended to routers and switches, internode authentication and network and transport layer encryption. Security Gateways are responsible for all IP network operations (and therefore implicitly require security) and shall be physically secured. 4. Key Management and Distribution Architecture for IP Networks 4.1. Security services afforded to the protocols IPSec offers a set of security services, which is determined by the negotiated IPSec security associations (SA). That is, the IPSec SA defines which security protocol to be used, the mode and the endpoints of the SA. For IP networks the IPSec security protocol shall always be encapsulation (ESP) and authentication headers (AH). For IP-networks it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used. 11 105 CLASSIFICATION: Public

The security services provided to the IP network shall be: Data integrity Data origin authentication Anti-replay protection Confidentiality Limited protection against traffic flow analysis when confidentiality is applied 4.2. Security Association (SA) For IP-networks the key management and distribution between Security Gateways shall be handled by the protocol Internet Key Exchange (IKE) (RFC-2407, RFC-2408 and RFC-2409). The main purpose of IKE is to negotiate, establish and maintain Security Associations between parties that are to establish secure connections. The concept of a Security Association is central to IPSec and IKE. To secure typical, bi-directional or uni-directional communication between two or more hosts, or between two security gateways an ISAKMP (Internet Security Association Key Management Protocol) Security Associations and two IPSec Security Associations (one in each direction) are required. IPSec Security associations are uniquely defined by the following parameters: A Security Parameter Index (SPI) An IP Destination Address (this is the address of the ESP and AH SA endpoint) A security protocol identifier (this will always be the ESP protocol in IP) 12 105 CLASSIFICATION: Public

With regard to the use of IPSec security associations in the network domain control plane of IP-networks the following is noted: IP only requires support for tunnel mode IPSec SA IP only requires support for ESP and AH SA There is no need to be able to negotiate IPSec SA bundles since a single ESP and AH SA is sufficient to set up to protect traffic between the nodes The specification of IPSec SAs can be found in RFC-2401. ISAKMP Security associations are uniquely defined by the following parameters: Initiator's cookie Responder's cookie With regard to the use of ISAKMP security associations in the network domain control plane of IP-networks the following is noted: IP only requires support for ISAKMP SAs with pre-shared keys The specification of ISAKMP SAs can be found in RFC-2408. NOTE: The shortened key negotiation possibility known as "Aggressive Mode" should be disabled to avoid Private Secret Key (PSK) bruteforce attacks. "Aggressive Mode" is usually only used for IP enabled low bandwidth devices but is considered a security threat. 13 105 CLASSIFICATION: Public

4.3. Security Policy Database (SPD) The Security Policy Database (SPD) is a policy instrument to decide which security services are to be offered and in what fashion - in the Microsoft world, Active Directory is used as a mechanism to control access to network resources and stands to reason that SPD shall do the same. The SPD shall be consulted during processing of both inbound and outbound traffic. This also includes traffic that shall not/need not be protected by IPSec. In order to achieve this the SPD must have unique entries for both inbound and outbound traffic such that the SPD can discriminate among traffic that shall be protected by IPSec, that shall bypass IPSec or that shall be discarded by IPSec. The SPD plays a central role when defining security policies, both within the internal security domain and towards external security domains. The security policy towards external security domains will be subject to roaming agreements. 4.4. Security Association Database (SAD) The Security Association Database (SAD) contains parameters that are associated with the active security associations. Every SA must have an entry in the SAD. For outbound processing, a lookup in the SPD will point to an entry in the SAD. If an SPD entry does not point to an SA that is appropriate for the packet, a pseudotemporary SA shall be automatically created. The pseudo-temporary SA shall enforce the same security as other security associations. 5. Profiling of IPSec This section gives an overview of the features of IPSec that are used by IP. The overview given here defines a minimum set of features that must be supported. In particular, this minimum set of features is required for interworking purposes and constitutes a well-defined set of simplifications. The accumulated effect of the simplifications is quite significant in terms of reduced complexity. This is achieved without sacrificing security in any way. It shall be noted explicitly that the simplifications are specified for IP and that they may not necessarily be valid for other network constellations and usages. 14 105 CLASSIFICATION: Public

5.1. Support of ESP When IP is applied, only the ESP (RFC-2406) security protocol shall be used for all IP inter-domain control plane traffic. 5.2. Support of AH When IP is applied, only the AH (RFC-2402) security protocol shall be used for all IP inter-domain control plane traffic. 5.3. Support of tunnel mode Given that security gateways are an integral part of the IP architecture, tunnel mode shall be supported. For IP inter-domain communication, security gateways shall be used and consequently only tunnel mode (RFC-2401) is applicable for this case. 5.4. Support of ESP encryption transforms IPSec offers a fairly wide set of confidentiality transforms. The transforms that compliant IPSec implementations are required to support are the ESP_NULL and the ESP_DES transforms. However, the Data Encryption Standard (DES) transform is no longer considered to be sufficiently strong in terms of cryptographic strength. This is also noted by IESG in a note in RFC-2407 to the effect that the ESP_DES transform is likely to be deprecated as a mandatory transform in the near future. It is therefore explicitly noted that for use in IP, the ESP_DES transform shall not be used and instead it shall be mandatory to support the ESP_3DES transform. Support for the AES-CBC cipher algorithm (RFC-3602) is mandatory. It is noted that the AES- CBC key length for use with this specification shall be 128 bits. 15 105 CLASSIFICATION: Public

5.5 Support of ESP authentication transforms The transforms that compliant IPSec implementation is required to support are the ESP_NULL, the ESP_HMAC_MD5 and the ESP_HMAC_SHA-1 transforms. For IP traffic ESP shall always be used to provide integrity, data origin authentication, and anti-replay services, thus the ESP_NULL authentication algorithm is explicitly not allowed for use. ESP shall support ESP_HMAC_SHA-1 algorithm in IP. 5.6 Requirements on the construction of the above The following strengthening of the requirements on how to construct the above shall take precedence over the description given in the implementation note in RFC-2405 section 5, the description given in RFC-2451 section 3 and all other descriptions for the above. The above field shall be the same size as the block size of the cipher algorithm being used. The field shall be chosen at random, and shall be unpredictable to any party other than the originator. It is explicitly not allowed to construct the field from the encrypted data of the preceding encryption process. The common practice of constructing the field from the encrypted data of the preceding encryption process means that the field is disclosed before it is used. A predictable field exposes IPSec to certain attacks irrespective of the strength of the underlying cipher algorithm. The second bullet point forbids this practice in the context of IP. These requirements imply that the network elements must have a capability to generate random data. RFC-1750 gives guidelines for hardware and software pseudorandom number generators. 16 105 CLASSIFICATION: Public

6. Profiling of IKE The Internet Key Exchange protocol shall be used for negotiation of IPSec SAs. The following additional requirement on IKE is made mandatory for inter-security domain SA negotiations over interfaces. For IKE phase-1 (ISAKMP SA): The use of pre-shared secrets for authentication shall be supported Only Main Mode shall be used IP addresses and Fully Qualified Domain Names (FQDN) shall be supported for identification Support of 3DES in CBC mode shall be mandatory for confidentiality Support of AES in CBC mode (RFC-3602) shall be mandatory for confidentiality Support of SHA-1 shall be mandatory for integrity/message authentication Support of Diffie-Hellman group 2 shall be mandatory for Diffie-Hellman exchange. Phase-1 IKE SAs shall be persistent with respect to the IPSec SAs is derived from it. That is, IKE SAs shall have a lifetime for at least the same duration as does the derived IPSec SAs. The IPSec SAs should be re-keyed proactively, i.e. a new SA should be established before the old SA expires. The elapsed time between the new SA establishment and the cancellation of the old SA shall be sufficient to avoid losing any data being transmitted within the old SA. For IKE phase-2 (IPSec SA): 17 105 CLASSIFICATION: Public

Perfect Forward Secrecy is optional Only IP addresses or subnet identity types shall be mandatory address types Support of Notifications shall be mandatory Support of Diffie-Hellman group 2 shall be mandatory for Diffie-Hellman exchange Key Length and support of AES transform: Since the AES-CBC allows variable key lengths, the Key Length attribute must be specified in both a Phase 1 exchange and a Phase 2 exchange. It is noted that the key length for use with this specification shall be 128. 7. Security policy granularity The policy control granularity afforded by IP is determined by the degree of control with respect to the ESP Security Association between the Network elements (NE) or Security Gateways. The normal mode of operation is that only one ESP and one AH Security Association is used between any two NEs or Security Gateways, and therefore the security policy will be identical to all secured traffic passing between the NEs. This is consistent with the overall IP concept of security domains, which should have the same security policy in force for all traffic within the security domain. IPSec security policy enforcement for inter-security domain communication is a matter for the Security Gateways of the communicating security domains. 18 105 CLASSIFICATION: Public

8. Network Domain Security Key Management and Distribution Architecture for Native IP Based Protocols 8.1. Network domain security architecture outline The IP key management and distribution architecture is based on the IPSec IKE (RFC-2401, RFC-2407, RFC-2408 and RFC-2409) protocol. As described in the previous section a number of options available in the full IETF IPSec protocol suite have been considered to be unnecessary for IP. Furthermore, some features that are optional in IETF IPSec have been mandated for IP and lastly a few required features in IETF IPSec have been deprecated for use within IP scope. The compound effect of the design choices in how IPSec is utilised within the IP scope is that the IP key management and distribution architecture is quite simple and straightforward. The basic idea to the IP architecture is to provide hop-by-hop security. This is in accordance with the chained-tunnels or hub-and-spoke models of operation. The use of hop-by-hop security also makes it easy to operate separate security policies internally and towards other external security domains. The Security Gateways shall engage in direct communication with entities in other security domains for IP traffic. The Security Gateways will then establish and maintain IPSec secured ESP and AH Security Association in tunnel mode between security domains. Security Gateways shall maintain at least one IPSec tunnel available at all times to a particular peer Security Gateway. The Security Gateway will maintain logically separate SAD and SPD databases for each interface. The NE shall establish and maintain ESP and AH Security Associations as needed towards a Security Gateway or other NE within the same security domain. 19 105 CLASSIFICATION: Public

All IP traffic from a NE in one security domain towards a NE in a different security domain will be routed via a Security Gateway and will be afforded hop-by-hop security protection towards the final destination. A diagram describing how this is achieved is presented in reference 1. Ref.1 20 105 CLASSIFICATION: Public

8.2. Interface description The following interfaces are defined for protection of native IP based protocols: Security Gateway to Security Gateway (SGSG). The SGSG interface covers all IP traffic between security domains. On the SGSG interface, authentication and integrity protection is mandatory. ESP and AH shall be used for providing authentication, encryption and integrity protection. The Security Gateways shall use IKE to negotiate, establish and maintain a secure ESP tunnel between them. The tunnel is subsequently used for forwarding IP traffic between security domain A and security domain B. Inter-Security Gateway tunnels can be available at all times, but they can also be established as needed. The Security Gateway of security zone A (as represented above as SEG A) can be dedicated to only serve a certain subset of security domains that security domain A needs to communicate with. This will limit the number of SAs and tunnels that need to be maintained from an operational perspective. All security domains compliant with this specification shall operate on the SGSG-interface. The NESG interface is located between Security Gateways and NEs and between NEs within the same security domain. ESP AH and IKE shall implement. On the NESG interface, ESP and AH shall always be used with authentication, encryption and integrity protection. The ESP Security Association shall be used for all control plane traffic that needs security protection. The Security Association is subsequently used for exchange of IP traffic between the NEs. 9. Filtering routers and firewalls In order to strengthen the security for IP based networks, border gateways and access routers would normally use packet filtering strategies to prevent certain types of traffic to pass in or out of the network. Similarly, firewalls are used as an additional measure to prevent certain types of accesses towards the network. Simple filtering may be needed before the Security Gateway functionality. The filtering policy must allow key protocols to allow DNS and NTP etc to pass. This will include traffic over the SEG interface from IKE and IPSec ESP and AH in tunnel mode. Unsolicited traffic shall be rejected. 21 105 CLASSIFICATION: Public

This section of the document is separated into a number of sections covering off; Firewall controls, DMZ controls, Business continuity and planning, Audit controls and Network controls. 9.1. Firewall controls Configurations, policies and rules for firewalls must be documented. It must include what their purpose or function is. Policies, rules and the reason for firewall configurations must be known. In the event of failure, downtime may be increased as a result of the confusion. In addition, a change to a rule may adversely affect a business application. Only authorised administrative staff must be allowed access to firewall and management systems and logs. All users must have at least a login and password. Changes to firewalls by unskilled and unauthorised staff may result in corruption and extended downtime. Firewall authenticated sessions on the firewall must timeout (if supported) after a certain time. Users may leave their workstation unattended and unauthorised access could be gained if no timeout is used. Security patches or fixes for known weaknesses with firewall hardware, software and operating systems must be tested and installed as soon as they are available, proven and agreed by a change management process. Failure to implement security patches on a timely basis may increase the likelihood of the network being compromised. Any protocol, binary program, network service or rc script that is not necessary for the purpose of operation must be disabled on the firewall device and any platform in the DMZ, e.g., TFTP, Chargen, Echo and Finger, etc. This control ensures that all devices and platforms are security hardened to prevent illegal access. 22 105 CLASSIFICATION: Public

Connections initiated externally to an external facing firewall must be limited to Web (HTTP and HTTPS), Mail (SMTP) DNS lookups and zone transfer. This traffic must go to specific destination addresses, i.e., Web, Mail, etc, within a DMZ. All other ports must be blocked by default, i.e., a cleanup rule. A number of standard protocols have vulnerabilities that can be exploited to grab files, gain information or gain illegal access to systems. Hackers will port scan externally facing firewalls to identify ports to exploit. NO DNS based firewall objects or any other DNS reliant options can be used in the firewall configuration. Connections initiated internally to an internal facing firewall must be limited to allowed traffic only. This traffic must go to specific destination addresses, i.e., Gi, Gn, etc, within a specified VLAN. All other ports must be blocked by default. Connections initiated internally within the core network must be restricted to authorised traffic types. All traffic types which are restricted in-bound must also be restricted out-bound unless there is a good business reason for not doing so. Although traffic is uni-directional it may be configured to explicitly deny all outbound traffic unless specified. For example, if there is a rule restricting in-bound telnet then there should be an equivalent rule restricting out-bound telnet. Trojans may download a payload the gives an attacker access to the various systems within the core by exploiting outgoing connects, e.g., it may be possible to establish a covert channel over a port that allows outbound traffic. A cellular network operator should protect itself against possible litigation from the internal core network(s), backbone networks, radio network, VAS network, public Internet or corporate network. 23 105 CLASSIFICATION: Public

Internal IP addresses must be hidden from the outside world, e.g., DNS zone transfers and DNS UDP queries that would leak internal ip addresses must be prevented. Network Address translation must by used on the firewall or border router. Information about the network topology must not be leaked to third parties as it can be used for attacks, e.g., IP spoofing. If there are no users being authenticated on the firewall, only control connections from the firewall management station must be accepted. All other connections to firewall modules must be prevented by adding a stealth rule within the security policy. Packets must be dropped under this rule. A stealth rule should be placed as early as possible in the firewall policy. First defining all access that is allowed to/from the firewall and then denying (and logging) all traffic to/from firewall. The firewall must drop internal broadcast traffic on the core network by default and allow by defining the rules to allow. Allow rules must be created to permit internal broadcast traffic where required. In doing this, it shall reduce the amount of unrequired entries in the firewall logs and help to prevent overload. ICMP and UDP packets must not be accepted by Internet facing firewalls or at PE and CE routers and Border Gateways. ICMP is used by a utility called traceroute. Traceroute can be used by hackers to find Network Elements thus, exposing internal network elements. ICMP and UDP packets can be used for a number of Denial of Services (DoS) exploits and firewalls should be configured to disallow such attacks be default. CAUTION: Although dropping all incoming ICMP packets if not needed is a security best practice, it could however have a production impact on infrastructure. TCP based protocols that are sensitive to timeouts such as HTTP and SMTP need to be able to timeout properly to avoid problems such as sluggish web server responses, slow proxy and reverse proxy responses, to name a few. 24 105 CLASSIFICATION: Public

The following ICMP types and codes are the minimum courtesy of the proper functioning of TCP: ICMP type 3 Code 1 - Host Unreachable ICMP type 3 Code 3 Port Unreachable ICMP type 4 Source Quench ICMP type 11 Code 0 Time to Live Exceeded These should be allowed only with proper connection control on the amount of packets per timeframe coming from a specific source address. The firewall must prevent IP Spoofing across all internal and external interfaces. Spoofing is a method of making packets appear as if they originate from a communicating IP addresses. For example, a packet originating on the Internet and going to an internal network may be disguised as a local packet. Anti-spoofing features of a firewall ensure that ip addresses entering a system are valid. The firewall, router and intrusion detection system must prevent SYN flooding. A SYN flood initiated by an attacker can disable the target system. The firewall, router and intrusion detection system must prevent GTP attacks. A SYN flood initiated by an attacker can disable the target system. Simple Network Management system protocol (SNMP) must not be set to Any Community, Guessable Community or Public Community name on any firewalls or devices that are located on a vulnerable network or DMZ. The firewall must disallow SNMP requests to NEs that do not require SNMP traffic with a deny rule. SNMP must not be available from external networks to the core network, i.e., external to internal. 25 105 CLASSIFICATION: Public

In addition, NEs must support SNMP version 3 as encryption of the data is achieved. SNMP can be used by an attacker to obtain valuable information about the machine, such as information on network devices and current open connections, when SNMP uses default words, such as public or private, for the community name. If no community is specified, then the SNMP server responds to queries from any host. 9.2. DMZ controls Any servers or devices that are located on a DMZ implicit trust network must not use a predictable TCP sequence. If the TCP sequence is predictable, an attacker can send packets that are forged to appear to come from a trusted machine. Services such as telnet, ftp, rsh and rlogin may be compromised. The server or device can be security hardened by using an improved sequential generation with random variance in increment script. NFS must not be used on any servers or devices that are located on a DMZ or implicit trust network. NFS is the UNIX networking protocol that allows resources to be shared across the network. If it is mis-configured, attackers may be able to gain access to other network resources such as files. NIS must not be used on any servers or devices that are located on a DMZ implicit trust network. NIS is a naming service that allows resources to be easily added, deleted or relocated. An attacker who possesses the NIS domain name (often set up as a derivative of the public domain name, can steal information helpful in guessing passwords and gain unauthorised access. RPC must not be used on any servers or devices that are located on a DMZ implicit trust network. RPC allows one program to use the services of another program on a remote machine. If exploited, an intruder may be able to execute commands on a vulnerable system. 26 105 CLASSIFICATION: Public

Applications on hosts connected to the core network must not use the same ports as backdoor and remote control programs. These ports cannot be opened on the firewall as they are major security risk. Procedures detailing methods of recovery of the Firewalls must exist and be proven. This is an issue of integrity and availability. Detailed procedures help prevent failures due to incorrect methods being used. This is especially important where actions are required which are specific to a given Network element which may not be commonly known. System files on the firewall that contain policy, rule base, key, licence, object, user and configuration information must be documented and backed up. If the firewall is corrupted users must be able to re-install to the same patch level and security policy that was running before the event. If these files were lost there may be considerable downtime whilst the firewall is re-built. Firewalls that route transaction data must be clustered or mirrored to provide high availability. In the event of hardware failure there shall be no loss of service as traffic will seamlessly cutover over to the other firewall through stateful fail over technology. 9.3. Audit controls All users or groups of users that authenticate, at or via the firewall, to gain access to the Core Packet Switched network must have their access authorised. Authorised users should be granted access through the use of One Time Passwords (OTP) preferably integrated with Single Sign On (SSO). An account with a fixed password should be kept (in a sealed envelope in fire proof safe with limited human access) for in case the technology that facilitates remote user authentication fails. 27 105 CLASSIFICATION: Public

All accesses through a firewall to the Core Packet Switched network should be authorised by an independent, trusted party. Typically, access would be requested by the initiator. If automated, a ticketing system might manage the process for the initiator, with involvement from operations, management, an audit function and possibly other areas of an organisation. This information must be logged in a central repository that can easily be accessed by IT and Telecoms Operations teams, Security Operation Centres (SOCs), Security teams, management and Human Resources in line with relevant business policy. The information gathered by this process allows Security and Network Operations teams the ability to identify valid authorised users and it helps to ensure that the access permission allowed is removed when it is no longer required. Apart from transaction and broadcast traffic, all dropped and accepted connections must be logged. Connection attempts from unauthorised IP addresses must be rejected. The logging of this type of event is necessary so that it is possible to identify unauthorised attempts to connect or users having problems connecting. It would prove time consuming and meaningless for an Administrator to wade through sorting through volumes of irrelevant log files. 28 105 CLASSIFICATION: Public

The telecommunication operator s network must have a mechanism for detecting malicious or suspicious events and intrusions on the firewalls and the Core Packet Switched network. At a minimum this must include the following: Port scanning Successive multiple connections Syn and land attacks IP address spoofing Login failures Successive alerts Signature files for known vulnerabilities Consideration may also be given to marrying the IDS and IPS logs with a Fraud Management System. Information from suspicious activity can be used for investigation and firewall policy tuning. Configuring the firewall with these controls assists in hardening the network against attack and ensuring rules are accurate. Changes to production firewalls, including amendments or additions to security policies, must go through a change management procedure. To ensure that changes are authorised, tested and do not impact on any other systems. 29 105 CLASSIFICATION: Public

9.4. Network controls With the appropriate level of additional security (physical, environmental, procedural, technical), Virtual Private Networks can be used to guarantee data confidentiality, integrity and availability. VPNs or encrypted tunnels should not transverse the Core Packet Switched firewalls but VPN termination on the firewall. Virtual Private Networks (VPNs) allow a secure tunnel to be set-up for communicating with a host/application. Their use must be limited to where the data or transactions being transferred contain sensitive or value transactions. VPNs or encrypted tunnel functionality may be abused to tunnel unauthorised protocols or even viruses. Where the firewall software is installed on a host (rather than a hardware firewall), e.g., SunScreen, the operating system must be sufficiently hardened to such an extent to allow only requisite services. An attacker may be able to exploit services being run on the operating system, thus compromising the firewall. * Detailed Information on how to security harden a Cisco firewall is documented in Appendix 1 Configuration of Cisco PIX firewall 30 105 CLASSIFICATION: Public

10. IDS/IPS Deployment for GTP and IP Networks Consideration should be given to GTP aware IDS/IPS. Operators must determine whether GTP aware IDS/IPS can be installed and configured to correctly identify erroneous, irregular, fraudulent, malicious or other data contained within the GTP and encapsulated payload. In preparing this document and reviewing available technology, Mobile Network Security have not identified any one vendor with a satisfactory IPS/IDS solution for GTP. While vendors claim to have real-time IDS/IPS capabilities, Mobile Network Security have not seen evidence of this. It would be Mobile Network Security s recommendation for any cellular network operator to discuss in depth, and trail vendor products to determine their level of maturity and suitability for deployment into a GTP environment. Consideration should be given to deep packet inspection engines or firewalls with GTP processing capabilities. To help with host based integrity, an IDS must be used on all network elements to guard against unauthorised changes, unauthorised access and potentially erroneous or malicious known attack signatures. Similarly, a Unix security standard might instruct that all Unix Operating Systems have Tripwire installed before they are moved into production. While outside the heading of IDS/IPS Deployment for GTP and IP Networks, Mobile Network Security recommend GTP and in fact any telecommunication protocol is tested rigorously by security experts using fault injection, analysis, and security testing tools to determine the level of risk when engineering a cellular network with enhanced Packet Switched options. 31 105 CLASSIFICATION: Public

11. DNS Security The DNS plays a critical role in supporting the IP infrastructure by providing a distributed and fairly robust mechanism that resolves Internet host names into IP addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information pertaining to DNS Name Servers, Canonical Names, Mail Exchangers, etc. Unfortunately many security weaknesses surround IP and the protocols carried by IP. The DNS is not immune to these security weaknesses. The accuracy of the information contained within the DNS is vital to many aspects of IP based communications. The threats that surround the DNS are due in part to the lack of authenticity and integrity checking of the data held within the DNS and in part to other protocols that use host names as an access control mechanism. Therefore, the following are documented as security requirements for DNS within core PS networks. Typically, security policy might include the following characteristics: 11.1. Generic Requirements The DNSi infrastructure has no Internet communication by means of internal DNS servers. The DNSx infrastructure has external Internet communication by means of external DNS servers. The Telecommunication core network should utilise split DNS functionality as an internal DNS root and namespace, where all authority for DNS zones is internal. 32 105 CLASSIFICATION: Public

DNS servers that are configured with forwarders use internal DNS server IP addresses only. All DNS servers limit zone transfers to specified IP addresses. DNS servers are configured to listen on specified IP addresses. Secure cache against pollution is enabled on all DNS servers. Internal DNS servers are configured with root hints that point to the internal DNS servers hosting the root zone for internal namespace. Secure dynamic update is configured for all DNS zones except for the top-level and root zones, which do not allow dynamic updates at all. An access control list (ACL) is configured on the DNS Server service to allow only authorised users of the Gom to perform administrative tasks on DNS servers. An ACL is configured to allow only specific individuals to create, delete, or modify DNS zones. ACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data. 11.2. Internal DNS Security (DNSi) A requirement exists to eliminate any single point of failure. It should be noted that DNS redundancy cannot help if internal routing fails to access network services. DNS must be located in the same logical zone as the GGSN for security purposes. It is not best practice to allow DNS requests from network elements that are outside of a certain zone. 33 105 CLASSIFICATION: Public

All unauthorized access to DNS servers must be disallowed either through ACLs, VPN/VRF or by way of other restrictive measure. A secure dynamic update of zones and a list of DNS servers that are allowed to obtain a zone transfer must be limited to those that require DNS. All DNS events must be logged both remotely and locally. Monitoring DNS logs can help in detecting unauthorised modifications to DNS server or zone files. 11.3. External DNS Security (DNSx) The DNSx server must be logically placed on a separate zone than the zone identified for the DNSi server. Split DNS must be used. This reduces the risk of exposing private namespace, which can expose sensitive names and IP addresses to public Internet-based users and subscribers. It also increases performance because it decreases the number of resource records on the DNS server. In separate zones, i.e., London, Birmingham, etc., all GGSNs must resolve to their own DNSx server rather than relying on a central DNSx. This reduces the likelihood of GGSNs being subject to DNS based exploits. Common DNS exploits such as denial-of-service attacks would render the GGSN external resolution service useless in the event of a Denial of Service (or any other form of IP based attack). It would be possible for a GGSN to fail-over to a separate GGSN for DNS resolution purposes however this would require exceptional loading on the various GGSN interfaces. Where an outage occurs, a DNSx resolution may resolve to another DNSx in a logically separate zone. This is largely dependent upon operator policy and telecommunication vendor technology. 34 105 CLASSIFICATION: Public

All DNSx zone replication traffic must be secured through use of virtual private network (VPN) tunnels to hide the names and IP addresses from Internet-based users. Should the operator require and should sufficient hardware exist, the operator may request that Internet Protocol security (IPSec), rather than VPNs are used for DNSx zone replications. Configure firewalls to enforce packet filtering for UDP and TCP, port 53. Restrict the list of DNS servers that are allowed to initiate a zone transfer on the DNSx server. This must be configured for every DNSx in the Core network. All DNSx events must be logged both remotely and locally. Monitoring DNSx logs can help in detecting unauthorised modifications to DNSx server or zone files. Refer to your policy on DNS logging. The following diagram represents how Mobile Network Security believe DNS should be deployed in the Core PS network: 35 105 CLASSIFICATION: Public

Further information on DNS Security can be found at the following: http://www-08.nist.gov/publications/nistpubs/800-81/sp800-81.pdf Mobile Network Security recommend the following resources where practical information on DNS and DNS security can be found: RFC 4033, DNS Security Introduction and Requirements http://www.ietf.org/rfc/rfc4033.txt RFC 4034, Resource Records for the DNS Security Extensions http://www.ietf.org/rfc/rfc4034.txt RFC 4035, Personnel Modifications for the DNS Security Extensions: http://www.ietf.org/rfc/rfc4035.txt RFC 3833, Threat Analysis of the Domain Name System (DNS): http://www.ietf.org/rfc/rfc3833.txt RFC 2845, Secret Key Transaction Authentication for DNS (TSIG): http://www.ietf.org/rfc/rfc2845.txt RFC 3007, Secure Domain Name System (DNS) Dynamic Update: http://www.ietf.org/rfc/rfc3007.txt RFC 1035, Domain Names - Implementation and Specification: http://www.ietf.org/rfc/rfc1035.txt RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE): http://www.ietf.org/rfc/rfc2136.txt RFC 1034, Domain Names - Concepts and Facilities: http://www.ietf.org/rfc/rfc1034.txt RFC 2104, HMAC: Keyed-Hashing for Message Authentication: http://www.ietf.org/rfc/rfc2104.txt FIPS 198, The Keyed-Hash Message Authentication Code (HMAC): http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf RFC 4034, Resource Records for the DNS Security Extensions: http://www.ietf.org/rfc/rfc4034.txt RFC 1912, Common DNS Operational and Configuration Errors for more information: http://www.ietf.org/rfc/rfc1912.txt Bind: http://www.isc.org/index.pl?/sw/bind 36 105 CLASSIFICATION: Public

12. Core CS and Core PS Network Infrastructure Layer 2 and Layer 3 Security Requirements The purpose of this section is to list technical requirements that are security-related to the Core Circuit Switched (CS) and Core Packet Switched (PS) - referred to as the Core - in order to define router and switch configurations during low level design. This document is not intended to offer high level information such as a policy. This section is based on manufacturer s current best-practice taken from the normative references section. 12.1. Scope (example) The scope of this section covers typical network elements that form Core infrastructure. It is important to note that not every telecommunication vendor equipment is the same. Not all core networks within the cellular operator s network would necessarily require Cisco infrastructure. Mobile Network Security have worked on many core networks where Juniper products have been in use. Similarly, Mobile Network Security have seen instances where routing between core network islands is managed by servers rather than routers. However, for the purpose of this document, Mobile Network Security have used Cisco infrastructure as the example and example core network elements can be found in point format below: Cisco 7609 routers Cisco 12010 routers Core Provider Edge (PE) routers in core routing infrastructure Core Provider (P) routers in core routing infrastructure Cisco IP MPLS BackBone (IPMPLSBB) Layer 2 (L2) switching infrastructure 37 105 CLASSIFICATION: Public

E1 infrastructure Cisco PIX Firewalls Should you wish to learn more about securing other core network vendor technologies, please contact Mobile Network Security and we will be happy to talk through your requirements. Note: It is not the intention of this document to list security requirements for existing LANs or WANs under any transmission plane. 12.2. Release This version covers the requirements for the Core, principally the configuration of the routing infrastructure, firewalling operations and Operating System configuration. Security requirements for the connectivity of client networks should be listed in an update to this document when that information is made available by the telecommunication vendor. 12.3. References 12.3.1 ISP ESS Cisco ISP Essentials, version 2.9 Cisco. Ref: http://www.cisco.com 12.3.2 L3 VPN L3 MPLS/VPN Security Considerations, version 1.0, Cisco Ref: http://www.cisco.com 12.3.3 CISCO SECURITY Cisco Improving Security on Cisco Routers, Cisco Ref: http://www.cisco.com 12.3.4 SAFE LAYER2 Cisco SAFE Enterprise Layer 2 Addendum, Cisco Ref: http://www.cisco.com 12.3.5 VLAN BEST PRACTICE Cisco Virtual LAN Security Best Practices Cisco Ref: http://www.cisco.com 12.4. Technical Requirements 38 105 CLASSIFICATION: Public

Unless stated specifically in the text, the configuration described in this document shall be applied to all Core infrastructure. By default, routing configurations are disabled, however the services offered by Cisco devices should be explicitly disabled given the default settings can change across different IOS versions/trains. In reference to Operating System configuration, out of the box configuration is by default highly insecure and therefore adherence to the security standards and guidelines for Unix Operating Systems must be strictly followed. 12.5. Hardening the Core These requirements describe features enabled/disabled in order for the Core infrastructure to maintain a consistently secure operation. One of the prime requirements of the Core is that it is available and able to provide a transport for services that are dependent upon the Core for delivery. Providing security for the networks that are responsible for delivering those services via the Core is out of scope. 12.6. Removal of Services Cisco Routers Following the general security principle that unrequired protocols and services shall be disabled, the following shall be globally disabled throughout the Core: Finger daemon service no service finger Chargen daemon service no service udp-small-servers Echo daemon service no service udp-small-servers HTTP Server service no ip http server BOOTP Server service no ip bootp server 39 105 CLASSIFICATION: Public