osp 24 security guidelines draft 03

Alcatel 8690

Security Guidelines

OSP 2.4.01

3CL-02350-BBXX-BGZZA

............................................... April 20, 2006

Table of Contents

Table of Contents .................................................................................................. 1

1. Overview of the different LAN and access modes ........................................ 31. Corporate (Management or intranet) LAN access to OSP R2.4.02 .................................... 42. User LAN access to OSP R2.4.02 ................................................................................... 53. OSP Private LAN ........................................................................................................... 54. Remote access for field support ...................................................................................... 65. Sigtran Signalling network ............................................................................................. 6

2. Securing the different access types ............................................................... 71. Secured Corporate (Management or intranet) LAN access ............................................... 7

1.1. Assessing the Risks ............................................................................................... 71.2. Intranet Security Policy .......................................................................................... 71.3. Authentication and access control implementation ................................................. 81.4. Passwords management ....................................................................................... 91.5. Encryption & Integrity checking ............................................................................ 101.6. Network segmentation & Protocol filtering ........................................................... 101.7. Operating System hardening and services limitation on the servers ....................... 10

2. Secured User LAN access ............................................................................................ 102.1. Authentication and access control ....................................................................... 112.2. Web server implementation ................................................................................ 112.3. Restrict the traffic between the public network and the Corporate intranet .............. 122.4. Network segmentation ........................................................................................ 12

2.4.1. Servers in the DMZ ............................................................................................ 132.4.1.1. Reverse Proxy Server .........................................................................................132.4.1.2. Secure Reverse Proxy Server ...............................................................................13

2.4.2. DMZ Topology .................................................................................................. 132.4.2.1. Screened subnet Firewall ...................................................................................142.4.2.2. Multi-homed Gateway .......................................................................................152.4.2.3. Conclusion .......................................................................................................15

2.5. Security policy .................................................................................................... 162.6. Operating System Hardening and Services Limitation ........................................... 172.7. Double LAN for HTTP flow .................................................................................. 17

3. Secured OSP Private LAN access .................................................................................. 174. Secured Remote access for field support ....................................................................... 185. Secured access for Sigtran signalling network ............................................................... 18

3. Communication with the OSP ...................................................................... 191. Communication with the SMF ...................................................................................... 19

1.1. Intranet communication with the SMF based on SOAP .......................................... 191.2. Secured Internet communication with the SMF via a ‘Reverse PROXY’ .................... 19

1.2.1. Advantages ....................................................................................................... 201.2.2. Drawbacks ........................................................................................................ 20

1.3. Why SOAP for PC to SMF communication? .......................................................... 201.3.1.R easons of the choice .......................................................................................... 201.3.2. gsoap ............................................................................................................... 21

1.4. Java Web Start ................................................................................................... 21

OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 1/42

April 20, 2006 ......................................................................

1.4.1. Difference between Java applications and Java applets ...................................... 211.4.2. Presentation of Java Web Start .......................................................................... 211.4.3. Signing ............................................................................................................. 22

1.4.3.1. Description .......................................................................................................221.4.3.2. Signed applet ...................................................................................................22

1.5. Intranet communication for OSP 2.4 Management Application .............................231.6. Secure communication for OSP 2.4 Management Application ...............................241.7. Thin client and mass access communication ........................................................28

1.7.1. Definition of thin client ...................................................................................... 281.7.2. Description of thin client .................................................................................... 281.7.3. Mass Access service presentation ....................................................................... 281.7.4. Communication process .................................................................................... 29

2. Communication with the SLEE ......................................................................................302.1. Communication with the SLEE via DPE router .......................................................302.2. Communication with the SLEE via SOAP ..............................................................31

2.2.1. Web service architecture .................................................................................... 312.2.2. Communication process .................................................................................... 32

4. Recommended Firewall solution ................................................................. 331. Simplex configuration ..................................................................................................332. Duplex configuration ...................................................................................................34

5. Alcatel Product Security Incident Response ................................................ 36

List of figures ...................................................................................................... 37

Index of Topics .................................................................................................... 38

Document References ......................................................................................... 41

2/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines

Overview of the different LAN and access modes April 20, 2006

1. Overview of the different LAN and access modes

The OSP R2.4.02 provides four LAN and access modes depending on the needs:

Corporate (Management or intranet) LAN : access for service and platform management.

User LAN : access for service management (via SOAP on HTTP or HTTPS).

OSP Private Internal LAN: No external access, only used for OSP process inter-communication.

Remote access via PSTN or vLan for field support.

The figure below illustrates one possibility showing the different LAN and access modes:

Figure 1.1 - Different LAN and access modes

In a typical OSP configuration, the following networks are defined:


April 20, 2006 Overview of the different LAN and access modes

1. Corporate (Management or intranet) LAN access to OSP R2.4.02

This LAN is protected from the Internet by a DMZ (with a firewall + Reverse Proxy on dedicatedhardware). It supports a very limited set of protocols: HTTP, SIP, … This section presents the external (i.e.: from the public Internet) access to the OSP R2.4.02 viaSOAP on HTTP(s).

• The SOAP server sends the SOAP requests.• A JAVA signed applet is downloaded to the client PC from the HTTP to SOAP gateway. • The SOAP requests are sent to the SOAP servers of the SMP.• SOAP answers are sent to the client.

Figure 1.2 - Access to OSP from Internet via a reverse proxy

For security reasons, this document recommends to use a reverse proxy and a DMZ between thepublic Internet where the PC is located and the operator's network.

This architecture will be explained in “Secured User LAN access” on page 10.

Internet

SOAP Server

SMF 2

Internal

Network

DMZ

SMF 1

Firewall Reverse Proxy

Firewall

Soap bus


Overview of the different LAN and access modes April 20, 2006

2. User LAN access to OSP R2.4.02

This LAN is protected from the Internet by a DMZ (with a firewall + Reverse Proxy on dedicatedhardware). It supports a very limited set of protocols: HTTP, SIP, … This section presents the external (i.e.: from the public Internet) access to the OSP R2.4.02 viaSOAP on HTTP(s).

• The SOAP server sends the SOAP requests.• A JAVA signed applet is downloaded to the client PC from the HTTP to SOAP gateway. • The SOAP requests are sent to the SOAP servers of the SMP.• SOAP answers are sent to the client.

Figure 1.3 - Access to OSP from Internet via a reverse proxy

For security reasons, this document recommends to use a reverse proxy and a DMZ between thepublic Internet where the PC is located and the operator's network.

This architecture will be explained in chapter 2.2.

3. OSP Private LAN

This LAN is dedicated and reserved to OSP machines (no ip forwarding is allowed from thisnetwork to any other network). It supports all internal (and proprietary) protocols required by theOSP to provide high performance (pseudo real time) and high availability features: DPE on TCP,

Internet

SOAP Server

SMF 2

Internal

Network

DMZ

SMF 1

