SDF_Security_A4_0606

Nokia Service Delivery
Framework and Security
White paper

2
Nokia white paper Nokia Service Delivery Framework and Security
Contents
Executive summary 3
Deﬁnition of security in the service delivery
platform domain 4
The system architecture process for deﬁning
a service delivery platform 5
Network security and Nokia SDF 7
Service security and SDF 8
Service Security 8
Security requirements for SDP 9
Service security requirements for SDP overall architecture 9
Service Security implications for functional subgroup 9
Example of a SECURE IMS Enabled Converged SDP 10
Summary 11

3
Executive summary
There is, however, an inverse relationship
between convenience (ease of use) and
security – as security is increased,
convenience tends to be lost. Security
mechanisms should therefore be
transparent, while upholding business
competence by not affecting service
quality.
At the other end of the spectrum,
operators need to enhance their service
offering through new services, quality,
capacity and many other factors. By doing
this, new security challenges open up in
the form of service provisioning security,
data privacy and terminal security, to name
a few, each of which needs to be balanced
with the user convenience.
The Service Delivery Platform (SDP)
implements the delivery portion of the
service provider’s service strategy.
Potentially, the SDP must cater for many
different requirements. Therefore,
the process of defining the SDP’s required
architecture must consider its deployment
in a tailored environment, rather than
as a standard product deployment.
The important factor, therefore, is the
method used to realize the architecture
and the environment.
This balancing of security against other
needs is one of the services of Nokia’s
Service Delivery Framework (SDF).
alt. ’security by obscurity’ n.
A term applied by hackers to
most OS vendors’ favorite way
of coping with security holes –
namely, ignoring them,
documenting neither any
known holes nor the
underlying security algorithms,
trusting that nobody will find
out about them and that
people who do find out about
them won’t exploit them.
Over the years, security by obscurity has
become the prevailing attitude of the
Information Technology community:
• Speak not and all will be well.
• Hide and perhaps they will not find you.
• The technology is complex. You are safe.
These principles have not only been
proven faulty, but they also go against the
original concepts of how security could
evolve through discussion and open
education.
Security, in all its forms, plays a hidden yet
pivotal role in the design and exposure of
every product and service that operators
provide – from content provisioning to the
user and from the Operations Support
System (OSS) right through integration to
Customer Care and Billing.
Mobile operators strive to provide good
quality, good value services available
anywhere, with the provisioning that
users expect. Any compromise in security
may well influence any of the above.
This in turn affects the users’ overall
satisfaction – if this declines, it could very
quickly escalate into a major problem for
the operator.

4
Security Policy and Controls
Network
Controls
Incident
Management
Validation
Logical
Access
End
User
Education
Physical
Risk/IssueManagement
Definition of security in the service delivery
platform domain
Security is a continuous process, both within
and across different industry segments,
including the telecommunication and
IT industries. Although this is not a new
phenomenon, in recent months a new
trend has emerged, that of security
requirements over and above that of
normal service providers, fixed and mobile
operators. This has become especially
relevant for mobile operators entering
the converged environment, as the design
of a secure information infrastructure is
becoming more complex.
”Defence in depth” is a concept that
describes multiple layers of defence.
This approach, employed in Nokia’s SDF
design, not only provides several layers
of security but also ensures that any
compromise is localized, contained and
eliminated. This also ensures a marriage
between the needs of the business and
the capabilities of the technical security
infrastructure.
The term ’security’ is used to mean many
different things and we therefore need to
be clear what is meant by security in
respect to the telecoms industry. Figure 1
illustrates the security relationships
targeted by Nokia’s Solution Design
Framework.
Figure 1. Telecom Security Relationships
It is the latter two of these that are of
particular interest to the Service Delivery
Platforms. New services are introduced
every day with security gaps and the
possibility of service abuse is recognised
as a growing threat.
Within the telecoms industry, there is a
further refinement, known as Fixed
Mobile Security (FMS), which embraces
three specific aspects of security:
• Terminal (Device) Security – the security
requirements of a physical device
• Network Security – the historical IT
security aspects
• Service Security – the ability of a
converged operator to deliver secure
services in accordance with new laws
and regulations, balanced with the ease
of service access by end users, ensuring
not only efficient service delivery but
also ARPU. assurance.

