A PrismTech Product Line

INFOSEC Boundary Control for Middleware INFOSEC Boundary Control for Middleware Based Telco Systems and for SDR SystemsBased Telco Systems and for SDR Systems

a comparisona comparison

Sebastian M. StaamannSebastian M. StaamannDirector of Security ProductsDirector of Security Productssebastian@prismtech.comsebastian@prismtech.com

Slide 2 © PrismTech 2005

MotivationMotivation

! Both, telco infrastructure services and SDR applications, are normally based on a middleware layer (mostly CORBA, although telco is also looking towards Web Services, e.g., Parlay-X)

! In both these application areas of middleware, the security problem domain is structured using the concept of security boundaries and security enforcement at these boundaries.

! Question:Can SDR can adopt some approaches, patters, and solutions for security of middleware based application systems in the telco domain?

Slide 3 © PrismTech 2005

SDR reference architecture: SCASDR reference architecture: SCA

SCA defines Cryptographic Boundaryin the overall architecture

Source: JTRS-5000SEC SCA Security Supplement

Slide 4 © PrismTech 2005

Reference architecture: SCA (cont.)Reference architecture: SCA (cont.)

! Security requirements and architecture for use of SCA in defense specified in the SCA Security Supplement document

! Focus (architecture and interface specs.) clearly on the cryptographic boundary

Cryptographic Boundary inthe SCA overall architecture

Source: JTRS-5000SEC SCA Security Supplement

Slide 5 © PrismTech 2005

Reference architecture: SCA (cont.)Reference architecture: SCA (cont.)

! Security boundaries in the SCA Security Supplement:

Source: JTRS-5000SEC SCA Security Supplement

Slide 6 © PrismTech 2005

Security Boundaries in Telco and SDRSecurity Boundaries in Telco and SDR

! Air Interface Protection(over-the-air encryption, controlling over-the-air access)

! INFOSEC Boundary(COMPUSEC, e.g., AAA, perimeter protection [firewalling], encryption [non-classified]...)

! Equipment Security Boundary (physical protection, protection against tamper)

! Cryptographic Boundary(classified cryptographic

subsystem hardware)

! INFOSEC Boundary(COMPUSEC, e.g., authentication,access control, audit, separation...)

! Equipment Level Security Boundary (protection against tamper, TEMPEST,electrical protection [UIC]...)

Telco (value-add services,network [element] management)

SDR (more preciselyJTRS / SCA, incl. Security Suppl.)

Slide 7 © PrismTech 2005

COMPUSEC Requirements in TelcoCOMPUSEC Requirements in Telco-- at the middleware layer at the middleware layer --

! Many Telco application systems (value-add services [Parlay and the like], network [element] management) based on CORBA

! Often deployed across the own network boundary, e.g., to external partners (e.g., 3rd party service providers), and over non-trusted networks

! Core functional requirements are:

! Authentication/identification (users, components, sub networks)

! Authorization / access control (per component, per operation)

! Audit

! Network Boundary Protection / Application Level Firewall Security (deep packet inspection / authorization per operation)

! Encryption

Slide 8 © PrismTech 2005

COMPUSEC Enforcement in TelcoCOMPUSEC Enforcement in Telco-- at the middleware layer at the middleware layer --

! Enforcement is distributed (and often autonomous) per node

! Enforcement focuses on theprotection of the network boundary(or of sub-networks)

Using Server-side Interceptors Using Security Gateways

internal IIOPservers and clients

external IIOP servers and clients

IIOP Security Gateway

OperationsCenter

nodes in the field(widely dispersed

application servers,often embedded,

often in verylarge numbers)

CORBA basedinteractions

Typical Multi-Server Scenario

Slide 9 © PrismTech 2005

Interceptors: FieldInterceptors: Fieldss of Applicationof Application

!Corba based multi-server applications

Common characteristics:!Servers deployed outside the

firewall (connected vianon-trusted networks)

!only one Corba server on each (physically protected)node in the field

Typical Example:Network Element Management

Typical requirements onthe security solution:

!Autonomous security enforcement

!Powerful and flexible security policy definition

OperationsCenter

nodes in the field(widely dispersed

application servers,often embedded,

often in verylarge numbers)

CORBA basedinteractions

Slide 10 © PrismTech 2005

The customer:the world’s largest supplier of mobile systems

The case:the customer’s generic platform for 3G telecom applications

Telco Customer Case

Management of Radio Base Stations

Application Scenario! Remote Management of

Radio Base Stations (RBSs)

! Based on Java JVM (J2ME)! Corba 2.6 compliant ORB! Whole Corba runtime, incl.

security & naming services,< 5MB (req. for embedding)

! One JVM to run everything on, incl. application, security, Corba naming service

Security Solution Requirements! Authentication and fine grained

authorization (role based access control) for thousands of systems (RBSs) in the field

! Corba-level security auditing! Security enforcement

transparent for the application(and the application developers)

! Security enforcement fully autonomous, no dependency on remote infrastructure (e.g., central security policy servers)

! Minimum performance impact! Capability for secure

interoperability (CSIv2)

Slide 11 © PrismTech 2005

Solution: Architectural OverviewSolution: Architectural Overview

CorbaClient non-secure access

Corba ServerApplication

Console (Security Editor)

---------(1)

Consoleimportsobjectinterfacedefinition(in IDL)

---------(2)

Consoleexportsnew (modified)security policy(file based)

(3)Security Interceptoris updated withnew (modified)security policy(4)

Client is configured

with authentication

credentials

(5)All Corbarequests areautomatically and transparentlyenhanced withauthenticatinginformation