Firewall Reverse Proxy

Firewall

Soap bus


April 20, 2006 Overview of the different LAN and access modes

Netwatcher on IPMP, Snaphot on Oracle SQL-net, Remote commands (RSH), Decnet (OSP 2.3-HPonly), …This LAN is totally private and doesn't permit any access to perform service management. Via theMCP, it's possible to perform platform management on this private LAN.

See “Remote access for field support” on page 6.

4. Remote access for field support

The Alcatel Field Support Team ("FBI") requires a remote access to the Multi Control Point ("MCP")and to all OSP servers, to be able to provide the support and maintenance services described inthe SLA.

Please refert to the OSP_FieldSupportSecurity_ed1 which explains all the different accessways which are validated and supported.

5. Sigtran Signalling network

This LAN is a dedicated/private/secured network (like SS7). It supports only Sigtran (M3UA)protocols on SCTP.


Securing the different access types April 20, 2006

2. Securing the different access types

The four kinds of access described in “Secured Corporate (Management or intranet) LAN access”on page 7 have to be distinguished and secured:

• Corporate (Management or intranet) LAN : access for service and platform management.• User LAN : access for service management (via SOAP on HTTP or HTTPS-Proxy).• OSP Private Internal LAN : No external access, only used for OSP process inter-communication.• Remote access via PSTN or vLan for field support.

1. Secured Corporate (Management or intranet) LAN access

1.1.Assessing the Risks

As there is no connection with an IP external network, this architecture is not vulnerable to externalnetwork attacks.But some statistics show that risks coming from the internal network itself are significant.These risks come from employees themselves and from the use of the services. These risks are forexample loss of data or data corruption (intentionally or not).To limit these risks, an OSP access security policy has to be defined and followed by the customer.

1.2.Intranet Security Policy

The Intranet security policy is then a matter of Authentication and Authorisation, in order to limitthe risks coming from the internal users themselves.We distinguish two kinds of users:

• Unix users• OSP operators.

Standard Unix users are created with OSP R2.4.02 (root, linus, oracle).OSP operators are defined in the database of the OSP Access service.Alcatel provides OSP R2.4.02 with security implementations and recommends some networkarchitecture for accesses, but a security policy has to be defined by the customer (operator of OSPR2.4.02) and is under his responsibility.The following aspects (not exhaustive) have to be taken into account when defining an Intranetaccess security policy:

• How do users interact with the OSP?• Who is allowed to use the resources?• Who is authorised to grant access and approve usage?• Who may have system administration privileges?• What are the users' rights and responsibilities?• What are the rights and responsibilities of the system administrator vs. those of the user?• What do you do with sensitive information?


April 20, 2006 Securing the different access types

1.3.Authentication and access control implementation

OSP R2.4.02 provides a password-based authentication mechanism. Before executing anycommand on the OSP platform and services, every operator has to authenticate himself byentering a dedicated login and password and he has to gain access to operator commands on theservice objects. The service objects and methods may vary according to the operator's profile(access control). The Access service provides this authentication and authorisation mechanism.The Access service is a SOAP server that:

• supports login, logout, modify password, login forced password • binds and unbinds service factories • validates the service factory for the session • manages the timeout of a service factory, as defined on the operator screen (in minutes).

Any session is divided in three steps:• login• work• logout.



Figure 2.1 - Commands flow of the Access service from the operator login.

1.4.Passwords management

The security policy can implement the password management in order to limit the risks ofimpersonation.The rules that follow are recognised standards for password syntax and management.

• DON'T use your login name in any form (as is, reversed, capitalised, doubled, etc.).• DON'T use your first, middle, or last name in any form or use your spouse or child's name.• DON'T use other information easily obtained about you. This includes telephone numbers, social security numbers, birthday dates, etc.• DON'T use a password of all digits, or all with the same letter.• DON'T use a word contained in English or foreign language dictionaries, spelling lists, or other lists of words.• DON'T use a password shorter than six characters.• Use a password with mixed-case alphabetic.• Use a password with non-alphabetic characters (digits or punctuation).• Use a password that is easy to remember, so you don't have to write it down.



1.5.Encryption & Integrity checking

As no access is performed from external IP networks and the local network is considered as a safeplace, no specific transmission encryption and integrity checking is needed.

1.6.Network segmentation & Protocol filtering

The management PC accesses the SOAP bus of OSP R2.4.02. Furthermore, switches are used inplace of hubs to limit the ability of hosts to receive network traffic that is not specifically directed tothem.

1.7.Operating System hardening and services limitation on the servers

All OSP servers are hardened. Only necessaries packages are installed on the machines. Securitypatches concerning the software installed on the servers are taken into account in each newBaseline release. Only the services necessary to the OSP are running on the servers. Other specific settings areimplemented to improve the security. A host based firewall (SunScreen) can be implemented on each server connected to the corporateintranet.

This information is part of the following Alcatel internal documents which can be obtainedon request:

Baseline (for OS minimization and security patches)Factory Settings (system hardening is part of "security sheet")

2. Secured User LAN access

When a service or a set of services running on OSP R2.4.02 need to be accessed and managed byoperators or end-users over the Internet, web servers can be used to access OSP. The serversbecome public web servers.These web servers are gateways that perform the translation between the protocols used onInternet (HTTP and HTTPS in particular) and the interfaces of OSP R2.4.02 (SOAP).The solutions presented hereafter are implemented or recommended in order to secure the HTTPto SOAP.First, the document describes how authentication and access control are ensured for both accesstypes.In a second step, the document describes the solution implemented to ensure data transferencryption over the Internet.Then the need of access filtering using firewalls as well as the need to insert a Demilitarised Zoneis described.Finally, a global security policy is proposed.



2.1.Authentication and access control

The same authentication and access control mechanisms than in the Intranet access are provided(See “Recommended Firewall solution” on page 33.).The picture below describes the exchanges.

Figure 2.2 - Overview of an Internet access to OSP R2.4.02 via SOAP on HTTP

2.2.Web server implementation

The following picture shows a possible configuration of an OSP WEB server with its DMZs betweenFirewall 1 and Firewall 2. In this picture, the DMZ plays a role of Reverse Proxy (HTTPS-HTTP),checks the Client Certificated and is a repository of Application Jar files, Java Server Pages.

Client Reverse Proxy

SOAP server SMP

HTTPS request (login+pwd) HTTP(S) request

(login+pwd)Soap connection phase

HTTPS response HTTP(S) response

HTTPS request(gcc command)

HTTPS response HTTP(S) response

HTTP(S) request(toc command)

Soap command phase

HTTPS request(gcc disconnect)

HTTPS response HTTP(S) responseSoap disconnect phase

HTTP(S) request(toc disconnect)



Figure 2.3 - Possible configuration of an OSP WEB server with its DMZs between Firewall 1 and Firewall 2.

2.3.Restrict the traffic between the public network and the Corporate intranet