5
Simplified
SDF design process
for architecture
Concept creation
with stakeholders
Requirement
mapping to
high level design
Requirement
elicitation
Requirement
analysis
Architecture
handover to
implementation
Design iteration
with stakeholders
Architecture
assessment
with stakeholders
High level design
elaboration to
next level designs
y
y
y
y
y
y
y
yy
y
yy
The system architecture process
for defining a service delivery platform
Based on the experience of numerous
projects delivering full blown SDPs,
Nokia has defined a tool for designing
and developing them, the Nokia Service
Delivery Framework (SDF). The SDF
incorporates reference architecture,
a design process for the creation of
architecture, a cumulative knowledge
base, Nokia products implementing SDP
functions, access to 3rd party technology
and service provider co-operation
networks, as well as links to business
value consulting and program
management.
Nokia SDF is a tool for designing and
deploying SDPs. As such, it needs to take
into account all aspects of SDP architecture
design, implementation and delivery.
In the context of security, the SDF is used
as a tool for handling and analyzing the
security requirements of a service delivery
platform.
The Service Delivery Platform (SDP)
implements the delivery portion of the
service provider’s service strategy.
Potentially, the SDP must cater for many
different requirements. Therefore,
the process of defining the SDP’s required
architecture must consider its deployment
in a tailored environment, rather than as
a standard product deployment.
For an SDP vendor, therefore, the important
factor is the process which is applied
when the architecture and delivery of the
environment is being realized. Clearly,
the requirements demanded of such a
process are diverse and complex due to
the specifics of the domain. However, in
this context there are some requirements
that the process must meet in order to
achieve the target of providing a high-
quality SDP deployment. As a minimum,
the process used for crafting a service
delivery platform needs to meet several
basic security requirements:
• Take account of all identified business
and technology requirements
• Address any hidden requirements,
that is, identify any implications
• Analyze the current state efficiently
• Support efficient identification of the
SDP growth path according to the
identified service strategy
• Allow co-operation and partnering with
any preferred third party technology
and service provider
• Address convergence requirements by
explicitly identifying those sub-areas
where a service delivery platform should
provide a solution for a convergence
offering
• Allow efficient reuse of accumulated
experience from previous SDP projects
Finally, it needs to ensure the definition
of a scalable and flexible target
architecture, with a well defined phasing
and growth path and with the ability to
reflect revisions to strategy.
Figure 2. High Level view of SDF Design Process for architecture of SDP

6
The SDF design process takes security into
account through a number of phases.
The first stage is requirement elicitation,
which looks at the explicit and implicit
requirements the different security
categories will place on the SDP. This is
followed by requirement mapping to the
first level design. This examines the
expected SDP growth path and respective
phasing mandated by the service strategy
and how security will be incorporated
into different phases of the specified
growth path.
Figure 3. Holistic approach to security
End-user Security Solutions
Security Assessment
Network Architecture, Security Organization and Policies
Security Planning
Network
Security Consulting
Implementation
Solutions
Security Optimization
Network and Process
Network Security Solutions
Gateway
Filters Logging
Intrusion
Detection Antivirus Firewall
Analyse Identify Craft Select Execute Launch Care
The next stage elaborates the architecture
and takes it to the next level of design,
looking at when different architecture
views are introduced, which architecture
elements cater for security requirements
(both business and technical) and how
they are described in the architecture.
This is followed by the detailed design,
which selects the technologies that will
provide the desired security architecture.
Physical mapping looks at the physical
implementations, which will be used for
balancing security against ease of use,
while design verification looks at how the
security integrity of the target platform is
assured.
The requirements of security are by their
nature pervasive. Therefore, security
requirements need to be considered in
every functional subgroup of the SDF
reference architecture. This type of holistic
approach to security on the service
delivery platform is a key requirement of
any SDP deployment project.

7
Content/Service Provider
End-User/Terminal
Delivery
Channel
Service
Logic
Common
Services
Value Chain
Management
Integration and Capability Exposure
OperationsSupportSystem(OSS)
CustomerCareandBilling(CCB)
Fixed
Network
Mobile
Network
Network security and Nokia SDF
With the Nokia Service Delivery
Framework, we need to consider the new
delivery channels that Network Security
introduces with the creation of the service
delivery platform. While the Nokia Service
Delivery Framework already supports
historical security technologies such as
those used in ﬁxed and mobile
environments, new delivery channels are
exposing new risks that could affect the
quality of delivered services. Nokia’s SDP
design allows these new channels to be
properly secured whilst maintaining ease
of use for the user.
These new elements in the Delivery
Channel will need to be managed by the
Operational Support Systems (OSS) and
may also affect the components within
the Common Services, such as charging
and provisioning. However, the degree of
impact will depend on the security
approach taken.
Figure 4. Nokia Service Delivery Framework Reference Architecture showing all areas of security integration.

