security architectures for mobile networks · to administer security centrally. ericsson is thus...

14
Goals and strategy Ericsson understands that to fulfill operator requirements for flexible and secure solu- tions that involve its products, it must pro- vide technical features that help operators with deterrence, prevention and protection, detection, response, and recovery. Security should be viewed as a process and not a state (Figure 1). It is about applying fit-to purpose, cost-effective mechanisms at each point in time throughout the process. A good vendor-operator relationship com- pletes the process with operations feedback from the system, thereby refining and fur- ther “hardening” the system. The process must also include operator assistance and service to subscribers—that is, the process must help operators and subscribers to maintain security and safeguard privacy. Ericsson’s approach to security is to build on a strong set of basic security features and inherently secure products that help opera- tors to lower their • capital expenditures (CAPEX)—that is, fewer dedicated security nodes are need- ed to protect the network; and • operating expenses (OPEX)—that is, greater product security reduces the need for administrative actions. Controlling access is an especially important part of Ericsson’s strategy. As security is pushed out to network endpoints, the nodes in access networks will be employed to con- trol access (which includes authentication, authorization and accounting). Notwith- standing, operators must retain the ability to administer security centrally. Ericsson is thus working to give operators better man- agement of nodes in access networks. 68 Ericsson Review No. 2, 2004 Security architectures for mobile networks Dirk Eschenbrücher, Johan Mellberg, Simo Niklander, Mats Näslund, Patrik Palm and Bengt Sahlin Security is a growing issue for carriers and operators. In particular, they are concerned about protecting network infrastructure. Ericsson shares these concerns and is putting great emphasis on secure products and security features. A holistic perspective is needed for planning the security services and functionality to be implemented in nodes, subnetworks, and at the net- work level. Decisions affecting security services and functionality need to based on a coherent, well-defined security architecture. The day is gone when vendors and standards could dictate the environ- ment for deploying the mobile network infrastructure and associated products. Today’s solutions and products must be flexible enough for use outside a reference network and resilient and extensible enough for use without external security appliances. Simple security checkpoints, such as firewalls, no longer suffice. As applications become more complex, general vulnerability to attacks also increases. A defense-in-depth strategy is thus needed, putting security features in each and every node. These features can be complemented with security functionality at site and network levels. While we acknowledge the importance of physical security, fraud detection, and management, the focus of this article is on logical network security. In addition, although this article primarily deals with GSM and WCDMA, the principles of security architecture presented here apply equally well to other cellular networks, such as CDMA. The authors describe Ericsson’s security architecture for GSM and WCDMA mobile networks. This architecture is based on security princi- ples mandated by standards and experience. Moreover, it is influenced by policies that regulate security, and by vulnerability audits of the mobile infrastructure. The authors also describe security services and functionali- ty, and how low-level mechanisms can be applied to make the mobile net- work infrastructure more secure. They cite examples from Ericsson’s product portfolio, including the security solution designed in the Mobile- PBN reference network. Figure 1 The security process. 1 Deter Protect Detect Respond Recover

Upload: others

Post on 20-Nov-2019

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Goals and strategy

Ericsson understands that to fulfill operatorrequirements for flexible and secure solu-tions that involve its products, it must pro-vide technical features that help operatorswith deterrence, prevention and protection,detection, response, and recovery.

Security should be viewed as a process andnot a state (Figure 1). It is about applyingfit-to purpose, cost-effective mechanisms ateach point in time throughout the process.A good vendor-operator relationship com-pletes the process with operations feedbackfrom the system, thereby refining and fur-ther “hardening” the system. The processmust also include operator assistance andservice to subscribers—that is, the processmust help operators and subscribers tomaintain security and safeguard privacy.

Ericsson’s approach to security is to buildon a strong set of basic security features andinherently secure products that help opera-tors to lower their• capital expenditures (CAPEX)—that is,

fewer dedicated security nodes are need-ed to protect the network; and

• operating expenses (OPEX)—that is,greater product security reduces the needfor administrative actions.

Controlling access is an especially importantpart of Ericsson’s strategy. As security ispushed out to network endpoints, the nodesin access networks will be employed to con-trol access (which includes authentication,authorization and accounting). Notwith-standing, operators must retain the abilityto administer security centrally. Ericsson isthus working to give operators better man-agement of nodes in access networks.

68 Ericsson Review No. 2, 2004

Security architectures for mobile networks Dirk Eschenbrücher, Johan Mellberg, Simo Niklander, Mats Näslund, Patrik Palm and Bengt Sahlin

Security is a growing issue for carriers and operators. In particular, theyare concerned about protecting network infrastructure. Ericsson sharesthese concerns and is putting great emphasis on secure products andsecurity features.

A holistic perspective is needed for planning the security services andfunctionality to be implemented in nodes, subnetworks, and at the net-work level. Decisions affecting security services and functionality need tobased on a coherent, well-defined security architecture.

The day is gone when vendors and standards could dictate the environ-ment for deploying the mobile network infrastructure and associatedproducts. Today’s solutions and products must be flexible enough for useoutside a reference network and resilient and extensible enough for usewithout external security appliances.

Simple security checkpoints, such as firewalls, no longer suffice. Asapplications become more complex, general vulnerability to attacks alsoincreases. A defense-in-depth strategy is thus needed, putting securityfeatures in each and every node. These features can be complementedwith security functionality at site and network levels.

While we acknowledge the importance of physical security, frauddetection, and management, the focus of this article is on logical networksecurity. In addition, although this article primarily deals with GSM andWCDMA, the principles of security architecture presented here applyequally well to other cellular networks, such as CDMA.