To secure the network access, the web server(s) must be separated from the Internet by a Firewallsolution. It allows restricting the traffic between the external network and the Corporate intranet. Itthen prevents from many possible attacks, but it still allows anyone to access the authorisedservices on the web server.

2.4.Network segmentation

As the web server is a (set of) computer(s) intended for public access, there are potentially a lot ofpeople that can access or try to access this server from locations all over the world.Even if the access to the web server is protected by a firewall and if the server and its applicationsare correctly configured (according to the security requirements), there is always a risk that a newvulnerability appears and that someone tries to exploit it on your web server.If it occurs, we need to prevent the intruder from observing or capturing the internal OSP IP traffic,performing denial of service attacks in the internal network or obtaining information on servers ofthe internal OSP platform.To guard against these threats, the public web server(s) must be isolated from the OSP and thecorporate internal networks as well as from the public network (the Internet).



A network has then to be added between the internal network with sensible data (OSP platform)and an external network (the Internet) in order to provide an additional layer of security. It forms aDemilitarised Zone (DMZ), which prevents the external network from directly referencing theinternal network.The DMZ is delimited by the firewalls that filter the access from the external network to the DMZand by a firewall that filter the access from the DMZ to the internal network.

2.4.1. Servers in the DMZ

The only servers allowed in the DMZ are gateways that perform HTTP/HTTPS to HTTP relay. Theseservers are called reverse proxy servers or secure reverse proxy servers. End-users have only accesswith http or preferably https flows to the server(s) in the DMZ that translate the commands onanother protocol(s) and on a different sub-network. It significantly limits network access.

2.4.1.1. Reverse Proxy Server

A Reverse Proxy Server (RPS) accepts requests from clients located on the Internet for the local webservers. Reverse Proxy Servers are generally used as part of the security infrastructure. They are typicallyplaced between the Firewall servers and the Web server farm. The RPS receives all of the HTTPrequests passing through the firewall and passes them to the Web Server farm, thus preventingdirect client access to the Web servers, and consequently hiding the identity of the Web servers.An RPS provides protection from attacks that are launched to take advantage of vulnerability suchas buffer overflow, malformed packets, etc. Thus, the reverse proxy can protect a normallyvulnerable Web server.In addition, an RPS could be load balanced using NLB service, clustering technology, or a load-balancing appliance.

2.4.1.2. Secure Reverse Proxy Server

A secure reverse proxy server is the name given to an RPS like described above when it is usingHTTPS / SSL to communicate with the clients located on the Internet. This adds another tier to thesecurity architecture.

2.4.2. DMZ Topology

Two topologies are possible:• Screened Subnet Firewall• Multi-Homed Gateway Firewall



2.4.2.1. Screened subnet Firewall

Figure 2.4 - Example of screened subnet firewalls

The screened Subnet firewalls provide the most secured topology: a DMZ is inserted between theinternal network and the untrusted network. The outer firewall only permits access from the outsidenetwork (Internet) and the bastion host(s) (Web servers). The inner firewall only permits accessfrom internal network (OSP platform LANs) to the bastion host(s).Since the outer router only advertises the DMZ to the untrusted network, a host on the Internetcannot reach the internal network. The inner firewall advertises the DMZ to the internal network, itis not possible to reach the external network from the internal one.In this case, an intruder has to penetrate 3 separate systems to reach the internal network.

Advantages

Safer because there are two physically separate layers

Drawbacks

ExpensiveMore difficult to manage

Internet

Firewall

Firewall

ReverseProxyServer

SMF SLEE

Screened Subnet

Private Network

UntrustedNetwork



2.4.2.2. Multi-homed Gateway

Figure 2.5 - Multi-homed gateway

In case of Multi-homed gateway as described in the above picture, the same firewall having twoconnections with the DMZ replaces the firewall pair in the screened subnet firewall case.

Advantages

• Safer than Dual Home Gateway topology• Management

Drawbacks

The Central Gateway can become a bottleneck or single point of failure. Note that the Highavailability system answers this problem.

2.4.2.3. Conclusion

The multi-homed gateway is the recommended implementation of a DMZ, because it represents agood compromise between security, complexity (configuration and management) and cost.

Internet

Firewall

ReverseProxyServer

SMF SLEE

UntrustedNetwork

Secured Network

DMZ



2.5.Security policy

The security policy defines the services that must be explicitly allowed by the firewalls. All othernetwork services are then denied.The firewall must accept TCP connection on port 80 for HTTP and TCP connection on port 443 forSSL between the external network and the DMZ.Furthermore, filtering rules have to be established to block TCP connection originating from webserver to the external network. The reverse proxy server within the DMZ has only access via SOAP on HTTP located on the internalnetwork. The firewall must accept TCP connection on port 80 (or another port) for HTTP betweenthe DMZ and the internal network.The firewall technology must also be configured to block all the possible traffic between theinternal network and the external network and vice versa. The following table sums up theconfiguration of the multi-homed firewall.

Table 1: The configuration of the multi-homed firewall.

Sourceaddress

Destination address

Source port

Destination port

Service Protocol A/D

Any Reverse Proxy >1023 443 HTTPS TCP Allowed

Any Reverse Proxy >1023 80 HTTP TCP Allowed

Any Reverse Proxy >1023 8050 SOAP on HTTPS

TCP Allowed

Reverse Proxy

Any 80 >1023 HTTP TCP Allowed

Reverse Proxy

Any 443 >1023 HTTPS TCP Allowed

Reverse Proxy

Any 8050 >1023 SOAP on HTTPS

TCP Allowed

Reverse Proxy

HTTP/SOAP GW

* 8088 HTTP TCP Allowed

HTTP/SOAP GW

Reverse Proxy * 8088 HTTP TCP Allowed

Reverse Proxy

LDAP SERVER * 389 LDAP TCP Allowed

LDAP SERVER

Reverse Proxy * 389 LDAP TCP Allowed

Reverse Proxy

OSP SMF * 22 SSH TCP Allowed

OSP SMF Reverse Proxy * 22 SSH TCP Allowed



2.6.Operating System Hardening and Services Limitation

All OSP servers are hardened. Only necessary packages are installed on the machines. Securitypatches concerning the software installed on the servers are taken into account in each newBaseline release. Only the services necessary to the OSP are running on the servers. Other specific settings areimplemented to improve the security. For the Web Servers, they are more services removed than for OPS servers (see Factory Settings)A host-based firewall (SunScreen) can be implemented on each server connected to the corporateintranet.

This information is part of the following Alcatel internal documents which can be obtainedon request:

Baseline (for OS minimization and security patches)Factory Settings (system hardening is part of "security sheet")

2.7.Double LAN for HTTP flow

In order to support Ethernet switch failure (LAN failure), the System should manage a double LANbetween the external network and the reverse proxies in the DMZ.Furthermore, a double LAN should be managed between the reverse proxies in the DMZ and theHTTP gateways of OSP R2.4.02.The "duplex configuration" based on CheckPoint product (See “Alcatel Product Security IncidentResponse” on page 36.) is compliant to this requirement