8
Service security and SDF
Service Security
Service security has implications for every
part of the SDF reference architecture.
Therefore, when looking at a service
delivery platform, services and their
security are a significant source of
requirements and architecture constraints.
In a converged environment, the risk is
not new types of attack but the increased
number of security gaps caused by
combining two historically separate
networks.
SDF covers a number of areas in service
security:
• Historical IT vulnerabilities
• Call interception
• Eavesdropping
• Invasion of privacy
• Service theft
• Spoofing and Presence theft
• Toll Fraud
• Risk mitigation
Historical IT vulnerabilities covers
current fixed and mobile network security
threats such as denial of service (DoS)
attacks. Even though these types of
attacks are very familiar to security
experts, the implications of voice and
communication disruptions in a converged
environment can be disastrous.
A simple example is ICMP or SYN attacks
on VoIP systems. These crash the
infrastructure, causing the user to reset
the IP phone and allowing the attacker to
gain control of the system.
Call interception is hardly new but with
sniffing tools freely available on the
Internet, this form of attack is growing by
the day.
Using a network monitoring tool in
conjunction with an ARP spoofing tool,
an attacker is able to identify the MAC
and IP address of a specific phone.
Impersonating the gateway and the
phone in question allows the attacker to
intercept a call.
Eavesdropping relies on the same
principle described above with the
difference that the attacker allows traffic
to flow without disturbing either end
point, thereby listening in on the
conversation.
Invasion of privacy relies on the fact
that in a converged environment,
signalling occurs in band,meaning that
the same physical infrastructure is used
for signalling and voice data, unlike SS7
communications where two physically
separate networks are used for almost the
whole completion of the call.
To attack such infrastructure, data streams
can be manipulated, through identity
theft, to reroute sessions, resulting in
unauthorized data collection,
eavesdropping and more.
Service theft is by no means new in
both fixed and mobile environments.
The security gaps provided by a
converged environment do, however,
involve unauthorized use of equipment
which could also affect service quality.
Spoofing and Presence theft in the
mobile environment is the classic ’man in
the middle’ attack with the attacker
tricking one or both parties by
impersonating an authorized user.
This type of attack will affect a business’
reputation among its peers, for example,
among the engineering community.
The ramifications of this attack on a CEO
of a large company while communicating
sensitive data could be enormous.
Toll fraud also involves unauthorized use
of equipment but results in direct revenue
loss when services are charged to the
operator or unsuspecting companies.
Risk Mitigation in the SDF context is
the comprehensive use of tools for
content-aware charging, protocol
blocking, web page black/white listing,
policy filtering, anti-virus, pro-active
Trojan prevention and adult verification,
to name but a few.

9
Security requirements for SDP
Service security
requirements for SDP
overall architecture
The requirements of service security can
be seen as those which need to be met by
the framework being used to design the
SDP architecture. For an architecture
framework, like SDF, a number of security
requirements have been identified.
The framework needs to allow access by
different access channels, depending on
the capabilities of the consuming terminal
and of the content being accessed.
It also needs to secure service and
application construction and ensure that
the security and integration requirements
are transparent to the end user.
Another requirement is that the
framework and respective architecture
implementation needs to allow runtime
introduction of tools intended for creation,
deployment, provisioning, management
and de-deployment of several types of
content and services, without service
outages due to attacks.
The framework also needs to acknowledge
the inherent insecurities of terminal
devices due to their physical location and
prevent any breaches of the network and
services initiated from them. Finally,
security policies and architectures are
living elements which need constant
attention. The framework must support
flexibility and modularity and allow
growth.
In addition to the above mentioned
requirements, every service provider will
have their own security needs, thrown up
by the service security strategies in their
own market segments.
Service Security
implications for
functional subgroup
The Delivery Channel functional subgroup
contains elements that are fundamental
to the delivery of a service. In the mobile
domain, this would include GGSN, SMSC,
MMSC, WAP/browsing gateways etc. and in
a converged environment, narrowband
and broadband access (WLAN, WiMAX, DSL),
in addition to the mobile access channels.
On top of these access technologies, there
are the delivery mechanisms already in
place, or being developed for service
delivery, for example, IM, IP-TV, along with
those that are familiar in the mobile
domain, such as WAP/browsing gateways,
IMS, MMSC and more.
One key area of SDP development is the
seamless inter-working between fixed/
Internet services and mobile services with
transparent integrated security.
This is also true between delivery channel,
service logic, value chain management,
common services and service
management sub groups in SDF.