The authors describe Ericsson’s security architecture for GSM andWCDMA mobile networks. This architecture is based on security princi-ples mandated by standards and experience. Moreover, it is influenced bypolicies that regulate security, and by vulnerability audits of the mobileinfrastructure. The authors also describe security services and functionali-ty, and how low-level mechanisms can be applied to make the mobile net-work infrastructure more secure. They cite examples from Ericsson’sproduct portfolio, including the security solution designed in the Mobile-PBN reference network.

Figure 1The security process.1

Deter Protect Detect Respond Recover

Page 2: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 69

Ericsson is also constantly improvingprocesses surrounding software develop-ment to make operating systems and appli-cations more secure. Through careful selec-tion of platforms and software, Ericsson en-sures that each product is delivered fit-to-purpose (this is also commonly referred toas hardening).

BackgroundIt has been said that there are two main ap-proaches to avoiding exploitable weakness-es in system design: • one can make the system so complex that

it has no obvious weakness; or • one can make the system so simple that it

is obvious it has no weakness. Ericsson is a strong adherent of the latter

approach—simplicity. But where telecom-munications network design is concerned itis impossible to entirely circumvent complexity—without complexity, onecould not guarantee backward compatibili-ty, multi-access, multi-service, and multi-ple platform support. Notwithstanding, un-less great care is exercised, one ends up witha patchwork of unrelated management andsecurity solutions.

The ideal solution to avoiding complexi-ty-related security flaws is complete systemredesign. If researchers and engineers wereallowed to start over from scratch, theycould create a simple system that operatorscould use to assess • the security of each independent compo-

nent; and• how each component interacts with other

components. In the real world, however, this is an unre-alistic ideal due to requirements put on theupper bound of design, maintenance costs,and practical system usability. Besides, asstated above, security is a process, not a state.Therefore it is impossible to fit every secu-rity aspect into the design phase. And let’snot forget proper life-cycle management.

Notwithstanding, it is possible to designa secure solution that can be managed at rea-sonable cost. But doing so successfully re-quires broad competence—for example,knowledge of the telecommunications busi-ness, end-user requirements, and an under-standing of the impact of regulatory aspects,as well as technical expertise in operatingsystems, protocol design, and cryptography.With all this complexity, what operatorsneed are a conceptual model for security inthe network and a sound, systematic ap-proach to threat-and-risk analyses.

Security in mobilenetworksThis article builds on the scenario of a typ-ical third-generation public land mobilenetwork (PLMN) whose services and accessroughly correspond to that defined by 3GPPRelease 6.

Mobile network evolution and threatsUp to and including second-generation mo-bile telephony, operators largely based mo-bile network security on security by obscu-rity—that is, • they were secretive about the crypto-

graphic algorithms they used; • they used proprietary hardware platforms

and operating systems;

2G Second-generation mobile tele-phony

3DES Triple data encryption standard3G Third-generation mobile

telephony3GPP Third-generation Partnership

ProjectAES Advanced encryption standardAKA Authentication and key agreementB3G Beyond 3GBICC Bearer independent call controlCAPEX Capital expenditureCC Common criteriaCORBA Common object request broker

architectureCRM Customer relationship manage-

mentCS Circuit-switchedDNS Domain name serverDRM Digital rights managementESP IP encapsulating security

payloadFCAPS Fault, configuration, accounting,

performance, and security man-agement

FW FirewallGPRS General packet radio serviceGRE Generic routing encapsulationGSM Global system for mobile com-

municationGSN GPRS support nodeHIDS Host-based IDSHMAC Keyed-hashing for message

authentication HTTP Hypertext transport protocolIDS Intrusion detection systemIETF Internet Engineering Task Force

IP Internet protocolIPsec IP security protocolISUP ISDN user partLAN Local area networkMD5 Message digest 5MGW Media gatewayMPLS Multiprotocol label switchingMSC Mobile switching centerO&M Operation and maintenanceOPEX Operating expenseOSI Open Systems InterconnectionPAN Personal area networkPEP Policy enforcement pointPIN Personal information numberPLMN Public land mobile networkRBAC Role-based access controlSBT Secure backbone tunnelSCLI Secure command line interfaceSFTP Secure file transfer protocolSHA Secure hash algorithmSIM Subscriber identity moduleSIP Session initiation protocolSNMP Simple network management

protocolSSH Secure shellSSL Secure sockets layerTCAP Transaction capabilities applica-

tion partTLS Transport layer securityUMTS Universal mobile telecommunica-

tions standardUSIM UMTS SIMVLAN Virtual LAN VPN Virtual private networkWCDMA Wideband code-division multiple

accessWLAN Wireless LAN

BOX A, TERMS AND ABBREVIATIONS

Page 3: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

• their protocols were practically unknownoutside the telecommunications sector;and

• their networks were separate from thepublic internet.

Today, however, all this is rapidly chang-ing. Experience has shown that proprietarysecurity solutions eventually “leak” andsoon after they break. Cost and interoper-ability with the public internet are driversof greater openness. For instance, most oftoday’s protocols are based on IP, and oper-ators are deploying more and more openplatforms (including software). Although agreater degree of openness decreases the riskof unpleasant surprises (unknown vulnera-bilities), it also increases the risk that knownvulnerabilities can and will be exploited.Openness is thus a two-edged sword. Togive the upsides a chance to bear fruit, wemust provide cost-effective, fit-to-purposesecurity measures that guard against thepossible downsides. Failure to recognize thisfact could be fatal to vendor or operator busi-ness, because in essence, it means failure toprovide service availability and end-userprivacy.