3. Secured OSP Private LAN access

No firewalls are deployed on this private LAN. In case this private LAN is interconnected via aWAN (Mated Pair configuration), it is up to the customers to protect the OSP private LAN from theirWAN.

Reverse Proxy

OSP SMF * 123 NTP TCP Allowed

OSP SMF Reverse Proxy * 123 NTP TCP Allowed

Else : DENIED

Table 1: The configuration of the multi-homed firewall.

Sourceaddress

Destination address

Source port

Destination port

Service Protocol A/D



4. Secured Remote access for field support

Please refer to the OSP_FieldSupportSecurity_ed1 that explains all the different securedaccess ways which are validated and supported.

5. Secured access for Sigtran signalling network

This security lets to the owner of the sigtran signalling network.


Communication with the OSP April 20, 2006

3. Communication with the OSP

This chapter describes the different communications with the OSP, including security issues.A communication can be established:

•between a PC and an SMF, or•between a PC and a SLEE.

The SMF servers handle management messages and run on an SMF. The communication with theSMF is always SOAP-driven (Simple Object Access Protocol). SOAP messages are created by theclient and enter the OSP by going through the SOAP FEP, which forwards the message to the rightSMF server. The communication with a SLEE can be established through the DPE Router. A SEP located on aSLEE SMF can also receive SOAP messages through the SOAP FEP. Mass access is managed by a dedicated service and also uses SOAP protocol.

1. Communication with the SMF

This section describes the two main ways to communicate with the SMF.• Intranet communication with SMF based on HTTP SOAP, using a Java Web Start application.• Secured Internet communication with SMF through a 'Reverse Proxy' using either a Java Web Start signed application or a project-based thin client.

1.1. Intranet communication with the SMF based on SOAP

A direct communication based on SOAP is established between the PC and the SMF. For securityreasons, it is mainly used for intranet purposes. By default, the SOAP technology uses HTTPtransport, which does not encrypt data and is thus not secured. For secure communications,HTTPS must be used.The SOAP messages are generated by the OSP management application, which uses the JavaWeb Start technology. This application is installed on operator PC when connecting for the firsttime to the OSP Web server.SOAP messages are received by a SOAP FEP, which forwards them to the right SMF Server.

1.2. Secured Internet communication with the SMF via a ‘Reverse PROXY’

In this secured mode, two different ways of communication can be distinguished.• using a JAVA application• using a thin client.

In order to provide data encryption during communication with SMF, the HTTPS communicationprotocol is used to communicate with a reverse proxy. The reverse proxy will translate the HTTPSmessage into a HTTP message and forward it to the SOAP FEP.

Security Guidelines 3CL-02350-BBXX-BGZZA 19/42

April 20, 2006 Communication with the OSP

1.2.1. Advantages

• secured communication, encrypted with standard SSL (Secured Socket Layer).• firewall possibilities: there is only one port needed because of http(s). Internet communication is possible. Another port must be opened to receive direct notifications from the SMF, such as session timeout or alarms monitoring.• HTTPS has a tradition to scale to high volume communication

1.2.2. Drawbacks

• the response time increases because of encryption• the performance is reduced because of encryption• resources consumption is higher on PC and HTTPS server.

1.3. Why SOAP for PC to SMF communication?

1.3.1. Reasons of the choice

The choice of using the SOAP protocol for remote procedure calls (RPC) in Release 2.4 is justifiedby the following points:

• CORBA uses several ports to communicate. In Rel 2.3, Corba was used for communication between SMF and management PC. Corba needs to keep several ports opened to work, which is a problem for secure communications, through a DMZ (demilitarized zone) for instance. SOAP uses HTTP transport, which only needs 1 port opened. The HTTP-to-Corba gateway that was needed to go through firewalls caused strong decrease in Rel 2.3 performance. This gateway is not needed in the Rel 2.4 architecture.• A standard to define interfaces: the SOAP clients and servers are generated by WSDL files. WSDL is becoming the standard for web services definition. The standard is defined and maintained by W3C Organisation, which also defines and maintains other widely used technologies such as HTTP or XML.• An open and interoperable architecture: through WSDL files, SOAP clients and servers can be created independently on both sides, whatever the technology (C++, Java, .NET, MS Office,..), and can communicate easily thanks to XML encoding.• Based on robust technologies: SOAP uses XML encoding on HTTP transport. These two technologies have a proven record of value and efficiency.• Web services growth: Web services become more and more present across the Internet. The use of SOAP in OSP creates a link between IT and telephony.• Support in JAVA: the Web Service Development Pack from Sun provides tools to easily generate and deploy SOAP clients and servers. The only input needed is the WSDL file.• Support in Microsoft .NET® and MS Office® products: recent Microsoft® products fully support SOAP messages by providing the WSDL file.

20/42 3CL-02350-BBXX-BGZZA Security Guidelines


1.3.2. gsoap

The SOAP stack used in SMF servers is gSoap. This stack proves to be reliable and provides goodinteroperability with other stacks. The design is simple and efficient. It integrates easily with theplatform since it is an open source product. Updates are frequent and include bug fixes andprotocol evolutions.It is directly integrated in the SMF server processes. The OSP toolchain automatically generates theserver and WSDL files.

1.4. Java Web Start

The communication between PC and SMF is made by exchanging SOAP messages. A brand newJava application is provided to easily generate the SOAP requests by simply filling fields in theapplication GUI (Graphical User Interface).This management application and its components are stored on the OSP web server. This includesseveral Jar files (Java classes containers), deployment scripts (JNLP files) and properties files.The operator can install the application automatically, by downloading the main deployment scriptlocated on the web server through a browser.After the application is installed, no browser is needed anymore: the PC to SMF communicationhappens through the management application.

1.4.1. Difference between Java applications and Java applets

A standard Java application is made of 'class' files, which may be zipped into JAR files. Anapplication runs by starting a Virtual Machine, providing the classes and specifying the class torun. This requires a copy of the application on the local drive or network. Such applications havethe right to do anything on your computer because the user is supposed to know the applicationand trust it.Applets are applications that are located on a web server and are downloaded before runninginside your browser. The application is not installed on the local drive; it is always up-to-date, sincethe user has to download it every time it has to be executed. But the download time can beimportant for complex applications. Moreover, you must use a browser to run the applet.Standards applets have restricted rights on the local computer since it can come from an untrustedsource.

1.4.2. Presentation of Java Web Start

