thales_toip teoz_ white paper_en ed5.0

Upload: cristian-rozas

Post on 05-Apr-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    1/28

    p. 1/28RSS/SSI/TeS/DCF/FH-PhD,07/32 April 2010Les informations contenues dans ce document demeurent la proprit du groupe THALES and ne doivent pas tre divulgues par le destinataire destiers sans laccord crit de THALES.Information contained in this document is the exclusive property of THALES Group and cannot be disclosed to a third party by the user without writtenauthorisation given by THALES Communications

    WHITEPAPER

    ToIP PROTECTION

    Edition 5.0

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    2/28

    Edition 5.0 April 20102 / 28

    1. TOIP AND SERVICE SECURITY __________________________________________3

    1.1 ToIP architectures and protocols Introduction___________________________________ 31.1.1 H.323 protocol___________________________________________________________________ 31.1.2 SIP (Session Initiation Protocol) _____________________________________________________ 31.1.3

    MGCP (Media Gateway Control Protocol)_____________________________________________ 3

    1.1.4 Proprietary technologies ___________________________________________________________ 4

    1.2 ToIP services_______________________________________________________________ 4

    1.3 ToIP security: background and stakes______________________________________ 51.3.1 From ISDN to ToIP_______________________________________________________________ 51.3.2 The challenges___________________________________________________________________ 51.3.3 The security stakes _______________________________________________________________ 61.3.4 2009 and 2010: the critical years_____________________________________________________ 8

    2. WHAT PROTECTION FOR TOIP? _________________________________________9

    2.1 Functional security blocks_____________________________________________________ 92.1.1 Network segmentation_____________________________________________________________ 92.1.2 Access control at the edge of the data network_________________________________________ 102.1.3 Access control at the edge of the telephony network ____________________________________ 102.1.4 Network authentication ___________________________________________________________ 102.1.5 Integrity and confidentiality of signaling and communications ____________________________ 102.1.6 Server and application authentication ________________________________________________ 102.1.7 Core filtering in front of servers: stream safety_________________________________________ 10

    2.2 Focus: an application-layer filter to protect ToIP servers __________________________ 11

    2.3 SBC, edge firewall, application-layer firewall ____________________________________ 112.3.1 Edge firewalls __________________________________________________________________ 112.3.2 Session Border Controller (SBC) ___________________________________________________ 122.3.3 Application-layer protection for servers ______________________________________________ 122.3.4 Conclusion ____________________________________________________________________ 14

    3. TEOZ: APPLICATION-LAYER SECURITY SOLUTION FOR TOIP _______________16

    3.1 TMZ: a sanctuary for voice and video applications _______________________________ 163.1.1 TMZ _________________________________________________________________________ 163.1.2 TMZ partitioning________________________________________________________________ 173.1.3 Two filtering levels ______________________________________________________________ 17

    3.2 Real-time IP application-layer analysis: Protocol Expert Module (PEM) ______________ 183.2.1 Stateful IP filtering ______________________________________________________________ 193.2.2 Application-layer analysis_________________________________________________________ 213.2.3 Contextualized signatures IDPS ____________________________________________________ 213.2.4 Synthesis ______________________________________________________________________ 223.2.5 ToIP threats Examples in Layers 3-7 _______________________________________________ 23

    3.3 Usage analysis and control: Session Expert Module (SEM) ________________________ 253.3.1 Description ____________________________________________________________________ 253.3.2 Supported protocols _____________________________________________________________ 263.3.3 Examples of threats prevented by the SEM function ____________________________________ 26

    3.4 Synthesis __________________________________________________________________ 26

    4. CONTACT INFORMATION _____________________________________________28

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    3/28

    Edition 5.0 April 20103 / 28

    1. ToIP and service security

    1.1 ToIP architectures and protocols Introduction

    1.1.1 H.323 protocol

    The H.323 protocol is the ITU Standard for audio-visual communication sessions on any IP networktransmission. The H.323 protocol is currently associated with additional standards as H.225 (signaling)and H.245 (codec selection). To complement fax and data, RTP (Real-time Transport Protocol) is usedfor sending or receiving multimedia information. Further standards, as H450, provide supplementaryservices: call transfer, call forwarding, call hold, call waiting

    The H.323 system is composed of end-points, terminals, gateways, and gatekeepers (address resolutionand bandwidth control).

    H.323 is the most commonly deployed ToIP (Telephony over Internet Protocol) protocol and is widelyused within Internet real-time applications such as NetMeeting. However SIP (Session Initiation Protocol)will probably become the more prevalent protocol in the years to come.

    1.1.2 SIP (Session Initiation Protocol)

    The SIP protocol is the IETF standard initially designed to create two-party or multiparty sessions. SIP isprimarily used in ToIP applications; it is also used in application-layer sessions. The SIP roadmap allowsits use in other media streams as video conferencing, video according to the development policy of themanufacturers.

    SIP is a text-based protocol, similar to HTTP, which can run on TCP, UDP or SCTP.

    SIP includes end-points (terminals, user agents (UA)), proxy servers or redirect servers, locationservers and registrars. These last two servers can be hosted in the proxy server.

    SIP has been selected as ToIP protocol for the fixed-mobile convergence of the IMS (IP Multimedia

    Subsystem) architecture defined by 3GPP and was then accepted for the TISPAN architecture asdesigned in ETSI.

    TISPAN and IMS have chosen other solutions for ToIP security: SIP is using TLS for TISPAN and isusing IPSec for IMS.

    1.1.3 MGCP (Media Gateway Control Protocol)

    MGCP is a client-server protocol developed by Telcordia and Level 3 Communications, unlike SIP andH.323 that operate in peer-to-peer or client-client modes.

    MGCP was first used by American cable operators who wished to add phone services to their cable TVofferings. MGCP is a stimulus protocol, the endpoints being "low-intelligence" devices: the protocol is onlyused to carry keystroke information from the subscribers set to a central server. The server will theninterpret the keystrokes to execute the corresponding actions.

    This protocol can then be used with all (analog or digital) terminals already installed at the clientsfacilities, and ToIP services can be deployed without impacting the existing terminal population.

    Similarly, ADSL Internet access providers and Centrex IP operators use this protocol: the central servercontrols the subscribers set.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    4/28

    Edition 5.0 April 20104 / 28

    1.1.4 Proprietary technologies

    Although standard protocols as SIP are the most widely used, the offers of many ToIP providers arebased on proprietary technologies.Example:

    Cisco: Skinny Client Control Protocol (SCCP or Skinny) Nortel: Unisteam

    Mitel: Minet

    Alcatel-Lucent: Universal Alcatel (UA)

    Siemens: Hipath Feature Access (HFA)

    These protocols often derive from ISDN technologies and consist in a transition to IP, their objectives areto:

    Keep a functional phone system, identical to the existing ISDN, that what the standard protocolswere not capable of at the beginning

    Ensure smooth transition from ISDN to IP

    Ensure a captive market for terminals

    The related architectures vary widely from one provider to another, although the components are thesame for all technologies.

    As the SIP protocol becomes mainstream and develops with manufacturers offering full SIP offers such as Aastra or Avaya proprietary technologies may lose ground.However, in 2009, proprietary technologies are still used and represent the lions share of corporatecustomers.

    1.2 ToIP services

    As we use a telephone every day, this technology seems to be rather simple. However, the servicesprovided by PABX, then by IPBXs, are complex and numerous, and depend on the manufacturers.Moreover, additional services as CTI (Computer Telephony Integration), and connections to IPapplications are available. The main telephone services are:

    Black lists

    Recall

    Hold

    Call transfer

    Multi-party conference

    Call trace

    Calling line identification presentation

    Caller ID block

    Authentication

    IVR (Interactive Voice Response)

    Tone management (hold, transfer )

    Messaging

    Interface conversion (Trunking mode)

    Vocoder conversion

    IPBX interconnection

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    5/28

    Edition 5.0 April 20105 / 28

    ISDN

    WAN IP(MPLS)

    ISDN PBX

    WAN IP(MPLS)

    IPBX ISDN

    1.3 ToIP security: background and stakes

    1.3.1 From ISDN to ToIP

    In ISDN architectures, voice and data applications are strictly separated:

    Distinct networks

    Distinct terminals

    Distinct services

    And distinct threats

    With ToIP, this is no longer the case:

    Integrated networks (at least at the hardwarelevel)

    Pooled terminals

    Converged services

    Andshared threats

    Although simple in appearance, convergence will be the source of complexities, first in terms ofinfrastructure, service and information security.

    1.3.2 The challenges

    We have to face it: ToIP is intrinsically vulnerable, because of several factors such as:

    Migration to IP. Telephony is becoming a common application in its design, which uses standardsoftware components that do not integrate security requirements. The component vulnerability isthen transmitted to telephony applications.

    Number of network elements implemented: a ToIP infrastructure will use several hundreds toseveral tens of thousands of network elements (routers, switches, servers, terminals). Eachone being a potential entry point for threats. Especially, ToIP terminals are functionally similar tocomputers, with operating systems, stacks, http services, ftp services this phenomenon isfurther accelerated by the development of virtual terminals (softphones).

    Hacking the iPhone through SMS reveals the potential weakness of terminals in an infrastructure.

    Figure 1: RNIS architecture

    Figure 2: ToIP architecture

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    6/28

    Edition 5.0 April 20106 / 28

    Variety and complexity of protocols: whether they are standard or proprietary, the complexity ofToIP protocols is far greater than the protocols currently used in data applications: semantics,sequencing and successions of multi-protocol sessions required for communication. This is nolonger the question-response mode currently used for data exchanges. Besides, most ofstandard protocols are open, and offered in various implementation configurations, according to

    the manufacturers, with proprietary extensions. SIP is therefore renowned for its misleadingsimplicity.

    Interconnection with data networks: by construction, partition of voice and data networks islimited. To benefit from service convergence, resources, as directories, messaging, or DNS andDHCP services, will have to be shared. Integration can be further extended for softphones,instant messaging, CTIs.

    Voice and data services are susceptible to their mutual vulnerability, with possible cross-contamination.

    Availability and Quality of Service (QoS) specifications are also to be considered, and telephony servicesmust meet our daily requirements. ToIP must meet these expectations in an open environment.

    Telephony is also critical for companies: any malfunctioning may lead to loss of revenues, loss ofopportunities and loss of efficiency.

    Moreover, emergency calls should be made at any time, to meet safety obligations and address person-related hazards.

    Service availability is a key point, even though alternative solutions such as messaging, e-business,mobile telephony, and collaborative work, etc. are spreading rapidly.

    Finally, there is a great rush to market products and services based on ToIP. Rapid development andshort time-to-market are decisive for the providers work. Comprehensive and native securityimplementation is considered, whether right or wrong, as a complication factor that slows downavailability.

    As a result, fraud and attacks increase significantly: these new means of communication are divertedfrom their original use, and their weaknesses are exploited.

    1.3.3 The security stakes

    They are classified in four categories:

    Confidentiality

    1. Signaling confidentiality, which is too often disregarded. Non-encrypted signaling allows thenetwork topology, stream matrixes, applications and protocols to be discovered and attackstrategies to be developed.

    2. Communication confidentiality: to protect the strategic data of the company (know-how,strategy, finances, commercial offers, litigations, conflicts) that can be used in fierce economiccompetition, whatever the field of activity and size of the company (this issue is often neglectedby too many companies) and to protect personal data (privacy) exchanged during phoneconversations. This is the case for administrations (income tax and social services, healthservices, legal services), and private sector (banks, insurance companies, human resourcedepartments). Many States require confidentiality of personal data stored and exchanged ininformation systems, including phone systems.

    Traditional telephony is considered as safe because we assume that tapping is not possiblewithout physically acting on the devices. IP communications are vulnerable to call interceptions(tapping) as other IP applications, especially if voice and data applications and networks are notsufficiently segmented. In addition, segmentation (VLANs) is not the ultimate solution.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    7/28

    Edition 5.0 April 20107 / 28

    Availability

    The purpose of ToIP is to deliver the 99.999% availability of ISDN telephony. If the newtechnological base seems to be unable to deliver this availability, the target is however 99.99%,which is high for a computer application.

    To achieve this performance, suitable resilient architectures will be implemented, with related

    energy supply and air conditioning.

    Unavailability due to aggressive streams or behaviors must also be prevented.

    Migration to IP makes the availability of the phone service more vulnerable to internal andexternal denials of service. Because of the sensitivity of telephone systems, a slightlydowngraded Quality of Service makes the application unavailable: attacks are much more subtlethan bandwidth saturation. Such attacks may alter the traffic and prevent access to thecompanys data.

    There are two ways of generating denial of service attacks in ToIP:

    o Making unavailable by saturation, freeze or isolation the resources indispensablefor the application operation (call server, directory, DNS). Note: for ToIP, saturationcan be achieved with a low bit rate, or a great number of connections, therefore

    attacks can be rather furtive.o Discouragement of use: making the terminals ring randomly until call pickup is

    abandoned; downgrading the communication quality by changing codecs orintroducing jitter; aborting calls by introducing latency or interfering on packetrouting.

    Finally, denial of service can occur upon technical failures, especially when using low-costtechnologies of insufficient maturity (e.g. some SIP terminals).

    Fraudulent, unlawful or abusive use

    The abusive use of telephone services charged to companies is already widespread in ISDNtechnology: call forwarding to premium-rate or international numbers, conference bridges to

    connect external subscribers free of chargeThe objective is not only to detect fraudulent use e.g. intrusion in the system for mercantilepurposes but also to detect abusive use of their rights by authorized subscribers.

    Identity fraud

    This is related to confidentiality and fraud. It involves identity spoofing or stealing the personaldetails of a user either to have access to unauthorized rights or privileges, or to deceive acorrespondent. Besides direct risks, there is a risk to compromise the trust in financial and statecertifications (SOX, Bale II, LOF) by weakening the non-repudiation mechanisms.

    Civil and penal responsibility

    It deals with the liability of Organization A whose ToIP system would be hacked to harmOrganization B.

    In this case, and according to the losses, Organization B is entitled to have Organization Acondemned, and to ask for civil remedies by law.

    Risks in terms of finance and image can be substantial. Therefore Organization A must detectintrusions and stepping-stone attacks beforehand, and in case of an attack as security is notinfallible demonstrate its goodwill.

    Nuisances like SPAM

    SPIT (Spam over Internet Telephony) and SPIM (Spam over Instant Messaging) may becomenuisances for ToIP. In comparison, more than 90% of emails are now considered as SPAM, and

    there is no reason that this be different for ToIP and instant messaging.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    8/28

    Edition 5.0 April 20108 / 28

    1.3.4 2009 and 2010: the critical years

    In computer security, it has been demonstrated that, when a new application is widely deployed, it takesabout 3 years for the protection and security aspects to be considered.This is due to the following reasons:

    Rush to market

    Time necessary for the actors to apprehend the application vulnerability, deployment, impactand interactions with infrastructures, and induced uses and behaviors

    The year 2009 is a milestone for ToIP: during seminars, customers are no longer asking if ToIP must besecured, instead they are rightfully asking: what do you suggest to secure ToIP?. Similarly, quality ofprotection becomes a selection issue for ToIP systems, with significant impact for the manufacturers.

    Besides, this 3-year delay is also observed in hacking.Most intrusions or frauds are no longer committed by individuals for notoriety, but are attempted bycriminal organizations, strictly for mercantile purposes: stolen data or topology information can be sold to

    third parties or serve for blackmail (e.g. denial of service or disclosure).

    These operations require comprehensive knowledge of applications, which takes time and requiresinvestments for their development, with risk-taking in their execution.

    The return on investment must be sufficient; two main factors can be considered:

    Criticality level of the application for the Organization: coverage rate, maturity, embedment in theIS, and impact on operations.

    This will determine the marketing and blackmail value of the data.

    Extent of computer population: wide application coverage results in increased vulnerability andhigher profits from frauds.

    Three to four years are required for these two parameters to become mature: this is the case in 2009 and2010.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    9/28

    Edition 5.0 April 20109 / 28

    2. What protection for ToIP?

    2.1 Functional security blocks

    The next figures summarizes the main components of ToIP protection:

    2.1.1 Network segmentation

    To avoid stepping-stone attacks from the data network to the voice network, streams will be segmentedinto different virtual (if not physical) networks. There are four virtual networks: voice, data, video, andadministration.

    This is achieved through VLAN technologies.

    If this measure is necessary and of common sense it is far from being sufficient, even if some users dobelieve it.

    There may exist bridges between these 3 VLANs:

    To benefit from convergence, some applications will be used by ToIP services/terminals, and bydata services/terminals as well: messaging, directories, DNS, DHCP.

    Some terminals can give access to both voice and data networks. E.g. PCs with softphones.

    A voice/data/video infrastructure for corporate customers will implement several hundreds to severalthousands of routers, switches, gateways that will be configured to support VLANs. Is there anynetwork operator to claim that VLAN configuration will be perfect and coherent any time?

    Even though the VLAN configuration would be ideal, Inter-VLAN bridging is easy for experiencedtechnicians.

    IP WAN(MPLS)

    Callservers

    ISDN

    Voice/data/video/administrationsegmentation

    Access control tonetwork, NAT,

    pinholing

    Hiding, translation( peering )

    Network authentication

    Servers authentication

    Integrity andconfidentiality of

    signaling

    Integrity andconfidentiality ofcommunications

    Streams safety

    Figure 3: bricks for protection

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    10/28

    Edition 5.0 April 201010 / 28

    2.1.2 Access control at the edge of the data network

    This is the current edge firewall, which often exists before ToIP implementation.The ToIP functionalities required for this firewall are limited to the border (see 4.3).

    2.1.3 Access control at the edge of the telephony network

    We have two situations to consider: peering (network interconnection) and filtering (access control)specific to voice streams.

    For peering, there are two functional needs:

    Hiding the Organization network from the operator and vice versa. This will require advanced NATfunctions, more complex than the functions proposed by edge firewalls.

    Translating the protocols used in the Organization network into those used in the operator network,and vice versa.

    Some networks may use Session Border Controllers (SBC) (see 4.3.).

    For specific filtering, we can use a voice application firewall.

    2.1.4 Network authentication

    It is possible to use a protocol as the 802.1x protocol, currently offered by providers.

    2.1.5 Integrity and confidentiality of signaling and communications

    These services are provided by stream encryption.All providers currently propose stream encryption, activated by default or not, the key point being theimpact on deployments and performances. Free encryption services must not be trusted, because theirperformances are not constant: hardware will have to be changed or added, and not free of charge.

    Several technologies are available:

    Ipsec, SIP-TLS for signaling

    SRTP for communications

    2.1.6 Server and application authentication

    Network authentication is not enough. An effective solution must ensure that only authorized terminalsconnect to ToIP services: this is signaling encryption. This is achieved through sharing of certificates andencryption keys.

    2.1.7 Core filtering in front of servers: stream safety

    This block will provide complex content control functions and call session control functions that cannot beensured by edge firewalls.This function is useful in front of servers, because it controls all data streams between terminals and

    servers and between servers.Only an application-layer filter, specific to ToIP, is capable of meeting this requirement.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    11/28

    Edition 5.0 April 201011 / 28

    2.2 Focus: an application-layer filter to protect ToIP servers

    As we have seen in the previous chapters, a security package for ToIP must address all threatspertaining to IP as well as to ISDN. Most security packages currently available with the ToIP label focuson the IP aspects (often partially), and just extend standard solutions of network security packages to

    telephone applications, without considering the specific threats to systems and protocols and theirparticularities.

    An application-layer protection mechanism for ToIP must be multi-functional to address all levels ofprotection (see 4.3.3).

    2.3 SBC, edge firewall, application-layer firewall

    Firewall, application-layer analysis, SBC as seen in Section 4.1 Functional security blocks, these three

    components are required to efficiently protect ToIP services. They are, however, not interchangeable, inspite of what some providers might make believe, source of confusion for users.

    The purpose of this section is to clarify the definition of each of these items.

    2.3.1 Edge firewalls

    These devices were developed in the 90s when companies were connected to the Internet. The purposewas to protect companies intranets from potential threats due to the Internet and to control incoming andoutgoing streams.

    Firewalls were designed to decide what network traffic should be let through or blocked, through Internet

    or MPLS connections: what protocols, ports, and addresses to control?

    Firewalls have generally limited or inexistent content control functionalities, because this control level isresource consuming. To be effective, edge filtering would require controlling all protocols accessing to thenetwork at that point. As a result, the size would need to increase, with significant risks of congestion.How and where to deny service to voice protocols by blocking POP3 or http traffic?

    Besides, firewall engines were designed to handle simple protocols, which operate on a request-responsemode, as http or POP3. They are therefore not suited to complex ToIP protocols and sessions.

    The ToIP functionalities of the firewalls can be broken down into two categories:

    Dynamic opening and closing of secondary communication ports (pinholing).Edge firewalls are often already installed when ToIP is deployed, and users do not want to changethem.

    ToIP uses successive protocol sessions to establish and maintain communications: first a primarysession (e.g. signaling) with predictable characteristics (protocols, ports) that can be included inthe firewall filter. However, the primary session is used to initiate secondary sessions (e.g.communications) with random characteristics especially ports that have been defined during theprimary session.

    Therefore, we have two possible situations:

    o The edge firewall is not able to decode the data exchanged during the primary session: bydefault, all communication ports likely to be used by the secondary communications will have tobe opened. This is canceling the border filter otherwise outgoing/incoming communications

    could not get through the firewall. This situation prevailed for first ToIP deployments.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    12/28

    Edition 5.0 April 201012 / 28

    o The edge firewall is able to decode the data exchanged during the primary session: only thenecessary ports are dynamically opened at the start of the secondary session, and closed at thesessions end. Related security flaws are then suppressed.

    Network Address Translation in Layer 7

    ToIP protocols send address data in Layer 3 as well as in Layer 7.

    Addresses are often private on the LAN and therefore will be translated into public addresses at theborder for routing over the operators or ISP network (NAT: Network Address Translation).

    If the edge firewall in charge of this function performs NAT in Layer 3 only, the private addresses willremain in Layer 7 and communications could not be established. NAT will have then to be performedin Layer 7 also. That was not the case in original edge firewalls.

    These two functionalities are the only ones absolutely necessary in edge firewalls, and are thereforethe only ones to be implemented.

    They require retrieving the data available in Layer 7 (application-layer). Many providers proposefirewalls with application-layer analysis capabilities, which is abusive, because no security control isperformed at that level, but only research or modification of parameters. Security controls operate in

    Layers 3 and 4.

    As pinholing and NAT do not allow the progress of application-layer sessions to be controlled, whichis the purpose of application-layer analysis, they do not need to be implemented at the border.

    2.3.2 Session Border Controller (SBC)

    SBCs are border devices. Unlike edge firewalls described in the previous chapter, they are located at theborder of the voice infrastructure, at the connection of the operators SIP or H.323 trunk.

    The SBC role is fundamentally the interconnection of Internet networks (peering). SBCs are provided with

    a suitable functional application content, to cover the following needs:

    Network topology hiding: the Organization must not know the network of its operator and vice versa.This is achieved through advanced NAT functions that can hide data other than address data.

    Protocol translation: for the transparent interconnection of networks that do not use the sameprotocols or same protocol implementations (e.g. SIP to H.323, or SIP A to SIP B).

    Traffic and user management:

    o Application routing: e.g. for incoming calls, with SIP, to softswitches.

    o

    Managing overflows: e.g. routing too many outgoing calls to Internet or PSTN connections.o Call/session admission control

    o SIP registrar and RAS Gatekeeper.

    Originally, SBCs were used to interconnect operators networks. With the arrival of the H.323 trunk, thenSIP trunk, functional needs now exist for companies/operators interconnections.

    2.3.3 Application-layer protection for servers

    Although they operate at the application level, SBCs are not designed to be used in the infrastructurecore, i.e. to protect servers. Their functional strong points (see previous section) are of limited use.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    13/28

    Edition 5.0 April 201013 / 28

    Application-layer protection for servers will focus on the following aspects:

    Precision analysis of protocol streams: to ensure session syntax, consistency, and integrity:

    o Checking the content and format of packets and packet fields.

    o Checking the consistency and integrity of a primary session on Protocol A.

    o Checking the opening of the secondary sessions (Protocols B, C) started by Protocol A.

    o Checking the consistency and integrity of secondary sessions (Protocols B, C).

    o Checking the consistency of secondary sessions (Protocols B, C) with what was expectedduring the primary session (Protocol A).

    ToIP protocols, sessions and session links are much more complex than what was previously knownin data services.

    Suitable engines will have to be implemented and the protocol technologies used by the providerswill have to be precisely known.

    Finally, standard protocols (SIP), proprietary protocols and proprietary extensions of standardprotocols will have to be comprehensively considered.

    Fight against fraud, abusive use, SPIT

    This service can be provided at protocols: telephone session parameters (E.164 numbers, calldirections, time stamp, codecs) will have to be retrieved and compared to specific rules.

    This requires advanced analysis capability of protocols, and the implementation of a specific engine,different from the engine that handles protocols.

    Support of back office streams

    For an efficient and comprehensive operation that has minimum impact on the infrastructureoperation, the application-layer filter will be capable of managing protocols or streams that can onlybe seen at the servers (e.g. CSTA phases 2 and 3 and redundancy streams).

    Support of ToIP traffic profiles

    The application-layer filter deployed in front of ToIP servers will be sized and tested according totraffic profiles very different from what is know at the network border.

    The filter will allow server restart i.e. simultaneous reconnection of all terminals to servers withina short time.

    The platform will therefore not be sized to throughput data (traditional performance indicator forfirewalls and IDPS), but to very short and very aggressive session bursts.

    Real-time stream processing

    The ToIP application-layer filter will have no impact in terms of latency and jitter, key parameters for

    the quality of the phone services. Therefore, the filter will especially implement:o Processor technologies specialized in network and security, with sets of specialized instructions:

    multi-purpose industrial PCs will thus be excluded.

    o Software architecture that optimizes processing operations.

    o Advanced hardware/software integration.

    o Low use of hardware resources to avoid congestion areas, including during the most criticalburst phases.

    High availability

    The application-layer security solution will be included in the ToIP SLA, including 99.99% availability.

    It will offer functionalities to achieve this rate. Contractual agreements between manufacturers andToIP providers will include this requirement.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    14/28

    Edition 5.0 April 201014 / 28

    Figure 4: functional weighting

    Integration, validation, simulation capabilities

    The manufacturer of the ToIP application-layer security solution will be provided with laboratoriesable to reproduce actual client environments:

    o Complete systems with related applications

    o Skills for realistic and binding configuration setting

    o Simulations tools for traffic and providers terminals, for realistic simulation of the behavior of areal infrastructure

    Cooperation with ToIP providers

    Only close cooperation with ToIP providers will meet these requirements:

    o Access to detailed technical specifications

    o Advanced access to technical developments (roadmaps synchronization)

    o Access to R&D expertise

    o Access to test and simulation environments

    o Implementation of suitable support and escalation processes

    Anyway, reverse engineering is potentially very risky for end-users.

    2.3.4 Conclusion

    Edge firewalls, SBCs and application-layer security solutions have distinct characteristics and purposes:their functional contents are therefore different.

    Some confusion may remain, sometimes created by providers. Strictly in terms of presence/absence offunctions, these three items may seem equivalent.

    If the lists of functions can be similar, the completeness and maturity level of each solution make them notinterchangeable.Checking the presence or absence of a function is not enough: this function must be weighted accordingto its quality. We then obtain a functional center of gravity that varies from one solution to the other.

    The next figure illustrates the positioning of each solution:

    Performance

    Routing QoS Dataprotocols

    Analysisengine

    Voiceprotocols

    Networkinterconnection

    TEOZEdge FW SBC

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    15/28

    Edition 5.0 April 201015 / 28

    Figure 5: positionning in the network

    As a conclusion, the next figure summarizes the position of each item:

    Voice IPWAN

    Voice / Videoservers

    Data IP WAN /Internet

    Distant subscribers

    Firewall

    SBC

    Distant subscribers

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    16/28

    Edition 5.0 April 201016 / 28

    3. TEOZ: application-layer security solution for ToIP

    TEOZ is an application-layer security solution for ToIP: it is designed for the sole purpose of protectingthe applications critical to ToIP.

    TEOZ is embedded in the Organizations network to create a Trusted Multimedia Zone (TMZ) that hostssensitive devices as servers.

    The next sections describe the notion of TMZ and the proposed application-layer security services offeredto IP and telephony systems.

    3.1 TMZ: a sanctuary for voice and video applications

    3.1.1 TMZ

    As described in the first part of this document, multimedia applications and especially ToIP willbecome the next major target for attacks, due to Quality of Service sensitivity and fraud potential.

    Application availability is critical for the Organization and has strong psychological effects. Therefore,suitable security mechanisms should be implemented, at the organizational and architectural levels andat the technical level as well.These measures must be more consistent than those currently available for data or messaging services,which accept downgraded Quality of Service.

    Attacks to ToIP can be launched from outside, however, in view of what has been happening in computernetworks for several years, many attack have been and will be launched from inside the infrastructure,either directly or by using an internal active component as stepping-stone.

    To secure ToIP availability and Quality of Service, all active elements, including terminals, will beconsidered as sources of potential (intentional or unintentional) attacks.

    Thus, security of ToIP applications must not only be considered at the infrastructure border, but also atthe core, i.e. as close to the services to be protected as possible.

    Each active element, each terminal, is likely to generate or relay attacks. Therefore, efficient filteringmust be provided between applications and users, and between applications themselves.

    Streams will be analyzed on all network interfaces, between applications and users (subscribers orcooperative applications), and applications will be isolated in a dedicated network area called the TrustedMultimedia Zone (TMZ). The TMZ is therefore a sanctuary for vulnerable servers.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    17/28

    Edition 5.0 April 201017 / 28

    Figure 6: Trusted Multimedia Zone

    3.1.2 TMZ partitioning

    In the simplest situation, all services necessary to a ToIP application are dedicated to this application,including the directory, DNS and messaging, which are separated from data application services.Then, they may be positioned in a common TMZ.

    However, according to the level of convergence required by the Organization, some services could bepooled between voice and data applications (e.g. directory, messaging and DNS).In this case, the TMZ could be partitioned into several sub-areas (e.g. two):

    One for applications dedicated to ToIP: call managers, ToIP DHCP, data saving

    One for voice and data pooled services: messaging, DNS, directory

    TEOZ will be positioned on the LAN, at the center of a triangle formed by the LAN and the two sub-TMZs. TEOZ will then be able to filter the streams between the LAN and TMZ, and between both sub-TMZs.

    3.1.3 Two filtering levels

    The TMZ is created through the creation of a second filtering stage, at the infrastructure core, whichcomplements the edge filter.The two filtering stages are the following:

    1st

    stage:

    o At the data border: access control to network (what protocols, ports and addresses to control?)

    o At the voice border: access control to network and peering as applicable (advanced NAT andprotocol translation)

    2nd

    stage. At the core: content control (syntax, consistency of packets and protocol sessions)

    These architectures are composed of two filtering levels border and core and are already well knownin other critical applications as web services (https, soap, XML), FTP or SQL databases.

    Anyway, core filtering is achieved through specialized items (web firewalls, SQL firewalls, FTPfirewalls) different from border items. It is also interesting to note that these specialized items aredesigned and marketed by specific providers, because their business models are different from edgefirewalls.

    The TMZ notion, created with TEOZ, is applicable to another critical application: ToIP.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    18/28

    Edition 5.0 April 201018 / 28

    Figure 7: the two filtering levels

    3.2 Real-time IP application-layer analysis: Protocol Expert Module(PEM)

    The solution is based on this set of services. The Protocol Expert Module is an intrusion preventionsystem, dedicated to voice and video applications. It is characterized by a comprehensive knowledge ofstandard protocols (SIP, H.323, MGCP, RTP, RTCP, SDP) and its capability of embedding analysismodules of proprietary (Alcatel-Lucent) or specific (CSTA ASN.1) protocols.

    The main advantages of the PEM technology are:

    Implementation of different protection techniques working in synergy to protect network,application and content layers

    High performances through the consistency of the seamless integration architecture of analysisengines

    Homogeneous administrative environment (graphical interface)

    The main security functions implemented in the PEM are:

    Stateful IP filtering:

    o Authorization/denial of protocols, ports, addresses

    o Dynamic opening/closing of ports

    Analysis of IP application layers:

    o Compliance analysis of protocol syntax (compliance with RFCs or proprietaryspecifications)

    o Compliance analysis of application protocol behavior

    IDPS based on contextual signatures

    PSTN

    IP WAN

    Web servicese-businesserp / crm

    FTP(s) services Databases

    HTTP, XML, SOAPapp. filter

    FTPapp. filter

    SQLapp. filter

    internal users

    The use of specialized items is already standard forcritical applications

    ToIPUnified comm.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    19/28

    Edition 5.0 April 201019 / 28

    The engine used by the PEM is the first real-time technology that combines stateful IP filtering techniquesand application-layer analysis techniques. The protection is based on stream analysis at the level of theinter-application communication protocols.

    RFC or proprietary specification compliance is used to detect attacks such as:

    Redirection

    Call interception

    Denial of services

    However, if compliance with specifications ensures communication quality, the specifications are notdefined with system security in mind. As a result, some attacks do not violate protocol specifications.

    Checking the compliance of protocols with their expected behavior will allow the following attacks to beblocked:

    Encapsulation of peer-to-peer protocols (instant messaging, file sharing, communications)

    Directory browsing, where a hacker can get control over an HTTP service by using abnormalrequests in the URL

    Buffer overflows due to unusually long requests

    Transport of malicious data in application-layer requests (code injection, use of reservedbytes)

    By analyzing applications and controlling their operation, the analysis engine defines the expectedbehavior. Violation of security rules generates a preventive action (active response) and/or an alertmessage to the administrator.

    Unlike strictly reactive methods (based only on signatures), the engine protects the ToIP system againstunknown and complex attacks.

    The PEM is frequently updated to keep up with the evolution of protocols and add new protocol tests.

    Protocol-specific rules can also be configured:

    Restrict/ban commands

    Restrict parameters (request sizes)

    This level of control is configured by the administrator. An analysis module (each protocol is associatedwith its own module) acts as a configuration object that can be associated with a service, the parameters

    of which are defined by the administrator.

    3.2.1 Stateful IP filtering

    This section describes the specifications of IP filtering and the checks performed at the different OSIlayers, up to the Transport Layer. The specifications of application-layer checks (up to OSI Layer 7) aredescribed in 3.2.5.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    20/28

    Edition 5.0 April 201020 / 28

    Filtering rules

    The filtering policy is defined as a sequence of filtering rules. For a given IP connection, the filteringengine browses the specified set of rules until it finds the matching rule and applies the correspondingaction.

    By default, the rule is to block any IP connection that does not match any filtering rule of the defined

    security policy (last rule from the list). This rule can be modified by configuration.

    A filtering rule is defined by:

    Source: host (defined by the IP address), network (defined by the IP address and network mask),host groups, network groups

    Destination: host (defined by the IP address), network (defined by IP address and network mask),host groups, network groups

    Service: defined by its protocol IP, source port number and/or destination port number for UDP andTCP protocols. Moreover, for a given service, it is possible to define a specific application with an

    applicable IDPS profile (see relevant sections) Time ranges: defined by a hours range from 00h00 to 23h59, and/or a days range (Monday

    Sunday)

    These 4 criteria are facultative: a rule can be defined by selecting a source network, a destination host,and no service and no time range.

    3 types of action are possible:

    Accept: if the rule criteria match the connection, the connection is accepted

    Block: the rule criteria do not match the connection, the connection is blocked Deny: the connection is blocked and the filtering system sends back a packet to the caller to

    indicate that the stream is rejected (by default, it is an ICMP packet: destination unreachable communication administratively prohibited)

    Similarly, the following log options are available:

    No log

    Standard log: generates logs (that can be viewed later using the TEOZ-Monitoring tool) about theheader sections of the IP packets in the stream

    Complete log: generates logs (that can be viewed later using the TEOZ-Monitoring tool) about theheader sections and data sections of the IP packets in the stream

    For a given filtering rule, the following advanced parameters can be configured:

    TCP desequencing: some servers generate TCP sequence numbers that are not random enough;this is a serious breach of security. When this option is enabled, it allows the sequence numbers tobe randomly generated for this type of servers and for the streams accepted by this rule.

    Maximum number of connections: defines the maximum number of connections allowed on astream.

    Maximum number of standby TCP connections: defines the maximum number of suspended TCP

    connections. Maximum value of TCP MSS for the streams accepted by the rule.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    21/28

    Edition 5.0 April 201021 / 28

    3.2.2 Application-layer analysis

    TEOZ implements a technology that allows real-time and contextualized application-layer (OSI Layer 7)traffic analysis. The analysis modules will detect inconsistencies or fraudulent uses of application

    streams. The major functionalities of these modules are:

    RFC compliance: ensures the traffic complies with the relevant RFC, protects against RFC-incompliant headers (e.g. binary data in headers), activates critical functions (e.g. redirection, callinterception and denial of service by VoIP protocols) or protects against Trojan horses.

    Normal use of the protocol: ensures not only that the traffic complies with the relevant RFC, butalso ensures the traffic meets the normal protocol usage to protect against RFC-compliant attacks orintrusions (e.g. insertion of malicious data in URLs, hidden scripts in requests and abuse ofencapsulated protocols).

    Additional rules for protocol: checks the traffic with reference to a set of limits or rules to provideadditional protection against attacks. Rules can be configured to prohibit or limit commands in a

    protocol, limit the size of commands and parameters and filtrate downloaded files.

    In addition, any available analysis module executes all the changes necessary to provide optimum NATtraversal for the protocol: changes the addresses contained in the application data block and opensdynamically the secondary connections.

    The analysis modules currently available for voice and video are: MGCP, SDP, RTP/RTCP, RTSP, UA,UA-DL, UA-IPLink, UA-NOE, CSTA, H.323, SIP.

    Other modules are also available for voice and video applications: HTTP, FTP, TFTP, DNS (UDP/TCP),NetBIOS Datagram Service (UDP), NetBIOS Name Service (UDP), NetBIOS Session Service (TCP),

    SQL*Net/Net 9, SNMP (v1, v2c, v3), SSL.

    3.2.3 Contextualized signatures IDPS

    IDPS General

    The IDPS (Inline Detection and Prevention System) technology is an extension to the application-layeranalysis to prevent attacks against ToIP servers.

    However, standard signature-based IDPSs have disadvantages and may not be suitable for real time

    applications.Standard IDPSs compare systematically the stored signatures with the connection content: it requiresconsiderable resources and can be a bottleneck to systems that cut off data streams. Off-line equipmentdoes not have this disadvantage but require active supervision to stop the detected attacks.

    Moreover, according to their sensitivity, standard IDPSs can generate a great number of false alarms(false positives). A false positive occurs when an IDPS incorrectly identifies benign sessions or protocolsas being malicious (containing attack signatures). IDPS signatures are often character strings: a sessionmay include this character string without being malicious. A signature is an attack signature only in agiven context. Same character strings (signatures) will not have the same action on different protocols. Ifthe IDPS detects a signature in a benign context, a false positive is generated.

    False positives are unacceptable for a system that cuts off the data stream to protect criticalcommunications as ToIP applications.

    Moreover, unjustified alerts hinder service availability and can hide real alerts (false negatives).

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    22/28

    Edition 5.0 April 201022 / 28

    TEOZ IDPS

    The IDPS (Inline Detection and Prevention System) is an extension to the TEOZ application-layeranalysis. It is capable of detecting and neutralizing application-layer attacks with or without protocolviolation, taking connection context into account.

    The TEOZ application-layer analysis stops attacks to application-layer protocols. This protection iscomplemented by the IDPS, which relies on a database of application attack signatures.

    The TEOZ IDPS engine has been optimized to provide processing performances compatible with ToIPreal-time streams. A contextualized signature database identifies and stops the attacks that cannot bedetected by the application-layer analysis.

    The IDPS engine is highly integrated to the application-layer analysis engine (see previous section) tominimize processes and optimize overall performance. Therefore, the IDPS engine:

    Does not have to process the major number of attacks, which have been previously stopped bythe application-layer analysis.

    Knows the connection context to apply to the streams only the relevant signatures.

    IDPS protocols

    IDPS signatures can be created and used for the following application-layer protocols:

    HTTP, SSL

    FTP, TFTP

    DNS UDP and DNS TCP

    SIP, H323

    MGCP

    SDP

    UA

    CSTA

    IDPS management

    The IDPS function is configurable using the TEOZ-Manager tool.

    For the application-layer profiles to be used in IDPS filtering, they need to be associated with servicesthat will be implemented in the stream rule configuration.

    The IDPS function is monitored by the TEOZ-Monitoring tool, via dedicated IDPS logs.

    3.2.4 Synthesis

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    23/28

    Edition 5.0 April 201023 / 28

    The next figure summarizes the IP application-layer analyses performed on streams:

    TEOZ filtering is broken down into 4 phases:

    1st

    phase: Layer-3 and Layer-4 filtering what is authorized to access the servers (addresses,ports, protocols).

    2nd

    phase: the authorized streams are analyzed by application-layer modules, which check protocolcompliance and monitor the state of active connections. If packets violate the protocol, theconnection is dropped. If packets are compliant, they enter the 3

    rdanalysis phase: the IDPS.

    3rd

    phase: the IDPS filtrates the packets authorized by the analysis modules by searching thestreams for application-layer attack signatures. The complete signature database is not used foreach analysis: only the relevant signatures for the profile and application-layer state associated withan active connection are searched for. The IDPS considers the analysis context to optimize filteringperformance.

    4th

    phase: should an attack be detected by the modules or IDPS, TEOZ will take proper action

    against the attack.

    3.2.5 ToIP threats Examples in Layers 3-7

    Malicious codes

    The nuisance of malicious codes is demonstrated, whether they constitute an attack themselves or easeother attacks by exploiting the system flaws and vulnerabilities, taking over components and havingaccess to contents.

    Pare-feu

    Filtrage IP statefulinspectio

    Rception du 1er

    paquet

    Confrontation aux

    rgles de flux

    Cration de la

    connexion

    Analyse individuelle

    du paquet

    Rception du 1er

    paquet

    Confrontation aux

    rgles de flux

    Analyse individuelle

    du paquet

    Analyse applicative

    Prvention

    Dfragmentation et

    rassemblage du message

    Contrle de conformit et

    usage du protocole

    Confrontation aux rgles

    protocolaires

    Dcodage applicatif

    IDS

    Temps

    Rcuparation du contexte

    de la connexion

    Pondration

    Confrontation aux

    signatures contextuelles

    FirewallStateful IP filtering - Stateful inspection

    1st packetreception

    Comparisonwith stream rules

    Connection setup

    Individual packetanalysis

    Application analysisIntrusion prevention

    Message defragmentationand reassembly

    Compliance andprotocol usage check

    Comparison with protocolrules

    Application-layer decoding

    IDSReal-time

    Retrieval of connectioncontext

    Weighting

    Comparison withcontextual signatures

    1st packetreception

    Comparisonwith stream rules

    Individual packetanalysis

    Figure 12: PEM synthesis

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    24/28

    Edition 5.0 April 201024 / 28

    The malicious codes (trojans, worms, bots, root kits, spyware, key-loggers) can attack ToIP components(IP telephones, gateways and servers, soft-phones) as they attack IP applications; they even go furtherby attacking mobile phones, smartphones and PDAs.

    Protocol, server, network, and terminal vulnerabilities

    Registration hijacking: this attack occurs when an attacker impersonates a valid user to a registrarand replaces the legitimate registration with its own address. All calls will be diverted to thefraudulent equipment.

    The attack range is very wide: monitoring, password phishing or fraudulent calls charged to the validuser.

    Proxy impersonation: a proxy server is substituted to the legitimate call server. The fraudulentserver will intercept the protocol to reroute the calls to fraudulent DNS servers, to have access to thecommunication content, or to block calls.

    Message tampering: the modification of message contents is intended to deceive servers intorerouting, listening and charging calls to another account.

    Session tampering: this attack will generate opening or closing frames either to generate falsecalls or tear down real calls.

    Hidden RTP channel: uses an open RTP channel to bypass the system and establish unauthorizedcalls (e.g. SIP in RTP), or exchange files.

    Denials of service (DoS), distributed denial-of-service (DDOS): these attacks consist insaturating the target machine with external communication requests or endless requests. They can

    occur through any of the means described above or come from the outside. DoS attacks are easedby weak authentication, absence of encryption, unprotected DNS, unterminated sessions or widelyopen ports on firewalls.

    DoS attacks can be perpetrated on signaling, communications (media) by quality disruption, andterminals by sending flood of reset commands, incoming calls

    Phishing: subscribers, calls, identifiers and password

    Unauthorized distant access: especially by rerouting web, FTP or telnet administration services ofservers or terminals.

    NAT issues: many protocols do not originally comply with address translation. Therefore, twocorrespondents cannot communicate between each other in private IPV4 space (Back-to-Back UserAgents) when NAT is enabled. Server-based mechanisms are able to establish this normallyimpossible connection by untangling the encryption chain (if any), which is a target for the attacksdescribed above.

    Migration phase

    The migration phase will see the new ToIP and the standard ISDN telephone working together. The ISDNtelephone is widely installed and will represent a significant part of the new installations.

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    25/28

    Edition 5.0 April 201025 / 28

    Migration will have its own requirements, and will generate its own security risks on existing networks.Once migration will be achieved, the ISDN services remaining in the Organization will have still to bemanaged: fax machines, modems, alarm systems, backup systems

    3.3 Usage analysis and control: Session Expert Module (SEM)

    3.3.1 Description

    Generalities

    The Session Expert Module (SEM) is an optional security service that complements the PEM.

    Whereas the PEM analyzes protocol behavior and provides IP security services, the SEM analyzes thecall parameters by considering the telephony services.

    Users of a ToIP server are assigned usage rights: external calls, calls to mobile phones, international

    calls, at any time or at restrictedtimes For each call setup request, the server will check if the call is authorized or not by the rules. The system'slimitation is that the server carries out this check for each unit call: it is able to decide if the call isauthorized or not, i.e. if the call matches the users right; however, it cannot detect if the usage islegitimate.

    Example:

    Mr. Magnac is a salesman for Germany. As such, he is allowed to pass international calls, but has nolegitimacy to phone to Brazil twice a day.

    The TEOZ SEM function is used to define the rules and usage thresholds that specify what theOrganization considers as a legitimate usage of its telephony system. When the system behaviorexceeds these limits, it may be an abusive use, fraud, Spam Over IP Telephony (SPIT) The SEM willtake the actions defined by the administrator.

    Operating principle

    The PEM function, the TEOZ base, captures the network frames and analyzes the protocols using thepreviously described functions.

    When the SEM is enabled, the PEM function retrieves the parameters of the calls in negotiation or inprogress and compares these parameters to the usage rules of the ToIP system.

    The SEM module implements an additional security policy, based on the analysis of sessions over thetelephone network. The analysis can be instantaneous (authorize/deny) or can take place after data

    integration over a time window (threshold rules).All rules are applied in real time to inform the system of any malicious use of telephony services.Suspicious sessions can be reported or terminated.

    Anti-SPIT capability

    The SEM module is used to filter parameters calls, especially for incoming calls. It is therefore able todetect occurrences of SPIT calls:

    N calls to one number

    Only 1 caller to N recipients

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    26/28

    Edition 5.0 April 201026 / 28

    3.3.2 Supported protocols

    The SEM module supports the following protocols:

    SIP H.323

    3.3.3 Examples of threats prevented by the SEM function

    The examples include, but are not limited to, the threats of the following list that demonstrates that someattacks are not correctly handled by the IP level analysis alone.

    Interception

    The PBX does not identify the function vulnerabilities, because it considers that they are systemfunctionalities. Example: the Monitor mode functionality (third party monitoring) allows the supervisor ofa call center to listen to agents conversations. Should it be unwisely used, this function is used to listen tothe conversations, without the persons knowledge.

    Call forwarding to premium-rate numbers

    The 08 numbers are authorized for occasional business uses. Hackers use the call forwarding function ofa terminal to divert the calls to their servers where the callers are overcharged (possible prejudice:several tens of thousands euros in a few hours).

    Specific context

    Several unusual numbers (international, mobile phones) are dialed at unusual hours: the PBX candetect the data separately but is unable to associate the events to take corrective actions.

    Functional abuse

    Use of conference bridges or call forwarding functions to make long-distance calls charged to thecompany.

    SPIT, war dialing

    Example 1: SIP telephones of various origins are deployed in the infrastructure. Protocols can be wronglyimplemented in some telephones that will send unsolicited calls, or mass calls.

    Example 2: an attacker floods heavy traffic to send advertising messages to voicemails.

    3.4 Synthesis

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    27/28

    Edition 5.0 April 201027 / 28

    Figure 19: Master-slave architecture

    The flow chart of PEM and SEM security services is illustrated in the next figure:

    With the association of PEM and SEM functionalities, TEOZ provides a unique security solution for ToIPservices, on both IP and telephone components.

    Moreover, the TEOZ ToIP expertise is supported by:

    Real-time stream processing: seamless integration of PEM analysis engines, IDPS optimization,use of advanced processors

    Availability optimization: strong diminution of false positives, HA architecture with conservationof security analysis states and connections states

    Quality of protocol analyses, on standard or proprietary protocols

    Appliance sizing ensuring Quality of Service according to the number and profiles of users

    The TEOZ functionalities will continue to be complemented with other ToIP services for the years to cometo provide users with a true security solution.

    Pare-feuFiltrage IP tat, stateful inspection

    Rception du 1erpaquet

    Confrontation aux

    rgles de flux

    Cration de la

    connexion

    Analyse individuelle

    du paquet

    Rception du Nmepaquet

    Confrontation aux

    rgles de flux

    Analyse individuelle

    du paquet

    Analyse applicativePrvention dintrusion

    Dfragmentation etrassemblage du message

    Contrle de conformit et

    usage du protocole

    Confrontation aux rgles

    protocolaires

    Dcodage applicatif

    IDSTemps rel

    Rcuparation du contextede la connexion

    Pondration

    Confrontation aux

    signatures contextuelles

    Scurit applicative IP (PEM)

    Politique Scurit VoixParamtres dappels

    Extraction des

    paramtres dappel

    Actions sur non

    conformit de lusage

    Confrontation aux rgles

    SEM

    Scurit applicative

    tlphonique (SEM)

    FirewallStateful IP filtering - Stateful inspection

    Comparison

    with stream rules

    Connection setup

    Individual packet

    analysis

    Application analysis

    Intrusion prevention

    Message defragmentation

    and reassembly

    Compliance and

    protocol usage check

    Comparison with protocol

    rules

    Application-layer

    decoding

    IDSReal-time

    Retrieval of connection

    context

    Weighting

    Comparison with

    contextual signatures

    IP application-layer security (PEM)

    Voice security policyCall parameters

    Retrieval of call

    parameters

    Actions in case of non-

    compliance with usage

    policy

    Comparison with SEM

    rules

    Telephone application-

    layer security (SEM)

    1st packetreception

    Ntt packetreception

    Comparison

    with stream rules

    Individual packet

    analysis

  • 7/31/2019 Thales_ToIP TEOZ_ White Paper_EN Ed5.0

    28/28

    Edition 5 0 April 201028 / 28

    4. Contact Information

    Thales Communications

    160, Boulevard de Valmy

    BP 82

    92704 Colombes CedexFrance

    Phone : +33 (0)1 46 13 22 29

    Fax : +33 (0)1 46 13 22 97

    Email : [email protected]