With traditional vertical services, such ascircuit-switched voice, end-users need onlyrely on a single operator who has completecontrol. But with the rise of multi-accessand multi-service networks, end-users mustrely on operator, access provider and serviceprovider. This, in turn, affects the securitysolutions used. End-users, for example,might be asked to authenticate themselvesfor every access and service they want to use.This is inconvenient at best, and a securitynightmare at worst (many end-users tend touse the same user name and password overand over).

At the technical level, some operators ofthird-generation services want to augmenttheir offering with WLAN hot-spot access.We remind the reader, however, that theWLAN access security architecture was developed using a trust model for corporateaccess (behind locked doors) and not for public access deployment.

Finally, an extremely important aspect toconsider is end-user expectation of security.Most end-users trust operators to handle circuit-switched voice services, but whatabout new services? What level of securitydo end-users expect (implicitly or explicit-ly) when they use chat, gaming, or e-com-merce services? Operators who do not un-derstand end-user requirements for securityand privacy run the risk of losing subscribers

who feel unsafe or who have unpleasant ex-periences after having used a service. On theother hand, excessive security might alsohave a dampening effect due to inconve-nience. Indeed, an odd quality of security isthat it is most effective when end-users senseneither its absence nor its presence.

StandardsStandardization is needed to ensure inter-operability. Open, scrutinized security stan-dards contribute to greater confidence thanproprietary solutions. At the same time,there is a need to uphold competitive posi-tions. In this respect, security-related stan-dardization is being driven by the same fac-tors as general-purpose standardization.

Apart from ensuring interoperability, themain goal of standardized security solutionsshould be to guarantee secure features or ser-vices. One must also maintain the high-levelview of security services to ensure that se-curity features at different levels and in dif-ferent systems or services can fit together.This implies a need for coordination be-tween standardization organizations, to ensure that the overall solution provides adequate security, and the components ofthe solution complement one another.

The most important standardization bod-ies for mobile network security are 3GPPand IETF. At the application level, stan-dards set in OMA and Liberty Alliance arealso very influential.

Structured approach tosecurity

The many facets of securityGiven the level of complexity in today’s mo-bile networks, operators, vendors and man-ufacturers need some way of modeling them.Likewise, the models they use must allowoperators to study security—for example, byallowing them to break the network downinto smaller, more manageable components.Likewise, a common language is needed fordiscussing security.

Identifying needed security services andfunctions

Security solution development begins withthreat-and-risk analysis. Proceeding from afunctional description (specification and as-sumption of logical and physical properties)of the system, one identifies conceivablethreats (Figure 2). Next, one estimates theprobability of these threats and associated

70 Ericsson Review No. 2, 2004

Page 4: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 71

financial risks. The risks are then groupedinto categories such as • must be minimized or eliminated;• should be minimized or eliminated; and • acceptable. This information enables decision-makersto capture requirements and to specify theimplementation of security services andfunctions.

Ericsson’s reference architecture In summary, to provide adequate security,one must be able to model the mobile net-work and analyze threats to assets. Ericsson’sthree-plane architecture provides a usefuland simple way of capturing relevant infor-mation (Figure 3).

Security planes

Because there are threats to assets in each ofthe three architectural planes, security ser-vices must be applied in each plane to mit-igate them.

Mobile networks should be designed in away that isolates incidents on any given se-curity plane. This makes it possible to dif-

ferentiate between security concerns and toaddress each independently. Although thesecurity planes are isolated, they can com-municate with one another by means of pol-icy enforcement points (PEP), which deployaccess control. If necessary, the securityplanes can be broken down into sub-planes.Ordinarily, firewalls serve as PEPs for secu-rity planes.

The end-user security plane manages sub-scriber access and use of the serviceprovider's network. It also represents actu-al end-user data flows.

The signaling-and-control security planeprotects activities that enable efficient de-livery of information, services and applica-tions across the network.

The O&M security plane protects O&Mfunctions of the network elements, charg-ing functions, transmission facilities, datacenters, and back-office systems (opera-tions support systems, business supportsystems, customer care systems). It alsosupports fault-, configuration-, account-ing-, performance-, and security-management (FCAPS) functions.

Systemdocumentation

1

2

4

3

5

6

7

8

Define user Define assets

Identify attackers, theirskills, motivationand rescources

Threat Workshop

Legal or policyrequirements

Understand the system

Document system assumptions and trust model(to limit the scope)

Risk assessment Work Shop

Deifine secutrity objectives

Define requirements based on result from risk Workshop

Gap analysis and vulnerability identification

Give recommendations

Identify keypersonel

Figure 2Threat-and-risk analysis.

Page 5: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Common technologies for separating se-curity planes are physical and logical sepa-ration—for instance, firewalls (FW), virtu-al private networks (VPN), multiprotocollabel switching (MPLS), virtual LANs(VLAN) and generic routing encapsulation(GRE).

Security domains

A security domain is a part of a network thatshares a security policy issued by a single ad-ministrative authority. This is not shown inFigure 3 because the division into domains

is dependent on external requirements de-rived from the network architecture andbusiness models. Note that a single opera-tor network can be divided into several se-curity domains.

Security layers

Each security plane has been divided intothree security layers that identify where se-curity needs to be addressed by providing asequential perspective of network security.This layered defense strategy acknowledgesthat each layer has different security threats

72 Ericsson Review No. 2, 2004

7 - Application

6 - Presentation

5 - Session

4 - Transport

3 - Network

2 - Data link

1 - Physical

Applicationsecuritylayer