Java Web Start is a technology developed by Sun Microsystems and available in the standard JavaRuntime Environment 1.4.2, and later. It gives the opportunity to mix both application and applettechnologies. A standard application is created, packaged in one or several JAR files and storedon a web server. The application and its content are described in deployment scripts in JNLP (JavaNetwork Launching Protocol) format. They contain the list of files, the parameters of theapplication and the context to execute it. Once a Java Runtime Environment 1.4.2 or later is installed, the user's PC is able to recognizeJNLP files downloaded from the Internet, through a MIME association. After the JNLP file isdownloaded, Java Web Start downloads all the JAR files needed by the application. If the JAR files



have already been downloaded before, Java Web Start only downloads new files or files that havechanged since last execution. The application runs on the local PC when the cache is up to date.The Java Web Start technology allows having a large application that is easily deployed and isconstantly updated. More specifically, the OSP management application is described in a JNLP filelocated on the OSP web server. The first launch of the application may take a long time since itneeds to be fully downloaded and put into cache, but next executions will start faster than with anapplet, while staying fully in line with the software stored on the SMF.

1.4.3. Signing

1.4.3.1. Description

Applets or Java Web Start applications are downloaded from the Internet. As such, they come froman untrusted and potentially harmful environment. For this reason, downloaded software runs bydefault into a restricted environment where it is not possible to access local resources (drives,printers…).Signing is a technology developed to increase the confidence in downloaded code and to lift somelimitations of the runtime environment. In the case of the OSP management application, acertificate allows lifting all limitations, with the user's agreement: the application can then storeand load data on local drives, print documents, access the clipboard…

1.4.3.2. Signed applet

A signed applet or signed application is an applet or application with a digital signature thatserves two main purposes:

• it identifies the applet or application signer, who should be the person or organisation that developed this applet or application.• it prevents tampering by detecting if the applet or application has been modified by someone other than the signer.

The applet or application and a signature are separate pieces of information. An ordinary appletor application becomes signed when it is bundled together with a certificate. This implies thatwhether an applet or application is signed does not depend on the applet or application code.Using a signed application implies that the application code is granted access to the resources ofthe PC. This means that the application can have access to the file management, printmanagement and communication management. An ordinary application started with Java WebStart is only allowed to perform display activities.Before using a signed application, the user must grant the privileges the certificate asks for. This isdone when the application starts.

Signing application is only needed when the application is downloaded (Java Web Starttechnology). If the same application starts from the local drive or network, no certificate is neededto access computer resources.



1.5. Intranet communication for OSP 2.4 Management Application

The OSP is managed by sending SOAP commands to the SMF. This is done by using the OSP 2.4management application. This application is deployed using the Java Web Start technologydescribed above.

Figure 3.1 - Client PC to SMP communication based on SOAP and using a signed application deployed by Java Web Start

Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.

Table 1: Legend of Figure 3.1 - Communication process .

Stage Description

1 The Java Web Start deployment script (JNLP files) is downloaded from the OSP Web server by

• the Java Web Start Application Manager (1a) or • a browser (1b).

2 A Java Web Start execution environment starts, with the JNLP files as parameters.

3 The Java Web Start execution environment checks the cache.

4 All jar files that are described in the JNLP files must be in cache. Missing files and files that are not up-to-date are downloaded from the Web server by the Java Web Start execution environment.

5 The Java Web Start execution environment executes the application.

PC

JVM 1.4.2 or later

Browser

Java WebStartApplication Manager

Cache

Java WebStartExecution Environment

OSP 2.4 ManagementApplication

Web Server

SMF

SOAP

FEP

SMF

SERVER

JNLP Files

Application JARFiles Repository

HTTP

HTTP

HTTP

HTTPSOAP

HTTPSOAP

TCP/IP XML

DPEXML

DPEXML

1a

1b

4

2

3

5

6

6

7

7

8

Intranet

Intranet

8

PC

JVM 1.4.2 or later

Browser


Cache



Web Server

SMF

SOAP

FEP

SMF

SERVER

JNLP Files


HTTP

HTTP

HTTP

HTTPSOAP

HTTPSOAP

TCP/IP XML

DPEXML

DPEXML

1a

1b

4

2

3

5

6

6

7

7

8

Intranet

Intranet

8



The web server and the SMF can be located on the same machine or on different machines.In this situation, port 80 is used for HTTP communications between PC and web server. Port 8088is used for SOAP communications between PC and SOAP FEP.In OSP 2.4, the SMF is able to send messages to a PC. The messages are addressed to a specificclient session on that PC. This means that a session must be opened for the PC to receivemessages from the SMF. Such messages are needed for alarm monitoring, session timeoutnotifications, and so on. To receive these messages, some ports are allocated on the management PC. One port is used foreach session running on the PC, starting from port 8088. This means that if you have a PCrunning 3 sessions, ports 8088, 8089 and 8090 will be allocated for monitoring messages.It is possible to run local management sessions. In that case, you don't need any connection to theSMF.However, the login used for the local session must have been used at least once on that PC before,so that the profile rights of the operator are stored on the local machine.At the end of a local session, the user has the choice to save the SOAP commands generated in afile for later execution, or to log to the SMF and execute them at once.It is also possible to install the application without web access, from a CD or a LAN, for example.This is useful when the connection is slow. In that case, it is not possible to make any upgrade fromthe Web server. A new CD must be provided for every upgrade.

1.6. Secure communication for OSP 2.4 Management Application

The OSP 2.4 management application is also able to generate SOAP commands over HTTPS. Thismeans that the SOAP messages are secured by SSL encryption over HTTP. The confidentiality of theinformation contained in the SOAP message is then guaranteed.

The Java classes generate a SOAP request that is sent through the FEP SOAP to an SMF Server.

The SMF Server sends the SOAP answer through the FEP SOAP to the client PC. The answer is handled by the Java classes.

The SMF sends a notification or a monitoring message to the PC (see below).

Table 1: Legend of Figure 3.1 - Communication process (Continued).

Stage Description



Figure 3.2 - PC communication with SMF through a reverse proxy using HTTPS

A reverse proxy is used to mask the SMF and/or the Web server from the application user, but alsoto transform HTTPS into HTTP. The functions assumed by the reverse proxy are:

• Hide the OSP network from the untrusted environment.• HTTPS to HTTP gateway. The reverse proxy must transform the encrypted message (HTTPS) so that the SOAP FEP can manage it. The SOAP FEP is only able to handle HTTP messages. • Firewall. Protects the OSP network from external attacks. Some specific ports must be opened in the firewall (see next paragraph for more information).• Load balancing. The messages coming from the external world can be distributed to several SOAP FEPs. This is particularly useful for mass access.

Firewall and load balancing functions are not required functions. In the previous figure, thereverse proxy can assume all or only some of the functions. The Web server can be behind areverse proxy or not.Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.

Table 2: Legend of figure 3.2 - Communication process .

Stage Description

1 The Java Web Start deployment script (JNLP files) is downloaded from the OSP web server by

• the Java Web Start console (1a) or• a browser (1b).

2 A Java Web Start execution environment starts, with the JNLP files as parameters.

DMZWeb Server

JNLP Files


HTTP

HTTPHTTP

