EP1803279A1 - Dispositif de securisation d un autocommutateur - Google Patents

Dispositif de securisation d un autocommutateur

Info

Publication number
EP1803279A1
EP1803279A1 EP05812485A EP05812485A EP1803279A1 EP 1803279 A1 EP1803279 A1 EP 1803279A1 EP 05812485 A EP05812485 A EP 05812485A EP 05812485 A EP05812485 A EP 05812485A EP 1803279 A1 EP1803279 A1 EP 1803279A1
Authority
EP
European Patent Office
Prior art keywords
server
communication
switch
analyzer
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05812485A
Other languages
German (de)
English (en)
Inventor
Gérard KAAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CheckPhone Technologies
Original Assignee
Checkphone
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Checkphone filed Critical Checkphone
Publication of EP1803279A1 publication Critical patent/EP1803279A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/47—Fraud detection or prevention means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/38—Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0148—Fraud detection or prevention means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/20—Automatic or semi-automatic exchanges with means for interrupting existing connections; with means for breaking-in on conversations
    • H04M3/205—Eavesdropping prevention - indication of insecurity of line or network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2218—Call detail recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/126—Interworking of session control protocols

Definitions

  • the present invention relates to the field of telecommunications and network security.
  • the present invention more particularly relates to a system and method for securing an enterprise switch by call control.
  • the corporate PBX is the gateway to a company network.
  • security must be strongly present, particularly since the convergence of circuit-mode network management and packet mode networks. Too many abuses are currently taking place on branch exchanges where communications are diverted by outsiders to make calls at lower cost.
  • the invention consists in controlling and realizing access between terminals of an enterprise to a plurality of sites and their respective circuits in the public switched network.
  • the system and method may include: a discrete line sensor within the sites to determine the nature of the calls, the line sensor not interfering with existing communications.
  • the line sensor may include: a pair of relays for routing the data through the line sensor without altering the data, a pair of transceivers and a processing unit for routing the data through the line sensor by storing and copying the data and transmitting the new data through the sensor line.
  • the system may also include: a PBX in the sites and connected to the line sensor; a central switch connected to the line sensor and the PBX; and a firewall management server.
  • a PBX in the sites and connected to the line sensor
  • a central switch connected to the line sensor and the PBX
  • a firewall management server The entirety of known systems for securing enterprise telecommunications networks and more particularly private branch exchanges reproduces an architecture similar to that described in FIG. 1. Namely, an analyzer (sensor 13) is placed on the trunk. (11) between the switched network (10) and the private branch exchange (14). This sensor analyzes the nature of the calls sent to / from the peripherals (16) of the private network (15), then confronts the information obtained with security rules contained in a server (17).
  • the communication analyzers deliver the following information:
  • the communication analyzer does not deliver all the functionalities that have been implemented nor their chaining.
  • the following two examples show the limitations of such a system in detecting "fraudulent" actions.
  • a call from an outside call A to a workstation of the company B can listen to the conversation with a caller C by activating the "unobtrusive entry" feature. Again the communication analyzer will detect only two separate and authorized communications.
  • VoIP voice-over-IP
  • the present invention intends to remedy at least one drawback of the prior art by proposing a system and a method for securing a switch, either in switched or mixed "switched-IP” mode, on the basis of an analysis of the "low” (call nature) and “high” layers (PBX features used) implemented during calls.
  • the method performs, on the one hand, an analysis of the incoming or outgoing calls to determine their nature, and on the other hand, receives information emitted by the switch, information indicating, among other things, the functionalities implemented during the operation. 'call.
  • a comparison is made with a set of network security rules (or scenarios), the method then making it possible to respond to the call or to terminate it.
  • the system of the invention has a communication analyzer somewhat similar in functional terms to those described in the aforementioned patents, and associated with a server as well as a second server analyzing the information transmitted by the switch. on current calls.
  • the system also proposes a server called "audit" to establish security rules according to the specificities of the network and the switch.
  • the invention respond particularly well to the expectations of companies whose private networks are too many times hacked by the use of one of the 400 or more functions of the switch (for example, the call in conference or conference call).
  • the invention relates in its most general sense to a firewall system for securing an enterprise branch exchange connected, on the one hand, to at least one switched mode communication network, of the PSTN type, and, on the other hand, to a set of communication and / or application server peripherals, said system comprising a low layer communication (1 to 3) of the OSI model of circuit and analog digital communications.
  • a firewall server connected to said analyzer characterized in that: said system further comprises a supervision server connected to the "water line" output of the switch for the analysis of the communication tickets and the application of safety rules for the OSI model layers (4 to 7).
  • said switch is further connected to a packet mode communication network of the Internet type; said communication analyzer is placed in parallel lines between the switch and the switched networks and in packet mode; said communication analyzer further analyzes the information of the lower layers of the packet mode communications (incoming and outgoing) of the switch.
  • said analyzer is a DSP for detecting digital circuit, digital packet and analog communications.
  • said supervision server comprises an expert system for learning security rules in the case of an unknown scenario.
  • said supervision server comprises a database for storing the information sent by said communication analyzer and information relating to the analysis of said tickets.
  • said system further comprises an audit server connected to the supervision server able to analyze the functionalities of the switch, the system architecture and to establish a set of call scenarios.
  • said audit server comprises an expert system for establishing said scenarios.
  • said firewall server is connected to a plurality of communications analyzers located on various enterprise sites.
  • said system further comprises an encrypted backup server of the configurations of the automatic switch.
  • said system further comprises a call-back modem connected to the remote maintenance port of said automatic switch.
  • the invention also relates to a method for securing an enterprise switch connected, on the one hand, to at least one switched mode communication network, of the PSTN type, and, on the other hand, to a set of peripherals communications and / or application servers, the method comprising a step of analyzing low layers (layers OSI 1 to 3) communications by a communication analyzer and application of security rules to terminate illegal calls, characterized in that it further comprises: - a recovery step by a communication ticket supervision server issued by the switch, a step of confronting the information contained in said tickets with the security rules containing in the supervision server, a step of applying the security rules according to the information contained therein in said tickets.
  • a step of analyzing low layers (layers OSI 1 to 3) communications by a communication analyzer and application of security rules to terminate illegal calls characterized in that it further comprises: - a recovery step by a communication ticket supervision server issued by the switch, a step of confronting the information contained in said tickets with the security rules containing in the supervision server, a step of
  • said method further comprises a step of reporting call information and decisions taken from said communication analyzer to said supervisory server.
  • said method further comprises a step of self-learning by an expert system in the supervision server scenarios not managed by the security rules.
  • said method comprises, beforehand, a step of determining the possible scenarios by an audit server and a step of establishing the security rules by selecting said scenarios.
  • said scenario determination step comprises:
  • the invention also relates to a computer program element comprising computer program code means arranged to perform the steps of the method.
  • FIG. 1 represents the standard architecture of the systems securing PBX on a switched telephone network (prior art);
  • Figure 2 illustrates the architecture of the present invention;
  • Figure 3 illustrates the functional structure of the communication analyzer;
  • Fig. 4 is a logic diagram showing the operation of the communication analyzer;
  • Fig. 5 is a logic diagram illustrating the establishment of the security rules according to the present invention;
  • FIG. 6 illustrates the different initial data tables retrieved by the expert analysis system;
  • FIG. 7 illustrates an example of a matrix of correspondences between the threats and the vulnerabilities of a system of the automatic switch type;
  • FIG. 1 represents the standard architecture of the systems securing PBX on a switched telephone network (prior art);
  • Figure 3 illustrates the functional structure of the communication analyzer;
  • Fig. 4 is a logic diagram showing the operation of the communication analyzer;
  • Fig. 5 is a logic diagram illustrating the establishment of the security rules according to the present invention;
  • FIG. 6 illustrates the different initial data tables
  • FIG. 8 illustrates an example matrix of correspondences between the threats and the functionalities provided by a switch
  • Fig. 9 logically illustrates the audit and countermeasure module according to the present invention
  • Figure 10 schematically shows the inference engine for system auditing
  • FIG. 11 schematically represents the module for establishing countermeasures
  • FIG. 12 represents a logic diagram of the operation of the security according to the invention
  • Figure 13 illustrates an example of packet mode communication.
  • FIG. 2 represents an exemplary embodiment of the system according to the present invention, comprising a switch (200), a communication analyzer (100) and a set of servers (110, 120 and 130) for management. security policy.
  • the enterprise-class switch (200) is a switch for real-time call processing and switching between private corporate (210) devices and the switched telephone network (300) and / or a network in the real-time mode. packets, for example the Internet (310).
  • the switch (200) provides, in addition, features (sometimes more than four hundred) that can be implemented during calls: for example, the double call, the call forwarding, the conference, ... It presents two dedicated ports, on the one hand, to remote maintenance (198) and, on the other hand, the sending (199) of "tickets" used, among others, billing calls.
  • the latter port (199) also called “over of water "is a serial port of data transmission, tickets.
  • the essential functions of a switch are: switching, interfaces with terminals, telephone application.
  • the switch (200) can be PBX (Private Branch eXchange) or PABX (Private Automatic Branch eXchange) dedicated only to a switched network, in which case the analysis of packet communications is not performed, or "mixed For example a centralized IP PBX in which all the functions are implemented except the switching performed by a network switch.
  • PBX Primary Branch eXchange
  • PABX Primary Automatic Branch eXchange
  • the corporate network may be of the LAN (Local Network Area) type and is composed of the PABX (200), the peripherals (210) and the inner lines (220) connecting the peripherals to the PABX.
  • LAN Local Network Area
  • the peripherals are of the fax type (203), modem (202), telephone (204), IP telephone (205), cordless phone (206), for example DECT, application servers (208) for example voice mail server , billing server,
  • the “telephony” servers (208) and (209) are furthermore connected to the PABX via an isolated IP network (230) dedicated solely to exchanging data between these various entities: controlling the PABX from the server. administration, for example.
  • a communication analyzer (100) is placed in parallel with the lines networks (320) between the public switched / packet network (300, 310) and the PABX (200).
  • a firewall server (110) is connected to the communication analyzer (100) and possibly to other analyzers (100 ', 100' ').
  • the firewall server (HO) contains all the rules or scenarios to be applied on the network and transmits them to the communication analyzers. A more detailed description of such a server may be provided by one of US 6,687,353, US 6,226,372, US 6,760,421 and US 2004/0168686 mentioned above.
  • the server 110 consolidates in real time all the information of all the communication analyzers of the various sites and manages the alerts related to possible malfunctions of these analyzers.
  • a supervisory server (120) is connected to the PABX's "run-of-the-river" port (199), the firewall server (110), and a third audit server (130). This server (120) provides management of communication analyzers (100) and the management of security rules.
  • the servers 110 and 120 must be physically different for reasons of real-time processing and operational safety.
  • the audit server (130) hosts an expert system for establishing the security rules or scenarios, which it sends to the supervisory server (120) for application thereof.
  • These different servers are, for example, dedicated computers, comprising a processor, RAM type RAM, an operating system, software for implementing the method of the invention, software executed on this operating system, and network connection means.
  • the system also includes a backup device (112) and a call-back modem (114).
  • the device (112) makes it possible to perform a backup, preferably encrypted by dynamic key, of the configurations of the automatic switch.
  • the modem (114) provides protection for access to the remote maintenance port (198) by implementing call detection, identification and callback mechanisms depending on the identification. obtained.
  • the communication analyzer (100) is implemented as DSP (Digital Signal Processing) with a suitable software. This allows, among other things, to easily coexist a circuit mode network analyzer (ISDN) and a packet network analyzer (IP).
  • ISDN circuit mode network analyzer
  • IP packet network analyzer
  • the prior art knows these analyzers dedicated to switched networks.
  • the analysis of the IP network is done by a filter retrieving the header of the transmitted packets.
  • the communication analysis method is provided by FIG.
  • the analyzer (100) receives digital calls in circuit mode (a), packet mode (b) and analog calls (c).
  • a first module (106) identifies the type of call (voice, data, ...) • This module is based on the recovery of the headers of transmitted packets, on the signaling of the D channel of digital communications switched (ISDN TO and T2) or the carrier value for analogue links.
  • the so-called acknowledged rules are the rules coming only from the server of audit (130) which is in charge of the consistency check of the set of rules.
  • the default behavior allows calls that are not explicitly prohibited, and when one of the rules coincides with the current call, the rule applies.
  • the set of rules that only involve the information collected by the communications analyzer (100) is resident therein for the site concerned; this is to ensure real-time processing (fast enough for the connection time of communications). These rules are stored either in Flash memory or on hard disk, depending on the number of links to be observed.
  • the security rules are sent by the supervision server (120) via the server (110).
  • An example of a communication analyzer (100) is one of the products of the "Wavetel" range.
  • the firewall server (110) is the guarantor of the 1-2-3 layer rules and periodically checks the integrity of the data of the communication analyzers to prevent any malicious changes to them.
  • a micro-relay cut is performed. The analysis is looped until the call has ended. Once this call is complete, the call information is sent back (6) to the firewall server (110) and sent through a "communications pipe" to the supervisory server (120) in real time.
  • Example 1 Analysis of the H.323 protocol
  • FIG. 13 illustrates, on the one hand, the layers on which the H.323 protocol is based and, on the other hand, the format of the Real-time Transfer Protocol (RTP) header used for voice over IP on the protocol.
  • RTP Real-time Transfer Protocol
  • the communication analyzer analyzes the RTP header contained in the UDP or TCP frame to determine the nature of the communication by taking into account in this header, the value "Payload Type". In the example provided, it is a G711 communication still called PCMA.
  • the auditing server (130) makes it possible to set up the scenarios for securing the network, scenarios that will be chosen by a human operator for setting the security rules.
  • a first step is performed before operating the system. It aims to determine the functional characteristics of the PABX (200) that change from one manufacturer to another (1010) and the specificities of the network architecture in place (1020). The operations described below are reproduced after an update of the PBX or after a modification of the network architecture (adding peripherals for example), which is why it is preferable for the audit server (130) not to does not share the same resources as the supervisory server (120).
  • the server (130) is connected to the maintenance port V24 (198) of the PABX to obtain the circuit architecture files (1020) contained in the PABX as well as to the IP network (230) to obtain the system architecture information (1010).
  • NESSUS-type application allows to get through the IP network (230) all the IP information of the network: VLANs, IP addresses, number of application servers, etc.
  • the circuit architecture files mention the configurations of internal links (directory of telephone numbers) and external links (TO, T2, voice IP for voice).
  • FIG. 6 represents an example of the configuration databases (1000) obtained by the audit server (130) after analysis of the system (1010) and circuits (1020).
  • the system database informs: - the elements present (PBX, voicemail, billing server);
  • the PABX features database provides: - phone numbers; - associated profiles or classes;
  • a step is performed to define the attributes and the corresponding values implemented by the PABX (200) (depending on the manufacturer), for example: associated_services_values: mevo (voicemail), Svi, Acd, charging ...;
  • Values_functionalities operator, intercom, multi Cco, multi-company, Disa, conference, recording, third-party entry, transfer, forwarding, listening, grouping, Sda ...;
  • Restriction_values time, geographic, range numbers, priority access, logical locking ...
  • the rules database (1110) contains, for its part, all the security rules applied by the system. This database is usually empty when the system is installed and is enriched at the end of this system audit phase.
  • the rules are in the form:
  • This example illustrates the risk of being wiretapped using the weaknesses of the system in automatically calling an outside number after the message is placed in voicemail.
  • This example illustrates the diversion of communication traffic using the external reference of a communication made possible by obtaining the password constructor ...
  • the EBIOS method makes it possible to establish, independently of the architecture of the corporate network, a matrix characterizing the dependencies between threats and vulnerabilities of the PABX (200), and a matrix characterizing the dependencies between the threats and the functionalities offered by the PABX.
  • FIG. 7 shows an example of a "threats / vulnerabilities" matrix where the threats are of the industrial espionage or hijacking type, and the vulnerabilities may be the ability to directly access a station or the ability to delete or modify programs.
  • FIG. 8 represents an example of a "threats / functionalities" matrix where the functionalities provided by the PABX (200) can be common abbreviated dialing, forwarding or grouping.
  • These matrices can be filled manually, that is, dependencies are established based on hardware knowledge and network security.
  • This expert system is contained in the server (130).
  • Forward and backward chaining is performed between the threats and the system vulnerabilities (according to the previously defined matrix) by the SCN1 module (1120).
  • Forward and backward chaining is understood to mean analyzing each of the threats (symmetric role of the vulnerabilities) in order to associate the dependent vulnerabilities with them and to complete this analysis by checking the determined vulnerabilities of the threat original.
  • a sequential analysis of access vulnerabilities, creation / modification / deletion vulnerabilities, and recovery vulnerabilities helps identify potential risks to the system from this threat. These risks are stored in a database.
  • a ranking of the risks makes it possible to determine the cases to be authorized, those to prohibit and finally those to authorize with restriction (time slot, geographical, ...): these are the scenarios.
  • the risks are classified according to two criteria.
  • a human intervention makes it possible to choose the countermeasures defining the security policy of the PABX (200): examples concerning the architectural vulnerabilities: to suppress the inactive links, to modify the numbers of remote maintenance if they meet the standards constructors, to reorganize the directory ... considering the proposals made by the expert system; examples concerning the functionalities provided by the PABX: the countermeasures relating to the risk scenarios are in the form of choices, since there can be no question of deleting all the open functionalities, by definition of the role of the PABX.
  • rules databases (1110), vulnerabilities (1100) and countermeasures (1210) are updated when new scenarios are created.
  • Example 3 Traffic diversion
  • a hijacking can come from the combination of the following vulnerabilities:
  • Vulnerability of access concerns the value_telemention (manufacturer's password, SDA number, no restriction)
  • Vulnerability of "cms” relates to the value_features (external referral, no restrictions)
  • the risk rule then established becomes: If value_telemaintenance (manufacturer password, number sda, no restriction) and value_functions (external reference) and value_architecture (external links, no restriction) then risk (diversion of traffic)
  • This scenario can occur frequently because the external hacker can, through a "war-dialer" (program that allows from a series of telephone numbers to massively launch calls to identify a modem or fax carriers and allow entry into a computer or telecom system), identify the remote maintenance modem, use the Internet to find the manufacturer's passwords, access and activate the forwarding feature or divert the traffic to his account.
  • a "war-dialer” program that allows from a series of telephone numbers to massively launch calls to identify a modem or fax carriers and allow entry into a computer or telecom system
  • identify the remote maintenance modem use the Internet to find the manufacturer's passwords, access and activate the forwarding feature or divert the traffic to his account.
  • the rules engine uses the correspondence matrices mentioned earlier to: - identify all the access vulnerabilities
  • associated_services_values voicemail, standard password, nda
  • Cms function_values (automatic callback after message delivery, external number),
  • Associated_services_values voicemail, standard password, sda
  • Operator_values automated callback after message delivery, external number
  • value_architecture external links, no restriction
  • the established rules are sorted according to their area of application: those concerning the "low layers” of communication (OSI layer 1-3) are transmitted to the database of the firewall server (110) via the supervision server (120), those concerning the "high layers” (OSI applications
  • PABX they are therefore directly set in the PABX database, automatically and / or manually.
  • the other rules are compared on the supervision server
  • Each call generates a communication ticket with 128 bytes. These tickets are generally used for billing calls.
  • the ticket provides, inter alia, the following information:
  • a consistency check between the information contained in the ticket and the PABX database is carried out: an alert is raised in case of inconsistency, and the call can be terminated. This is, for example, the case when during a manual reconfiguration of the PABX, all the new parameters edited by the audit module were not introduced into the PABX (no updating of the directory, forgetting to forbid a feature for a position, etc.). This control makes it possible to limit the calls to the possibilities provided and authorized (the parameters) by the PABX.
  • the data resulting from this analysis is sent together with the information of the communication tickets to the supervision server (120).
  • the information about the current call is combined with the alerts sent from the firewall server (110) for OSI layer analysis (BDD firewall alerts) and compared to the security rules of the supervisory server (120). Further analysis can be performed; it confronts the data of the current call with a history of the last calls (Tempo File Attacks) to establish if there is an attack or a violation of the security policy (according to models of typical attacks).
  • This history can be in the form of a file informing the last hundred calls processed by the PABX and their characteristics (called extension, ringing less than 4 shots, no answer, outside calling station, ).
  • extension ringing less than 4 shots, no answer, outside calling station, .
  • the purpose of this historization is to be able to determine repeated attacks.
  • the real-time monitoring of the company's communication system is based on traffic ticket analysis, monitoring and monitoring of features implemented by a call and presenting vulnerabilities, monitoring and alerting in the case where a risk scenario is occurring, the self-learning of the scenarios not envisaged and which occur and finally the watch in detection of attacks by the reconciliation of information, for example: o Number of calls lower at 4 and hung up compared to the average. Analysis of the standard deviation with triggering threshold, o Number of calls as above and analysis if the phenomenon takes place in a sequential or random manner, with indication of the times between each call of this nature and triggering threshold, o Number of calls answered through voicemail and detected as modem calls.
  • a weighting algorithm based on this information, will establish the presence or absence of an attack and will implement the alert and action procedure previously established.
  • the decision may be made to cut off all outside links if the event occurs. happens during a period during which the business is closed (at night).
  • the internal telephone number concerned may be inactivated.
  • the PBX is reconfigured taking this risk into account.
  • an expert system similar to the one described above, allows the self-learning of the system.
  • a new risk is determined, scenarios possibly proposed and a human operator determines the scenarios corresponding to the security policy.
  • This learning is done by fuzzy chaining: we analyze the closest scenarios. For example, a scenario with four out of five criteria identical to the current call is considered close.
  • the system also allows statistical feedback allowing among others to know the number of completed calls, the number of fraudulent access attempts, ...
  • the invention consists of a software running on a "Windows Server" operating system (business name) and the databases implemented are of SQL type and later on more sophisticated platforms such as Oracle (Business Name).
  • EXAMPLE OF A SCENARIO is an example of fraudulent call scenario processing, from its origin to the countermeasures applied by the system.
  • the logical communication port of the automatic switch is open and no VLAN configuration for the Ethernet network dedicated to the telephone servers,
  • the Firewall Data authorizes the port ftp 80 which made it possible to enter the PABX of which this port is also to remain open,
  • the attacker then creates a virtual station in the PABX with the open dialing function (this is a station where the interface has been activated without connecting a station physically and when it is requested dials the area code exit to the network and wait for the number to dial).
  • the hacker has assigned the function DISA (function that allows a position outside the company to be perceived as a position of the company).
  • cyclic grouping is a group of extensions that has a common generic internal number, which does not prevent these items from having an individual number, and who for each new call to this group directs it to the next free post belonging to the group).
  • the hacking community has been notified of the numbers to dial.
  • This community consists of 50 members, one of which has a voice server located in the Bahamas with a billing service ( € 1 per minute paid by the operator to an account in Switzerland).
  • the hacker activated a group forwarding to the Bahamas voice server during non-business hours.
  • the bill can be very salty for the company and the bleeding can not be stopped as easily because several actions have been conducted without a clear link.
  • Vlan Prohibit the absence of Vlan
  • Fictitious workstation limit the number of workstations that can be created and monitor the numbers authorized by the supervision software through the tickets and display them in the directory,
  • Timed out call prohibit, Forward: prohibit outside forwarding for all items belonging to a group on the group number
  • the "supervision” application will sort the rules and settings either to the firewall server (110) or to the PABX.
  • the configuration of the PABX will be done manually because the PABX does not have interface API or IAE in our example: the operation setting up of a Vlan will execute by acquittement of the direction IT and its realization will be checked and noted during the next automatic audit.
  • the firewall server no action planned because layers 1 to 3 of the OSI model managed by the communication analyzer are not requested in this example.
  • the current call scenario will be compared with all the scenarios of the database to find a possible new scenario close or original.
  • the call will be stored with its features in the waterwire database.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention se rapporte au domaine des télécommunications et de la sécurité des réseaux. La présente invention se rapporte à un système pare-feu de sécurisation d'un autocommutateur (200) d'entreprise connecté, d'une part, à au moins un réseau de communication en mode commuté, de type PSTN, et, d'autre part, à un ensemble de périphériques de communications et/ou de serveurs d'application (210), ledit système comprenant un analyseur de communication (100) des couches basses (1 à 3) du modèle OSI de communications numériques en mode circuit et analogiques, un serveur pare-feu (110) connecté audit analyseur (100), caractérisé en ce que ledit système comprend, en outre, un serveur de supervision (120) connecté à la sortie « fil de l'eau » (199) de l'autocommutateur (200) pour l'analyse des tickets de communication et l'application de règles sécuritaires portant sur les couches hautes applicatives (4 à 7) du modèle OSI.

Description

DISPOSITIF DE SÉCURISATION D7UN AUTOCOMMUTATEUR
La présente invention se rapporte au domaine des télécommunications et de la sécurité des réseaux.
La présente invention concerne plus particulièrement un système et un procédé pour sécuriser un autocommutateur d'entreprise par le contrôle des appels.
L'autocommutateur d'entreprise constitue la porte d'entrée dans un réseau d'une entreprise. De ce fait, la sécurité doit y être fortement présente notamment depuis la convergence de la gestion des réseaux en mode circuit et celle des réseaux en mode paquets. De trop nombreux abus ont lieu actuellement sur les autocommutateurs d'entreprise dans lesquels les communications sont détournées par des personnes extérieures pour téléphoner à moindre coût.
L'art antérieur connaît déjà, par le brevet américain US 6 687 353 (Securelogix) , un système et un procédé pour un système de sécurisation téléphonique. Illustré par la figure 1, l'invention consiste à contrôler et à réaliser l'accès entre des terminaux d'une entreprise à une pluralité de sites et leurs circuits respectifs dans le réseau public commuté. Le système et le procédé peuvent comprendre : un capteur de ligne discret à l'intérieur des sites pour déterminer la nature des appels, le capteur de ligne n'interférant pas avec les communications existantes. Le capteur de ligne peut comprendre : une paire de relais pour router les données à travers le capteur de ligne sans altérer les données, une paire d'émetteurs-récepteurs et une unité de traitement pour router les données à travers le capteur de ligne en stockant et copiant les données et en transmettant les nouvelles données à travers le capteur de ligne. Le système peut également comprendre : un autocommutateur PBX dans les sites et connectés au capteur de ligne ; un commutateur central connecté au capteur de ligne et au PBX ; et un serveur de gestion de pare-feu. L'intégralité des systèmes connus pour la sécurisation des réseaux de télécommunications d'entreprise et plus particulièrement des autocommutateurs privés, reproduit une architecture similaire à celle décrite dans la figure 1. A savoir, un analyseur (capteur 13) est placé sur la ligne réseau (11) entre le réseau commuté (10) et l'autocommutateur privé (14). Ce capteur analyse la nature des appels émis depuis/vers les périphériques (16) du réseau privé (15), puis confronte les informations obtenues a des règles sécuritaires contenues dans un serveur (17) .
Cela est notamment le cas dans le brevet américain US 6 226 372 (Securelogix) qui décrit un système et un procédé pour la mise en oeuvre d'un coupe-feu/scanneur de télécommunications coopérants, totalement intégrés, permettant la mise en oeuvre de fonctions de sécurité améliorées du coupe-feu et du scanneur de télécommunications, et la mise en place d'une structure de sécurité spécialisée demandée par l'entreprise, d'une visibilité événementielle et de la consolidation des rapports, dans une entreprise à répartition globale. Dans la configuration la plus basique, le coupe-feu/scanneur intégré présente des fonctions de contrôle d'accès protégé continu et de commande, des fonctions de contrôle et de commande de mots-clés et de contenu, et assure l'authentification d'accès éloigné, des évaluations de vulnérabilité coordonnées ainsi que des ajustements synchrones automatiques par rapport à la Politique de Sécurité, en réponse aux résultats de l'évaluation de vulnérabilité. De plus, les opérations, les résultats d'évaluation et les réponses du coupe-feu et du scanneur peuvent être consolidés dans des rapports détaillés ou synthétiques à utiliser par les administrateurs de la sécurité, pour l'analyse des tendances et la prise de décision en matière de sécurité. Cette solution propose une analyse des vulnérabilités des équipements afin d'adapter la politique de sécurisation en fonction de celles-ci.
On connaît également, par le brevet américain US 6 760 421 (Securelogix) , un système et un procédé de gestion de ressources et de sécurité téléphoniques qui permettent de surveiller et/ou de commander et d'enregistrer l'accès à un réseau téléphonique public commuté entre des stations d'utilisateurs finaux d'une entreprise et leurs circuits respectifs. Une politique de sécurité, constituée par exemple par un ensemble de règles de sécurité, est définie pour chacun des postes, ces règles spécifiant des actions à entreprendre sur la base d'au moins un attribut de l'appel sur le poste. Les appels sont détectés sur les postes pour déterminer les attributs associés à chaque appel. Les actions sont ensuite exécutées sur l'appel sélectionné sur la base de leurs attributs en fonction des règles de sécurité définies pour ces postes.
L'art antérieur connaît également, par la demande de brevet américain US 2004 / 0 161 086 (Securelogix), un système et un procédé de gestion et de sécurisation des ressources téléphoniques pour visualiser et contrôler les appels entrants et sortants entre les terminaux d'une entreprise et un réseau public commuté en mode circuit et/ou un réseau public commuté en mode paquet. Une politique sécuritaire est constituée d'une ou plusieurs règles désignant au moins une action à réaliser sur la base d'au moins un attribut de l'appel entrant ou sortant. Les appels sont détectés, captés sur la ligne et analysés pour déterminer les attributs associés à chacun de ces appels. Des actions mettant fin aux appels sont menées sur la base de ces attributs déterminés en accord avec les règles de politique de sécurisation. Un inconvénient de cette solution est l'application de règles de type uniquement coupure des appels lorsqu'une fraude est détectée. Un autre inconvénient est l'analyse uniquement des couches basses des protocoles de communication.
Les solutions apportées par ces documents réalisent une analyse des « couches basses » des protocoles de communication (couches 1/2/3 du modèle OSI) sur un réseau commuté de télécommunications en déterminant la nature des appels (type fax, type voix, numéro appelé, ...) . Elles ne permettent pas de protéger le réseau contre d'éventuelles attaques utilisant les fonctionnalités ( « couches hautes » applicatives, par exemple le renvoi d'appel, la conférence) offertes par l'autocommutateur et leurs failles.
En effet, les analyseurs de communication délivrent les informations suivantes :
- la nature de l'appel : Fax modem ou voix ;
- l'heure de début et de fin de la communication ;
- le numéro de l'appelant et de l'appelé ;
- la voie et le lien utilisés pour la communication.
L'analyseur de communication ne délivre pas l'ensemble des fonctionnalités qui ont été mises en œuvre ni leur chaînage. Les deux exemples suivants dénotent les limitations d'un tel système quant à la détection d'actions « frauduleuses ».
Exemple 1 :
Une communication d'un appel extérieur A vers un poste B de 1 'entreprise renvoyé immédiatement sans sonnerie vers un poste C extérieur à l'entreprise. L'analyseur va observer l'appel de A vers B puis de B vers C sans observer qu'il s'agit de la même communication. Ce n'est qu'avec l'analyse des fonctionnalités mises en œuvre pour cet appel que 1 Observation pourra être établie Exemple 2 :
Une communication d'un appel extérieur A vers un poste de l 'entreprise B peut écouter la conversation avec un interlocuteur C par l'activation de la fonctionnalité « entrée en tiers discrète ». Là encore l'analyseur de communication ne détectera que deux communications séparées et autorisées.
De plus, la convergence des réseaux commutés (RNIS par exemple) et en mode paquets (réseau IP) voit l'apparition des autocommutateurs mixte « commuté-IP ». Aucune solution n'a encore été apportée pour l'analyse des communications, du type voix sur IP (VoIP), en entrée d'un autocommutateur mixte.
On connaît également, par les documents US 6 801 607 et US 2004 / 0 111 305, des systèmes analysant les enregistrements émis par un autocommutateur. Ces solutions sont uniquement orientées pour la détection de fraudes et trouvent leur application du côté des opérateurs téléphoniques. Un inconvénient de ces solutions réside dans le fait qu'elles ne font pas intervenir une analyse des couches basses. Un autre inconvénient réside dans le fait que les informations nécessaires aux analyses présentées dans ces documents (les numéros de facturation) ne sont accessibles qu'aux opérateurs. La mise en oeuvre de telles solutions n'est pas réalisable dans les entreprises.
Il est un objet de l'invention de proposer une solution de sécurisation basée à la fois sur une analyse « couches basses » et une analyse des couches applicatives (couches hautes).
La présente invention entend remédier à au moins un inconvénient de l'art antérieur en proposant un système et un procédé de sécurisation d'un autocommutateur, soit en mode commuté, soit mixte « commuté-IP », sur la base d'une analyse des couches « basses » (nature de l'appel) et « hautes » (fonctionnalités de l'autocommutateur utilisées) mises en œuvre lors des appels.
Le procédé effectue, d'une part, une analyse des appels entrants ou sortants afin de déterminer leur nature, et d'autre part, reçoit des informations émises par l'autocommutateur, informations indiquant, entre autres, les fonctionnalités mises en œuvre pendant l'appel. Une comparaison est effectuée avec un ensemble de règles de sécurité du réseau (ou scénarii), le procédé permettant alors de donner suite à l'appel ou de le terminer.
Dans ce dessein, le système de l'invention dispose d'un analyseur de communication quelque peu semblable en termes fonctionnels à ceux décrits dans les brevets susmentionnés, et associé à un serveur ainsi qu'un second serveur analysant les informations émises par l'autocommutateur sur les appels en cours. Le système propose également un serveur dit « d'audit » permettant d'établir des règles de sécurité en fonction des spécificités du réseau et de 1'autocommutateur.
Le procédé et le système selon la présente invention répondent particulièrement bien aux attentes des entreprises dont les réseaux privées sont de trop nombreuses fois piratés par l'utilisation d'une des 400 fonctionnalités ou plus de l'autocommutateur (par exemple, l'appel en conférence ou conférence call) . A cet effet, l'invention concerne dans son acception la plus générale un système pare-feu de sécurisation d'un autocommutateur d'entreprise connecté, d'une part, à au moins un réseau de communication en mode commuté, de type PSTN, et, d'autre part, à un ensemble de périphériques de communications et/ou de serveurs d'application, ledit système comprenant -un analyseur de communication des couches basses (1 à 3) du modèle OSI de communications numériques en mode circuit et analogiques, un serveur pare- feu connecté au dit analyseur, caractérisé en ce que : ledit système comprend, en outre, un serveur de supervision connecté à la sortie « fil de l'eau » de l'autocommutateur pour l'analyse des tickets de communication et l'application de règles sécuritaire portant sur les couches hautes (4 à 7) du modèle OSI.
De préférence, - ledit autocommutateur est, en outre, relié à un réseau de communication en mode paquet, de type l'Internet ; ledit analyseur de communication est placé en parallèle des lignes entre l'autocommutateur et les réseaux commutés et en mode paquets ; ledit analyseur de communication analyse, en outre, les informations des couches basses des communications en mode paquet (entrantes et sortantes) de l'autocommutateur.
Avantageusement, ledit analyseur est un DSP permettant la détection des communications numériques circuits, numériques paquets et analogiques. Selon un mode de réalisation, ledit serveur de supervision comprend un système expert pour l'apprentissage de règles sécuritaires dans le cas d'un scénario inconnu.
Selon une mode de mise en œuvre particulier, ledit serveur de supervision comprend une base de données pour stocker les informations remontées par ledit analyseur de communication et les informations relatives à l'analyse desdits tickets.
De préférence, ledit système comprend, en outre, un serveur d'audit connecté au serveur de supervision apte à analyser les fonctionnalités de l'autocommutateur, l'architecture système et à établir un ensemble de scénarii d'appels.
Avantageusement, ledit serveur d'audit comprend un système expert pour l'établissement desdits scénarii.
Selon un mode de réalisation, ledit serveur pare-feu est connecté à une pluralité d'analyseurs de communications situés sur divers sites d'entreprise.
Selon un mode de réalisation particulier, ledit système comprend, en outre, un serveur de sauvegarde cryptée des configurations de l'autocommutateur.
Selon une variante, ledit système comprend, en outre, un modem call-back connecté au port de télémaintenance dudit autocommutateur.
L'invention concerne également un procédé de sécurisation d'un autocommutateur d'entreprise connecté, d'une part, à au moins un réseau de communication en mode commuté, de type PSTN, et, d'autre part, à un ensemble de périphériques de communications et/ou de serveurs d'application, le procédé comprenant une étape d'analyse des couches basses (couches OSI 1 à 3) des communications par un analyseur de communication et d'application de règles de sécurité pour mettre fin aux appels illicites, caractérisé en ce qu'il comprend, en outre, : - une étape de récupération par un serveur de supervision des tickets de communication émis par 1'autocommutateur, une étape de confrontation des informations contenues dans lesdits tickets aux règles de sécurité contenant dans le serveur de supervision, une étape d'application des règles de sécurité en fonction de ces informations contenues dans lesdits tickets.
De préférence, ledit procédé comprend, en outre, une étape de remontée des informations d'appels et de décisions prises depuis ledit analyseur de communication vers ledit serveur de supervision.
Avantageusement, ledit procédé comprend, en outre, une étape d'auto-apprentissage par un système expert dans le serveur de supervision des scénarii non gérés par les règles sécuritaires.
De préférence, ledit procédé comprend, au préalable, une étape de détermination des scénarii possibles par un serveur d'audit et une étape d'établissement des règles sécuritaires par sélection desdits scénarii.
Selon un mode de réalisation, ladite étape de détermination des scénarii comprend :
- une étape de récupération des fichiers de l'architecture circuit par ledit serveur d'audit auprès de l'autocommutateur et des fichiers de l'architecture système ; - une étape de détermination des risques et contre- mesures associées à partir desdits fichiers récupérés.
L'invention concerne également un élément de programme d'ordinateur comprenant des moyens de code de programme d'ordinateur organisés pour accomplir les étapes du procédé.
On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : la figure 1 représente l'architecture standard des systèmes de sécurisation d'autocommutateur sur réseau téléphonique commuté (art antérieur) ; la figure 2 illustre l'architecture de la présente invention ; la figure 3 illustre la structure fonctionnelle de l'analyseur de communication ; la figure 4 est un diagramme logique représentant le fonctionnement de l'analyseur de communication ; la figure 5 est un diagramme logique illustrant l'établissement des règles sécuritaires selon la présente invention ; - la figure 6 illustre les différentes tables de données initiales récupérées par le système expert d'analyse ; la figure 7 illustre un exemple de matrice de correspondances entre les menaces et les vulnérabilités d'un système de type autocommutateur ; la figure 8 illustre un exemple de matrice de correspondances entre les menaces et les fonctionnalités fournies par un autocommutateur ; la figure 9 illustre de façon logique le module d'audit et de contre-mesures selon la présente invention ; la figure 10 représente schématiquement le moteur d'inférence pour l'audit du système ; la figure 11 représente schématiquement le module d'établissement des contre-mesures ; - la figure 12 représente un diagramme logique du fonctionnement de la sécurité selon l'invention ; et la figure 13 illustre un exemple de communication en mode paquets.
L'invention va être décrite à l'aide d'exemples de modes de réalisation. Il est entendu que ces exemples ne sont pas limitatifs de l'invention et qu'un homme du métier serait à même de réaliser cette invention sous différentes variantes.
ARCHITECTURE ET DESCRIPTION DES DIFFERENTS MODULES La figure 2 représente un exemple de réalisation du système selon la présente invention, comprenant un autocommutateur (200), un analyseur de communication (100) et un ensemble de serveurs (110, 120 et 130) pour la gestion de la politique sécuritaire.
L'autocommutateur (200) d'entreprise est un autocommutateur permettant le traitement et la commutation en temps réel d'appels entre les périphériques (210) privés de l'entreprise et le réseau téléphonique commuté (300) et/ou un réseau en mode paquets, par exemple l'Internet (310). L'autocommutateur (200) fournit, en outre, des fonctionnalités (parfois plus de quatre cents) pouvant être mises en œuvre lors des appels : par exemple, le double appel, le renvoi d'appel, la conférence, ... Il présente également deux ports dédiés, d'une part, à la télémaintenance (198) et, d'autre part, à l'envoi (199) de « tickets » utilisés, entre autres, à la facturation des appels. Ce dernier port (199), aussi appelé port « au fil de l'eau » est un port série d'émission de données, les tickets. Ceux-ci contiennent de nombreuses informations sur les appels commutés par (200). Une description plus détaillée est fournie ci-après. Les fonctions essentielles d'un autocommutateur sont : la commutation, les interfaces avec les terminaux, l'application téléphonique. L'autocommutateur (200) peut être de type PBX (Private Branch eXchange) ou PABX (Private Automatic Branch eXchange) dédié uniquement à un réseau commuté, auquel cas l'analyse des communications en mode paquets n'est pas réalisée, ou « mixte », par exemple un PABX-IP centralisé dans lequel sont mises en œuvre toutes les fonctions exceptée la commutation réalisée par un switch (commutateur) réseau. Dans la suite de la description, nous utiliserons de façon non restrictive le terme de PABX pour l'autocommutateur (200) qu'il soit dédié au réseau commuté ou « mixte » .
Le réseau d'entreprise peut être du type LAN (Local Network Area) et est composé du PABX (200), des périphériques (210) et des lignes intérieures (220) reliant les périphériques au PABX.
Les périphériques sont de type fax (203), modem (202), téléphone (204), téléphone IP (205), téléphone sans- fil (206), par exemple DECT, serveurs d'applications (208) par exemple serveur boîte vocale, serveur de facturation,
..., ou serveurs d'administration (209) des autocommutateurs.
Les serveurs « de téléphonie » (208) et (209) sont reliés, en outre, au PABX par un réseau IP (230) isolé dédié uniquement à l'échange de données entre ces diverses entités : pilotage du PABX depuis le serveur d'administration, par exemple.
Toujours en référence à la figure 2, un analyseur de communication (100) est placé en parallèle des lignes réseaux (320) entre le réseau public commuté/en mode paquets (300, 310) et le PABX (200).
Un serveur pare-feu (110) est relié à l'analyseur de communication (100) et éventuellement à d'autres analyseurs (100', 100''). Le serveur pare-feu (HO) contient l'ensemble des règles ou scénarii à appliquer sur le réseau et les transmets aux analyseurs de communication. Une description plus détaillée d'un tel serveur peut être fournie par l'un des documents US 6 687 353, US 6 226 372, US 6 760 421 et US 2004 / 0 161 086 mentionnées précédemment. Le serveur 110 consolide en temps réel l'ensemble des informations de l'ensemble des analyseurs de communication des différents sites et gère les alertes liées aux dysfonctionnements éventuels de ces analyseurs. Un serveur de supervision (120) est relié au port « au fil de l'eau » (199) du PABX, au serveur pare-feu (110) et à un troisième serveur d'audit (130). Ce serveur (120) assure le management des analyseurs de communication (100) et la gestion des règles de sécurité. Les serveurs 110 et 120 doivent être physiquement différents pour des raisons de traitement temps réel et de sécurité de fonctionnement.
Le serveur d'audit (130) héberge un système expert permettant l'établissement des règles sécuritaires ou scénarii, règles qu'il transmet au serveur de supervision (120) pour application de celles-ci.
Ces différents serveurs sont par exemple des ordinateurs dédiés, comprenant un processeur, une mémoire vive de type RAM, un système d'exploitation, un logiciel pour la mise en œuvre du procédé de l'invention, logiciel exécuté sur ce système d'exploitation, et des moyens de connexion réseau.
Le système comprend également un dispositif de sauvegarde (112) et un modem de type call-back (114). Le dispositif (112) permet d'effectuer une sauvegarde, de préférence cryptée par clé dynamique, des configurations de l'autocommutateur. Le modem (114) fournit, quant à lui, une protection au niveau de l'accès au port de télémaintenance (198) en mettant en œuvre des mécanismes de détection d'appel, d'identification et de rappel en fonction de l'identification obtenue.
L'ANALYSEUR DE COMMUNICATION Les fonctionnalités de l'analyseur de communication (100) sont illustrées par la figure 3.
Pour des questions de coûts, l'analyseur de communication (100) est réalisé sous forme de DSP (Digital Signal Processing) avec un logiciel adapté. Ceci permet, entre autres, de faire cohabiter aisément un analyseur de réseau en mode circuit (RNIS) et un analyseur de réseau en mode paquets (IP). L'art antérieur connaît ces analyseurs dédiés aux réseaux commutés. Dans un mode de réalisation de l'invention, l'analyse du réseau IP est faite par un filtre récupérant l'en-tête des paquets transmis.
Le procédé d'analyse des communications est fourni par la figure 4.
(1) : l'analyseur (100) reçoit des appels numériques en mode circuit (a), en mode paquets (b) et des appels analogiques (c).
(3) : un premier module (106) identifie le type d'appel (voix, données, ...)• Ce module se base sur la récupération des en-têtes des paquets transmis, sur la signalisation du canal D des communications numériques commutées (RNIS TO et T2) ou sur la valeur des porteuses pour les liens analogiques.
(4) : dans un second module (105), les caractéristiques de l'appel sont comparées avec les règles de communications transmises par le serveur pare-feu (110) par l'intermédiaire de l'unité centrale (108) de l'analyseur.
En dehors des règles génériques liées à la sécurité du système (décision d'autoriser ou d'interdire tous les appels en cas de défaillance de l'analyseur de communication 100), les règles dites acquittées sont les règles en provenance uniquement du serveur d'audit (130) qui a en charge le contrôle de cohérence de l'ensemble des règles. Le comportement par défaut autorise les appels qui ne sont pas explicitement interdits et lorsqu'une des règles coïncide avec la communication en cours, la règle s'applique.
L'ensemble des règles qui ne font intervenir que les informations recueillies par l'analyseur de communications (100) est résident dans celui-ci pour le site concerné ; ceci afin d'assurer un traitement en temps réel (suffisamment rapide au regard du temps de connexion des communications). Ces règles y sont stockées soit en mémoire Flash, soit sur disque dur, suivant le nombre de liens à observer. Les règles de sécurité sont envoyées par le serveur de supervision (120) via le serveur (110). Un exemple d'analyseur de communication (100) est un des produits de la gamme « Wavetel ». Le serveur pare-feu (110) est le garant des règles relatives aux couches 1-2-3 et contrôle périodiquement l'intégrité des données des analyseurs de communication pour prévenir d'éventuelles modifications malicieuses au niveau de ces derniers.
S'en suit le traitement (104) de l'appel en fonction de ces règles. Soit l'appel est autorisé, soit il est autorisé avec des restrictions de plage horaire, de numéros, de destinations soit il est terminé par une procédure de raccrochage (5). Cette procédure s'effectue, pour les différentes natures de liens de la manière suivante :
- pour les liens numériques « circuits », s'il existe un lien API au niveau du PABX alors est générée une commande de coupure de la communication en cours. Sinon, on réalise un brouillage de la communication par l'entrée en tiers avec annonce du modem de l'analyseur de communication (100) connecté sur un joncteur de poste analogique jusqu'au raccroché par l'utilisateur, - pour les liens numériques « paquets », un comportement « Firewall data » est appliqué par blocage de l'appel après extraction et analyse de l'en-tête IP au niveau RTP ou RTCP dans le cas de figure d'une communication utilisant un protocole de communication H323, au niveau SDP dans le cas d'une communication utilisant le protocole de communication SIP et/ou MGCP, ces couches permettant l'identification des codées (G711 à G729), du protocole fax (T30, T38) ou du protocole modem (G723.1). L'appel sera bloqué soit par la commande « Cancel » au niveau de la signalisation pour SIP, soit par la commande « Reject » du protocole H245 pour H323, soit par la commande « DeleteConnection » pour MGCP.
- pour les liens analogiques, on réalise une coupure par micro-relais. L'analyse est réalisée en boucle tant que l'appel n'a pas pris fin. Une fois cet appel terminé, les informations de l'appel sont remontées (6) vers le serveur pare-feu (110), puis envoyées à travers un « pipe de communications » vers le serveur de supervision (120) en temps réel.
L'exemple suivant concerne l'analyse des paquets émis sur le réseau dans le protocole H.323. Exemple 1 : Analyse du protocole H.323
La figure 13 illustre d'une part, les couches sur lesquelles repose le protocole H.323 et d'autre part, le format de l'en-tête RTP (Real-time Transfert Protocol) utilisé pour la voix sur IP sur le protocole H.323.
L'analyseur de communication analyse l'en-tête RTP contenu dans la trame UDP ou TCP afin de déterminer la nature de la communication en prenant en compte dans cet en-tête, la valeur « Payload Type ». Dans l'exemple fourni, il s'agit d'une communication G711 encore appelé PCMA.
LE SERVEUR D'AUDIT
Illustré par la figure 5, le serveur d'audit (130) permet la mise en place des scénarii de sécurisation du réseau, scénarii qui seront choisis par un opérateur humain pour l'établissement des règles de sécurité. ANALYSE FONCTIONNELLE
Une première étape est réalisée avant l'exploitation du système. Elle vise à déterminer les caractéristiques fonctionnelles du PABX (200) qui changent d'un fabricant à l'autre (1010) et les spécificités de l'architecture réseau en place (1020). Les opérations décrites ci-après sont reproduites après une mise à jour du PABX ou après une modification de l'architecture du réseau (ajout de périphériques par exemple), c'est pourquoi il est préférable que le serveur d'audit (130) ne partage pas les mêmes ressources que le serveur de supervision (120).
Lors d'une phase préliminaire avant la mise en exploitation du système, le serveur (130) est connecté au port de maintenance V24 (198) du PABX pour obtenir les fichiers d'architecture circuit (1020) contenus dans le PABX ainsi qu'au réseau IP (230) pour obtenir les informations d'architecture système (1010). Une application du type NESSUS permet d'obtenir par le réseau IP (230) l'ensemble des informations IP du réseau : VLAN, adresses IP, nombre de serveurs d'application, ...
Les fichiers architecture circuit mentionnent les configurations des liens internes (annuaire des numéros de téléphone) et des liens externes (TO, T2, voix IP pour la voix) .
La figure 6 représente un exemple des bases de données de configurations (1000) obtenues par le serveur d'audit (130) après analyse du système (1010) et des circuits (1020).
La base de données des liens extérieurs renseigne :
- la nature des liens (RNIS TO ou T2, analogique IP) ;
- s'il s'agit d'un Intranet ; - le type de flux (entrant, sortant, mixte) ;
- le nombre de voies ;
- le débit effectif.
La base de données des liens internes renseigne :
- le numéro de téléphone ; - s'il possède une SDA (sélection directe à l'arrivée) ou non ;
- la nature du liens (analogique, numérique, IP) ; - le type de périphérique (téléphone, modem, fax). La base de données système renseigne : - les éléments présents (PABX, messagerie vocale, serveur de facturation) ;
- la version du système d'exploitation ;
- les mises à jour ;
- les mots de passe ; - les ports de communication ;
- l'adresse logique ;
- l'adresse physique.
La base de données des fonctionnalités du PABX renseigne : - les numéros de téléphone ; - les profils ou classes associés ;
- les fonctionnalités ouvertes sur chacun des numéros de téléphone (renvoi, conférence, groupement) ;
- les restrictions associées.
Préalablement, est effectuée une étape de définition des attributs et des valeurs correspondantes mis en œuvre par le PABX (200) (en fonction du constructeur), par exemple : Valeurs_services_associées : mevo (messagerie vocale), Svi, Acd, taxation... ;
Valeurs_états_logiciels : mise à jour, mot de passe, ports communication ouverts ;
Valeurs_architecture : Vlan, indépendant, QoS ; Valeurs_télémaintenance : sda, mot de passe, ip, v24, call back ;
Valeurs_sauvegardes : crypté, périodique ;
Valeurs_mobilité : borne ouverte, Dect, Wifi ;
Valeurs_fonctionnalités : opérateur, interphonie, multi Cco, multisociété, Disa, conférence, enregistrement, entrée en tiers, transfert, renvois, écoute, groupement, Sda... ;
Valeurs_restrictions : horaires, géographique, plage numéros, accès prioritaire, verrouillage logique...
Toujours en référence à la figure 5, une analyse des différentes vulnérabilités (1100) du PABX par rapport à ces valeurs permet de distinguer trois principaux types de vulnérabilités : les vulnérabilités d'accès (possibilité d'accès au système et aux données contenues à l'intérieur), celles de création/modification/suppression (cms)
(possibilité d'interagir avec le système et les données associées) et celles de récupération (possibilité de récupérer l'action qui se passe). La base de données des règles (1110) contient, quant à elle, l'ensemble des règles de sécurité appliquées par le système. Cette base est généralement vide à l'installation du système et s'enrichit à l'issue de cette phase d'audit du système. Les règles sont sous la forme :
Si (nom unité opérateur valeur) et ... et (nom_de_plusieurs_mots opérateur valeur)
Alors (nom = valeur) et .. et (nom = formule)
Voici deux exemples de règles :
Exemple 2
Si Valeurs_services_associés = (messagerie vocale, mot de passe standard, sda) et Valeurs_fonctionnalités = (rappel automatique après dépôt de message, numéro extérieur) et Valeur_architecture = (liens extérieurs, pas de restriction)
Alors risque = (écoute)
Cet exemple illustre le risque de subir une écoute téléphonique mise en œuvre en utilisant les faiblesses du système en matière de rappel automatique d' un numéro extérieur après le dépôt de message dans une messagerie vocale .
Exemple 3
Si valeur_télémaintenance = (mot de passe constructeur, numéro sda, pas de restriction) et valeurjonctionnalités = (renvoi extérieur) et valeurjarchitecture = (liens extérieurs, pas de restriction) Alors risque = (détournement de trafic)
Cet exemple illustre le détournement de trafic de communication en utilisant le renvoi extérieur d'une communication rendu possible par l'obtention du mot de passe constructeur...
Egalement, la méthode EBIOS permet d'établir, indépendamment de l'architecture du réseau d'entreprise, une matrice caractérisant les dépendances entre menaces et vulnérabilités du PABX (200), et une matrice caractérisant les dépendances entre les menaces et les fonctionnalités offertes par le PABX.
La figure 7 représente un exemple de matrice « menaces / vulnérabilités » où les menaces sont du type espionnage industriel ou détournement de trafic, et les vulnérabilités peuvent être la possibilité d'accéder directement à un poste ou la possibilité d'effacer ou modifier des programmes. La figure 8 représente un exemple de matrice « menaces / fonctionnalités » où les fonctionnalités fournies par le PABX (200) peuvent être la numérotation abrégée commune, le renvoi ou encore le groupement.
Ces matrices peuvent être remplies manuellement, c'est-à-dire que les dépendances sont établies en fonction de la connaissance du matériel et de la sécurité du réseau.
MOTEUR EXPERT - INFERENCE ET CONTRE-MESURES Chacune des configurations système/circuit (1000) définies précédemment est confrontée aux informations de menaces, vulnérabilités et règles établies pour évaluer les risques de cette configuration et les contre-mesures adéquates contre cette situation. Une représentation schématique de ce système expert est fournie en figure 9 dont les modules SCNl (1120) et SCN2 sont illustrés par les figures 10 et 11.
Ce système expert est contenu dans le serveur (130).
Un chaînage avant et arrière est réalisé entre les menaces et les vulnérabilités du système (selon la matrice définie précédemment) par le module SCNl (1120). On entend par « chaînage avant et arrière » l'analyse consistant à partir d'une part de chacune des menaces (rôle symétrique des vulnérabilités) pour lui associer les vulnérabilités dépendantes et de boucler cette analyse par la vérification à partir des vulnérabilités déterminées de la menace originelle. Une analyse successive des vulnérabilités d'accès, des vulnérabilités de création/modification/suppression et des vulnérabilités de récupération, permet d'établir les risques éventuels encourus par le système face à cette menace. Ces risques sont stockés dans une base de données.
Ces risques ont la forme suivante : « vulnérabilités(accès) et vulnérabilités(Mcs) et vulnérabilités (Récup) alors Menace (xx) », et permettent d'établir des contre-mesures. Ces nouvelles contre-mesures ou scénarii tiennent compte de ceux déjà existants (base de données des contre-mesures 1210) et sont réalisés par le module SCN2 illustré par la figure 11.
Un classement des risques permet de déterminer les cas à autoriser, ceux à interdire et enfin ceux à autoriser avec restriction (plage horaire, géographique, ...) : ce sont les scénarii. Les risques sont classés suivant deux critères.
Un classement selon les quatre grandes familles de risques :
- les risques liés au détournement de trafic,
- ceux liés à l'écoute,
-ceux liés à l'usurpation (la fonction sqatt, par exemple, permet de récupérer l'ensemble des caractéristiques d'un autre poste y compris son numéro de téléphone) ,
- ceux liés au déni de service (scénario permettant l'introduction d'un élément malin dans le logiciel du système) . Puis, à l'intérieur de ces familles, est effectué un classement par ordre de facilité suivant la règle : moins un scénario comporte d'item plus il est facile à mettre en œuvre. En conséquence et suivant la politique de sécurité de l'entreprise, il s'agira d'interdire au maximum ce qui parait le plus dangereux.
Une intervention humaine permet de choisir les contre-mesures définissant la politique de sécurité du PABX (200) : exemples concernant les vulnérabilités d'architecture : supprimer les liens inactifs, modifier les numéros de télémaintenance s'il répondent aux standards constructeurs, réorganiser l'annuaire... compte tenu des proposition faites par le système expert ; exemples concernant les fonctionnalités fournies par le PABX : les contre-mesures relatives aux scénarii de risques se présentent sous la forme de choix, car il ne peut être question de supprimer l'ensemble des fonctionnalités ouvertes, par définition du rôle du PABX. Il s'agira de limiter les scénarii et de surveiller ceux qui n'ont pas pu être éradiqués, par exemple, supprimer le scénario en interdisant le ou les fonctionnalités mises en cause, autoriser les fonctionnalités et surveiller leur usage ou encore, restreindre les fonctionnalités par plage horaire, par plage de numéros, par destination, ... ; exemples concernant les périphériques : autoriser ou restreindre un périphérique, un groupe de périphérique, un numéro de téléphone, ... un type de périphérique. Une itération du système expert se déroulera pour, en temps réel, vérifier que le couple fonctionnalités/périphérique ne crée pas de nouveau scénario de risque ; - gestion d'accès logiques et de mis à jour suivant les recommandations du module « Audit » ou aménagement avec itération du système expert. Ceci s'explique, par exemple, par le fait qu'il existe dans chaque composant du système de communication d'entreprise un certain nombre de ports logiques de communications ouverts. Certains ne servent pas et il est alors recommandé de les fermer quitte à les rouvrir en cas de nécessité. Par exemple, pour un PABX de type Alcatel, vingt ports sont ouverts en configuration standard et la moitié d'entre eux servent uniquement à l'installation du système.
De plus, les bases de données des règles (1110), des vulnérabilités (1100) et des contre-mesures (1210) sont mises à jour lors la création des nouveaux scénarii.
Voici l'établissement de contre-mesures en référence aux deux exemples 2 et 3 susmentionnés. Exemple 3 : détournement de trafic
Un détournement peut provenir de la combinaison des vulnérabilités suivantes :
Vulnérabilité d'accès concerne la valeur_télémaintenance (mot de passe constructeur, numéro SDA, pas de restriction)
Vulnérabilité de « cms » concerne la valeur_ fonctionnalités (renvoi extérieur, pas de restrictions)
Vulnérabilité de récupération concerne la valeur_architecture (liens extérieurs, pas de restriction)
La règle de risque alors établie devient : Si valeur_télémaintenance(mot de passe constructeur, numéro sda, pas de restriction) et valeur_ fonctionnalités (renvoi extérieur) et valeur_architecture( liens extérieurs, pas de restriction) alors risque ( détournement de trafic)
Ce scénario peut se produire fréquemment car le hacker externe peut, à travers un « war-dialer » (programme qui permet à partir d'une série de numéros de téléphone de lancer massivement des appels pour identifier une porteuses modem ou fax et d'autoriser l'entrée dans un système informatique ou télécom) , identifier le modem de télémaintenance, par Internet trouver les mots de passe constructeur, accéder et activer la fonctionnalité renvoi ou détourner le trafic à son compte.
Pour déterminer ces scénarii, le moteur de règles utilise les matrices de correspondance évoquées précédemment afin : - d'identifier toutes les vulnérabilités d'accès
(Ports maintenance et télémaintenance mal protégés, postes non protégés, fonctionnalités d'accès ouvertes (DISA), etc. ) , d'identifier toutes les vulnérabilités autorisant la création-suppression-modification des facilités répondant aux menaces (renvoi, transfert, DISA, conférence, etc. ) , - d'identifier toutes les vulnérabilités permettant de récupérer l' action précédemment mise en œuvre répondant à la menace (liens extérieurs, serveurs associés, etc.).
Exemple 2 ; écoute
Les vulnérabilités du système quant à l ' écoute concernent :
Accès : valeurs_services_associés (messagerie vocale, mot de passe standard, sda) ,
Cms : valeurs_fonctionnalités ( rappel automatique après dépôt de message , numéro extérieur ) ,
Récupération : valeur_archltecture ( liens extérieurs , pas de restriction ) .
La règle de risque alors établie devient :
Si Valeurs_services_associês (messagerie vocale, mot de passe standard, sda) et Valeurs_£onctionnal±tés (rappel automatique après dépôt de message, numéro extérieur) et Valeur_architecture (liens extérieurs, pas de restriction) alors risque(écoute)
Les contre-mesures proposées sont alors :
ANALYSE ET APPLICATION POLITIQUE SECURITAIRE L'étape d'audit a permis d'établir les configurations et instructions (règles) nécessaires à l'application de la sécurité des transactions, communications passant par le PABX.
Comme illustrées par la figure 12, les règles établies sont triées selon leur domaine d'application : celles concernant les « couches basses » de communication (couche OSI 1-3) sont transmises à la base de données du serveur pare-feu (110) via le serveur de supervision (120), celles concernant les « couches hautes » (applicatives OSI
4-7) et les fonctionnalités du PABX sont transmises à la base de données du serveur de supervision (120). Certaines règles affectent de façon permanent le
PABX : elles sont donc directement paramétrées dans la base de données du PABX, automatiquement et/ou manuellement. Les autres règles sont comparées sur le serveur de supervision
(120) avec les tickets de communications émis sur le port « au fil de l'eau » (199) du PABX.
TICKETS
A chaque appel, est généré un ticket de communication comportant 128 octets. Ces tickets sont généralement utilisés pour la facturation des appels. Dans le cadre de la présente invention, le ticket fournit, entre autres, les informations suivantes :
- Numéro appelant
- Numéro appelé
- Date -Heure de début d'appel
- Heure de fin d'appel
- Numéro intermédiaire - Numéro T2/T0
- Voie
- IP
- Opératrice - Interface (numérique, analogique, IP)
- Site
- Fonctionnalités mises en œuvre
- Nom de l'annuaire
Un contrôle de cohérence entre les informations contenues dans le ticket et la base de données du PABX est effectué: une alerte est levée en cas d'incohérence, et l'appel peut être terminé. C'est, par exemple, le cas lorsque pendant une reconfiguration manuelle du PABX, tous les nouveaux paramètres édités par le module audit n'ont pas été introduits dans le PABX (pas de mise à jour de l'annuaire, oubli d'interdire une fonctionnalité pour un poste, etc.). Ce contrôle permet de limiter les appels aux possibilités fournies et autorisées (les paramètres) par le PABX.
Les données issues de cette analyse sont remontées avec les informations des tickets de communications au serveur de supervision (120). Les informations concernant l'appel en cours sont combinées avec les alertes remontées du serveur pare-feu (110) d'analyse couches OSI 1-3 (BDD alertes firewall) et comparées aux règles de sécurité du serveur de supervision (120). Une analyse complémentaire peut être effectuée ; elle confronte les données de l'appel en cours à un historique des derniers appels (Fichier Tempo Attaques) pour établir s'il y a une attaque ou un non- respect de la politique de sécurité (selon des modèles d'attaques types) .
Cet historique peut être sous la forme d'un fichier renseignant les cent derniers appels traités par le PABX et leurs caractéristiques (poste appelé, sonnerie inférieure à 4 coups, absence de réponse, poste appelant extérieur, ...). L'objectif de cette historisation est d'être capable de déterminer les attaques répétées.
La supervision en temps réel du système de communication de l'entreprise repose sur une analyse des tickets du trafic, la surveillance et la supervision des fonctionnalités mises en œuvre par un appel et qui présentent des vulnérabilités, la surveillance et l'alerte dans le cas où un scénario de risque est en train de se produire, l'auto-apprentissage des scénarii non envisagés et qui se produisent et enfin la veille en détection d'attaques par le rapprochement d'informations, par exemple : o Nombre d'appels inférieurs à 4 et raccrochés comparé à la moyenne. Analyse de l'écart type avec seuil de déclenchement, o Nombre d'appels tels que ci-dessus et analyse si le phénomène se déroule de manière séquentielle ou aléatoire, avec indication des temps entre chaque appel de cette nature et seuil de déclenchement, o Nombre d'appels répondus au travers de la messagerie vocale et détectés comme étant des appels de type modem.
Un algorithme de pondération, aux vues de ces informations, établira la présence ou non d'une attaque et mettra en œuvre la procédure d'alerte et d'action établie auparavant.
Lorsqu'une attaque, un non-respect de la politique sécuritaire, un nouveau scénario de risques est détecté, un traitement des contre-mesures adéquates est effectué.
Exemple 4
Si une attaque se présente, la décision peut être prise de couper tous les liens extérieurs si l'événement se passe lors d'une période pendant laquelle l'entreprise est fermée (la nuit).
Exemple 5
En cas de non-respect de la politique sécuritaire, le numéro de téléphone intérieur concerné peut être inactivé.
Exemple 6
En cas de mise à jour d'un nouveau scénario de risque, le PABX est reconfiguré en prenant en compte ce risque.
Dans le cas où la configuration de l'appel en cours n'est prise en charge par aucun scénario, un système expert, similaire à celui décrit ci-dessus, permet l'auto- apprentissage du système. Un nouveau risque est déterminé, des scénarii éventuellement proposés et un opérateur humain détermine les scénarii correspondants à la politique de sécurité. Cet apprentissage se fait par chaînage flou : on analyse les scénarii les plus proches. Par exemple, un scénario ayant quatre critères sur cinq identiques à l'appel en cours est considéré comme proche.
- soit les scénarii proches sont cohérents entre eux, et un nouveau scénario est établi pour l'appel en cours,
- soit les scénarii ne sont pas cohérents entre eux, auquel cas une alarme est remontée, par exemple par email ou SMS, pour demander l'établissement d'une règle adaptée.
Le système permet également des remontées statistiques permettant entre autres de connaître le nombre d'appels terminés, le nombre de tentatives d'accès frauduleux, ...
Selon un mode de réalisation, l'invention consiste en un logiciel exécuté sur un système d'exploitation de type « Windows Serveur » (nom commercial) et les bases de données mises en œuvre sont de type SQL et plus tard sur des plateformes plus élaborés tel que « Oracle » (Nom commercial) .
EXEMPLE D'UN SCENARIO Voici un exemple de traitement de scénario d'appel frauduleux, depuis son origine jusqu'aux contre-mesures appliquées par le système.
La situation est la suivante :
1. Un pirate s'est introduit au travers du réseau IP data en profitant du fait que :
- le port de communication logique de l'autocommutateur est ouvert et pas de configuration VLAN pour le réseau Ethernet dédié aux serveurs téléphone,
- le Firewall Data autorise le port ftp 80 ce qui a permis de rentrer dans le PABX dont ce port est aussi rester ouvert,
- le pirate a ensuite introduit un exécutable qui lui donne la main sur le port télémaintenance,
- le mot de passe a été corrompu par un outil de « Crackage » car le mot de passe a été changé et n'est plus celui du constructeur.
2. Le pirate a ensuite créer un poste virtuel dans le PABX avec la fonction numérotation ouverte (il s'agit d'un poste où l'interface a été activé sans connecter un poste physiquement et qui lorsqu'il est sollicité compose l'indicatif de sortie vers le réseau et attend le numéro à composer) .
3. Le pirate s'est attribué la fonction DISA (fonction qui permet à un poste extérieur à l'entreprise d'être perçu comme un poste de l'entreprise).
4. Le pirate a ensuite repéré des postes dit en groupement cyclique (un groupement cyclique est un groupe de poste qui possède un numéro interne générique commun, ce qui n'empêche pas ces postes d'avoir un numéro individuel, et qui pour chaque nouvel appel à ce groupement l'oriente vers le poste suivant libre appartenant au groupement) .
5. La communauté des pirates a été prévenue des numéros à composer. Cette communauté est constituée de 50 membres dont un dispose d'un serveur vocal situé aux Bahamas avec une surfacturation du service (1 € la minute reversé par l'opérateur sur un compte en suisse).
6. Le pirate a activé un renvoi du groupement vers le serveur vocal situé aux Bahamas pendant les heures non ouvrées.
Le pirate a ainsi à sa disposition :
- un poste DISA qui lui permet d'être appelé et de transférer toutes les communications vers les destinations souhaitées par les appelants,
- de joindre le serveur vocal avec des mobiles anonymes (cartes prépayées) et de partager le gain lié au service surfacturé pendant les heures non ouvrées grâce au groupement de poste, - de pouvoir appeler avec le poste fictif à n'importe quelle heure n'importe quelle destination sans être repéré car ce poste ne figure pas dans l'annuaire.
La facture peut être très salée pour l'entreprise et l'hémorragie ne pourra pas être stoppée aussi facilement car plusieurs actions ont été menées sans un lien manifeste.
Après installation du système pare-feu de sécurisation du PABX de l'entreprise, selon la présente invention :
- l'application « audit », grâce au module SCNl, par l'application des règles de vulnérabilité / menaces / risques, va mettre à jour les scénario suivants : Vulnérabilités accès : Valeurs_états_logiciels = (ports communication ouverts)
Valeurs_architecture ≈ (Vlan) Valeurs_télémaintenance = (IP)
Vulnérabilités (cms) : Valeurs_fonctionnalités = (Disa) Valeurs_fonctionnalités = (renvoi, groupement) Valeurs_fonctionnalités ≈ (poste fictif, appel au décroché extérieur temporisé)
Vulnérabilités (Récup) ;
Valeur_architecture = (liens extérieurs, pas de restriction)
Règles
A. Si Valeurs_étatsjogiciels = (ports communication ouverts) et Valeurs_architecture = (vlan) et Valeursjélémaintenance = (ip) et Valeurs_fonctionnalités = (disa) et Valeur_architecture = (liens extérieurs, pas de restriction)
Alors risque = (Détournement de trafic)
B. Si Valeurs_états_logiciels = (ports communication ouverts) et Valeurs_architecture = (vlan) et Valeurs_télémaintenance = (ip) et Valeurs_fonctionnalités = (poste fictif, appel au décroché extérieur temporisé) Alors risque = (détournement de trafic)
C. Si Valeurs_états_logiciels = (ports communication ouverts) et Valeurs_architecture ≈ (vlan) et Valeursjélémaintenance ≈ (ip) et Valeurs_fonctionnalités = (renvoi, groupement) Alors risque = (détournement de trafic)
Dans le module SCN2, le logiciel classe ces risques : Famille : Détournement de trafic Difficulté croissante : A, C, B
Contre-mesures retenues : Ports communication ouverts : Autorisé le port 80 car utile pour les mises à jour et Patchs,
Vlan : Interdire l'absence de Vlan,
Poste fictif : restreindre le nombre de postes pouvant être créés et surveiller les numéros autorisés par le logiciel de supervision au travers des tickets et les afficher dans l'annuaire,
Appel au décroché temporisé : interdire, Renvoi : interdire le renvoi extérieur pour tous les postes faisant partie d'un groupement sur le numéro du groupement,
Groupement ; autoriser.
L'ensemble de ces données est ainsi enregistré dans la base de données « nouvelle configuration »
L'application « supervision » va trier les règles et les paramétrages soit vers le serveur pare-feu (110) soit vers le PABX.
Le paramétrage du PABX se fera manuellement car le PABX ne dispose pas d'interface API ou IAE dans notre exemple : l'opération mise en place d'un Vlan s'exécutera par acquittement de la direction informatique et sa réalisation sera contrôlée et constatée lors du prochain audit automatique. Pour le serveur pare-feu : aucune action prévue car les couches 1 à 3 du modèle OSI gérées par l'analyseur de communication ne sont pas sollicitées dans cet exemple.
Le contrôle de cohérence de la configuration se fera au fur et à mesure des appels et si une des facilités ci- dessus est retrouvée pour les postes incriminés et ne répond pas aux contre-mesures adoptées alors une alerte est levée pour correction.
Dans le traitement du « module expert », le scénario d'appel en cours sera comparé avec l'ensemble des scénarios de la base pour trouver un éventuel nouveau scénario proche ou original.
Le programme d'alerte « attaque » ne se déclenchera pas dans cet exemple.
L'appel sera stocké avec ses caractéristiques dans la base de données fil de l'eau.
L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de 1 'invention sans pour autant sortir du cadre du brevet.

Claims

REVENDICATIONS
1. Système pare-feu de sécurisation d'un autocommutateur (200) d'entreprise connecté, d'une part, à au moins un réseau de communication en mode commuté, de type PSTN, et, d'autre part, à un ensemble de périphériques de communications et/ou de serveurs d'application (210), ledit système comprenant un analyseur de communication (100) des couches basses (1 à 3) du modèle OSI de communications numériques en mode circuit et analogiques, un serveur pare-feu (110) connecté au dit analyseur (100), caractérisé en ce que :
- ledit système comprend, en outre, un serveur de supervision (120) connecté à la sortie « fil de l'eau » (199) de l'autocommutateur (200) pour l'analyse des tickets de communication et l'application de règles sécuritaire portant sur les couches hautes (4 à 7) du modèle OSI.
2. Système pare-feu selon la revendication précédente, caractérisé en ce que :
- ledit autocommutateur (200) est, en outre, relié à un réseau de communication en mode paquet, de type l'Internet, ledit analyseur de communication (100) est placé en parallèle des lignes entre l'autocommutateur (200) et les réseaux commutés et en mode paquets ; ledit analyseur de communication (100) analyse, en outre, les informations des couches basses des communications en mode paquet (entrantes et sortantes) de l'autocommutateur (200) ;
3. Système pare-feu selon la revendication 1 ou 2, caractérisé en ce que ledit analyseur (100) est un DSP permettant la détection des communications numériques circuits, numériques paquets et analogiques.
4. Système pare-feu selon l'une des revendications 1 à 3, caractérisé en ce que ledit serveur de supervision (120) comprend un système expert pour l'apprentissage de règles sécuritaires dans le cas d'un scénario inconnu.
5. Système pare-feu selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit serveur de supervision (120) comprend une base de données pour stocker les informations remontées par ledit analyseur de communication (100) et les informations relatives à l'analyse desdits tickets.
6. Système pare-feu selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, en outre, un serveur d'audit (130) connecté au serveur de supervision (120) apte à analyser les fonctionnalités de l'autocommutateur, l'architecture système et à établir un ensemble de scénarii d'appels.
7. Système pare-feu selon la revendication 6, caractérisé en ce que ledit serveur d'audit (130) comprend un système expert pour l'établissement desdits scénarii.
8. Système pare-feu selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit serveur pare-feu (HO) est connecté à une pluralité d'analyseurs de communications (100, 100', 100'') situés sur divers sites d'entreprise.
9. Système pare-feu selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend, en outre, un serveur de sauvegarde cryptée (112) des configurations de l'autocommutateur.
10. Système pare-feu selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, en outre, un modem call-back (114) connecté au port de télémaintenance (198) dudit autocommutateur (200).
11. Procédé de sécurisation d'un autocommutateur (200) d'entreprise connecté, d'une part, à au moins un réseau de communication en mode commuté, de type PSTN, et, d'autre part, à un ensemble de périphériques de communications et/ou de serveurs d'application (210), le procédé comprenant une étape d'analyse des couches basses (couches OSI 1 à 3) des communications par un analyseur de communication (100) et d'application de règles de sécurité pour mettre fin aux appels illicites, caractérisé en ce qu'il comprend, en outre, :
- une étape de récupération par un serveur de supervision (120) des tickets de communication émis par l'autocommutateur (200), une étape de confrontation des informations contenues dans lesdits tickets aux règles de sécurité contenant dans le serveur de supervision (120),
- une étape d'application des règles de sécurité en fonction de ces informations contenues dans lesdits tickets.
12. Procédé de sécurisation selon la revendication 11, caractérisé en ce qu'il comprend, en outre, une étape de remontée des informations d'appels et de décisions prises, depuis ledit analyseur de communication (100) vers ledit serveur de supervision (120).
13. Procédé de sécurisation selon la revendication 11 ou 12, caractérisé en ce qu'il comprend, en outre, une étape d'auto-apprentissage par un système expert dans le serveur de supervision (120) des scénarii non gérés par les règles sécuritaires.
14. Procédé de sécurisation selon l'une des revendications précédentes, caractérisé en ce qu'il comprend, au préalable, une étape de détermination des scénarii possibles par un serveur d'audit (130) et une étape d'établissement des règles sécuritaires par sélection desdits scénarii.
15. Procédé de sécurisation selon la revendication précédente, caractérisé en ce que ladite étape de détermination des scénarii comprend :
- une étape de récupération des fichiers de l'architecture circuit par ledit serveur d'audit (130) auprès de l'autocommutateur (200) et des fichiers de l'architecture système ;
- une étape de détermination des risques et contre- mesures associées à partir desdits fichiers récupérés.
16. Elément de programme d'ordinateur comprenant des moyens de code de programme d'ordinateur organisés pour accomplir les étapes du procédé selon l'une quelconque des revendications 11 à 15.
EP05812485A 2004-10-19 2005-10-19 Dispositif de securisation d un autocommutateur Withdrawn EP1803279A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0452361A FR2876855B1 (fr) 2004-10-19 2004-10-19 Dispositif de securisation d'un autocommutateur
PCT/FR2005/002601 WO2006042973A1 (fr) 2004-10-19 2005-10-19 Dispositif de securisation d’un autocommutateur

Publications (1)

Publication Number Publication Date
EP1803279A1 true EP1803279A1 (fr) 2007-07-04

Family

ID=34954135

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05812485A Withdrawn EP1803279A1 (fr) 2004-10-19 2005-10-19 Dispositif de securisation d un autocommutateur

Country Status (3)

Country Link
EP (1) EP1803279A1 (fr)
FR (1) FR2876855B1 (fr)
WO (1) WO2006042973A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115705035B (zh) * 2021-08-13 2024-05-28 中国石油天然气集团有限公司 无人站场阀室控制系统及无人站场阀室的控制方法
US12034758B2 (en) * 2021-09-14 2024-07-09 The Mitre Corporation Optimizing network microsegmentation policy for cyber resilience

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6601048B1 (en) * 1997-09-12 2003-07-29 Mci Communications Corporation System and method for detecting and managing fraud
US6226372B1 (en) * 1998-12-11 2001-05-01 Securelogix Corporation Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities
US7133511B2 (en) * 1998-12-11 2006-11-07 Securelogix Corporation Telephony security system
US6760420B2 (en) * 2000-06-14 2004-07-06 Securelogix Corporation Telephony security system
US6801607B1 (en) * 2001-05-08 2004-10-05 Mci, Inc. System and method for preventing fraudulent calls using a common billing number

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006042973A1 *

Also Published As

Publication number Publication date
FR2876855A1 (fr) 2006-04-21
WO2006042973A1 (fr) 2006-04-27
FR2876855B1 (fr) 2007-02-09

Similar Documents

Publication Publication Date Title
US6760420B2 (en) Telephony security system
US6226372B1 (en) Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities
US7653188B2 (en) Telephony extension attack detection, recording, and intelligent prevention
US6700964B2 (en) Encapsulation, compression and encryption of PCM data
US7133511B2 (en) Telephony security system
US20020090073A1 (en) Telephony security system
US6879671B2 (en) Virtual private switched telecommunications network
EP1894350B1 (fr) Securisation de la telephonie sur ip
WO2011083226A1 (fr) Procédé de détection d'un détournement de ressources informatiques
US6718024B1 (en) System and method to discriminate call content type
EP1193945A1 (fr) Procédé et appareil pour contrôle d'accès dans un réseau
EP3104585B1 (fr) Dispositif et procédé de traitement d'une communication
EP1803279A1 (fr) Dispositif de securisation d un autocommutateur
US20050025302A1 (en) Virtual private switched telecommunications network
FR3037465A1 (fr) Dispositif et procede de traitement d'une communication
De Lutiis et al. An innovative way to analyze large ISP data for IMS security and monitoring
Sharma Implementation of Unified Communication and analysis of the Toll Fraud Problem
Androulidakis et al. Confidentiality, Integrity, and Availability Threats in PBXs
Patton A case study of Internet Protocol Telephony implementation at United States Coast Guard headquarters

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070511

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
111Z Information provided on other rights and legal means of execution

Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR

Effective date: 20080110

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CHECKPHONE TECHNOLOGIES

17Q First examination report despatched

Effective date: 20140210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140503