Security layers OSI referencelayers

Assets Threat Countermeasure

Application dataand SW

- Virus infections- False data- Malicious programs- Unauthorized users- File corruption

- Corrupted router tables- Denial of services- Interception of data

- Electronic attack- Relays destroyed

- Virus protection- System access control- Certificates- Application layer GW- Deep inspection FW- SSH- SNMPv3

- IP sec VPN- SSL/TLS- Stateful inspection FW

- Secure perimeters- Limited administrators- Role based access control- L2 VPN/VLAN- MAC filtering

Routing, addressing anddata

Switching, communications,wire, computerworkstations

Networkservicessecuritylayer

Infrastructuresecuritylayer

Figure 4Layered defense strategy.

End-usersecurity plane

Security servicesSeparate security planes

Au

the

nti

ca

tio

n

Ac

co

un

tab

ilit

y

Au

tho

riz

ati

on

Av

ail

ab

ilit

y

Co

nfi

de

nti

ali

ty

Inte

gri

ty

No

n-r

ep

ud

iati

on

Pri

va

cy

Security polices and principles

Signaling and controlsecurity plane

O&M security plane

Application security layerNetwork services security layer

Infrastructure security layer

Application security layerNetwork services security layer

Infrastructure security layer

Application security layerNetwork services security layer

Infrastructure security layer

Threats

Disclosure

Modification

Destruction/loss

Interruption

Unauthorized access

Attacks

Figure 3Reference model for security architecture.

Page 6: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 73

and ensures that solutions can be deployedin each OSI reference layer (Figure 4).

The infrastructure security layer consistsof the network transmission facilities andthe individual network elements protectedby the security services. It represents thefundamental building blocks of networks,their services and applications. Examples ofcomponents that belong to the infrastruc-ture security layer are individual routers,switches and servers, and the communica-tion links between them.

The network services security layer ad-dresses network services to end-users. Theserange from basic transport and connectivi-ty to the service enablers that are necessaryfor providing network access. The networkservices security layer protects serviceproviders and their customers—for exam-ple, by blocking malicious attempts to keepservice providers from offering network ser-vices (denial of service) or attempts to dis-rupt service to individual customers.

The focus of the application security layeris on network-based applications. These ap-plications, which are enabled by networkservices, include • traditional voice applications (for exam-

ple, ISUP and TCAP protocols and ap-plication services that use these proto-cols);

• multimedia applications (for instance,BICC, SIP and H.323 protocols and ap-plication services that use these proto-cols); and

• high-end applications, such as customerrelationship management (CRM), elec-tronic and mobile-commerce, network-based training, and video collaboration.

There are four main targets of security at-tacks in the application security layer: theend-user (or application user), the applica-tion provider, the middleware provided bythird-party integrators (web-hosting ser-vices), and the service provider.

The last column in Figure 4, which showsthe relationship between security and OSIlayers, lists mitigation mechanisms em-ployed against different threats in the lay-ers. These mechanisms protect stored dataand data in transit.

Security service

Security service is a fundamental concept inevery security architecture. The servicemeets the security objectives identified bythe threat-and-risk analysis. Security ser-vices are implemented by means of securityfunctions and mechanisms. A confidentiality

protection security service, for example,might be implemented using an IP layer en-cryption security function. This, in turn,might make use of the AES encryptionmechanism. At each intersection point ofthe security plane or layer, every security ser-vice must be evaluated in terms of • authentication;• authorization; • accountability;• availability;• confidentiality;• integrity;• non-repudiation; and • privacy.Authentication is used to confirm the iden-tities of communicating entities (person, de-vice, service or application) and ensures thatthe entities are not masquerading or at-tempting unauthorized replay of previouscommunication.

Authorization protects against unautho-rized use of network resources. Access con-trol ensures that solely authorized personnelor devices have access to network elements,stored information, information flows, ser-vices and applications. Role-based accesscontrol (RBAC) is commonly used to regu-late authorization in O&M. Similarly, end-user authorization is used to control acces-sibility to services.

Accountability procedures are used tokeep track of who does what and when. Ac-countability functions track the usage of se-curity services and network resources. Ac-countability logs facilitate recovery andfault discovery.

Availability means that authorized enti-ties have access to network elements, storedinformation, information flows, services andapplications regardless of incidents that af-fect the network. Common techniques forensuring availability are redundancy,perimeter protection and node hardening.

Confidentiality entails protecting datafrom unauthorized disclosure. Data confi-dentiality ensures that data content cannot beunderstood by unauthorized entities. En-cryption (for example, 3DES and AES), ac-cess control lists, and file permissions are fre-quently used to protect data confidentiality.

Integrity ensures the correctness or accu-racy of data—the data is protected againstunauthorized modification, deletion, cre-ation, and replication. Integrity featuresmight also indicate unauthorized activities.Keyed hashes are commonly used to guar-antee integrity—for example, HMAC-MD5 and SHA-1.

Page 7: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Non-repudiation guarantees that an enti-ty cannot deny that it has performed an ac-tion. Some common techniques for provid-ing non-repudiation are authenticationcombined with the logging and signing ofcommunication content with private keys.

Privacy entails giving an entity (usually aperson who is acting on his or her own be-half) the right to determine the degree towhich it will interact with its environment,including the degree to which the entity iswilling to share information on itself withothers (anonymity). Privacy is also aboutprotecting information that might other-wise be obtained from observing networkactivities—for example, the websites a userhas visited, a user's geographic location,calling and called telephone numbers, andthe IP addresses and DNS names of devicesin a service provider network. Likewise, pri-vacy entails the filtering of unwanted or in-decent information.