HTTP

HTTP

TCP/IP XML

1b

PC

JVM 1.4.2 or later

Browser


Cache



2

3

5

SMF

SOAPFEP1

SMF

SERVER

DPE

DPE

7

8

10

SOAPFEP2

ReverseProxy

ReverseProxy

4

1a

1b

77

DPE78

HTTP

9

10

4

6

INTERNET

INTRANET

INTRANET

HTTP(S)

HTTP(S)

HTTP(S)

HTTP(S)

HTTP(S)

TCP/IP XML

1a

Firewall Firewall

DMZWeb Server

JNLP Files


Web ServerJNLP Files


HTTP

HTTPHTTP

HTTP

HTTP

TCP/IP XML

1b

PC

JVM 1.4.2 or later

Browser


Cache



2

3

5

SMF

SOAPFEP1

SMF

SERVER

DPE

DPE

7

8

10

SOAPFEP2

ReverseProxy

ReverseProxy

4

1a

1b

77

DPE78

HTTP

9

10

4

6

INTERNET

INTRANET

INTRANET

HTTP(S)

HTTP(S)

HTTP(S)

HTTP(S)

HTTP(S)

TCP/IP XML

1a

Firewall Firewall



Stage 10 is optional. The firewall can be configured to block the messages coming from the SMF.It depends on the functionality needed in the untrusted area. If no monitoring or notification isneeded, these messages can be blocked.The reverse proxy must be configured to transform HTTPS messages (port 443) to HTTP messageson port 8088, because the SOAP FEP is only able to understand HTTP messages emitted on thatport. Firewalls must also be configured to let messages go through these ports. If the firewall is betweenthe reverse proxy and the PC, port 443 must be opened from PC to SMF. If the firewall is betweenthe reverse proxy and the SOAP FEP, port 8088 must be open from PC to SMF.For communication with the web server, port 80 must be opened for communication from PC toSMF. If HTTPS is also used on the web server, port 443 must be opened. If the client PC needs monitoring or SMF notifications (such as session timeout), port 8088 must beopened from SMF to PC also. If several client sessions must be opened for monitoring or SMFnotifications from the same PC, the same number of ports must be opened from SMF to PC,starting from 8088. Monitoring messages and SMF notifications are not encrypted.Example 1:You have 2 PCs running the management application. The first PC uses one client session withoutmonitoring. The second PC uses 3 client sessions without monitoring. The following ports must beopened in the firewall:

3 The Java Web Start execution environment checks the cache.

4 All jar files that are described in the JNLP files must be in cache. Missing files and files that are not up-to-date are downloaded from the web server by the Java Web Start execution environment.

5 The Java Web Start execution environment executes the application.

6 The JAVA classes generate a SOAP request that is sent through the Internet to a reverse proxy.

7 The reverse proxy transforms the HTTPS request into a HTTP request. The request is then sent to a SOAP FEP according to load balancing rules.

8 The SMF Server sends the SOAP answer through the SOAP FEP to the reverseproxy.

9 The reverse proxy encodes the HTTP SOAP message into a HTTPS SOAP messageand forwards it to the client PC. Answer is treated by the JAVA classes.

10 The SMF sends a notification or a monitoring message to the PC. This messagecan be blocked by the firewall function of the reverse proxy according to theopened ports (see below).

Table 2: Legend of figure 3.2 - Communication process (Continued).

Stage Description



Example 2:You have 2 PCs running the management application. The first PC uses one client session withmonitoring. The second PC uses 3 client sessions, with 1 monitoring session. The following portsmust be opened in the firewall:

Example 3:You have 2 PCs running the management application. The first PC uses the one client session withmonitoring. The second PC uses 3 client sessions, with 3 monitoring session. The following portsmust be opened in the firewall:

If HTTPS is used, port 443 must also be opened in the previous tables.

Table 3: Example 1

Port Direction

80 PC to SMF.

8088 PC to SMF.

Table 4: Example 2

Port Direction

80 PC to SMF.

8088 Both directions.

Table 5: Example 3 .

Port Direction

80 PC to SMF.

8088 Both directions.

8089 SMF to PC.

8090 SMF to PC.



1.7. Thin client and mass access communication

1.7.1. Definition of thin client

We call 'thin client' a client that requires little resource from the local computer. We are usuallytalking about HTML pages for thin client management. It is most of the time used for subscriberaccess, which therefore means mass access to the SMP with few commands per session.OSP 2.4 offers a new service dedicated to high management traffic, called Mass Access(pfmmassaccess).

1.7.2. Description of thin client

Thin client pages may be plain HTML pages located in a Web server and containing the SOAPrequests, but they are most often generated by some tools, such as HTTP servlets or JSP. Whateverthe technology used to get the HTML pages, they have to generate SOAP requests that the SOAPFEP can understand and route to the mass access server.

1.7.3. Mass Access service presentation

The Mass Access service maintains a small number of pfmaccess sessions to create a profile andmanagement context shared among a number of mass access users (we assume a large numberof users). The pfmaccess sessions created by the Mass Access service have the authorisation toaccess several SMF servers of the same service. When trying to send SOAP commands, a MassAccess user directly addresses the Mass Access service, which performs an authentication based ona LiteSCE script. The service then gives the user access to one of the pfmaccess sessions itmaintains.



1.7.4. Communication process

Figure 3.3 - Mass access communication from a thin client page to the SMF through a revers proxy using HTTPS



Stage Description

1 A user wants to post some data. An html page in the browser sends the data to the OSP web server. The request is encrypted in HTTPS.

2 The reverse proxy forwards the message in HTTP to the web server.

3 Optional step: the code is provided as a JavaServer Page (jsp) and requires to be compiled to a servlet (Tomcat).

4 A SOAP request is needed. Local jar files contain the stubs.

5 The SOAP request is sent to the SMF.

6 The SOAP FEP routes the message to the Mass Access Service.

7 The Mass Access service authenticates the user and forwards themessage to the right SMF server.

8 The response is sent to the SOAP FEP.

9 The response is forwarded to the servlet engine.

DMZWeb Server

Servlet Engine (TomCat)


PC

Browser

SMF

SOAP FEP

SMF SERVER

ReverseProxy

HTTPS

MASS ACCESS SEP

JavaServerPages

2

11 10

1

4

3

SOAP DPE

SOAP DPE

SOAPDPE

SOAP HTTP

INTRANET

INTERNET

HTTP

HTTPSHTML

HTTP HTML

5 9

86

7

Firewall Firewall

DMZWeb Server



PC

Browser

SMF

SOAP FEP

SMF SERVER

ReverseProxy

HTTPS

MASS ACCESS SEP

JavaServerPages

2

11 10

1

4

3

SOAP DPE

SOAP DPE

SOAPDPE

SOAP HTTP

INTRANET

INTERNET

HTTP

HTTPSHTML

HTTP HTML

5 9

86

7

