This section covers OAM servers and - as an example of user application servers – web proxies.
4.4.1 OAM Servers
Operation, Administration and Maintenance of a mobile network is typically a highly complex task, as a mobile network is a highly complex system of a multitude of network elements of
various different types. Rather than a single network element management system, mostly a variety of different OAM servers is required, many of which are dedicated to perform OAM functions for a specific type of network elements only. Configuration management, fault management, performance management etc. may be combined for a set of network elements on the same management platform, but in addition, specific servers may be needed for tasks such as logging or backup and restore.
Typically, OAM servers are deployed on specific sites, called Operation and Maintenance Centers (OMCs), which are connected to all the different network sites and allow remote OAM for the complete network. This is mostly complemented by locally deployed OAM devices that may be needed for specific tasks like initial installation of systems.
Besides the interconnection to the managed network elements, OAM servers may also be interconnected to higher level management systems, like business support systems. In the context of the present risk assessment, such interconnectivity is not taken into account, however.
It is recommended security practice for mobile networks to provide dedicated network resources for the OAM network. In the core area, the OAM network may even be physically separated from the user and control plane networks. On the backhauling link towards the (e)NBs or 2G base stations, this is mostly not feasible, so there is only a logical separation of OAM traffic and other traffic types.
It is also highly recommended to use cryptographical protection of OAM traffic end-to-end between OAM servers and network elements. Many protocols are available for this, on different network layers, like IPsec, TLS, SSH, SFTP, HTTPS, SNMPv3 etc. However, there is a variety of different management protocols, and a variety of network elements, including
"legacy" equipment that has been developed years ago, when security was not yet perceived as an essential property by many equipment providers and operators. Moreover, errors in the implementation of secure protocols may be exploited to break the protection. Therefore, it must NOT be assumed that all management protocols are truly secured.
Another recommended practice is to protect OMCs by additional firewalls against the network elements, to prevent that a network element that has been compromised by an attacker subsequently successfully attacks OAM servers. However, it cannot be assumed that such protection covers all possible connection and protocols and that it is, where available, flawless.
The impact of successful attacks on OAM network elements, in particular compromise, can be devastating. The network operator may lose control not only over single network elements, but over large parts of the network.
The following table shows the assessment resulting from these considerations.
Threats Likelihood
Vulnerab.
Factor Impact Risk
T1 Flooding an interface 1 2 4 8
T2 Crashing a network element 1 2 4 8
T3 Eavesdropping 3 2 3 18
T4 Unauthorized data access 3 2 3 18
T5 Traffic modification 1 2 5 10
T6 Data modification on a
network element 2 2 5 20
T7 Compromise via
implementation flaw 3 2 5 30
T8 Compromise via
management interface 3 2 - 3 5 30 - 45
T9 Malicious insider 1 - 2 2 - 4 5 10 - 40
T10 Theft of service 2 2 5 20
Table 25: Risk Assessment for OAM Servers
4.4.2 Web Proxies
A number of operators have implemented HTTP ("web") proxies as part of their 3G/4G infrastructure. Those proxies mainly serve to cache HTTP-based content that is frequently accessed (by different users) and thereby preserve bandwidth needed to get this content from the Internet while at the same moment contribute to a better user experience by fulfilling requests (for the cached content) in a faster way. At times and depending on the exact service the operator provides (e.g. some offer "network based malware protection", usually for an extra fee) the proxies constitute centralized points of storage where scanning for malware can be performed.
T1 Flooding an interface
Attacking a web proxy serving user requests would mostly cause bad user experience (and - maybe - potentially subsequent loss of customers to the operator) but would not cause direct impact on the operator's core, revenue-generating services (that is still voice [services] – although this may change in the future – maybe even in the near future). Hence DoS attacks against this type of devices can rarely be observed which leads to a likelihood estimate of
"2". Given the long existence of HTTP proxies in various networks both the underlying OSs (usually Linux or FreeBSD) and the application part of these components usually can cope well with high packet load (hence vulnerability factor estimated as "2"). In case of a successful attack no confidentiality or integrity violations would occur and most of the operator's core services would be not impacted, which gives an impact estimate of "2".
T2 Crashing a network element via a protocol or application implementation flaw The same rationale as for T1 applies here. The likelihood is estimated as "2", the vulnerability as "2" (as the IP stacks and HTTP processing parts can be considered to be mature and stable) and the impact as "2".
T3 Eavesdropping
Eavesdropping on cached (and subsequently delivered) HTTP traffic would possibly not be performed in the environment of the web proxies but in other parts of the networks that are in closer proximity to the user(s) to eavesdrop on. Therefore these attacks rarely occur in current operator networks (likelihood: "2"). Large parts of the traffic-in-question are unencrypted, but on the other hand an attacker would need access to the traffic path of the proxies which can be considered unlikely (overall estimation of the vulnerability factor "2"). As HTTP traffic served to users usually is public anyway the impact would be small ("2") as well.
T4 Unauthorized access to sensitive data on a network element via leakage
The vast majority of data processed and delivered by the web proxies is public anyway so there's only a very small ("1") likelihood an attacker will try to get hold of the data stored on web proxies. Under certain circumstances (e.g. knowing an exact path or directory) it might be possible to retrieve some data as in general web proxies do not implement strict access controls. This leads to an estimate of the vulnerability factor of "3". Given the nature of the data the impact would be very small ("1").
T5 Traffic modification
Modifying parts of the outbound network traffic of a web proxy (that is the traffic leaving the proxy, potentially destined to users) might serve as an attack vector for large scale malware spread (e.g. if an attacker can modify frequently accessed files like an update of a popular desktop component). This type of attack does actually happen in operator environments (likelihood "3"), however for the attack to be successful an attacker would need access to the traffic path of the proxies (see also discussion of T3). It should be noted that there's no integrity protection in place for large parts of HTTP based traffic (namely executables) which leads to an overall vulnerability factor of "3".
The impact could be severe, not so much for the operator itself but potentially for a large number of users (whose systems/terminals, being parts of a then-botnet, might in turn attack the operator). Therefore, the impact is rated as "4".
T6 Data modification on a network element
This threat can be compared to T5 "Traffic modification". We estimate the difficulty of getting ("write") access to a web proxy to be roughly the same as to get into the traffic path so overall the same values can be applied.
T7 Compromise of a network element via a protocol or application implement. flaw In the last years only few vulnerabilities leading to a system compromise have been discovered in current TCP/IP stacks and HTTP processing entities (a notable exception might be the so-called Sockstress vulnerabilities disclosed in 2009). The likelihood of associated attacks is thus estimated medium ("3") taking into account this type of attack still happens, albeit not too often. While the web proxies' IP stacks and HTTP processing parts can be considered to be mature and stable those systems are publicly reachable, at least to some degree (attacker might initiate a data connection from a terminal, fetching data from an attacker-controlled system which is then processed by an intermediate web proxy). This gives an overall vulnerability factor of "3". A successful compromise might not directly impact revenue-generating services of the operator but it would enable an attacker to modify the delivered data (see above) which leads to an impact estimate of "4".
T8 Compromise of a network element via a management interface
As web proxies deployed in operator environments usually run common-of-the-shelf operating systems (mostly Linux or FreeBSD) they are managed with the associated mechanisms (e.g. by SSH) and according to widely available Best Practices, including (IP-) restricted management access. Certainly attacker try to compromise these systems (likelihood "3"), however given the overall operational maturity they rarely succeed (hence vulnerability factor "2"). If successful the same considerations as above in the section on T7 apply (impact "4").
T9 Malicious insider
Probably a malicious insider would go for other goals and targets than web proxies (e.g. will perform billing fraud or redirection by LI interfaces [see so-called Athens affair] or sth.).
Therefore we estimate a very small ("1") likelihood for most operator environments with regard to this asset. Still it should be noted that due to the underlying operating systems' architectures (with usually insufficient auditing and logging mechanisms) such systems are vulnerable to malicious insider attacks (therefore vulnerability factor rated as high, "4"). As for the impact the same considerations as above in the section on T7 apply (impact "4").
T10 Theft of service
Usually web proxies are not attacked by attackers going after theft of service. Those attackers go after weakly protected entry points (VoIP Gateways etc.). The likelihood for this asset is thus estimated to be very small ("1"). The vulnerability factor is considered to be very small as well as web proxies usually cannot be abused for this goal. Usually revenue-generating services will not be affected which gives an impact estimate of "2".
The following table shows the assessment resulting from the above considerations.
Threats Likelihood
Vulnerab.
Factor Impact Risk
T1 Flooding an interface 2 2 2 8
T2 Crashing a network element 2 2 3 12
T3 Eavesdropping 2 2 2 8
T4 Unauthorized data access 1 3 1 3
T5 Traffic modification 3 3 4 36
T6 Data modification on a
network element 3 3 4 36
T7 Compromise via
implementation flaw 3 3 4 36
T8 Compromise via
management interface 3 2 4 24
T9 Malicious insider 1 4 4 16
T10 Theft of service 1 1 2 2
Table 26: Risk Assessment for Web Proxies