Security principles

Ericsson uses certain specific security prin-ciples and best practices as a basis for pro-viding network protection. One importantprinciple, defense in depth, calls for the em-ployment of security mechanisms and secu-rity layers. If one mechanism or line of de-fense fails, the remaining mechanisms andlines of defense will provide adequate pro-tection. This principle is frequently used toprotect the site perimeter.

One other fundamental principle, least

privilege, states that entities should solely begiven the privileges they need to performtheir tasks. This is especially importantwhere node protection is concerned. The ser-vices running on a node need only have theprivileges that are necessary for providingthe service. Moreover, the node should notrun any unnecessary services.

Ericsson strongly believes in employingthe fail-safe principle in its systems andnodes. In essence, this means that system ornode failure must not allow harmful side ef-fects. Consideration for this principle deter-mines which features are implemented andhow solutions behave.

Ericsson also recommends the diversity-of-defense principle, which is based on usingdifferent types of systems to provide spe-cific kinds of protection. If one of the sys-tems is vulnerable, for example, the other sys-tems might be less vulnerable, thereby mit-igating the overall impact of vulnerability.

A choke point forces attackers to use a nar-row channel that can be monitored and con-trolled. In network security, proper siteperimeter protection constitutes a chokepoint. In other words, any attempt to attackthe site from the outside must pass throughthat channel.

Implementing the security architecture

Strong site protection

Figure 5 shows a high-level view of the rel-evant components in an advanced security

74 Ericsson Review No. 2, 2004

Figure 5Example of advanced site perimeter protection.

Internalservers

Externalservers

IDPin-line

NIDSsniffer

VPN (ESP)

Site router

IPsec VPN tunneltermination and origination

Integrated firewall/IPsec VPN

Interior site Internal DMZ External DMZ Internetuntrusteddomain

Node protectionincluding basicpacket filtering,node hardenigand simple HIDS

Site L2/L3switch withpacket filtering

Statefulinspection

Packetfiltering

Dedicatedapplicationproxies

Page 8: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 75

solution (site protection). It also depicts thebasic components of node protection, suchas packet filtering, node hardening and sim-ple host-based intrusion detection systems(HIDS—file integrity checker, minimumaudit logging, security alarm generation,and so forth). The figure does not illustratefault tolerance or network resilience. Inpractice, high-availability configurations(duplication of routers, firewalls, securitygateways, and switches that employ hot-standby or load-sharing mechanisms) areneeded to avoid single points of failure. Sev-eral lines of defense from the outer shell tothe core of the inner site illustrate the de-fense-in-depth principle.

Separation between functions and traffic types (planes/domains)

Sensitive traffic needs further protection(encryption). SCLI and SFTP of the SSH pro-tocol suite are used to protect O&M accessand traffic. If SNMP and CORBA are used,then IPsec or TLS/SSL should also be used.For the best possible protection, operatorsmight also physically separate O&M trafficfrom other traffic.

Traffic in the user plane should be sepa-rated from other traffic in the network. Tofurther protect user traffic, Ericsson advisesoperators to employ end-to-end securitymechanisms per application.

Internal architecture in nodes (layers)

At the node level, Ericsson’s systemarchitecture is mainly reflected byseparation into security planes. Within asecurity plane, security functions, such asper-node packet filtering, help enforcelayering. This design may be repeated inthe system’s sub-units. The fundamentalconcept dictates that every availablesecurity service must be deployed to theextent required by threat or risk at everyconnection point where security planesand security layers communicate. Definedsecurity policies must be enforced at theseconnection points (PEP).

End-user plane

Needless to say, because subscribers are theultimate asset, operators must take adequatemeasures to protect them. Today, every mo-bile phone call is encrypted (over the air in-terface), but only a small percentage of e-mail messages sent over the internet are pro-tected. Why is this? In a word, convenience.Once a subscriber has entered his personalidentification number (PIN) the mobilenetwork (via SIM/USIM) transparently han-dles all key management. By contrast, theaverage PC user is intimidated by the ideaof having to install security software and certificates.

Finally, user privacy (which is already

Other nodes

Node withVLANtagging

SEG

Node withdedicatedinterfaces

Site routerSite switch

IPsec ESP

MPLS tunnels

WAN linkVLAN link

4 VLANs

Virtualrouters

Sharedlink

Tagging (IEEE 802.1Q)based VLANs

Interface-based VLANs

IPsec-capable node

IPsec ESP

AA required to accessany node, physicalaccess restricted

IPsec ESPin genericrouting domain

Figure 6Example of traffic separated into VPNs.Note: The term IPsec ESP denotes a tun-nel—either IPsec transport mode or IPsectunnel mode.

Page 9: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

ply put, it makes little sense to spend hugesums of money on detection mechanismswithout first adding some means of pro-tection. Otherwise, the detection systemwill be overloaded. However, this does notmean that one can forget about responseuntil detection has been added. A sprinklersystem, for example, is very useful whenused in combination with a smoke detec-tor. But even without the smoke detectorit can play a significant role.

Ericsson recommends that operators im-plement security in a layered manner, by con-sidering network, site, and node levels. Eachlevel requires a baseline of inherent security,but protection can also often be added out-side-in, by • strengthening defense around the network

perimeter;• adding a second line of defense at site level;

and• strengthening node and platform

security.Although OPEX is generally more an issuethan CAPEX, one should not downplay therole of the supplier. Operators can obtainnetworking (security) products from anynumber of sources, but it pays to choose asupplier who understands mobile telecom-munications and who can provide supportfor the entire lifetime of the system. Oper-ators should also think end-to-end when ad-dressing security, because no chain isstronger than its weakest link. Here again,there are obvious advantages to choosing a

being driven by regulatory requirements) isbecoming increasingly important and willaffect the entire network. The time will sooncome for true end-to-end protection of usertraffic, because increasing network hetero-geneity will make it impossible to trustevery hop in a path. This does not in any waydiminish the role of the operator or SIMcard, because very convenient network-assisted key management solutions can beused in end-to-end scenarios, even when oneof the end-users is a subscriber and the otheris an arbitrary internet user.