DMZWeb Server



PC

Browser

SMF

SOAP FEP

SMF SERVER

ReverseProxy

HTTPS

MASS ACCESS SEP

JavaServerPages

2

11 10

1

4

3

SOAP DPE

SOAP DPE

SOAPDPE

SOAP HTTP

INTRANET

INTERNET

HTTP

HTTPSHTML

HTTP HTML

5 9

86

7

Firewall Firewall



2. Communication with the SLEE

For some applications, it may be interesting to access the service script in the SLEE directly via theDPE Router. It is also possible to access a SEP located in a SLEE via SOAP.

2.1. Communication with the SLEE via DPE router

In order to be able to directly access the service script in the SLEE, a secured Internetcommunication can be setup between a thin client PC and the SLEE via the DPE Router.

Figure 3.4 - Secured Internet thin client communication with the SLEE through an HTTP-to-DPE gateway


10 An HTML page based on the SOAP response is created by the servletand sent to the browser over HTTP.

11 The HTML page is encrypted in HTTPS.

Table 6: Legend of figure 3.3 - Communication process (Continued).

Stage Description

Internet

Secured (SSL)

Firewall

Demilitarised Zone

HTTP(S) request

HTTP(S) answer

HTMLPage

Servlet

HTTP(S)Server(Html Page)

DPE answer

toHTTP answer

HTTP requestto

DPErequest

11

2 23

455

SLEE

DPERouter



In this mode, • the security is guaranteed due to SSL encryption• firewall possibility is available• no certification is needed• mass access is possible• servlet/html page has to be developed and is service specific.

2.2. Communication with the SLEE via SOAP

SOAP requests can be sent directly to a SEP located in a SLEE SMF. This possibility is used inparticular by web services.

2.2.1. Web service architecture

From an architectural point of view, a Web service in the OSP is simply a standard servicereceiving an object encoded in a SOAP message. The way of working is the same as with otherservices.A standard service, using DPE encoding for objects, can be easily transformed into a web serviceby simply inserting the SIB that decodes the object from a SOAP message. This way you can havea service triggered by DPE messages, SOAP messages or both.The SOAP message must first come to the SOAP FEP that will forward it to the right SEP. Themessage arrives in the SEP, is decoded and transformed into a standard object. The rest of theservice can handle the object indifferently, whether it comes from a SOAP or DPE message.


Stage Description

1 HTML Page is downloaded from HTTP(S) server.

2 HTTP(S) requests are generated by the browser. HTTP(S) requests are sent through the Internet and a firewall to the DMZ (demilitarised zone) where they are decrypted.The 'HTTP-to- DPE gateway' is a servlet translating the HTTP requests into DPE requests.

3 DPE requests are sent to the SLEE via the DPE router.

4 DPE answers are sent to the 'HTTP-to-DPE gateway'. The servlet translates the DPE answers into HTTP anwers.HTTP answers are encrypted into HTTP(S).

5 HTTP(S) answers are sent through the firewall on the Internet to the client PC. The answer is managed by the browser.



2.2.2. Communication process

Figure 3.5 - Secured Internet thin client communication with SLEE using SOAP with HTTPS through a reverse proxy

Legend: we do not develop the thin-client architecture that has already be discussed in the previouspages. We limit the description to the process of a client sending a SOAP message.

Table 8: Process of a client sending a SOAP message .

Stage Description

1 A thin client emits a SOAP request, encrypted in HTTPS.

2 The reverse proxy transforms the message into an HTTP message.

3 The SOAP FEP routes the message to the right SEP.

4 The Web Service SEP sends the response to the SOAP FEP.

5 The SOAP FEP forwards the message in HTTP.

6 The reverse proxy encodes the message in HTTPS.

7 Another SEP in the network sends an object to the Web Service SEP. The DPE object is treated the same way as the object encoded in a SOAP message.

8 The response is sent through DPE.

DMZ

PC

BrowserReverseProxy

SOAPHTTPS

6

1

SLEE

SOAP FEP

Standard SEP

Web Service(SOAP-enabled SEP)

8

SOAP DPE

SOAP DPE

INTERNET

SOAPHTTP

INTRANET

4

7

2

5

3

Authentication(LDAP)

Accounting

Authorisation

FirewallFirewall

SOAPHTTP

SOAPHTTPS

DMZ

PC

BrowserReverseProxy

SOAPHTTPS

6

1

SLEE

SOAP FEP

Standard SEP

Web Service(SOAP-enabled SEP)

8

SOAP DPE

SOAP DPE

INTERNET

SOAPHTTP

INTRANET

4

7

2

5

3

Authentication(LDAP)

Accounting

Authorisation

FirewallFirewall

SOAPHTTP

SOAPHTTPS


Recommended Firewall solution April 20, 2006

4. Recommended Firewall solution

This chapter describes the firewall solution validated and supported by Alcatel.The firewall and secure reverse proxy are implemented on a simplex or duplex Intel 32 bitmachine (HP or Sun) running the CheckPoint VPN-1/FireWall-1 software. The duplex is a multientry point, where there is no single point of failure. Alcatel has validated the CheckPoint product(See “Alcatel Product Security Incident Response” on page 36.), for which a specific Baseline andFactory Settings are defined (available on request).The Checkpoint SecurePlatform operating system is a minimised and hardened version of RedhatLinux 7.2 (kernel 2.4.9-13).The firewall can be managed with a GUI client (SmartDashBoard) running on a Windows OS,used mainly to define the topology of the network and to install the secure policy.This secure policy is the base of the firewall: on these rules, the firewall is capable to access,analyse and utilise the communication information (all 7 layers), the communication-derived state(from previous communications), application-derived state and information manipulation. So the filtering is not decided on a simple isolated packet. This way the firewall ensures the highestlevel of security. Firewall log events generated by the syslog daemon are passed to the OSP syslogserver (PSMF). The firewall is configured as a reverse Proxy ("clientless VPN"). This enables establishing anencrypted session with an SSL-enabled Web browser, such as Microsoft Internet Explorer (5.0 SP2and above) or Netscape Navigator (4.8 and above).The Internet Explorer default certificate or other certificates (eg. The VPN-1/FireWall-1 InternalCertificate Authority or Verisign ) can be used to authenticate the user.When an OSP management PC connects with a web browser to the OSP, the data between thefirewall and the OSP Management will be encrypted using SSL (HTTPS), whereas the data in thesecure network will remain in clear text (HTTP). The firewall works like a reverse proxy, becausethere is no direct connection from a user to the dedicated server.

1. Simplex configuration

The simplex configuration is a very secure and easy to configure solution. It consists out of oneCheckpoint VPN-1/FireWall-1 and a smartcenter server module. The firewall is then managed viaa GUI interface somewhere in the entire network that will connect to the smartcenter server of thatfirewall.


April 20, 2006 Recommended Firewall solution

The picture below shows the simplex configuration:

