ToIP PROTECTION ITEM DESCRIPTION V2.1

ToIP PROTECTION ITEM DESCRIPTION V2.1 Edition 4.0 p. 1/58 RSS/SSI/TeS/DCF/FH-PhD,07/32 September 2009 Les informations contenues dans ce document demeurent la propriété du groupe THALES and ne doivent pas être divulguées par le destinataire à des tiers sans l accord é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 written authorisation given by THALES Communications

1. TOIP AND SERVICE SECURITY 4 1.1 ToIP architectures and protocols Introduction 4 1.1.1 H.323 protocol 4 1.1.2 SIP (Session Initiation Protocol) 4 1.1.3 MGCP (Media Gateway Control Protocol) 4 1.1.4 Proprietary technologies 5 1.2 ToIP services 5 1.3 ToIP security: background and stakes 6 1.3.1 From ISDN to ToIP 6 1.3.2 The challenges 6 1.3.3 The security stakes 7 1.3.4 2009 and 2010: the critical years 9 2. WHAT PROTECTION FOR TOIP? 10 2.1 Functional security blocks 10 2.1.1 Network segmentation 10 2.1.2 Access control at the edge of the data network 11 2.1.3 Access control at the edge of the telephony network 11 2.1.4 Network authentication 11 2.1.5 Integrity and confidentiality of signaling and communications 11 2.1.6 Server and application authentication 11 2.1.7 Core filtering in front of servers: stream safety 11 2.2 Focus: an application-layer filter to protect ToIP servers 12 2.3 SBC, edge firewall, application-layer firewall 12 2.3.1 Edge firewalls 12 2.3.2 Session Border Controller (SBC) 13 2.3.3 Application-layer protection for servers 13 2.3.4 Conclusion 15 3. TEOZ: APPLICATION-LAYER SECURITY SOLUTION FOR TOIP 17 3.1 TMZ: a sanctuary for voice and video applications 17 3.1.1 TMZ 17 3.1.2 TMZ partitioning 18 3.1.3 Two filtering levels 18 3.2 Real-time IP application-layer analysis: Protocol Expert Module (PEM) 19 3.2.1 Stateful IP filtering 20 3.2.2 Application-layer analysis 23 3.2.3 Contextualized signatures IDPS 32 3.2.4 Synthesis 35 3.2.5 ToIP threats Examples in Layers 3-7 36 3.3 Usage analysis and control: Session Expert Module (SEM) 37 3.3.1 Description 37 3.3.2 Supported protocols 39 3.3.3 SEM module actions 39 3.3.4 Examples of threats prevented by the SEM function 39 3.4 Network functionalities 40 3.4.1 IP translations 40 3.4.2 Routing 41 3.4.3 Connectivity, VLAN, aggregation 42 3.4.4 Quality of Service (QoS) 42 3.4.5 DHCP 42 3.4.6 Date and time 43 3.5 High availability (clustering) 43 2 / 58

3.5.1 Principle 43 3.5.2 VRRP (state protocol) 44 3.5.3 Active/Passive mode 45 3.5.4 Active/active mode 47 3.5.5 Cluster supervision 48 3.6 High Availability (OXE spatial redundancy) 48 3.7 Hardware technology 49 3.8 Licenses 49 3.9 PEM module administration 49 3.9.1 Secured access 50 3.9.2 Configuration tool 50 3.9.3 Supervision 51 3.9.4 Logs 51 3.9.5 Master/slave supervision architectures 52 3.10 SEM module administration 53 3.11 Updates 53 3.11.1 Updating the software 53 3.11.2 Updating IDPS 53 3.12 Synthesis 54 3.13 TEOZ 2000 and TEOZ 3500 54 3.13.1 Hardware characteristics 54 3.13.2 Security-safety 55 3.13.3 TEOZ 2000 performance 56 3.13.4 TEOZ 3500 performance 56 3.14 Alcatel-Lucent inter-operability 56 4. CONTACT INFORMATION 58 3 / 58

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 network transmission. 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 used for sending or receiving multimedia information. Further standards, as H450, provide supplementary services: call transfer, call forwarding, call hold, call waiting The H.323 system is composed of end-points, terminals, gateways, and gatekeepers (address resolution and bandwidth control). H.323 is the most commonly deployed ToIP (Telephony over Internet Protocol) protocol and is widely used 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 is primarily used in ToIP applications; it is also used in application-layer sessions. The SIP roadmap allows its use in other media streams as video conferencing, video according to the development policy of the manufacturers. 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, location servers 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 as designed in ETSI. TISPAN and IMS have chosen other solutions for ToIP security: SIP is using TLS for TISPAN and is using 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 and H.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 TV offerings. MGCP is a stimulus protocol, the endpoints being "low-intelligence" devices: the protocol is only used to carry keystroke information from the subscriber s set to a central server. The server will then interpret the keystrokes to execute the corresponding actions. This protocol can then be used with all (analog or digital) terminals already installed at the clients facilities, 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 server controls the subscriber s set. 4 / 58

1.1.4 Proprietary technologies Although standard protocols as SIP are the most widely used, the offers of many ToIP providers are based 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 are to: Keep a functional phone system, identical to the existing ISDN, that what the standard protocols were 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 the same 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 lion s share of corporate customers. 1.2 ToIP services As we use a telephone every day, this technology seems to be rather simple. However, the services provided 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 IP applications 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 5 / 58

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 ISDN PBX ISDN WAN IP (MPLS) Figure 1: RNIS architecture With ToIP, this is no longer the case: Integrated networks (at least at the hardware level) Pooled terminals Converged services And shared threats IPBX WAN IP (MPLS) ISDN Figure 2: ToIP architecture Although simple in appearance, convergence will be the source of complexities, first in terms of infrastructure, 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 standard software components that do not integrate security requirements. The component vulnerability is then transmitted to telephony applications. Number of network elements implemented: a ToIP infrastructure will use several hundreds to several tens of thousands of network elements (routers, switches, servers, terminals ). Each one being a potential entry point for threats. Especially, ToIP terminals are functionally similar to computers, with operating systems, stacks, http services, ftp services this phenomenon is further accelerated by the development of virtual terminals (softphones). Hacking the iphone through SMS reveals the potential weakness of terminals in an infrastructure. 6 / 58

Variety and complexity of protocols: whether they are standard or proprietary, the complexity of ToIP 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 no longer the question-response mode currently used for data exchanges. Besides, most of standard protocols are open, and offered in various implementation configurations, according to the manufacturers, with proprietary extensions. SIP is therefore renowned for its misleading simplicity. Interconnection with data networks: by construction, partition of voice and data networks is limited. To benefit from service convergence, resources, as directories, messaging, or DNS and DHCP 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 crosscontamination. Availability and Quality of Service (QoS) specifications are also to be considered, and telephony services must 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 of opportunities and loss of efficiency. Moreover, emergency calls should be made at any time, to meet safety obligations and address personrelated 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 and short time-to-market are decisive for the providers work. Comprehensive and native security implementation is considered, whether right or wrong, as a complication factor that slows down availability. As a result, fraud and attacks increase significantly: these new means of communication are diverted from 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 the network topology, stream matrixes, applications and protocols to be discovered and attack strategies 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 economic competition, whatever the field of activity and size of the company (this issue is often neglected by too many companies) and to protect personal data (privacy) exchanged during phone conversations. This is the case for administrations (income tax and social services, health services, legal services ), and private sector (banks, insurance companies, human resource departments ). Many States require confidentiality of personal data stored and exchanged in information systems, including phone systems. Traditional telephony is considered as safe because we assume that tapping is not possible without 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 not sufficiently segmented. In addition, segmentation (VLANs) is not the ultimate solution. 7 / 58