Striking the right balance The bottom line is that if the mobile net-work is not secure and cannot be trusted,then nobody will use it and operators willnot receive any revenue. On the other hand,excessive security measures can easily havethe same effect due to greater inconvenience.Moreover, the cost of developing and run-ning a super-secure system could easily eatup all revenue. As we have argued above, se-curity is a process. In the long run, operat-ing expenses (network management, train-ing of staff, and so on) will, in all likelihood,be more critical than capital expenditures.

How, then, should one invest in securi-ty? Figure 7 roughly outlines the priori-tized steps of the security process. The ini-tial priority is at the functional level—thatis, protection mechanisms are given greaterpriority than detection mechanisms. Sim-

76 Ericsson Review No. 2, 2004

Deter Protect Detect

Where?

Network

Site

Node

Time

Respond Recover

Figure 7Investing in security.

Page 10: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 77

supplier who understands and can delivercomplete end-to-end solutions.

It might also pay to view investments insecurity as something more than a “life-vest”. Greater security can mean greatervalue, which in turn, often results ingreater income. A sufficiently secure digi-tal rights management (DRM) solution, forexample, might spell the difference be-tween having small or having ampleamounts of content flowing in the network.Mobile phones (with SIM cards) are posi-tioned to become a universal security andpayment token.

Examples: securitysolution, analyses Ericsson has developed a verified referencenetwork design that optimally integratesits GSM and WCDMA technology withsite and backbone IP infrastructure. TheMobile Packet Backbone Network (Mobile-PBN), now in its third release, in-tegrates Ericsson’s core network products(for example, GSN, MSC, MGW) and in-cludes optimized designs for many otherintegrated solution modules, such as theservice network, network managementcenter, network synchronization, and soon. Mobile-PBN, which is offered as partof Ericsson’s network design services, in-corporates the security principles and ser-vices described in this article into a high-ly complex WCDMA/GSM network (in-cluding the service network andIPMM/EIT).

Network security design developmentprocessFrom the outset, Ericsson has interwoven se-curity into the Mobile-PBN network designdevelopment process. First, it assessed risksusing a rough design template. All assetswere then accounted for, and finally, relat-ed threats and the probability of related at-tacks were considered.

During the process, Ericsson could seethat a layered approach to security would beneeded to complete the task. The security ofthe physical layer has a direct impact on se-curity measures at higher layers. For in-stance, an insecure backbone is at greaterrisk of attack, which puts data running overthe backbone at risk.

Forming security domainsOne other high-level aspect to considerwhen designing a secure network is parti-

tioning—that is, of dividing the networkinto security domains. Each domain maythus represent a part of the network withdedicated security requirements. In terms oforganization, partitioning gives various usergroups access to specific parts of the net-work. This results in a network that is splitinto multiple security domains.

Although security domains are keptstrictly separate there is often a need to ex-change data between them. In such cases, asecurity gateway—usually an advanced fire-wall product—serves as a policy enforce-ment point, inspecting all traffic between domains. Figure 8 depicts a net-work seen purely in terms of security domains.

What constitutes a security domain? Thelayered approach once again provides uswith the answer: in the physical layer, a do-main is defined by a set of physical inter-faces and their interconnections—that is,physical separation is necessary to separatedomains at this level. In practice, domainsextending to higher layers often share thephysical layer and must therefore be sepa-rated logically.

The most critical entity is the node. In re-ality, few nodes belong to a single securitydomain. Each network node or server gen-erally has several interfaces. Some interfacesmight be reserved for a single security do-main (such as O&M); others might be sharedusing virtual interfaces. Therefore, the ap-plication level inside the node must providethe security level needed to separate securi-ty domains.

Ericsson’s Mobile-PBN solution makesextensive use of logical separation. On-sitelogical separation is realized using VLANsand IPsec.

Site perimeter protectionAs indicated in Figure 8, a network may con-tain internal and external security domains.Seen in terms of the physical layer, the in-ternal domains are domains that reside with-in a physically protected area that can onlybe accessed by authorized O&M personnel.An external security domain might reside inpublicly accessible areas or protected areasto which the owner of the network does notcontrol access. In Mobile-PBN terminologya protected area with its internal security do-main is called a site. Likewise, the desirableaccess-control mechanism constitutes afoundation on which higher security layerscan be built or added.

Physical access is based on regional char-

Page 11: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

acteristics, such as buildings, rooms, doors,and corresponding mechanisms, such asgatekeepers or electronic devices. In Fig-ure 9, physical site protection is depicted bya double ring around the Mobile-PBN site.

A Mobile-PBN site connected to exter-nal security domains must be protectedagainst potential attacks from these do-mains. In the network layer, firewalls pro-vide this protection.

Some external networks, such as a roam-ing partner, might require access to networkelements within the site, whereas other net-works will only use the Mobile-PBN as atransport network to other external securi-ty domains (for instance, user traffic that isbeing tunneled between mobile users via theMobile-PBN network). A “demilitarizedzone” is created for networks that must haveaccess to internal network elements. The op-timum solution for external security do-mains to be tunneled through the Mobile-PBN is to configure the packet filter in thesite router to solely allow traffic to and fromthe tunnel.