Figure 4.1 - Firewall and Secure Reverse Proxy in simplex configuration

2. Duplex configuration

With the duplex we have a configuration of two firewalls. This is configured as a Multi Entry Point,meaning there is more than one-entry point to the OSP platform. That leads to a more complexway of configuring the network itself.However, nothing else is needed to define the secure policy. The big advantage is here that weavoid a single point of failure and have an even more reliable secure solution.

Internet

SOAP serverSMF 2DMZ SMF 1

SLEE 2SLEE 1

OSP Private Network

Corporate Intranet

FEP SOAP

HTTPS

HTTPS

HTTPSHTTP

OSP R2.4.02

PLMN or

PSTN

...

PC forremote

connections

Alcatel’s support center

Serial links towards each OSP server

Management PC&

Untrusted ApplicationsManagement PC

&Trusted Applications

Firewall and SecureReverse Proxy


Recommended Firewall solution April 20, 2006

The picture below shows the duplex configuration:

Figure 4.2 - Firewall and Secure Reverse Proxy in duplex configuration

Internet

SOAP serverSMF 2DMZ SMF 1

SLEE 2SLEE 1

OSP Private Network

Corporate Intranet

FEP SOAP

HTTPS

HTTPS

HTTPSHTTP

OSP R2.3.08

PLMN or

PSTN

...

PC forremote

connections

Alcatel’s support center

Serial links towards each OSP server

Management PC&

Untrusted ApplicationsManagement PC

&Trusted Applications




April 20, 2006 Alcatel Product Security Incident Response


5. Alcatel Product Security Incident Response

The Alcatel Product Security Incident Response Team (A-PSIRT) is the organization within Alcatel,under the leadership of the Product Security Officer (PSO), that enables Alcatel to respond in atimely and effective fashion to security vulnerabilities that (may) impact any Alcatel product. The overall process followed by the A-PSIRT for every Alcatel Product is described on the AlcatelIntranet Web Site of the Network Strategy Group.A dedicated team within Alcatel, called Security Incident Watch Team (SIWT) is permanentlymonitoring all security incidents, weakness reports, warnings, … reported by various channels(CERT, Alcatel Suppliers, Customers, …) and ensures the PSO is aware of all such issues.Alcatel statements on security risks (whether responses or advisories to customers) can be sent tocustomers via different channels. Regardless of the channel, the source material for the message isalways the same and is provided via the PSO web page.

April 20, 2006


List of figures

Figure 1.1 -Different LAN and access modes ............................................................... 3Figure 1.2 -Access to OSP from Internet via a reverse proxy ......................................... 4Figure 1.3 -Access to OSP from Internet via a reverse proxy ......................................... 5Figure 2.1 -Commands flow of the Access service from the operator login. ................... 9Figure 2.2 -Overview of an Internet access to OSP R2.4.02 via SOAP on HTTP ........... 11Figure 2.3 -Possible configuration of an OSP WEB server with its DMZs between Firewall 1 and Firewall 2. ........................................................................................................ 12Figure 2.4 -Example of screened subnet firewalls ...................................................... 14Figure 2.5 -Multi-homed gateway ............................................................................. 15Figure 3.1 -Client PC to SMP communication based on SOAP and using a signed applica-tion deployed by Java Web Start ............................................................................... 23Figure 3.2 -PC communication with SMF through a reverse proxy using HTTPS ........... 25Figure 3.3 -Mass access communication from a thin client page to the SMF through a revers proxy using HTTPS ................................................................................................... 29Figure 3.4 -Secured Internet thin client communication with the SLEE through an HTTP-to-DPE gateway ........................................................................................................... 30Figure 3.5 -Secured Internet thin client communication with SLEE using SOAP with HTTPS through a reverse proxy ........................................................................................... 32Figure 4.1 -Firewall and Secure Reverse Proxy in simplex configuration ...................... 34Figure 4.2 -Firewall and Secure Reverse Proxy in duplex configuration ........................ 35

April 20, 2006

Index of Topics

AAlcatel Product Security Incident Response 36Applet

Description 21CCommunication with the OSP 19Communication with the SLEE 30Communication with the SLEE via DPE router 30Communication with the SLEE via SOAP 31Communication with the SMF 19Corporate LAN access

Assessing the risks 7Authentication and access control implementation 8Description 4Encryption and integrity checking 10Intranet security policy 7Network segmentation and protocol filtering 10Passwords management 9

DDMZ

Topology 13FFirewall solution 33Ggsoap

Description 21IIntranet communication with the SMF based on SOAP 19JJava application

Description 21Java Web Start

Presentation 21LLAN and access modes

OSP2.4.02 ones 3Types 3

MMass Access service

Presentation 28Multi-homed gateway

Advantages 15Descritpion 15


April 20, 2006

Drawbacks 15OOSP private LAN

Description 5Secured 17

RRemote access for field support

Description 6Secured 18

Reverse ProxySecured Internet communication 19

Reverse Proxy server 13SScreened subnet firewall

Advantages 14Description 14Drawbacks 14

Secure reverse proxy server 13Secured Internet communication with the SMF 19Servers

DMZ 13Signed applet

Definition 22Use 22

Signed applicationDefinition 22

SigningDescription 22

Sigtran signalling networkDescription 6Secured 18

SOAPChoice reasons 20

TThin client

Definition 28UUser LAN access

Authentication and access control 11Description 5Double LAN for HTTP flow 17Network segmentation 12Operationg System hardening and services limitation 17Restrict the traffic 12Security policy 16Web server implementation 11


April 20, 2006

WWeb service

Architecture 31


April 20, 2006

Document References

Document title

OSP 2.4.01S Security Guidelines

Reference number

3CL-02350-BBXX-BGZZA

Status

Draft

Current edition

Draft03

Date of current edition

04/08/05

History

History of changes

Edition Date Authors Editor Appraisor

Draft03 04/08/05 Thierry DemontyAlcatel

Sophie EvrardAlcatel

Lisiane GoffauxAlcatel







Edition Changes note DDTS ID

01 • Added:3. Communication with the OSP

This chapter was extracted from OSP 2.4 Architecture andFunctionality. The aim is having one single documentdealing with security.

NA


April 20, 2006

42

Disclaimer

All rights reserved. Passing on and copying of this document, use and communicationof its contents not permitted without written authorisation from Alcatel.A8690 OSP is a registered trademark of Alcatel.The other marks and product names cited are the service marks or registeredtrademarks of their respective owners.The information in this documentation is subject to change without notice. If you findany problems in the documentation, please report them to us in writing. Alcatel doesnot warrant that this documentation is error free.

Address

Alcatel lAvenue Comte de Smet de Nayer, 145000 Namur, Belgium

42

Draft Draft version NA

Edition Changes note DDTS ID

/42 3CL-02350-BBXX-BGZZA OSP2.4 Security Guidelines

osp 24 security guidelines draft 03

Documents