(6) Each request

is checked forauthentication

& authorizationagainst the

security policy

(5-6) Automaticaudit of allsecurity relevant events

Slide 12 © PrismTech 2005

Interceptor Solution: Security FunctionsInterceptor Solution: Security Functions

! Peer-Entity Authentication! based on public-key certificates (SSL handshake)! or based on username/password (CSIv2)! or based on sender IP address! user access can be suspended and resumed! anonymous users can be permitted

! Authorization / Access Control! flexible and fine grained target selection

! IDL type! or object instance! per single operation, if wanted

! Role based access control, incl. role hierarchies! Security Audit! Identity delegation (CSIv2 based), interoperable with other vendors! Integrated with ORB-SSL (connection integrity & confidentiality)

and SSL key management

Slide 13 © PrismTech 2005

! IIOP embeddedattacks pass undetected

Example: IT-infrastructure with IIOP based applications without adequate firewall security

HTTP serverswith Servletengines in DMZspeak IIOP withthe back-end

Security Gateway as IIOP FirewallSecurity Gateway as IIOP Firewall

external network,e.g., the Internet

JBoss EJBserver

IonaOrbix

JacORBserver

SunJavaORB

internal network

TAOserver

IIOP

DMZ

IIOP

IIOP

HTTPHTTP

Webclients

smartclients,externalservers

IBMWebLogic

BorlandVisibroker

Internal and/or external filtermust open whole port ranges. NAT is not possible.

All non-protected ports on all machines hosting IIOP servers are vulnerable to attacks from the external net and/or the DMZ.

Oracle EJBserver

BEAWebLogic

+ Deep packet inspection for IIOP, User authentication, and Authorization per operation

DBC protected IIOP server sphere

Internal and/or external filter opens only one port (for the I-DBC host). NAT can be done at any place in the DMZ.

No port at the IIOP server hosts can be reached without detailedsecurity control.

Slide 14 © PrismTech 2005

application server

Security Gateway IllustratedSecurity Gateway Illustrated

enterprise access control tier(authentication, authorization,

audit, administration)

wide spectrum ofpossible users

po

ten

tial

use

rs o

f C

OR

BA

or

EJB

ob

ject

s

bu

sin

ess

lo

gic

an

d d

ata

to

be p

rote

cted

external IIOP client

external HTTP clientvia IIOP capable servlet

intern IIOP client

other IIOP server(server-server integration)

Unified Security(one security policy, one

security enforcement module,for all IIOP based AppServers,

for all IIOP enabled users)

- Mutual authentication- Fine grained, identitybased access control(also role & group based)

- IIOP content inspection- SSL off-loading- Security audit- Unified, GUI based,intuitive securityadministration

Corba 1 from vendor A (e.g., Visibroker)

EJB application server 2from vendor A (e.g., Borland)

Corba application server 3 from vendor B (e.g., Orbix)

Corba and EJB servers with vendorspecific (or w/o) security features

server 4 (application with Corba interface) from C (e.g., Lotus Notes)

Slide 15 © PrismTech 2005

FeaturesFeatures

! Proxification of all object references (IORs) that cross the firewall

! solves IIOP’s dynamic port allocation problem with firewalls,All incoming TCP connections to IIOP servers in the internal network end at the same port at the same IP address, which is the freely configurable ingress transport address of the I-DBC (in most cases port 535 for pure IIOP, port 683 for IIOP over SSL).

! solves IIOP’s NAT problem,The proxy object references generated to be used from outside the NAT device contain the NATified TCP address of the I-DBC for ingress IIOP and IIOP/SSL traffic.

! transparently without any modification of the IIOP applications.

! Deep packet inspection of IIOP / Authorization per operation Expressive message filters enable content based access control.

! Set of user authentication mechanisms allows flexibilityChoice between SSL/X.509, username/password, RSA SecurID, IP address based identification (and anonymous access) per registered user (supports of customer specific authentication technologies too).

! SSL transport protection for all connectionsSSL protection for applications without modification. Certificate revocation with OCSP.

Application Level Firewall Security for IIOPApplication Level Firewall Security for IIOP

Slide 16 © PrismTech 2005

! User and identity management, incl. user groups, and authentication management

! Fine granular access management (authorization & access control enforcement), for object types, object instances, and down to single operations

! Role based access control (RBAC)

! Audit: Security monitoring at runtime,Creation of security records

! Flexible authorization depending onthe strength of the authenticationand encryption of the session

Contents based authorization and access control

! Authorization can be constrained to certain parameter value ranges

FeaturesAuthentication, Authorization, Audit

Slide 17 © PrismTech 2005

Interceptors Interceptors vs.vs. Gateways in Telco Gateways in Telco -- advantages of each approach advantages of each approach --

! More suitable for application scenarios with servers widely dispersed over non-trusted networks

! Completely autonomous security enforcement

! Very small footprint implementation possible

! Unlimited scalability

! One security enforcement point for all applications

! Suitable for “firewall oriented” security philosophy

! Non-invasive security implementation

! Reliance on the security of the layers (e.g., OS) below only on the gateway (bastion) host

! Centralized security policy

Security Interceptors Security Gateways

Slide 18 © PrismTech 2005

INFOSEC Boundary in SDR INFOSEC Boundary in SDR -- at the middleware layer at the middleware layer --

! Identification / authentication! Access Control! Process Separation! System Integrity! Object Reuse! Inter-component security! Secure connection of wireline

networks and applications to the radio

Interceptor based

Gateway based

Requirements Breakdown Possible Enforcement Solution