Availability The purpose of ToIP is to deliver the 99.999% availability of ISDN telephony. If the new technological 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 and external denials of service. Because of the sensitivity of telephone systems, a slightly downgraded Quality of Service makes the application unavailable: attacks are much more subtle than bandwidth saturation. Such attacks may alter the traffic and prevent access to the company s data. There are two ways of generating denial of service attacks in ToIP: o Making unavailable by saturation, freeze or isolation the resources indispensable for the application operation (call server, directory, DNS ). Note: for ToIP, saturation can 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 or introducing jitter; aborting calls by introducing latency or interfering on packet routing. Finally, denial of service can occur upon technical failures, especially when using low-cost technologies 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 ISDN technology: call forwarding to premium-rate or international numbers, conference bridges to connect external subscribers free of charge The objective is not only to detect fraudulent use e.g. intrusion in the system for mercantile purposes 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 personal details of a user either to have access to unauthorized rights or privileges, or to deceive a correspondent. Besides direct risks, there is a risk to compromise the trust in financial and state certifications (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 harm Organization B. In this case, and according to the losses, Organization B is entitled to have Organization A condemned, and to ask for civil remedies by law. Risks in terms of finance and image can be substantial. Therefore Organization A must detect intrusions and stepping-stone attacks beforehand, and in case of an attack as security is not infallible demonstrate its goodwill. Nuisances like SPAM SPIT (Spam over Internet Telephony) and SPIM (Spam over Instant Messaging) may become nuisances 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. 8 / 58

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 takes about 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, impact and 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 be secured, instead they are rightfully asking: what do you suggest to secure ToIP?. Similarly, quality of protection 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 by criminal 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 requires investments 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 the IS, 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 and higher profits from frauds. Three to four years are required for these two parameters to become mature: this is the case in 2009 and 2010. 9 / 58

2. What protection for ToIP? 2.1 Functional security blocks The next figures summarizes the main components of ToIP protection: Servers authentication Integrity and confidentiality of communications Streams safety Call servers Hiding, translation («peering») Network authentication ISDN Integrity and confidentiality of signaling IP WAN (MPLS) Voice/data/video/administration segmentation Figure 3: bricks for protection Access control to network, NAT, pinholing 2.1.1 Network segmentation To avoid stepping-stone attacks from the data network to the voice network, streams will be segmented into different virtual (if not physical) networks. There are four virtual networks: voice, data, video, and administration. 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 do believe it. There may exist bridges between these 3 VLANs: To benefit from convergence, some applications will be used by ToIP services/terminals, and by data 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 several thousands of routers, switches, gateways that will be configured to support VLANs. Is there any network 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 experienced technicians. 10 / 58

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 NAT functions, 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 the impact on deployments and performances. Free encryption services must not be trusted, because their performances 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 terminals connect to ToIP services: this is signaling encryption. This is achieved through sharing of certificates and encryption 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 be ensured 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. 11 / 58

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 threats pertaining to IP as well as to ISDN. Most security packages currently available with the ToIP label focus on 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 their particularities. An application-layer protection mechanism for ToIP must be multi-functional to address all levels of protection (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, in spite 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 90 s when companies were connected to the Internet. The purpose was to protect companies intranets from potential threats due to the Internet and to control incoming and outgoing 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 is resource consuming. To be effective, edge filtering would require controlling all protocols accessing to the network 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-response mode, 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 change them. ToIP uses successive protocol sessions to establish and maintain communications: first a primary session (e.g. signaling) with predictable characteristics (protocols, ports ) that can be included in the 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 the primary session. Therefore, we have two possible situations: o The edge firewall is not able to decode the data exchanged during the primary session: by default, all communication ports likely to be used by the secondary communications will have to be opened. This is canceling the border filter otherwise outgoing/incoming communications could not get through the firewall. This situation prevailed for first ToIP deployments. 12 / 58

o The edge firewall is able to decode the data exchanged during the primary session: only the necessary ports are dynamically opened at the start of the secondary session, and closed at the session s 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 the border for routing over the operator s 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 will remain in Layer 7 and communications could not be established. NAT will have then to be performed in 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 therefore the only ones to be implemented. They require retrieving the data available in Layer 7 (application-layer). Many providers propose firewalls with application-layer analysis capabilities, which is abusive, because no security control is performed 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, which is 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 the border of the voice infrastructure, at the connection of the operator s 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 same protocols 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, then SIP 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 infrastructure core, i.e. to protect servers. Their functional strong points (see previous section) are of limited use. 13 / 58

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 expected during the primary session (Protocol A). ToIP protocols, sessions and session links are much more complex than what was previously known in data services. Suitable engines will have to be implemented and the protocol technologies used by the providers will have to be precisely known. Finally, standard protocols (SIP ), proprietary protocols and proprietary extensions of standard protocols 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, call directions, 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 infrastructure operation, the application-layer filter will be capable of managing protocols or streams that can only be 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 to traffic 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 within a short time. The platform will therefore not be sized to throughput data (traditional performance indicator for firewalls 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 critical burst 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 and ToIP providers will include this requirement. 14 / 58

Integration, validation, simulation capabilities The manufacturer of the ToIP application-layer security solution will be provided with laboratories able 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 a real 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 of functions, these three items may seem equivalent. If the lists of functions can be similar, the completeness and maturity level of each solution make them not interchangeable. Checking the presence or absence of a function is not enough: this function must be weighted according to 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 Edge FW TEOZ SBC Routing QoS Data protocols Analysis engine Voice protocols Network interconnection Figure 4: functional weighting 15 / 58

As a conclusion, the next figure summarizes the position of each item: Voice / Video servers SBC Distant subscribers Voice IP WAN Firewall Distant subscribers Data IP WAN / Internet Figure 5: positionning in the network 16 / 58

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 protecting the applications critical to ToIP. TEOZ is embedded in the Organization s network to create a Trusted Multimedia Zone (TMZ) that hosts sensitive devices as servers. The next sections describe the notion of TMZ and the proposed application-layer security services offered to 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 will become 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 and at 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 computer networks 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 be considered as sources of potential (intentional or unintentional) attacks. Thus, security of ToIP applications must not only be considered at the infrastructure border, but also at the 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 filtering must be provided between applications and users, and between applications themselves. Streams will be analyzed on all network interfaces, between applications and users (subscribers or cooperative applications), and applications will be isolated in a dedicated network area called the Trusted Multimedia Zone (TMZ). The TMZ is therefore a sanctuary for vulnerable servers. 17 / 58

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 be pooled 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, which complements the edge filter. The two filtering stages are the following: 1 st 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 and protocol translation) 2 nd 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 known in 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, FTP firewalls ) different from border items. It is also interesting to note that these specialized items are designed and marketed by specific providers, because their business models are different from edge firewalls. The TMZ notion, created with TEOZ, is applicable to another critical application: ToIP. 18 / 58

Web services e-business erp / crm HTTP, XML, SOAP app. filter FTP(s) services FTP app. filter Databases SQL app. filter ToIP Unified comm. internal users IP WAN The use of specialized items is already standard for critical applications PSTN 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 a firewall (IDPS) dedicated to voice and video applications. It is characterized by a comprehensive knowledge of standard protocols (SIP, H.323, MGCP, RTP, RTCP, SDP ) and its capability of embedding analysis modules 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 analysis engines Homogeneous administrative environment (graphical interface) The main security functions implemented in the PEM are: Stateful IP filtering: o State engine for Layers 3 & 4 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 proprietary specifications) o Compliance analysis of application protocol behavior 19 / 58

o Protocols supported: SIP, MGCP, H.323, RTP, RTCP, RTSP, CSTA, SSL, SNMP, SQLnet, Netbios, DNS, FTP, TFTP, HTTP, proprietary protocols IDPS based on contextual signatures The engine used by the PEM is the first real-time technology that combines stateful IP filtering techniques and application-layer analysis techniques. The protection is based on stream analysis at the level of the inter-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 not defined 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 be blocked: 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 abnormal requests in the URL Buffer overflows due to unusually long requests Transport of malicious data in application-layer requests (code injection, use of reserved bytes ) By analyzing applications and controlling their operation, the analysis engine defines the expected behavior. Violation of security rules generates a preventive action (active response) and/or an alert message to the administrator. Unlike strictly reactive methods (based only on signatures), the engine protects the ToIP system against unknown 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 associated with 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 OSI layers, up to the Transport Layer. The specifications of application-layer checks (up to OSI Layer 7) are described in 3.2.5. 20 / 58