Secure site connectionAs opposed to simple corporate networks,WCDMA and GSM networks are not re-stricted to a single site. Instead, they are

composed of multiple sites with various dif-ferent functions. One must thus also con-sider another layer of security to guaranteesecure transport of strictly separated datathrough a potentially insecure backbone.

The assignment of appropriate securityservices to protect data passing through thebackbone is based on type or class of data.The Mobile-PBN security policy classifiesinformation in accordance with the securi-ty reference model (Figure 3). Ericsson hasbased Mobile-PBN on an MPLS-enabledbackbone to provide traffic separation andother non-security-related benefits. To pro-tect sensitive data, Mobile-PBN employsconfidentiality, integrity, and authentica-tion security services over IPsec tunnels be-tween site firewalls. In Ericsson Mobile-PBN terminology these are called securebackbone tunnel (SBT) firewalls.

Bringing it all togetherAs we have seen, Ericsson has given properconsideration to the physical layer, inside aswell as outside sites. Mobile-PBN derivesits physical access areas (site, backbone, andexternal) from this layer. Security domainshave then been defined in the network andat higher layers. These can extend across ac-

78 Ericsson Review No. 2, 2004

O&Msecuritydomains

GpFirewall

LIFirewall

(OM) SBTFirewall

SNSAP

Internetcorporatesecuritydomain

CNsecuritydomain

GiSecurity domain

SNSecurity domains

DMZ securitydomain

GRX/roaming/internet security

domain

LIsecurity domain

LEMFsecurity domain

Operator intranetsecurity domain

Chargingsecurity domain

O&Msecuritydomains

GpFirewall

LIFirewall

(OM) SBTFirewall

SNSAP

CNsecuritydomain

GiSecurity domain

SNSecurity domains

DMZ securitydomain

LIsecurity domain

Figure 8Mobile-PBN R3 security domains with andwithout adjacent external zones.

Page 12: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 79

cess areas, which is to say the classified dataof a related security domain may cross thephysical access layer via a network layer.Moreover, security domains may traversemultiple access areas, and a given access areamay contain multiple security domains.

In summary, the security of the physicallayer has direct impact on all higher layers.Let us assume for example, that a man in themiddle has a physical connection to networkequipment that transports sensitive data. Ifhe possesses the “right” know-how andtools, and appropriate security service havenot been applied, then he can easily tap thewire and capture data. Even worse, a mali-cious person in this position could replay,insert, and modify data or even bring downthe entire network.

The designers of the Mobile-PBN havegiven due consideration to the direct rela-tionship between physical and network se-curity. This is expressed via a security ma-trix (Figure 10).

Traditionally, there have been two com-peting principles of security design: network-centric security design and site-centric security design. Although the focusof network-centric security design is on pro-tecting networks it often overlooks physicalimpact. By contrast, the focus of site-centricsecurity design is on protecting the siteperimeter—the assumption being thateverything inside the domain can be trust-ed. Obviously, this assumption does notwork for complex GSM and WCDMA net-works. Mobile-PBN brings it all together,by incorporating network- and site-centricsecurity principles (Figure 11).

As stated above, Mobile-PBN incorpo-

rates an advanced security concept for mo-bile networks, based on a comprehensive se-curity policy. This policy is realized with aconsistent security solution enforced bybest-of-breed security products. The Mobile-PBN security concept fits well intoEricsson’s overall security architecture andis greatly appreciated by internal and exter-nal customers alike.

Public site

IPsec

IPsec

IPsec

(OM)SBTFw

LI Fw

SN SAPI Gp Fw

Server NAT

Terminal NAT

IPsec optional

Partner site

M-PBN site

M-PBNsecuritydomains

Chargingsite

LEAsite

Roamingpartner

site

Corporatenetwork

site

Internet

Internet

GRX

ISP

Internet

GGSN

Figure 9Mobile-PBN perimeter site protection.

Figure 10Mobile-PBN R3 security matrix.Site ASite A Site B

External(Potentially highly

insecure)

Backbone(potentially insecure)

MPLS separation VLAN separation

IPsec protection IPsec protection

IPsec protectionSignaling traffic

User traffic

O&M, LI and charging traffic

VLAN separation

Firewall Firewall Firewall

Firewall Firewall

Firewall

Page 13: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson as a partner in security

Ericsson has extensive experience of fixedand mobile telecommunications and hasbeen a major driver of standardization forthird-generation mobile networks. In par-ticular, Ericsson has gone to great lengthsto drive security-related standardization in3GPP, IETF, and other standards bodies.Ericsson also complies with and monitorsregulatory bodies to guarantee that the func-tionality of its products supports regula-tions concerning end-user privacy.

Ericsson’s implementation of security inits product offerings begins with basic in-herent security in nodes. Its design and im-plementation are based on best-practicesconcerning virtually every detail includingchoice of pseudo-random number genera-tors and choice of locks on cabinet doors.When applicable, Ericsson partners withleading suppliers of security technologies,such as firewalls and intrusion-detectionsystems, to give its customers technologythat has been adapted to the special needs of

mobile networks. Ericsson is committed toprovide efficient customer support as need-ed via software updates, security patches,and so on. Ericsson has coordinated its prod-uct portfolio to provide a uniform, easy-to-manage and cost-effective security architec-ture that yields carrier-grade security. Toensure that the right security solutions aredeveloped for post-3G mobile networks,Ericsson is also actively participating in, andis the driving force behind, a number of re-search projects in the Fifth and Sixth Frame-work Programs of the European Union.