10
IMS Register Video
Mailbox
Call
Processing
Server
Push to Talk
(PoC)
Generic SIP
Application
Server
List
Management
Server
IP Centrex
Streaming
Server
Presence
Application
Service Logic Domain
Call
Processing
Server
HTTP
Proxy
WAP
G/W
MMSC SMSC
Traffic
analysis
GGSN
Traffic node
Common Services
Service
configuration
tools
Nokia
Profile
Manager
Online
charging
Unified
Directory*
Charging
and CDR
gateway
IMR
Billing Domain
Mediation
system
IN based
billing
system
Video
G/W
SGSN MGW Network Domain
(sub-set of elements)
SMLC GMLC HLR MSCLBS
Content
Request
Security
Delivery Server
Charging
I/F
Content
Delivery
DRM
Personalisation Promotions
Navigation Single Sign-On
Rendering/
Branding
Self-Care
Services
Portal Services
Meta
Data
Content Management
Tools
Content
Workflow
tools
CDR
store
AAA
Profile
server
SIP/ISC
Delivery Channels
H.248, SIGTRAN
MAP over IP
RTP
HTTP Diameter
LDAP
Radius
Gn
WAP
Cx
SMPP
MM7
PAPHTTP
Ftp
Custom API
Publish
Content
Retrieve Content
Register Content
HTTP
Value Chain Management Domain
Service
Profile
Data
Subscriber
Profile
Data
Unified Directory*
Service
SLAs
Device
Database
WAP MMSC
Network Adaptors
SMSC SIP MLC
Retrieve
Content
HLR MSC
Policy
Management
Service Provider Access
Gateway
Traffic
Management
OSA/Parlay
Framework
OSA/Parlay
Gateway
Service
Capabilities
Lg
MAP
CAP
Service
Interaction
Management
EAI
Adaptors
Integration
and Capability
Exposure
Enterprise
Applications
Hosted
OSA/Parlay
Applications
Rich Call and
Enterprise
Services
OSA/Parlay,
Parlay-X
Parlay-XWSI
(or Legacy)
Internet
External
OSA/Parlay
Applications
External
Service Providers
(Push Content)
Content Provider
Domain
External
Content
Content
Publishers
External
Web Content/
Service Providers
Managed and
hosted content
and services
Security Cluster I/F
Example of a SECURE IMS Enabled Converged SDP
When considering security on the solution
delivery framework, a holistic picture
needs to be mapped. The red indications
in the illustration below are by no means
exhaustive as there are security
implementations in and across services,
products and elements, such as
encryption, AAA, DMZ requirements etc.
However, it does illustrate the scope of
SDP security, which encompasses every
single element in the network.
Figure 5. The security scope of SDP
The security interfaces could include:
• Policies and procedures deployment
• Firewall and management thereof
• IDS/IPS
• Risk Mitigation in all its forms such as
anti-virus, anti-spam, content ﬁltering etc.
• Logical Access controls
• Risk Assessment and Auditing
• Encryption in all its forms, from digital
certiﬁcations to SIM encryption
• Physical Security

11
The contents of this document are copyright © 2006 Nokia. All rights reserved. A license is hereby granted to download and print a copy of this document for personal use only.
No other license to any other intellectual property rights is granted herein. Unless expressly permitted herein, reproduction, transfer, distribution or storage of part or all of
the contents in any form without the prior written permission of Nokia is prohibited.
The content of this document is provided “as is”, without warranties of any kind with regards its accuracy or reliability, and specifically excluding all implied warranties,
for example of merchantability, fitness for purpose, title and non-infringement. In no event shall Nokia be liable for any special, indirect or consequential damages, or any
damages whatsoever resulting form loss of use, data or profits, arising out of or in connection with the use of the document. Nokia reserves the right to revise the document
or withdraw it at any time without prior notice.
Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Nokia product names are either trademarks or registered trademarks of Nokia.
Other product and company names mentioned herein may be trademarks or trade names of their respective owners.
Summary
Every security expert, analyst and
practitioner will state that there is no
silver bullet when it comes to securing
architecture in the mobile and fixed
environment, and, as a matter of fact,
in any network.
Nokia’s Service Delivery Framework is the
closest that information technology has
come to achieving that goal.

Copyright©2006Nokia.Allrightsreserved.NokiaandNokiaConnectingPeopleareregisteredtrademarksofNokiaCorporation.
Otherproductandcompanynamesmentionedhereinmaybetrademarksortradenamesoftheirrespectiveowners.
Productsaresubjecttochangewithoutnotice.
Nokiacode:11394–06/2006Indivisual/Libris
Nokia Corporation
Networks
P.O. Box 300
FI-00045 Nokia Group
Finland
Phone: +358 (0) 7180 08000
www.nokia.com

SDF_Security_A4_0606

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (17)

Similar to SDF_Security_A4_0606

Similar to SDF_Security_A4_0606 (20)

SDF_Security_A4_0606