Filtering rules The filtering policy is defined as a sequence of filtering rules. For a given IP connection, the filtering engine browses the specified set of rules until it finds the matching rule and applies the corresponding action. 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 and TCP 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 hour s range from 00h00 to 23h59, and/or a day s 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 the header sections of the IP packets in the stream Complete log: generates logs (that can be viewed later using the TEOZ-Monitoring tool) about the header 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 to be 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 a stream. 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. 21 / 58

IP filtering The following checks are performed on any stream accepted by the filtering policy: LAND attack checking: checking that the source and destination addresses are different. Limitation of private addresses: checking that the source and destination addresses of a packet coming from an external interface are not private IP addresses, as defined in RFC 1918. Broadcast packets filtering. Deleting IP options of source packets before delivery to the destination. This check can be disabled through a system command. ICMP checks For an ICMP stream, a specific policy can be applied for each ICMP code/type. This filtering policy is defined in each TEOZ configuration. By default, an ICMP filtering policy is defined for each TEOZ. The possible criteria of each ICMP type/code of an ICMP policy can be: Internal network to internal network (in2in): the ICMP message transmitted by an internal network to an internal network is accepted. Internal network to external network (in2out): the ICMP message transmitted by an internal network to an external network is accepted. External network to internal network (out2in): the ICMP message transmitted by an external network to an internal network is accepted. Log-reject: the rejected ICMP message is logged. Log-accept: the accepted message ICMP is logged. Connection timeout: if the connection associated with the ICMP message is a TCP connection, the TCP connection timeout can be changed: if the Redefine connection timeout option is ticked, the TCP connection timeout is set to 5 seconds. Timeouts of UDP and ICMP pseudo-connections are not changed by the reception of ICMP messages. TCP filtering The following checks are performed on any TCP stream accepted by the filtering policy: Validity of header formats (lengths, among other things) TCP checksum Sequence number TCP flags: validity of headers with reference to the state of the TCP session These checks are not configurable Should a TCP stream not comply with the checks, a specific alert is transmitted and can be read from IP logs 22 / 58