Security topics beyond3G—identity and trustmanagementA sound approach to security architecturemust consider changes in society, technolo-gy, network architecture, and the emergingbusiness and role models of various players.It is thus interesting to contemplate whatmobile networks might look like in, say, tenyears.

80 Ericsson Review No. 2, 2004

Figure 11Mobile-PBN R3 approach to security design:distributed security domains.

MPLSVPNs

IPsec VPNsover GRD

OMSBTFirewall

SBTFirewall

SBTFW

SBTFW

SBTFW

IPsec ESP

IPsec ESP

IPsec ESP

IPsec ESP

IPsec ESP

IPsec ESP

VLANs

VLANs VLANs

VLANsVLANs and VPNs

VLANs andVPNs

VLANs andVPNs

VLANs andVPNs

VLANs andVPNs

MPLS VPNs

MPLS VPNsMPLS VPNs

MPLS VPNs

MPLS VPNs

Gp Firewall Gp Firewall

LIFirewall

Primary 1

Secondary 1 Secondary 2 Concentrator

Primary 2

SN SAP

O&M

NOC

DMZ

Gp

GI

GI

SN

LI O&M

O&M O&M O&M

CN

CN

GI

VLANs

GI

CN CN

DMZ

Gp

GI

CN

Page 14: Security architectures for mobile networks · to administer security centrally. Ericsson is thus working to give operators better man-agement of nodes in access networks. 68 Ericsson

Ericsson Review No. 2, 2004 81

One thing we can expect to see more of isspecialization, as players tend to optimizetheir business in a narrower niche. New par-ticipants, such as providers of content, iden-tity, trust, and payment, will be increasinglyinterested in mobile clients. This, in turn,will affect basic trust models. Other trends,seen in terms of technology, are new (high-speed) access, and personal area networks.Social aspects might also play a role. Usercommunities, for instance, might want tocreate private overlay networks. In summa-ry, we might very well have a scenario suchas that depicted in Figure 12.

What role does the operator have in thismodel and what are the needs for security?Services that guarantee end-user privacy, se-curity and trust, coupled with convenience.Greater fragmentation implies that userswill find security and convenience in hav-ing a trust-anchor that manages ID, au-thentication, secure payments, and so on.Operators can also provide end-users withgreater territorial privacy, by filtering outspam and unwanted content.

We cannot stress the convenience aspectenough. Thanks to SIM cards, end-userswith a mobile subscription need not con-figure security. Compare this to the chal-lenge most end-users face when trying tomake e-mail secure on a PC. This is why themajority of e-mail traffic is completely un-protected. Where security and private ser-vices are concerned, the full potential of SIMcards and mobile terminals is far from ex-hausted. In principle, network-assisted,end-to-end protection can also be based onSIM cards. Indeed, this might become a re-quirement in the near future, given the het-erogeneity of “beyond 3G” (B3G) networksand the impact they have on trust models.

From the network point of view, greaterfocus must be put on security domains.There is a need for strong policy enforce-ment at domain edges and intrinsic infra-structure security at site, node and platformlevels.

ConclusionRegardless of how complex mobile net-works become, the issue of security shouldalways be approached and managed in astructured and uniform way. Otherwise,gaping holes are left in a patchwork of non-interoperable solutions that are difficult aswell as expensive to operate.

Likewise, investments in security shouldfollow a balanced, well-thought-out plan. In

Figure 12Future mobile network scenario.

Accessnetwork

providers

Accessservice

providers

Applicationservice

providers

Contentproviders

Transport providers

Users

Personal

Vehicular

Bulk l/f

Individual l/f

Home

Community

Identity and trust provider Operator

1 Stewart Kowalski, Mariné Boden, ValueBased Risk Analysis: The Key to Suc-cessful Commercial Security Target forthe Telecom Industry, 2nd Annual Inter-national Common Criteria CC Confer-ence Ottawa 2002, http://www.icc-conference.com

2 Ahonen et al: Taking Security Beyond3G, Contribution to the 7th WWRF Meeting, Eindhoven, The Netherlands,December 3-4, 2002.

3 September 11, 2001: InfrastructureImpacts, Implications, and Recommen-dations; Yankee Group Special Report;September 19, 2001.

4 EU Council Resolution on Network andInformation Security 2002/C 43/02.

5 EU directive 2002/58/EC.6 The Three Phases of Security: Product,

Pervasive, and Persistence; YankeeGroup; June 17, 2003.

7 To serve and protect: Operator strategiesfor selling security; Strategy AnalyticsIndustry Report; July 2001.

8 Wireless spam could cost operators USD2 billion per annum; Strategy AnalyticsInsight; August 22, 2002.

9 Sue Uglow, Structuring for survival:Strategies for telecoms players, OvumReport, April 2002

10 US (Ca) Database Security Breach Notifi-cation Act, of July 1, 2003.

11 Ambient Networks, http://www.ambient-networks.org/

12 ITU-T recommendation X.805, Securityarchitecture for systems providing end-to-end communications

REFERENCESthis context, choice of supplier is very im-portant, because only a total system suppli-er can truly understand the telecommuni-cations business and offer life-cycle supportfor uniform, easy-to-manage, end-to-end so-lutions with the right balance between costand security.

Ericsson is a firm believer in resolving se-curity issues through standardization, notjust to guarantee homogeneity, but also toensure that emerging security standardsgive proper consideration for the mobile andwireless aspects of data- and telecommuni-cations.