3.2.2 Application-layer analysis Presentation 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 RFCincompliant headers (e.g. binary data in headers), activates critical functions (e.g. redirection, call interception 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, but also ensures the traffic meets the normal protocol usage to protect against RFC-compliant attacks or intrusions (e.g. insertion of malicious data in URLs, hidden scripts in requests and abuse of encapsulated protocols). Additional rules for protocol: checks the traffic with reference to a set of limits or rules to provide additional 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 NAT traversal for the protocol: changes the addresses contained in the application data block and opens dynamically 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. RTSP module The RTSP module is used to filtrate the RTSP multimedia streams and protocol parameters at the establishment of the connection. It does not cut down the RTSP negotiation but prevents the negotiation of the secondary connections that do not comply with the filtering rules. RTP/RTCP module The RTP/RTCP module is used to secure the RTP (Real Time Protocol) or RTCP (Real Time Control Protocol) part of a VoIP communication. RTP/RTCP is used during the transfer phase of VoIP communication data (audio/video). The major threats targeting VoIP services are created when SIP/MGCP calls (protected by the SIP or MGCP module) are established and released. However, attacks can happen through invisible RTP channels, during the data transfer phase. The RTP/RTCP module reduces these attack risks. The major functionalities of the RTP/RTCP module to prevent these attacks are: Codec check: at the establishment of a VoIP call and negotiation of a RTP/RTCP channel to transfer multimedia streams, a set of codecs is negotiated and used for session encoding and numbering. The list of supported codecs is communicated to the RTP/RTCP module for the module to check 23 / 58

that the codec used for a received RTP/RTCP packet is valid. The codec used is identified in the packet payload and compared with the list of supported codecs. Format check: there are a number of checks carried out by the RTP/RTCP module on the received RTP/RTCP packets (RTP headers, RTCP headers). MGCP module The MGCP module is used to secure the VoIP communication through media gateways: e.g. VoIP calls between two networks (telephone network and IP network). The main functionalities of the module against MGCP attacks are the following: Header check: the module checks that the MGCP headers are correctly formatted and comply with RFC 3435 Data check: first, the module checks that the SDP header lines are correctly formatted and that the SDP data parameters comply with the configuration set by the firewall administrator. This module will then be able to produce tracking information on RTP streams between gateways. Call-Agent and gateway restrictions: the module is able to authorize or not a gateway or Call-Agent to communicate with it, according to the firewall standard filtering rules. The Access Control Lists (ACL) required for the system s security are generated at the IP level and not at the domain name space. Moreover, gateways can be filtered according to the IDPS rules. Authorized and unauthorized RTP/RTCP data streams: the module is able to authorize or not a RTP/RTCP stream to pass the firewalls. The RTP module analyzes each RTP data stream. Note: The MGCP module is a stimulus protocol: it does not transmit enough information through the network to escalate the events to the SEM feature. H323 module H.323 is an umbrella recommendation from the ITU (International Telecommunication Unit) that defines the processes and protocols to provide audio-visual communication sessions on any packet network. The H323TCP module escalates the call data to the SEM module. If the call is denied, the H323TCP module is able to terminate the call by sending a frame to the relevant terminals. The H.323 module will allow the dynamic opening of signaling streams: Between terminals Between terminals and Gatekeepers This specification deals with the signaling streams of a H.323 trunk (between two media gateways). The H323 module will allow the opening of multimedia streams: Voice Audio Data (T120) Sub-modules H.323 (H244 and H235) Fax (T38 ) 24 / 58

Optionally, the opening of some multimedia streams may be prohibited. The H323 module handles NAT management (handles addresses and ports to create connections). SIP module The SIP module is used to secure a VoIP network implementing the SIP (Session Initiation Protocol) protocol. SIP can be used to establish and release VoIP communications. During the communication phase, multimedia data are exchanged through one or many RTP/RTCP streams (secured by the RTP/RTCP module). SIP VoIP communication requires at least two UAs (User Agents): one for the client (UAC), which sends SIP requests, and one for the server (UAS), which receives the requests. In the simplest communication scenario, SIP messages are directly exchanged between both UAs. The call can be routed through a proxy server, which is an intermediary entity between UAs and establishes a VoIP communication to transfer the SIP messages from the callers to the called parties. Then, calling parties and called parties are supported by the proxy server only at the establishment and release of the communication. Therefore, the proxy server acts as both a server and a client. Sometimes, a redirect server can handle the calls (e.g. when the call is redirected to the voicemail of the called party). Note: So far, the SIP module is able to handle the SIP messages transported by UDP. The major functionalities of the SIP module to prevent UDP attacks are: Header check: the module checks that the SIP headers are correctly formatted and comply with the RFC 3261. Management of requests and return codes, manegament of SIP verbs (INVITE, ACK, BYE, CANCEL, ), management of headers (Call-ID, From, To ), of parameters (rport, branch, ), check of the headers size, management of URIs, For each level, options allow to add proprietary items (verbs, headers ). Translation: the module translates NAT addresses in the body of the SIP messages. The corresponding RTP/RTCP addresses are similarly translated. Management of dynamic opening/closing of ports for the secondary connection, through analysis of the SDP protocol NAT management Control of the sequence of the messages The SIP module escalates the call data for transmission to the SEM. If the call is denied by the SEM feature, the SIP module is able to terminate the call by sending a frame to the relevant terminals. UA and UA-DL modules The UA module is used to manage the analysis of the UA (Universel Alcatel) protocol used in the Alcatel-Lucent s OmniPCX Enterprise system (VoIP telephony system). 25 / 58

Figure 8: Alcatel-Lucent s OmniPCX Enterprise system Overview The UA protocol is a set of protocols used between the Alcatel-Lucent hardware components. It is the main module for UA management and is broken down in several sub modules: Figure 9: UA module architecture The UA module presents a single entry point to the user for the UA protocol by hiding the sub-modules required to analyze the UA protocol (TFTP, UA-DL, UA-NOE, UA-IPLINK...). In specific deployment situations, the UADL and TFTP modules are available for the manager. The UA protocol is a stimulus protocol: it does not transmit enough information through the network to escalate the events to the SEM. The UA module executes the following checks: Analyzes Alcatel proprietary TFTP options Analyzes files transferred by TFTP Manages errors due to TFTP transfers Cancels checks using application-layers options Forces operating parameters 26 / 58

The UA module executes the following tasks: Dynamically opens the ports for the UA-DL signaling stream (secure version or not) Dynamically opens the ports for the secondary TFTP streams Maintain inactive the redundant UA-DL communications (can be disabled, optional) Manages NAT (handles addresses and ports to create connections) Handles the nature of the files transmitted to manage NAT The UA-DL (Data Link) protocol is used to secure the data transmission through UDP by adding a sequence number which acknowledges each transmitted data packet. Data Link is a level-5 protocol used to establish a session between 2 endpoints (Call Server and IP telephone). The UA-DL module executes the following checks: Figure 10: UA modules architecture Checks session establishment Closes UA-NOE and UA-IPLINK secondary connections Checks message formats Checks timers Checks data sequences The UA-DL module executes the following tasks: Routes UA/NOE and UA/IPLINK signaling streams UA-NOE module The UA-NOE module is used to establish RTP/RTCP connections, supervise communication recording (as applicable) and establishment of telnet debugging sessions. The UA-NOE protocol is mainly used by the following terminals: IP Phone IP Touch SoftPhone The UA-NOE module executes the following checks: Checks the validity of the UA/NOE protocol parameters 27 / 58

Checks the establishment and release of audio streams between two terminals Manages Call Server debugging for a terminal Manages NAT (handles addresses and ports to create connections) UA-IPLINK module The UA-IPLINK (IPlink signaling) protocol is a sub-assembly of the UA protocol, used in signaling between MGs (Media Gateways) and CSs (Call Servers). The UA-IPLINK module is used to establish RTP/RTCP connections to MG elements and to supervise the establishment of telnet debugging sessions. The UA-NOE module executes the following checks: Checks the validity of the UA/IPLINK protocol parameters Checks the MG initialization phase Checks the establishment and release of session streams between a MG and the Call Server Manages Call Server debugging for a MG Manages NAT (handles addresses and ports to create connections) CSTA module The CSTA module is used to analyze and secure the CSTA protocol. Initially, it is limited to the Alcatel- Lucent equipment. CSTA (Computer-Supported Telecommunications Applications) is a standard that defines a set of advanced services and protocols for communications between computer and telephony networks. It is located at the upper OSI (Open Systems Interconnect) Layer (Application Layer: Layer 7, last layer). This standard has been developed by ECMA, a group of companies having extensive experience in interconnections between computer and telephony systems. The CSTA module supports only the CSTA Phase II protocol based on ASN1, as defined in the following documents: ECMA-217: Services for Computer Supported Telecommunications Applications (CSTA) - Phase II - December 1994 ECMA-218: Protocol for Computer Supported Telecommunications Applications (CSTA) - Phase II - December 1994 ECMA-TR/68: Scenarios for Computer Supported Telecommunications Applications (CSTA) - Phase II -December 1994 HTTP module The HTTP protocol (all versions) is validated by TEOZ using a finite-state automaton, which includes a state for each connection end: one for the client end, and one for the server end. The methods supported by the module depend on the HTTP version used by the client. Authorized methods are the following: HTTP/0.9: GET HTTP/1.0: GET, POST, HEAD and CONNECT 28 / 58

HTTP/1.1: GET, POST, HEAD, CONNECT, OPTIONS, PUT, DELETE and TRACE FTP module The FTP module executes the following checks on the data sent by the Client to the Server: Checks general command format (command, arguments, CR+LF) Ensures the command is authorized Checks spacer and arguments according to the command The list of commands authorized by default derives from RFCs and drafts: RFC 959: USER, PASS, ACCT, CWD, CDUP, SMNT, QUIT, REIN, PORT, PASV, TYPE, STRU, MODE, RETR, STOR, STOU, APPE, ALLO, REST, RNFR, RNTO, ABOR, DELE, RMD, MKD, PWD, LIST, NLST, SITE, SYST, STAT, HELP and NOOP. RFC 765: XMKD, XRMD, XPWD and XCUP (for implementations that do not comply with RFC 959). FTPEXT: MDTM, SIZE, FEAT, MLST, MLSD and OPTS. Commands indicated for RFC 765 were deleted from RFC 959 but are still used by some FTP clients. The list of authorized commands can be changed using the cmd_allow, cmd_forbidden and cmd_refuse application options. The responses sent by the server are checked by the FTP module: they always include 3 digits, 1 space or 1 dash (-), text and end-of-line characters CR+LF. TFTP module The TFTP module is used to manage the analysis of the TFTP (Trivial Transfer File Protocol) protocol. Protocol characteristics: Transport protocol: UDP Default port: 69. RFC 1350, RFC 2347 and RFC 2348 compliant The TFTP module executes the following checks: Manages the dynamic opening/closing of ports for the secondary connection of data transfer Checks message formats Checks frame sizes Checks message sequencing Hook management for external modules Manages request retransmissions Checks authorized messages NAT management (handles addresses and ports to create connections) 29 / 58

Example of TFTP exchange: Step 1: A requests to read Figure 11: TFTP exchange Step 2: A receives data packet No. 1 Step 3: A acknowledges data packet No. 1 DNS module The DNS protocol uses both TCP and UDP and is always the same. The DNS module is used to manage the DNS protocol on both transport protocols TCP and UDP. The module analyzes the validity of the header and the DNS data as well. It checks that the packet is coherent with the data already transferred. It especially checks that the response corresponds to a transmitted request. For the UDP protocol (not connected), the active connection is closed after the server has sent all responses. NetBIOS module The NBT (NetBIOS over TCP) protocol provides NetBIOS services on a TCP/IP or UDP/IP network layer. It includes several sub-protocols: NetBIOS Name Service (NBNS): Uses UDP (or TCP) Port 137 NetBIOS Datagram Service (NBDGM): Uses UDP Port 138 NetBIOS Session Service (NBSSN): Uses TCP Port 139 The NetBIOS application-layer module analyzes stream compliance with the 3 sub-protocols. 30 / 58

SQLNET module The following security functions apply to the SQLNET module for exchanges of SQL requests and data (using SQL*NET/Net9 protocol) with an Oracle database: Protocol filtering Address translation Compliance with the rules of the SQL*NET/Net9 protocol The SQLNET module supports only Oracle version 10g. SNMP module The SNMP module analyzes the SNMPv1, SNMPv2c and SNMPv3 protocols. The SNMP protocol checks the set and get commands and SNMP TRAPs. A SNMPv1 or SNMPv2c packet contains: The SNMP version number One SNMP community name One PDU (Protocol Data Unit) A SNMPv3 message contains: The SNMP version number One header Security parameters One PDU The SNMP module executes the following checks on SNMP exchanges: ASN.1 Version number Content SSL module The SSL/TLS module analyzes the SSL (Secure Socket Layer) traffic and TLS (Transport Layer Security) traffic encapsulated in the TCP protocol. It supports the SSL v2.0, SSL v3.0, TLS v1.0 and TLS v1.1 protocols. This module is used by the HTTP modules that use the HTTPS (HTTP + SSL) protocol. 31 / 58

3.2.3 Contextualized signatures IDPS IDPS General The IDPS (Inline Detection and Prevention System) technology is an extension to the application-layer analysis 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 requires considerable resources and can be a bottleneck to systems that cut off data streams. Off-line equipment does 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 protocols as being malicious (containing attack signatures). IDPS signatures are often character strings: a session may include this character string without being malicious. A signature is an attack signature only in a given context. Same character strings (signatures) will not have the same action on different protocols. If the 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 critical communications as ToIP applications. Moreover, unjustified alerts hinder service availability and can hide real alerts (false negatives). TEOZ IDPS The IDPS (Inline Detection and Prevention System) is an extension to the TEOZ application-layer analysis. It is capable of detecting and neutralizing application-layer attacks with or without protocol violation, taking connection context into account. The TEOZ application-layer analysis stops attacks to application-layer protocols. This protection is complemented 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 ToIP real-time streams. A contextualized signature database identifies and stops the attacks that cannot be detected by the application-layer analysis. The IDPS engine is highly integrated to the application-layer analysis engine (see previous section) to minimize processes and optimize overall performance. Therefore, the IDPS engine: Does not have to process the major number of attacks, which have been previously stopped by the application-layer analysis. Knows the connection context to apply to the streams only the relevant signatures. Optimization of the signature database The IDPS being integrated to TEOZ, session characteristics are compared with the database content after the application-layer has been analyzed. In consequence, the signature database only contains the attack signatures that are not reliably blocked by the application-layer analysis. More precisely, protocol attacks and violations of expected use are blocked by the application-layer analysis engine. Therefore, they do not need to be referenced in the IDPS database: this mechanism reduces the size of the signature database, and then the processing time. 32 / 58

Optimization of the signature search mechanism TEOZ modules monitor the application state of each connection and provide the IDPS with accurate data to define the connection context. This function allows false positives to be limited (the analysis is performed with reference to the application state of the connection) and detects attacks with reference to a reduced and targeted signature database, for enhanced performances. The main system characteristic is to contextualize the signature database: signatures are indexed according to the protocol state in which they represent an attack. Therefore, for a given protocol and given application-layer state (i.e. at a given time of the session) intrusion detection is only performed on the signatures relevant to the context. This way, the IDPS does not search for all signatures in all contexts to optimize performance and avoid false positives. In addition, the search algorithm is mathematically optimized: it searches for all context signatures in only one pass. Finally, the IDPS engine has been developed in kernel mode, resulting in more rapid packet processing. Elimination of false positives Elimination of false positives is achieved through 3 complementary mechanisms: Signature databases are contextualized: by comparing only the signatures that match the protocol state of a connection, the IDPS drastically reduces the risk of false positives. Analysis is weighted: to limit false alerts through flexible behavior. When an IP packet contains a signature of interest, the IDPS does not necessarily trigger the alert and apply the corresponding procedure, because an attack is often a combination of individual benign actions. Using this weighting pattern, the IDPS behavior is as follows: o A score is assigned to each signature. o For a given active connection, each time the IDPS detects an attack signature (match), the score increments the connection alert level. This mechanism identifies an attack by matching the detection of several weighted signatures: the connection is stopped only when the cumulative score of detected signatures exceeds an attack threshold. The administrator sets the intervention threshold and the type of action: alert, TCP reset, half-drop (TCP reset on server side only), transparent drop. Signatures are grouped by profile according to the configuration of the environment to be protected (server, OS ). This profile management mechanism means that streams are searched only for attack signatures relevant to the protected environment. TEOZ IDPS remedies The IDPS response actions are the following: RESET: a TCP RST packet is sent to the hacker (source of IP packets having triggered the IDPS) and to the target (destination of IP packets having triggered the IDPS). RESET is applicable to 33 / 58

authorized connection: if the user has executed a command that does not comply with the RFCs, it is best to close the connection with an error message, rather than having a time out. However, a RESET response can inform the hacker of the presence of an IDPS; this could allow the hacker to change the attack. DROP: connection state is DROPPED, on hacker side and on server side. All further packets corresponding to this connection will be dropped. The DROP action is used to stop the connection without revealing the IDPS presence to the hacker. It has the disadvantage that it does not release the resources associated with the connection on the TMZ side (the connection stays open). HALF-DROP: connection state is DROPPED on hacker side only. All further packets transmitted by the hacker will be dropped, and a TCP RST packet is sent to the target. The HALF-DROP action is a compromise between the two previous actions. It is used to release the target resources and does not reveal the IDPS presence to the hacker. IDPS application signatures and profiles The IDPS relies on an attack signature database accessible in read mode using the TEOZ-Manager tool. Signatures are classified according to a logical tree structure: by application protocol, then by application state. A signature is defined by: Its name The application-layer protocol with which it is associated The application-layer state in which it will be searched Its identifier (the identifier of a signature generated by the administrator is greater than 100 000) Its pattern (the searched character string) The pattern type: o CS = Case Sensitive, when searching for the pattern, distinguish uppercase letters from lowercase letters o CI = Case Insensitive, when searching for the pattern, do not distinguish uppercase letters from lowercase letters o Joker = in the character string, the administrator writes one or many stars * that can be replaced by any other character. Note: one * replaces only one character. Its score References, which are descriptions or links to the signature origin, its explanation, etc. The administrator can create new application-layers signatures. Attack signatures are grouped in application-layer profiles. An application-layer profile is associated with a service to filtrate connections according to a relevant context by selecting only the suitable profile for a given stream. This mechanism limits the scope of the search. IDPS protocols IDPS signatures can be created and used for the following application-layer protocols: HTTP, SSL FTP, TFTP DNS UDP and DNS TCP 34 / 58

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 services that 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 The next figure summarizes the IP application-layer analyses performed on streams: Firewall Pare - feu Stateful IP filtering - Stateful inspection Filtrage IP à stateful inspectio Application Analyse applicative analysis Intrusion prevention Prévention IDS Real-time Temps Réception 1 st packet du 1er reception paquet Réception 1 st packet du 1er reception paquet Message Défragmentation defragmentation et réassemblage and reassembly du message Récuparation Retrieval of connection du contexte de la context connexion Confrontation Comparison aux with règles stream de flux rules Confrontation Comparison aux with règles stream de flux rules Application-layer Décodage applicatif decoding Confrontation Comparison with aux signatures contextual contextuelles signatures Connection Création de setup la connexion Contrôle Compliance de conformité and et usage protocol du usage protocole check Pondération Weighting Analyse Individual individuelle packet du analysis paquet Analyse Individual individuelle packet du analysis paquet Confrontation Comparison aux with règles protocol protocolaires rules Figure 12: PEM synthesis TEOZ filtering is broken down into 4 phases: 1 st phase: Layer-3 and Layer-4 filtering what is authorized to access the servers (addresses, ports, protocols). 2 nd phase: the authorized streams are analyzed by application-layer modules, which check protocol compliance and monitor the state of active connections. If packets violate the protocol, the connection is dropped. If packets are compliant, they enter the 3 rd analysis phase: the IDPS. 3 rd phase: the IDPS filtrates the packets authorized by the analysis modules by searching the streams for application-layer attack signatures. The complete signature database is not used for 35 / 58

each analysis: only the relevant signatures for the profile and application-layer state associated with an active connection are searched for. The IDPS considers the analysis context to optimize filtering performance. 4 th 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 ease other attacks by exploiting the system flaws and vulnerabilities, taking over components and having access to contents. 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 further by 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 registrar and replaces the legitimate registration with its own address. All calls will be diverted to the fraudulent equipment. The attack range is very wide: monitoring, password phishing or fraudulent calls charged to the valid user. Proxy impersonation: a proxy server is substituted to the legitimate call server. The fraudulent server will intercept the protocol to reroute the calls to fraudulent DNS servers, to have access to the communication content, or to block calls. Message tampering: the modification of message contents is intended to deceive servers into rerouting, listening and charging calls to another account. Session tampering: this attack will generate opening or closing frames either to generate false calls or tear down real calls. Hidden RTP channel: uses an open RTP channel to bypass the system and establish unauthorized calls (e.g. SIP in RTP), or exchange files. Denials of service (DoS), distributed denial-of-service (DDOS) : these attacks consist in saturating 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 eased by weak authentication, absence of encryption, unprotected DNS, unterminated sessions or widely open ports on firewalls. DoS attacks can be perpetrated on signaling, communications (media) by quality disruption, and terminals by sending flood of reset commands, incoming calls Phishing: subscribers, calls, identifiers and password 36 / 58

Unauthorized distant access: especially by rerouting web, FTP or telnet administration services of servers or terminals. NAT issues: many protocols do not originally comply with address translation. Therefore, two correspondents cannot communicate between each other in private IPV4 space (Back-to-Back User Agents) when NAT is enabled. Server-based mechanisms are able to establish this normally impossible connection by untangling the encryption chain (if any), which is a target for the attacks described above. Migration phase The migration phase will see the new ToIP and the standard ISDN telephone working together. The ISDN telephone is widely installed and will represent a significant part of the new installations. 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 be managed: 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 the call 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 restricted times For each call setup request, the server will check if the call is authorized or not by the rules. The system's limitation is that the server carries out this check for each unit call: it is able to decide if the call is authorized or not, i.e. if the call matches the user s right; however, it cannot detect if the usage is legitimate. Example: Mr. Magnac is a salesman for Germany. As such, he is allowed to pass international calls, but has no legitimacy to phone to Brazil twice a day. The TEOZ SEM function is used to define the rules and usage thresholds that specify what the Organization considers as a legitimate usage of its telephony system. When the system behavior exceeds these limits, it may be an abusive use, fraud, Spam Over IP Telephony (SPIT) The SEM will take the actions defined by the administrator. Operating principle The PEM function, the TEOZ base, captures the network frames and analyzes the protocols using the previously described functions. When the SEM is enabled, the PEM function retrieves the parameters of the calls in negotiation or in progress and compares these parameters to the usage rules of the ToIP system. 37 / 58

The SEM module implements an additional security policy, based on the analysis of sessions over the telephone 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. The purpose of the SEM module is to define users and exchange rules between users. These rules are based on the following factors: Identity of terminals involved in the calls: o E164 number o URI o IP address, port number o Interface o Location o Domains or groups of terminals o Etc. Protocol used for the exchange Exchange nature (voice, fax, modem, videoconference...) Occurrences over time (convergent calls: N to 1, divergent calls: 1 to N, convergent/divergent calls, over a sliding time window) Calendar management of exchanges Etc. Anti-SPIT capability The SEM module is used to filter parameters calls, especially for incoming calls. It is therefore able to detect occurrences of SPIT calls: N calls to one number Only 1 caller to N recipients To discriminate SPIT, the SEM will manage detection thresholds by determining: The sliding time window in seconds over which the detection is carried out The number of calls occurring within this time window These parameters enable a more or less aggressive SPIT detection, according to the customers requirements, and with rules of the following form: N incoming calls from a single caller within the last P seconds N incoming calls to a single internal terminal within the last P seconds The filtering rule is used to select N and P. The (N, P) pair determines detection aggressiveness. When the SEM has detected a suspicious caller (E164, URI...) it can be (temporarily or permanently) banned and blacklisted. 38 / 58

Call simulator The simulator is used to generate a call stream that transmits the call information to TEOZ, which will analyze the call and apply the previously set filtering rules. Therefore, it is possible to check the rule behavior, both before and after their implementation. The result is transmitted to the simulation interface and reports the action effectively applied to the communication. This test information will have no impact on the statistics of current and processed calls, whatever the result, as the production task has priority over the simulation task. The simulation can be performed: From a specific window of the graphical interface From a call file 3.3.2 Supported protocols The SEM module supports the following protocols: SIP H.323 3.3.3 SEM module actions The filtering engine performs real-time analysis of communications, according to the security policy. As a result, the filtering module can execute the following actions: PASS: communication is authorized DROP: communication is denied and must be dropped immediately BAN: idem DROP + the communications from the same caller will be denied during N seconds TAG: the exchange is tagged to perform a posteriori a behavioral analysis Generates an email alert This solution will allow the user to manage Black Lists, and Green Lists, and to put some streams under observation to detect potentially hazardous behaviors. 3.3.4 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 some attacks 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 system functionalities. Example: the Monitor mode functionality (third party monitoring) allows the supervisor of 39 / 58

a call center to listen to agents conversations. Should it be unwisely used, this function is used to listen to the conversations, without the person s knowledge. Call forwarding to premium-rate numbers The 08 numbers are authorized for occasional business uses. Hackers use the call forwarding function of a 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 can detect 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 the company. SPIT, war dialing Example 1: SIP telephones of various origins are deployed in the infrastructure. Protocols can be wrongly implemented 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 Network functionalities 3.4.1 IP translations IP address translation is used to hide the IP addresses of private networks from public networks. The address of a private network host is called private address ; the translation address is called public address. There are several types of translations of different uses and purposes. TEOZ supports the following IP translations: Static NAT (Network Address Translation) or static translation. Static NAT allows the network system to be protected when it connects to an external private network. A private address is mapped to a public address. Static NAT applies to incoming and outgoing connections. This is a simple one-to-one mapping of private and public addresses. Network masquerading Network masquerading consists in translating private network addresses into a single public IP address. Network masquerading does not apply to incoming connections: it is an asymmetric process. It would be indeed impossible to decide to which private address the incoming connection will be directed. For an outgoing connection, the source addresses of the packets coming out of the private network are translated into an address of the TEOZ output interface. For the return packets to be directed to the private host who has initiated the call, TEOZ also translates the source port (UDP, TCP) of the outgoing packets and maintains a translation table that connects the port to the private host. This translation requires a single public address for N private addresses. The method maximizes the available public IP address space. 40 / 58

N-1 translation The principle of N-1 translation is the same as network masquerading, but it is possible to select the IP address used to hide the source address. Therefore, it is possible to select a different translation address for a stream to a specific group of servers. This may be the case when a third party service requests a connection to a server with a specific IP address. PAT (Port Address Translation) Port Address Translation is used to send a server-specific service (TCP/UDP port) of the network to be protected to the unprotected domain. This is an asymmetric translation that applies only to incoming connections. The public destination pair (address, port) of the incoming packets is translated into a private destination pair (address, port). The reverse translation is performed on the source pair (address, port) of outgoing packets. This translation mode is used to hide the TCP/UDP ports really open in TMZ from the public network. 3.4.2 Routing TEOZ operates according to the following modes: Routed mode Each network interface has an IP address and the IP packets are transmitted from one input interface to an output interface, according to the sources/destinations. The routed mode is based on the routing data obtained either by configuration (static routing), or via protocol exchanges on Ethernet links. The exchanges implement the OSPF and RIP-2 routing protocols. Note: it is possible to define a default route for TEOZ: the route selected when no other route has been determined by the routing function. Bridge mode It is possible to allocate (or not) an IP address to the bridge interface (br0) that replaces for the network all bridged interfaces. The IP address of a bridge is configured; otherwise the bridge is called furtive (its interface has no IP address). Default route In TEOZ, the default route (public access) uses only an access via an Ethernet router. Accesses through ADSL, ISDN or cable interface/modem are not supported. The following functionalities can be configured on the interface associated with the default route: Anti-DoS TCP protection: maximum number of TCP-SYN packets authorized per second. This option is used to limit the number of TCP-SYN packets received on the specified access from the public domain. Anti-DoS ICMP protection: maximum number of ICMP packets authorized per second. This option is used to limit the number of ICMP packets received on the specified access from the public domain. Checking the external connectivity: checks the connectivity state of the default route by sending regularly a ping request to external hosts. In case of failure, a specific alert is transmitted via the log management function. 41 / 58

3.4.3 Connectivity, VLAN, aggregation TEOZ supports: 10/100/1000 Ethernet interfaces (copper) 802.1q VLAN. Each VLAN is identified by an ID VLAN from 2 to 4095 Ethernet link aggregation (Bonding). This functionality is used to: o Increase the maximum link bandwidth (aggregation of several Ethernet interfaces) o Increase the redundancy for higher availability: if an aggregated physical interface is faulty, the other interface(s) handle the network traffic It is possible to aggregate different types of interfaces (Ethernet, VLAN, bonding). 3.4.4 Quality of Service (QoS) It is possible to set the actual input and output bandwidth in the configuration parameters of a default route and network interfaces. The configuration parameters are used by the QoS functionality. This functionality is used to define the rules that: Display a stream in the Bandwidth window of the TEOZ-Monitoring tool Limit and display a stream bandwidth Reserve and display a stream bandwidth These rules include the following criteria: Source IP addresses Destination IP addresses Services Time ranges Access (QoS filters, either the default route and/or interfaces) Connection direction The QoS rules are defined by the TEOZ-Manager tool. 3.4.5 DHCP DHCP server DHCP (Dynamic Host Configuration Protocol) is used to dynamically assign IP addresses to clients over the LAN network. 42 / 58

A DHCP server hosts a dynamic or manual list of IP addresses assigned by the administrator or automatically assigned to the clients that connect to the LAN. Detailed information about DHCP is available in the RFC 2131. TEOZ implements the IPv4 version of the DHCP Server. DHCP relay A DHCP relay is a proxy that relays DHCP messages between a DHCP client and a DHCP server in different networks. The DHCP relay listens for DHCP and BOOTP requests and responses. When a request is received from a client, it is transmitted to the destination DHCP server(s). When a response is received from a server, the response is transmitted back to the client who has sent the initial request. DHCP relaying When many DHCP relays exist between clients and DHCP servers in a network, DHCP relaying can be useful: each DHCP relay adds its own data (Agent Information Option) to each DHCP request before transmission to the server. 3.4.6 Date and time It is possible to set one or many external time servers interrogated via the NTP protocol. The TEOZ system clock will be regularly updated by interrogating the servers. 3.5 High availability (clustering) 3.5.1 Principle The purpose of high availability (called Cluster function) for a network architecture is to reduce the periods of service unavailability. Unavailability can come from diverse internal or external origins: physical incident (fire, flood ), hardware failure, network service failure, software failure, etc. The TEOZ high availability solution is based on the implementation of N appliances connected in parallel architectures. The N appliances ensure minimum unavailability of TEOZ in case of complete hardware failure, interface failure, and failure of a network element associated with one appliance (hub, router, switch ). (Note: in version V1.0, N=2) Two Cluster configuration modes are available: Active/Passive (HA) Active/Active (HP) The Cluster function is based on the following concepts: State Protocol: Protocol that determines the appliance state (Active, Passive, Out of Order ). This protocol can be sent through different media (serial port, Ethernet ). The VRRP (Virtual Router Redundancy Protocol) protocol is used to perform this function. Data Synchronization Protocol: Protocol that transfers the data and states of application-layer modules, IDPS between the different cluster nodes/appliances (proprietary protocol). 43 / 58

3.5.2 VRRP (state protocol) In a given network, all nodes share one or many VRIDs (Virtual Router Identifier). A VRID is an integer ranging from 1 to 255. Each VRID represents a virtual router with one virtual IP address and one virtual MAC address (00:00:5E:00:01:VRID). In this network, for one given VRID, the Master router has a priority of 255, other routers have a priority between 1 and 254. A TEOZ node can be the Master Router for a given VRID, and Backup Router for another VRID. For the synchronization protocol, it is important to know which node is the master for a given VRID. The VRRP operation varies according to the 2 available operating modes. VRRP in Active/Passive mode In Active/Passive mode, TEOZ uses the VRRP protocol with only one VRID by interface: one of the 2 nodes is the Master for the VRID, the other node is the Backup. The VRRP protocol elects a Master or Backup node for each VRID. In our situation, the same state applies to all VRIDs. Therefore, the VRRP state of the VRID associated with an interface is the same for all VRIDs used on one appliance. We then have the appliance state instead of the VRID state. If the VRRP state of one VRID is Backup, all VRRP VRIDs will become Backup. Figure 13: VRRP in Active/Passive mode VRRP in Active/Active mode In Active/Active mode, the appliance uses 2 VRIDs by interface (for a 2-node cluster). For the 1 st VRID, one appliance is the Master, and for the other VRID, the other appliance is also the Master. 44 / 58

Figure 14: VRRP in Active/Active mode 3.5.3 Active/Passive mode In Active/Passive mode, one appliance is the Master and the other is the Backup. The master propagates its configuration and active connections to the Backup. In case of Master failure, the Backup is elected Active, and supports the traffic. 45 / 58

Figure 15: Active/Passive mode 46 / 58

3.5.4 Active/active mode In Active/Active mode, both appliances are set to be Active, and share the traffic distributed by a Load Balancing device. Each appliance receives about 50% of network traffic. In case of appliance failure, the other appliance supports 100% of network traffic. Figure 16: Active/Passive mode 47 / 58

3.5.5 Cluster supervision The TEOZ state in Cluster mode is displayed in the Cluster window of the TEOZ-Monitoring tool. The window provides the following information: Cluster mode (Active/Passive or Active/Active) List of cluster nodes For each node, the following information: o State: active or passive; o System state (sysmon) Interfaces configured For each interface, the following information: o Static IP address; o Initial virtual IP address o Current virtual IP address(es) At any time the operator can set one or many nodes in Failure mode. 3.6 High Availability (OXE spatial redundancy) In addition to the VRRP cluster mode (see previous section), TEOZ can be totally transparent to the geographical redundancy of Alcatel-Lucent OXE servers. The redundancy is ensured by an inter-oxe Alcatel-Lucent proprietary protocol, which replicates the telephone stable states (record, ring, call...). When a passive OXE server cannot see the active OXE server any longer, it connects to all connected telephones (UADL level only) because telephones have been authenticated during the primary provisioning. In this mode: TEOZ does not add any traffic over the WAN and does not change the sequences TEOZ does not change the OXE and network configurations (complete transparency) The next figure illustrates the system implementation (presence or absence of SSMs does not change the operating principle): Figure 17: OXE spatial redundancy 48 / 58

3.7 Hardware technology To meet the requirements and specificities of real-time critical streams, TEOZ uses advanced processor technologies, different from the PC technologies currently used in general-purpose security devices. The architectures of TEOZ processors allow the packets to be quickly processed, and there is little bias introduced by the packet sizes on the effective output. For general-purpose processors, the effective performance is greatly impacted by the introduction of small packets into the streams. The processors used by TEOZ, significantly attenuate this phenomenon, which is useful in ToIP. 3.8 Licenses To use the TEOZ security functionalities a valid license must be installed. The installation steps are the following: Generating a license request. The license request includes the TEOZ hardware imprint. These data generate a single identifier called Hardware ID (HWID). The license request is formalized by a text file transmitted by e-mail to the Thales support center. Checking the generation of a valid license file, which includes the license dead line. Sending the license file to the HTTPS server, where it is available for the Thales customer. Installing the license in TEOZ and activating the security functions (by a technician) The license and its validity over time are checked only at the TEOZ system start-up. If the license is valid, the TEOZ security functions are activated and can be used. Otherwise, only the administration connections using the TEOZ-Manager tool, TEOZ-Monitoring tool, and SSH are enabled. The license is also used to: Accept or deny IDPS updates Upgrade from TEOZ 2000 to TEOZ 3500 Enable or disable the SEM function 3.9 PEM module administration Note: to suit the users operational needs, the SEM module is managed by a different tool, separated from the tool used for the PEM module, but using the same graphical interface. TEOZ administration is performed using local or remote graphical tools (TEOZ-Manager and TEOZ- Monitoring). These tools are installed on a dedicated administration console. The tools are available for the following operating systems: Windows (2000 and XP) Linux (RedHat and Debian) 49 / 58

Tools are delivered as installer: for Windows, the installer is delivered as an executable file; for Linux the installer is delivered as a compressed archive including the installation script. Two connection modes to the appliances are currently available: Stand-alone mode: the user is directly connected to the platform. Master-slave mode: the user is connected to a master platform that centralizes the administration of other active platforms. 3.9.1 Secured access The remote TEOZ administration tasks can be performed from an external or internal network. Two securing techniques are used: Multiple and mutual authentication: the identity of the administration terminal is filtered from its IP address and access interface to the equipment. The administrator s identity is validated by a password-protected digital certificate (X509). In the other direction, the administration terminal also uses a certificate to check the identity of the TEOZ to which it will be connected. SSLv3 and SSHv2 ciphered communications between the equipment and the administration console. 3.9.2 Configuration tool General This tool is used to entirely set TEOZ, whatever the selected administration architecture (stand-alone or master-slave): Configuration of protocol modules Configuration of Active/Passive mode Configuration of IDPS etc. The tool generates stand-alone configuration files or configuration files shared by several devices for centralized architectures. These files can be saved and archived (with encryption) on the administration terminal, and used to change the configuration off-line. The changes will be downloaded afterwards to the equipment. Filtering rules A specific menu is used to create, change, enable, disable and displace the filtering rules. These rules can be fine-tuned to the application-layer to be protected. The currently available filtering rules are the following: Source IP address (network, group of network objects, host) Source TCP port Destination IP address (network, group of network objects, host) Service (transport protocol, port or set of ports) Protocol rules 50 / 58

Actions on the rules According to the security rules, the connections can be: Accepted Blocked Denied Besides, connection logs can be set: No log Log + first connection packet only Log without packet 3.9.3 Supervision Monitoring tool The monitoring tool is used to: Supervise the logs (alerts, IP and IDPS) and active connections to or from the monitored TEOZ Retrieve general information about TEOZ: current version, CPU load, hard disk partitions, memory use and system time Display the available updates: system partition and IDPS database signatures Retrieve diagnostics: states of services performed on the system, state of network interfaces System monitoring The system monitoring tools are used to supervise the states of the different system elements. Changing the element states generates alerts displayed in the Alerts window of the TEOZ-Monitoring tool. Moreover, this function can be used with a High Availability TEOZ to switch to another TEOZ when the active TEOZ is faulty. Two types of elements are monitored: Interfaces Public access(es) (default route) The states of interfaces and public accesses are checked by sending ping frames to one or many hosts configured in the monitoring system. 3.9.4 Logs The logs that can be monitored using the TEOZ-Monitoring tool are: General alerts 51 / 58

IP logs about filtering policy IDPS about the detections of the IDPS intrusion detection engine (see net section) Logs are stored in a local SQL database using the MySQL embedded SGBD. The logs of slave TEOZs can be exported to the log database of the Master TEOZ where they can be read. So as not to overload the storage peripheral (hard disk) with log files, the embedded system includes an automatic purge mechanism. Logs can be transmitted to the output devices via: Syslog protocol to an external server E-mail to an address set in the TEOZ configuration SNMP traps to an external SNMP supervisor In addition to the supervision functionalities, a SNMP agent is included in the embedded system and can be programmed using the configuration tool. It is used to retrieve via the SNMP protocol the data supplied by UCD-DAVIS and MIB-II MIBs, available on the supervised TEOZ. 3.9.5 Master/slave supervision architectures The Master/Slave mode provides a central point (the Master TEOZ) to deploy configurations and receive logs from other TEOZs (Slaves). One single instance of the Administration/Supervision tool executed on the administration console is used to manage and deploy the TEOZs configuration (Master and Slaves) and supervise all logs. The connections between the Master TEOZ and Slave TEOZs are performed using the SSL protocol. The different Slave TEOZs are authenticated to the Master TEOZ via X509 certificates generated by the Certification authorities (generally hosted on the Master TEOZ) and deployed on each of them during installation. These connections enable: Deployment of configurations from the Master TEOZ to each Slave TEOZ Escalation of the logs of each Slave TEOZ to the Master TEOZ Administration console Figure 18: Master-slave architecture Master Slave Slave 52 / 58

3.10 SEM module administration The SEM module is administrated from a distinct application, but using a graphical interface in coherence with the PEM graphical interface. This is used to delegate server protection and control to different and independent managers. The SEM module administration tool is used to: Manage users Configure, save, and restore analysis rules Manage call statistics o Processed calls, whether authorized, denied or banned o Current calls Manage e-mail alerts Manage SEM module performance Monitor SEM module activity Simulate calls to check a rule behavior 3.11 Updates The update feature is activated after subscription to the support and maintenance contract. 3.11.1 Updating the software Online update The connections with the update servers are protected by the SSL protocol and are authenticated by the TEOZ certificate and the X509 certificate of the Support servers, retrieved from the license file. This functionality is used to update online the TEOZ software from the Thales https servers. The TEOZ-Monitoring tool displays the availability of the new TEOZ versions and their verification/installation. Offline update If TEOZ does not have a direct access to the Thales https site used for online updates, the offline procedure can be implemented: o The update file is obtained from the Thales https server. The connection is authenticated by the support certificate in the license file o The file is transferred to the TEOZ hard disk via the SSH/SCP protocol o The update-version command updates the software from the file 3.11.2 Updating IDPS This functionality is used to update signatures offline. The file of the last IDPS update must be downloaded from a Thales https site, transferred to the TEOZ, its signature must be checked, and installed for activation. 53 / 58

3.12 Synthesis The flow chart of PEM and SEM security services is illustrated in the next figure: IP application-layer Sécurité applicative security (PEM) IP (PEM) Telephone Sécurité applicative applicationlayer téléphonique security (SEM) (SEM) Pare Firewall - feu Analyse Application applicative analysis IDS Politique Voice security Sécurité policy Voix Stateful Filtrage IP IP filtering à état, - stateful Stateful inspection Prévention Intrusion prevention d intrusion Temps Real-time réel Paramètres Call parameters d appels Réception 1 st packet du 1er reception paquet Réception N tt packet du N ème reception paquet Message Défragmentation defragmentation et réassemblage and reassembly du message Récuparation Retrieval of du connection contexte de la context connexion Retrieval Extraction of call des paramètres parameters d appel Confrontation Comparison aux with règles stream de flux rules Confrontation Comparison aux with règles stream de flux rules Application-layer Décodage applicatif decoding Comparison Confrontation with aux contextual signatures signatures contextuelles Confrontation Comparison with aux règles SEM SEM rules Connection Création setup de la connexion Contrôle Compliance de conformité and et protocol usage du usage protocole check Pondération Weighting Actions in case of noncompliance Actions with sur non usage conformité policy de l usage Individual packet Analyse analysis individuelle du paquet Individual packet Analyse analysis individuelle du paquet Confrontation Comparison with aux protocol règles protocolaires rules Figure 19: Master-slave architecture With the association of PEM and SEM functionalities, TEOZ provides a unique security solution for ToIP services, 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 conservation of 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 come to provide users with a true security solution. 3.13 TEOZ 2000 and TEOZ 3500 3.13.1 Hardware characteristics Interfaces: o 10/100/1000 Ethernet: 2 o 10/100/1000 4-port Ethernet switch: 1 o 10/100/1000 management port: 1 54 / 58

o RS232C serial port (RJ45): 1 o USB 2.0 port: 1 o LCD screen: 2 lines of 16 characters TEOZ is provided with a physical connection indicator on each Ethernet interface to indicate the link state (LINK indicator light). Other connections: o ON/OFF switch at the back side o Reset button at the front side (to restart the appliance) o 16-character LCD screen Data storage: o Hard disk: >160 GB SATA o Compact Flash card: >1 GB Dimensions o Format: 1U, 19 o Width * Depth * height (mm): 428 * 255 * 44 o Weight: 3 kg Operating conditions: o Temperature: 5 C 40 C o Humidity: 20% 90% Storage conditions: o Temperature: 0 C 70 C o Humidity: 5% 95% Transportation conditions: o Temperature: 0 C 70 C o Humidity: 5% 95% Power supply o Integrated mains power supply: 100-240 V AC at 50/60 Hz o Maximum electrical consumption: 65 W MTBF > 40 000 hours 3.13.2 Security-safety ROHS & WEEE: TEOZ complies with ROHS and WEEE EMC (ElectroMagnetic Compatibility) o CE 55 / 58

o FCC part 15 o UL Electrical safety: TEOZ is provided with a CB test certificate 3.13.3 TEOZ 2000 performance 3.13.4 TEOZ 3500 performance 3.14 Alcatel-Lucent inter-operability TEOZ is part of a technical, non-exclusive partnership between Thales and Alcatel-Lucent. In this context, TEOZ has been qualified as interoperable with the Alcatel-Lucent ToIP system, including: OXE (including geographical redundancy) 4059 operator console MyTeamWork OTUC 4760 console Recorders CTI The document Alliance & Application Partner Program, Inter-Working Report, TEOZ describes all interoperability scenarios. The next figure illustrates the general architecture supported: 56 / 58

Figure 20: TEOZ within the Alcatel-Lucent solution 57 / 58

4. Contact Information Thales Communications 160, Boulevard de Valmy BP 82 92704 Colombes Cedex France Phone : +33 (0)1 46 13 22 29 Fax : +33 (0)1 46 13 22 97 Email : Security@fr.thalesgroup.com 58 / 58