SYSTEM FOR INTRUSION DETECTION AND VULNERABILITY ANALYSIS IN A TELECOMMUNICATIONS SIGNALING NETWORK

Abstract: Detecting (206) attempted intrusions in a telecommunications signaling network (202) and assessing (212) the vulnerability of the network to the attempted intrusions. Intrusion rules are applied to received messages in the network in real-time, using a known protocol for the network, in order to detect anomalies tending to indicate an attempted intrusion. In order to assess the vulnerability of the network, the vulnerability rules are applied to rankings of particular parameters relating to elements in the network. The rankings provide an indication of susceptibility of a network element to an attempted intrusion relative to other network elements.

Description: SYSTEM FOR INTRUSION DETECTION AND VULNERABILITY ANALYSIS IN A TELECOMMUNICATIONS SIGNALING NETWORK Technical Field The present invention relates to a system and method for detecting intrusion into, and for assessing the vulnerability of, a telecommunications signaling network. Background Art Telecommunications signaling networks are susceptible to intrusion, meaning that a person may use software or physical means to cause disruption or denial of service within the network. For example, a person may use software operating on a computer in an attempt to seize control of a particular node or link in the network and consequently cause a disruption or denial of service. As another example, a person may attempt to take physical control of an entity in the network, such as a link, resulting in a disruption or denial of service. These intrusions create an undesirable situation for communications service providers and for customers using the network. In particular, the disruptions or denials of service may inconvenience customers and potentially cause a loss in revenue for the communications service provider. When a disruption occurs, a service provider may attempt to locate the disruption and determine a cause of the intrusion. However, in that case the service provider only obtains an indication of the intrusion after it has already caused a disruption and thus cannot anticipate such an intrusion before it occurs. In addition, the server provider may not necessarily know in advance which portions of the network are most susceptible to an intrusion and thus not know how to best monitor the network for potential intrusions. Accordingly, a need exists for detection of intrusion in a telecommunications signaling network, potentially in real-time, and for analysis of the vulnerability of the telecommunications signaling network to an intrusion. Brief Description of the Drawings FIG. 1 is a diagram of an exemplary telecommunications signaling network and associated machine for monitoring the network; FIG. 2 is a diagram of software modules operating on the machine shown in FIG. 1 for implementing an embodiment consistent with the present invention; FIG. 3 is a flow chart of an exemplary process for monitoring a telecommunications signaling network for intrusion detection; FIG. 4 is a flow chart of an exemplary process for determining vulnerability of a telecommunications signaling network to potential intrusion; FIG. 5 is an exemplary user interface for entering set-up information for an intrusion detection process; FIG. 6 is an exemplary user interface for displaying status information related to an intrusion detection process; and FIG. 7 is an exemplary user interface for displaying information related to a vulnerability analysis of a telecommunications signaling network. Disclosure of Invention Apparatus and methods consistent with the present invention provide indications of attempted intrusions in a telecommunications signaling network and the vulnerability of particular elements in the network to attempted intrusions. An apparatus consistent with the present invention receives messages related to communications in a telecommunications signaling network. The apparatus applies intrusion rules to the messages in order to order to detect anomalies in the messages, and it reports an indication of the detected anomalies. Another apparatus consistent with the present invention receives rankings for particular parameters related to elements of a telecommunications signaling network. The apparatus applies vulnerability rules to the rankings in order to determine a likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network, and it reports an indication of the likelihood of the attempted intrusions. A method consistent with the present invention includes receiving messages related to communications in a telecommunications signaling network. Intrusion rules are applied to the messages in order to order to detect anomalies in the messages, and an indication of the detected anomalies is reported. Another method consistent with the present invention includes receiving rankings for particular parameters related to elements of a telecommunications signaling network. Vulnerability rules are applied to the rankings in order to determine a likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network, and an indication of the likelihood of the attempted intrusions is reported. Best Mode for Carrying Out the Invention Apparatus and method consistent with the present invention provide indications of attempted intrusions in a telecommunications signaling network and the vulnerability of particular elements in the network to attempted intrusions. Although both intrusion detection and vulnerability analysis are described, each is typically a separate entity, and the operation of one is not necessarily dependent on the other. Attempted intrusions refers to attempts to disrupt or deny service in the network or to otherwise tamper with the network. Intrusion rules are applied to received messages in the network, typically in real-time and using a known protocol for the network, in order to detect anomalies tending to indicate an attempted intrusion. Messages refers to any particular data element transmitted in the network. For example, standard telecommunications signaling networks use messages in order to provide particular telephone-related services to customers. Intrusion rules refers to any criteria or methodology for detecting the anomalies. Indications of the attempted intrusions may be presented, for example, in a user interface that includes a topological representation of a monitored portion of the network. In order to assess the vulnerability of the network, vulnerability rules are applied to rankings of particular parameters relating to elements in the network. Vulnerability rules refers to any criteria or methodology for processing the rankings to provide indications of likelihood of attempted intrusions with respect to particular elements in the network. Rankings refers to any information providing an indication of susceptibility of a particular network element to an attempted intrusion relative to one or more other network elements. A user interface may be presented in order to receive the rankings and to display indications of the vulnerability of elements in the network. FIG. 1 depicts a data processing system 100 suitable for practicing methods and systems consistent with the present invention. Data processing system 100 includes a machine 101 for intrusion detection and vulnerability analysis, connected to a network 107 such as a private or public telecommunications signaling network. Machine 101 includes a memory 102, a secondary storage device 104, a processor 105 such as a central processing unit, an input device 106, and a display device 103. Memory 102 and secondary storage 104 may store applications and data for execution and use by processor 105. Input device 106 may be used to enter information and commands into machine 101, and display device 103 provides a visual of information in machine 101. Although machine 101 is depicted with various components, one skilled in the art will appreciate that this computer can contain additional or different components. Additionally, although machine 101 is shown connected to network 107, machine 101 may be connected to other networks, including other wide area networks or local area networks. Furthermore, although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer program products or computer-readable media, such as secondary storage devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet; or other forms of RAM or ROM. In addition, the computer-readable media may include instructions for controlling a computer system, such as machine 101, to perform a particular method. FIG. 2 is a diagram of software modules operating on the machine shown in FIG. 1 for implementing an embodiment consistent with the present invention. These modules include modules 200 for intrusion detection and modules 201 for vulnerability analysis of a network 202. Network 202 is a standard Signaling System 7 (SS7) protocol network and illustrates an example of network 107. Other examples of network 107 include an integrated Services Digital Network (ISDN) and an X.25 network. A monitoring analyzer module 204 receives real-time data 203 from network 202. Real-time data 203 may include messages transmitted in an SS7 protocol network or other type of network. Monitoring analyzer 204 packages the data for analysis and forwards it in real-time to a data collector process module 205. Data collector process module 205 parses the received data to remove information from the messages not necessary for intrusion analysis, and it reformats the parsed messages to a consistent format to facilitate intrusion analysis. Data collector process module 205 alternatively may receive preformatted SS7 protocol messages 214 from a test file 208 for use in testing or verifying the intrusion detection capabilities of the system. An intrusion detection process module 206 receives the reformatted messages and performs processing of the messages to detect intrusion. In particular, it applies intrusion detection rules to the messages in order to detect anomalies in the messages or other events tending to indicate an attempt at intrusion into the network or to otherwise tamper with the network. These rules may be stored in memory or in a database such as memory 102 or secondary storage 104, or they may be implemented in hard-wired logic. Examples of these rules are provided in the Appendices. After or during performance of the intrusion detection processing, intrusion detection process 206 outputs the results to an intrusion log 209 that maintains a time-stamped history of the processing in the form of a textual listing, and it outputs the results to a display management process module 207. The textual listing may be printed in hard copy form using a printer connected to machine 101 or may be displayed on display device 103. Display management process module 207 formats the processed data for display within a topology status display 210, which may be displayed by display device 103. Topology status display 210 provides a visual indication of the status of the monitored network and indications of intrusions into the network, and an example of a user interface for the topology status display is described below. A topology database 215 stores information representing a topology or interconnectivity of network 202. Intrusion detection process module 206 and display management process module 207 may access database 215 in order to retrieve the topology information and use it in the processing performed by those modules. In addition, topology database 215 may store the rules used by intrusion detection process module 206. Topology database 215 may correspond to secondary storage 104, and it may be implemented, for example, with a Sybase database. Vulnerability analyzer modules 201 include a vulnerability analysis process module 212 and a display management process module 21 1. Vulnerability analysis process module 212 receives the network topology information from topology database 215, and it applies vulnerability rules to the topology information in order to determine the vulnerability of elements in network 202 to intrusion attempts. Examples of these rules are provided in the Appendices. Vulnerability analysis process module 212 outputs the results of its analysis to a vulnerability log 213, which maintains a time-stamped textual history of the processing in the form of a textual listing, and it also outputs the results to a display management process module 21 1. The textual listing may be printed in hard copy form using a printer connected to machine 101 or may be displayed on display device 103. Display management process module 21 1 operates in a similar manner as module 207. In particular, it receives output results from module 212 and formats the received data for presentation in a user interface by display device 103. An example of a user interface for presenting the vulnerability process data is described below. FIG. 3 is a flow chart of an exemplary process 300 for monitoring a telecommunications signaling network for intrusion detection. Process 300 may be implemented on machine 100 operating under control of intrusion detector modules 200 and module 204. In process 300, the system receives communication messages from the network such as SS7 messages provided by monitoring analyzer module 204 from network 202 (step 301). The system parses and formats the messages using data collector process module 205 (step 302). Intrusion rules are applied by intrusion detection process module 206 to the formatted messages to detect anomalies or other events in the network tending to indicate an attempted intrusion (step 303). The results are reported and potentially displayed by display device 103, using intrusion log 209 or topology status display 210, to provide a visual indication of attempted intrusions into network 202 an potentially the status of the network (step 304). FIG. 4 is a flow chart of an exemplary process 400 for determining vulnerability of a telecommunications signaling network to potential intrusions. Process 400 may be implemented on machine 100 operating under control of vulnerability analyzer modules 201. Process 400 operates by using static rankings processed as input weightings according to particular rules to generate further rankings. The process may be performed iteratively such that the output from one particular processing rule may be input as a ranking to another rule. The boxes in process 400 represent static rankings for particular parameters related to the network, and the circles represent vulnerability rules for processing the rankings. Examples of these vulnerability rules are provided in the Appendices. Examples of parameters providing rankings as particular weightings for processing by vulnerability rules include the following: a percent utilization 401, a number of links 402, a percent traffic external 403, a monitoring 404, a screening 405, a media type 406, a transmission provider 407, a services 41 1, a user service rank 413, a connectivity by service 414, a node occupancy by service 416, and a user SSP ranking 418. These parameters are explained in the Appendices, and different or additional parameters may be used to perform a vulnerability analysis of a telecommunications signaling network. Each parameter produces a static rank, in this example a particular number, to be processed by vulnerability rules. A functional capacity rank rule 408 receives inputs from parameters 401 -404 and produces a result according to the function of rule 408. A security rank rule 409 receives inputs from parameters 404 and 405 and produces a result according to the function of the 409. A physical access rank rule 410 receives inputs from parameters 406 and 407 and produces a result according to the function of rule 410. A functional services rank rule 412 receives as input parameters 41 1 and 404, as well as the output from rule 409, and produces a result according to the function of rule 412. The process continues iteratively as an inherent link ranks rule 420 receives the outputs from rules 408, 409, 410, and 412, and produces a result according to the function of rule 420. Rule 420 provides one input to a most critical links rule 422. The following provides the other input to most critical links rule 422. An SCP criticality rule 415 receives as inputs parameters 413, 414, and 416, and it produces a result according to the function of rule 415. An STP criticality rule 417 receives as inputs parameters 414 and 416, and the output of rule 415, and it produces a result according to the function of rule 417. An SSP criticality rule 419 receives as inputs parameters 414, 416, and 418, and it produces a result according to the function of rule 419. As the process proceeds iteratively, a most critical nodes rule 421 receives the outputs from rules 417 and 419, and it provides the other input to most critical links rule 422. Therefore, as a result of this iterative process, the result of rule 422 provides an indication of the most vulnerable link in the network, and the result of rule 421 provides an indication of the most vulnerable node in the network, the phrase "most vulnerable" meaning that it is the element most likely to be susceptible to an attempted intrusion. FIG. 5 is an exemplary user interface 500 for use in entering set-up information for an intrusion detection process such as process 300. User interface 500 may be displayed on display device 103. User interface 500 includes a first section 501 used to receive threshold values for detection of intrusion, a second section 502 used to identify a point in the network from which the intrusion detection process receives data, and a third section 503 used to save and retrieve set- up information so that a user need not repeatedly enter the same set-up information. A user may enter relevant information into sections 501 and 502 using input device 106, and section 502 identifies where data 203 originates in network 202 and thus provides a reference point for performing an intrusion detection process. The location where the data originates may typically be changed so that a user may monitor the network from varying locations, and the location may be selected by using, for example, results of a vulnerability analysis. FIG. 6 is an exemplary user interface 600 for displaying status information related to intrusion detection such as information produced by process 300. User interface 600 may be displayed on display device 103. User interface 600 includes a main section 601 for displaying a topological representation of a portion of the network and including information indicative of various conditions in the network. These conditions may provide an indication of attempted intrusions in the network. A displayed node 602 corresponds to the node identified in section 502 of user interface 500, and node 602 represents the node from which the system receives data. Other displayed nodes 603 and 604 represent nodes located one link away from node 602 in the monitored network. Each of the displayed nodes includes associated point codes and link information, displayed adjacent the corresponding node. Section 601 also displays lines between the nodes, and the lines represent the corresponding links. When a user selects a particular displayed node the system displays a section 605 for presenting node information relating to the selected node. The node information may include a ranking determined by a vulnerability analysis. When a user selects a displayed link, the system displays a section 606 for presenting static information relating to the selected link, including link attributes, an anomaly history, and a linkset selection label. The anomaly history may correspond to history log 209. The user may select a particular node or link by, for example, using a cursor-control device to "click on" the particular node or link. The system may optionally present the links in different colors to provide indications of varying conditions. For example, it may present the links using the following colors: green for a normal condition; yellow for a minor condition; orange for a major condition; red for a critical condition; and gray to indicate that the link is not monitored. The various conditions may be determined by the detected anomalies from module 206 and particular predefined thresholds, which are further explained in the Appendices. FIG. 7 is an exemplary user interface 700 for displaying information related to a vulnerability analysis such as process 400. User interface 700 may be displayed on display device 103. User interface 700 includes various sections in which a user may enter rankings for use by the rules in process 400. For example, it includes a section 701 to receive values for a services ranking and a section 702 to receives values for an SSP ranking. A user may select an appropriate tab 703 on a menu bar to view the corresponding section 701 and 702. User interface 700 may include additional tabs 703 and sections for receiving information concerning other rankings. The accompanying Appendices, which are incorporated in and constitute a part of this specification, include the following: Appendix A includes a system overview for an exemplary intrusion detection process and vulnerability analysis; Appendix B includes a software user's manual for an exemplary intrusion detection process and vulnerability analysis; Appendix C includes a software design document for an exemplary intrusion detection process and vulnerability analysis; Appendix D includes a description of exemplary vulnerability analysis attributes and algorithm, including vulnerability rules; and Appendix E includes a description of exemplary intrusion detection algorithms including intrusion rules. APPENDIX A SYSTEM OVERVIEW TABLE OF CONTENTS 1. SCOPE 3 l . l SYSTEM OVERVIEW 3 1.2.1 Vulnerability Analysis Tool. 3 1.2.2 Intrusion Detection Tool J 1.2.3 Network Topology Database 4 2. REFERENCES 4 3. INTRUSION DETECTION TOOL 4 3.1 CONCEPT OF OPERATION 4 3.1.2 Concept of Execution 4 3.1.3 Interfaces 5 3.1.3.1 Graphical User Interface (GUI) 5 3.1.4 Data Collector 6 3.1.4.1 Concept of Execution 6 3.1.4.3 Test Files 7 3.1.5 Network Topology Database 8 4. VULNERABILITY ANALYZER. 8 4.1 CONCEPT OF EXECUTION 8 4.1.1 Node Evaluation 9 4.1.2 Link Evaluation 9 4.2 INTERFACES 10 4.2.1 User Interface 10 4.2.1.1 Control and configuration 10 4.2.1.2 Analysis Results I I 4.2.2 Network Topology Database 1 1 5. NETWORK TOPOLOGY DATABASE 11 5.1 CONCEPT OF EXECUTION 1 1 5.1.2 Interfaces 1 1 5.1.2.1 GUI/Intrusion Detector 12 5.1.2.2 Vulnerability Analyzer 12 O 00/0731 APPENDIX A SYSTEM OVERVIEW LIST OF FIGURES FIGURE 3- 1 - INTRUSION DETECTOR CONTEXT DIAGRAM 5 FIGURE 2 DATA COLLECTOR PATH 7 FIGURE 3 VULNERABILITY ANALYSIS LOGIC FLOW 9 FIGURE 4-4 - VULNERABILITY ANALYZER CONTEXT DIAGRAM 10 FIGURE 5-5 - NETWORK TOPOLOGY DATABASE DOMAIN DIAGRAM 12 APPENDIX A SYSTEM OVERVIEW 1. Scope 1.1 System Overview Signaling System 7 (SS7) is the Control Service Layer of the Public Switched Telephone Network (PSTN ) therefore, an attack on the SS7 network can cause PSTN service disruption denial without undertaking a physical attack An attack on the SS7 network can actually be accomplished through the manipulation and exploitation of the SS7 message protocol itself by means of message insertion onto the network signaling links. The SS7 network is inherently vulnerable to such attacks for two (of several ) reasons the SS7 protocol does not include Security and SS7 was built for robustness and thus, is very forgiving t o anomalous states The System includes two tools an SS7 Intrusion Detection Tool and a Vulnerability Analysis Tool The operational concept is that the intrusions would be well organized with the intent of service disrup t ion service denial through insertion of SS7 messages into the SS7 message traffic stream Due to the equal access' provision of the 1996 Telecommunicanons Reform Act, concern within the PSTN indus t rv has increased over the fear of new and unknown earners entering the market. These unknown entities pose a new threat to the SS7 network since they can demand full interconnection capabilities into the exis t ing SS7 network while providing only limited visibility into their operations. Hence a modestly funded operator could gam full access the SS7 network for illicit purposes. 1.1.1 Vulnerability Analysis Tool The purpose of the System SS7 Network Vulnerability Analysis Tool is to allow the user to determine which network elements in the SS7 Network are most vulnerable to an SS7 Message Insertion attack designed for Service Disrupnon/ Denial As the analysis relates to Intrusion Detection, the results are used to indicate where Intrusion Detection resources should be applied in the Network based on the evaluated preferences supplied by the operator The Vulnerability Analysis Tool uses an SS7 Network Topology daubase which contains a set of attributes describing all of the SS7 Network Elements (links and nodes) These Network Element attributes are evaluated against a set of attribute weighting factors and against formulas relating combinations of attributes. The user has the ability to modify attribute weightings to tailor the analysis for specific preferences. 1.1.2 Intrusion Detection Tool The real-time SS7 Intrusion Detection Tool provides SS7 link monitoring and analysis of SS7 message traffic for anomalous events which indicate possible intrusion mto the message stream. The Intrusion Detecnon algoπthms apply rules based logic and event thresholding against the message traffic stream. The logic evaluates message sequence and timing irregulaπnes, inconsistent parameter values, and exceeded thresholds of message type occurrences The User Interface includes of a Network Topology display of the monitored network nodes and corresponding signaling linksets. The linkset status is indicated to the user by coloring the link icons corresponding to the seventy of the detected anomaly The detected anomaly text is displayed to the user in an Alarm Status wmdow APPENDIX A SYSTEM OVERVIEW 1.1 J Network Topology Database One of t he goals of the system program has been to bas e rt v , . 2. References The follow i ng documents provide background informa ti on and are i ncoφorated herein by reference DOCUMENT No. TITLE [ 1 ] ANSI T1 1 1 1-1992 S i gnal i ng System Number 7, Message Transfer Part ( MTP ), Amer i can Nat i onal Standards Institute Inc , 1992 [2] ANSI T1 1 13- 1995 S i gnal i ng System Number 7, ISDN User Par t (ISUP), Ameπcan Nat i onal Standards Institute Inc , 1995 3. Intrusion Detection Tool 3.1 Concept of Operation md i ca t ed to t he user by color i ng t he links on the topolog,c7n p § m0m0Te D " ee * d 3.1.1 Concept of Execution The Intrus i on Detector analyzes each new messaee r ec ^ A The follow i ng cond i t i ons are tested at different levels of the protocol: a) ISDN User Part (ISUP) messages (See reference 161) 0 Improper RELEASE «) proper BLOCKING and/or CIRCUIT GROUP BLOCKINr '" Improper RESET and/or CIRCUIT GROUP RESET ■ v) Improper FACILITY DEACTIVATED v) Improper UNIDENTIFIED CIRCUIT IDENTIPICATON CODE b) 0/07312 APPENDIX A SYSTEM OVERVIEW in) Improper SIGNALING ROUTE MANAGEMENT (Transfer-Prohibited and Transfer-Restricted only) Whether there was an anomaly detected or not, the current SS7 message is finally stored, to be used in t he next anomaly test 3.1.2 Interfaces The context diagram, shown in Figure 3- 1, identifies the multiple subsystem processes The following subsections address these interfaces, with the excepnon of the Data Collector input Figure 3-1 - Intrusion Detector Context Diagram 3.1.2.1 Graphical User Interface (GUI) The GUI is the mechanism used to allow the system operator to configure the system, start and stop operations and provides the message analysis results on a topological status display The design reflects a network management type display to the user As with such systems, a nerwork topology display depicts the network elements (m this case SS7 nodes and links). Upon initialization of this process, the GUI retπeves configuration and network topology mformanon from the corresponding databases to construct a view of the local SS7 network infrastructure (nodes, signal links, etc ), relative to the link being monitored. This view is used to communicate to the operator the current state of each link of that local network All direct links, to the link being monitored, are represented by a dashed line The link being monitored is represented by a solid line to differennate itself Nerwork status is displayed by coloring the links Node informanon and link status windows provide greater detail of the network 3.1.2.1.1 Control and configuration APPENDIX A SYSTEM OVERVIEW In response to a control message from the GUI subsystem, the Intrusion Detector accepts the following information from the GUI message queue for configuration and control a) START operation b) STOP operation c) PAUSE operation d) Send Status Statistic data e) Threshold and parameter values for algoπthms 3.1.2.1.2 Status and Statistics When any of the predefined anomaly rules or a combination of these rules are sansfied (indicating an anomaly), a message is sent to the GUI mput queue for display The message will indicate the following information about the anomaly a) the SS7 message (protocol analyzer output format) b) a time stamp generated by the Data Collector c) the rule(s) fired that caused the anomaly repoπ d) the link affected and the color code indicating the anomaly ranking (GREEN. YELLOW. ORANGE or RED) as displayed to the operator 3.1J Data Collector The Data Collector accepts SS7 message data from both a protocol analyzer and a test file source It is a real-time operation, which is compπsed of thee primary funcnons: the Message Parser, the input stream multiplexer and the output message queue. The complexity of this subsystem is minimal, however, partitioning of the collection functionality enables the possibility of porting it to another processor, if the performance is required. Also, it isolates the impact to the other subsystems if there are hardware changes to the front-end collecπon method (e g., change of protocol analyzer). 3.1.3.1 Concept of Execution The Data Collector can manage inputs from a live message stream from a protocol analyzer source, or from a test file, or both. When accepting inputs from a protocol analyzer, the Message Parser is invoked to reformat the SS7 data into a condensed format needed by the Intrusion Detector process. When live data is combmed with test file data, the test file data must be multiplexed into the hve data stream. This combined mode is useful smce it allows injecnon of test SS7 mtrusion messages against a background of live nommal SS7 messages. In this manner, the Intrusion Detector can be tested against real message traffic (and message traffic volume) and still be able to test specific mtrusion scenaπos without the need to inject anomalies onto the actual network. APPENDIX A SYSTEM OVERVIEW Figure 2 Data Collector Path 3.1 -3.1.1 Protocol Analyzer The protocol anaiyzer uses an IXET Turbo- with an MSU Forwarding option. The MSU Forwarding feature provides TCP P forwarding capability of the collected SS7 Message Signal Units (MSUs). The Turbo-7 protocol analyzer outputs the SS7 as received in time sequence from all of the monitored SS" links. Each message has a header including of the port and timestamp followed by the raw SS7 message The Turbo-" outmessage format is shown in the Software User's Manual. 3.1-3.1.2 Message Parser The Message Parser operates as a go-between from the protocol analyzer and the Intrusion Detector process. The input from the protocol analyzer is received over a TCP/IP socket interface. Each message is analyzed and reformatted by message type, retaining only those parameters required by the Intrusion Detector process. If addinonaJ message types and/or message parameters are desired or if different message ;ollecnon hardware is used, the Message Parser can be modified without impact to follow on processes. 3.1.3.2 Test Files The test files allow the Intrusion detector to run in a testing / sunulanon configuration when it is not desired or when it s impractical to have a live nerwork connection. The test file is simply a concatenated set of SS 7 messages ui the data format output by the Message Parser. The messages can represent data from any protocol analyzer poπ with any values desired in the data fields. Therefore, test files can be set up to emulate normal SS7 network traffic on a variety of signaling links with embedded anomalies. Although the test files use data formats output by the Message Parser, there is one distmcπon: the timestamp field. The test file αmestamp field represents a time delay vice an absolute time. This convenπon was established ui order to accommodate both a real time aspect to the test data timing and to facilitate test file message injecnon into the live data stream. Test file formats are descπbed in the Input MSU Test File secnon of the Software User's Manual. APPENDIX A SYSTEM OVERVIEW 3.1.4 Network Topology Database The Nerwork Topology Database provides the intrusion detection algoπthms with the required relevant infrastructure data of the SS7 network. The network topology mformation and its format, is descπbed in the Software User's Manual The topology data is used by the Intrusion Detector to perform several types of legitimacy checks of the message point codes Basically, checks are made to ensure that the messages are oπginating from legitimate locations and are arπving over the proper routes These checks are based on message type 4. Vulnerability Analyzer The primary responsibility of the Vulnerability Analyzer is to evaluate an SS7 infrastructure data and determine the locations most vulnerable to SS7 nerwork mtrusion. The goal was to produce a tool that evaluated the nerwork vulnerability in the same manner as a network analyst evaluates the network To demonstrate the ability to evaluate different operational pπoπties, the user is able to designate certain evaluation parameters 4.1 Concept of Execution In response to a START message sent to its message queue from the User Interface, the analyzer retrieves network topology mformation from the database. These Network Element attributes are evaluated against a set of attnbute weighting factors and against formulas relatmg combmations of attributes. The attributes are stored in the topology database whereas the rankings are stored in a configuration file (Refer to the Software Users Manual for descπptions.) The user has the ability to modify attribute rankings to tailor the analysis for specific evaluation preferences such as: • select whether to evaluate Advanced Intelligent Network (A N) services or Plain Old Telephone Service (POTS) • when AIN is selected, rank the AIN services relative to each other to indicate the servιce(s) that have greater importance to the evaluation • select specific SSP locations and rank those locations higher than nominal to indicate customers ) locations that may have greater importance to the evaluation (such as government or business groups) The evaluation formulas have been implemented within the software. Below is an outline of the analysis logic that is performed. Every attribute of every node and link within the network is evaluated. A base score of each node and link is established and is subsequently modified at each stage of the evaluation T e influence to the vulnerability score of each attribute is determined by the value of the attribute and on the importance ranking of that attribute. The rankings act as a weighting applied to the attribute value within the formula and control how much of a modifier of the attnbute to the overall vulnerability score. As each node and link is evaluated, combmations of attnbutes are also evaluated and ranked. The cnteπa for determining most cπtical node is that which attains a score of 10 or above. If more than one node is identified as exceeding a score of 10 than each node is listed with the corresponding list of vulnerable links to that node. (This is due to determinmg the number of hops to the cπtical node from each link) O APPENDIX A SYSTEM OVERVIEW Figure 3: Vulnerability Analysis Logic Flow 4.1.1 Node Evaluation The nodes are pπmaπly evaluated to determme their cππcality to the overall nerwork operanons and thus desirability to attack In the case of POTS evaluaπon. each STP pair is evaluated based on the number of SSPs directly connected to the STP and the volume of the SS7 traffic routed through the STPs For AIN cases, the evaluation is more complicated smce the network becomes hierarchical with parent- child relationships formed among the STPs organized by the routing to each specific service Therefore, node cππcality becomes a funcπon of not only the number and traffic from directly connected SSPs but also the number of SSPs indirectly connected that also gam access to the AIN service through the STP Following the cπnca ty evaluanon, certain inherent vulnerability attnbutes are also evaluated, such as • whethβT a node is owned or operated by a non-GTE entity is evaluated has the vulnerability increased by some measure. The ranking is applied by company • whether the node is occupied by personnel and by how many (physical control) • how many backup nodes are available for auto rerouting. 4.1.2 Link Evaluation The overall evaluaπon of the links is in effoπ to assess the inherent vulnerability to inserting messages onto the links to gam access to the cπncal nodes However, the links are also evaluated on the cππcality attnbutes related to traffic load and by service Therefore, the user service rankings also influence the link vulnerability This funcπonal capacity ranking is used throughout the evaluanon to modify the other APPENDIX A SYSTEM OVERVIEW i nheren t vulnerab i hty attr i bute scores At the end of the inherent link vulnerab.l. tv , n ,ι . . mod i fied one las t ti me by the number of hops the link ,s from t he cπtica not Z « , * "" grea t er number of hops from me arget e less . e,y me inseπed ^^ ffi^ ^ The ma j or i ty of t he l i nk at t ributes relate to inherent vulnerabilities of the l i nks to SS7 m«« a i med at affect i ng the cπncal nodes. Some examples are listed below ^ mSertl0nS ' l∞ K l£. 3ddreSSeS "" C ° nCCPt ° f a PhyS,Cal * P t ° a n and *" — c accessibility of • whe t her t he transmission faci πes are operated bv a n on f . TF ,„,,„, . « . • amount message traffic oπgmatmg external to the GTE ne t work an H th^ - Λ , unknown sources. d * erefore c °™ng from potentially • whether STP screenmg is voked and the robustness of the screen i ng log i c 4.2 Interfaces The con t ext diagram, shown in Figure 4-4, idennfies t he mul t [ P r t „~ A _ . followmg subsections address these interfaces. P "^ by ώ ' S Subsystem ™ e Network Topology Database Figure 4-4 - Vulnerability Analyzer Context Diagram 4.2.1 User Interface The User Interface i s t he mechanism used for control and receive analysis results for d i splay 4.2.1.1 Control and configuration In response to a con t rol message from the GUI subsystem, the Vulnerability Analyzer accepts t he followmg l nformaπon from the GUI message queue for con iguranon and control: a) START operaπon b) STOP operaπon c) PAUSE operanon 00/07312 APPENDIX A SYSTEM OVERVIEW d) Send Status/Statistic data e) Threshold and parameter values for algorithms 4.2.1.2 Analysis Results Upon completion of the vulnerability analysis, the textual results file is displayed to the user in a scrollable window The POTS case lists the cnπcal node(s) followed by the most vulnerable links to that node The AIN case also indicates the Most Cπncal SCP 4.2.2 Network Topology Database The Network Topology Database provides the Vulnerability Analyzer algoπthms with the required relevant infrastructure data of the SS7 network. In addinon to the topology data requu-ed by the Intrusion Detector, the Vulnerability Analyzer requires many add onal attnbutes assigned to the nodes and links. Routmg in the GTE network for local STPs to regional STPs changes dependmg on the AIN service being accessed This data had to be deπved from drawmgs of the network topology and requu-ed manual analysis and database algoπthm≤ to deπve the proper link routes. 5. Nerwork Topology Database The Network Topology Database is the persistent storage for the GTE SS7 network infrastructure. It contains all the nodal and link mformanon requu-ed to implement both the Intrusion Detector and the Vulnerability Analyzer processes. 5.1 Concept of Execution In response to a client process, the database provides the means, first, of determinmg the data set being requested by the client, and second, to send the data set to the proper process input message queue. 5.1.1 Interfaces The context diagram, shown in Figure 5-5, idennfies the mulπple interfaces used by this subsystem. The followmg subsections address these interfaces. 00/07312 APPENDIX A SYSTEM OVERVIEW Figure 5-5 - Network Topology Database Domain Diagram 5.1.1.1 GUI/Intrusion Detector The GUI and the Intrusion Detector will use the same mformanon set from the database. The GUI extracts the mformanon needed to construct the operator's view of the local SS7 network, used to display the realtime conclusions of the Intrusion Detector. The Intrusion Detector uses the link-node relaπonships to accomplish its algoπthms (e.g., determme nearest neighbor, etc.). 5.1.1.2 Vulnerability Analyzer The Vulnerability Analyzer requires a different lnformaπon set from the of the Intrusion Detector. It's requirements clude not only link-node relaπonships, but also, link media type, mode supplier, SS7 services provided and so on. APPENDIX B SOFTWARE USER'S MANUAL TABLE OF CONTENTS 1. SCOPE S 1 1 SYSTEM OVERVIEW 5 1 2 DOCUMENT OVERVIEW 5 2. REFERENCES 5 3. (TJ) SYSTEM REQUIREMENTS 5 4. SYSTEM INSTALLATION AND ENVIRONMENT SETUP 6 5. (U) INTRLSION DETECTOR EXECUTION PROCEDURE 6 5 1 INITIALIZATION \ Ό STARTUP 5 2 L SER INPUTS AND CONTROL 5 2 1 File Management 5 2 2 Threshold Management g 5 2 3 View Control g 5 2 4 Start Stop g 5 2 5 Termination g 5 3 SYSTEM INPUTS 9 5 3 1 Protocol Analyzer g 5 3 2 Input MSU Test File g 5 3 3 Topology Database / 5 3 ■> -elp Files / 5 4 OUTPUTS l 5 4 1 Operator s Topology Display / 5 4 2 Intrusion Log File / 5 4 2 1 Anomaly Messages 1 1 5 4 3 (U) Operational Error and Warning Messages / <5 6. (U VULNERABILITY ANALYZER EXECUTION PROCEDURE 19 6 1 INITIALIZATION AND STARTUP 19 6 2 USER INPUTS AND CONTROL 1 6 2 I File Management 20 6 2 1 2 File Retrieve 20 6 2 2 Rankings Management 22 6 2 3 Controls 22 6 2 4 Termination 22 6 3 SYSTEM INPUTS 22 6 3 1 Topology Database 22 6 3 2 Help Files 22 6 4 OUTPUTS 23 6 4 1 Operator s Vulnerability Analysis Display and Analysis Log 23 6 4 2 (U) Operational Error and Warning Messages 23 7. (TJ) NOTES 25 7 l (U) ABBREVIATIONS AND ACRONYMS 25 APPENDIX B SOFTWARE USER'S MANUAL TABLE OF CONTENTS TOPOLOGY D ATABASE SCHEMA AND PROCEDURES 26 APPENDIX B SOFTWARE USER'S MANUAL LIST OF FIGURES FIGURE 5- 1 - TOP-LEV EL GUI ENVIRONMENT 7 FIGURE 6- 1 - VULNERABILITY ANALYSIS TOP LEVEL GUI 20 APPENDIX B SOFTWARE USER'S MANUAL LIST OF TABLES TABLE 3- 1 - S\ STEM REQUIREMENTS 5 TABLE 5- 1 - INTRUSION DETECTION ADJUSTABLE PARAMETERS 8 TABLE 5-2 - [NET MSU RECORD FORMAT 9 TABLE 5-3 - INPUT TEST FILE MSU FORMATS 9 TABLE 5-4 - OUTPUT ANOMALY MESSAGES 12 TABLE 5-5 - OPERATIONAL ERROR AND WARNING MESSAGES 16 TABLE 6- 1 - VULNERABILITY CONFIGURATION PARAMETERS 20 TABLE 6-2 - VULNERABILITY ADJUSTABLE RANKJNGS 22 TABLE 6-3 - VULNERABILITY OPERATIONAL ERROR AND WARNING MESSAGES 23 TABLE 6-4 - VULNERABILITY FAULT LOG MESSAGES 24 TABLE 7- 1 - NODES TABLE DESCRIPTION 26 TABLE " '-2 - NODE TYPES 26 T ABLE 7-3 - LΓNKS TABLE DESCRJPTION 2 " T BLE "-4 - LINK SERV ICES TABLE DESCRJPTION 2S TABLE ^-5 - SCP TABLE DESCRIPTION 2S TABLE "-6 - SCP SERVICES TABLE DESCRJPTION 29 TABLE 7-7 - STP TABLE DESCRIPTION 29 TABLE 7-8 - STP SERV ICES TABLE DESCRIPTION 29 TABLE 7-9 - SSP TABLE DESCRIPTION Ό TABLE 7- 10 - SSP SERVICE TABLE DESCRIPTION :o TABLE 7- 1 1 - NETWORK CODES DESCRIPTION 30 TABLE 7- 12 - TRUNK NEIGHBOR DESCRIPTION 30 TABLE 7- 13 - LOCATIONS TABLE DESCRJPTION 30 APPENDIX B SOFTWARE USER'S MANUAL 1. Scope 1.1 System Overview The System Network and Signal Infrastructure Vulnerability Analysis and Intrusion Detection System (hereafter referred to as the system) is a software application capable of providing real-time protection to the U S telecommunications Signaling System No 7 (SS7) infrastructure The goal of the system is to perform the following a) Determine the vulnerability of the SS7 network based on its topology and identify the nerwork elements most vulnerable to intrusion b) Detect intrusions to SS7 links being monitored c) Provide a User Interface for operator control and status display in support of the above processes The system uses a Sun Microsystems s SPARC-20 platform, running the Solans 2 5 operating system 1.2 Document Overview This Software Users Manual (SUM) descπbes the procedures required for using the System prototype This system software includes two (2) independent tools a) Intrusion Detector (including SS7 Monitoring, User Interface, and Anomaly Detection processes) b) Vulnerability Analyzer (User Interface, and Vulnerability Analysis processes) 2. References The documents identified below provide background information and are incoφorated herein by reference DOCUMENT No. TITLE [ 1 ] ISO 9001 International Organization of Standards 9001 [2] ANSI Tl 1 1 1-1996 Signaling System Number 7, Message Transfer Part (MTP), American National Standards Institute Inc , 1996 [3] ANSI Tl 1 12-1996 Signaling System Number 7, Signaling Connecπon Control Part (SCCP), American National Standards Institute Inc , 1996 [4] A SI T1 113-1995 Signaling System Number 7, Integrated Services Digital Network User Part (ISDN), American National Standards Institute Inc , 1995 3. (U) System Requirements This section descπbes the workstanon' s configuration and system requirements necessary for the System prototype These requirements are shown below APPENDIX B SOFTWARE USER'S MANUAL Name Description PLATFORM System RAM 64Meg or greater COTS Software Sybase Server Version 10.02 Sybase Open Version 1 1.1 Client ICS OSF Motif Version 1.2.4 4. System Installation and Environment Setup This secnon descπbes the mstallation and environment setup procedures necessary to get staπed with t he application. The following steps are required to run the system: a) Modify the environment by adding the followmg lines to your .cshrc file. After modificanon. perform the required source .cshrc to implement these changes. i) setenv SYSTEMHOME pathname, where pathname defines the path of the System home directory. II) setenv INTR_CONπG $(SYSTEMHOME)/confιg, where $(SYSTEMHOME)/confιg defines the path of the System configuration subdirectory, in) setenv XENVIRONMENT $INTR_CONFIG/guι.res, where $INTR_CONFIG/gui.res defines the configuranon file used for the X window environment. IV) setenv MOTTFHOlME /Opr/Motιfl24/usr, where pathname defines the path of the Motif compile-rime libraπes directory. v) setenv SYBASE pathname, where pathname defines the path of the Sybase database utilities (/cots/sybase) vi) setenv DSQUERY SYSTEM vii) setenv LD_LIBRARY_PATH $ {LD_LBRARY_PATH} :SMOTUHOME lib/Xl l : usr/lib/Xl l ::usr/lang lib: usrli b:$OPENWTNHOME/lib: :$OPENWINHOME/lib: usr/lib:SMOTIFHOME/Tib/X 1 1. usr/dt/lib vin) setenv PATH S {PATH} :$SYBASE/bιn b) INSTALLATION: Move to this directory and extract TAR format tape: a) mkdir pathname, where pathname defines the path of the System home directory (as defined by SYSTEMHOME). b) cd SSYSTEMHOME. to move to this directory for lnstallanon. c) tar xvf /dev/rmtvO, to extract the tar file to the current directory. 5. (U Intrusion Detector Execution Procedure This secnon descnbes the information and instructions necessary for user interacnon with the system Intrusion Detector. It gives the step-by-step procedures for executing the software and identifies the options available to the user. APPENDIX B SOFTWARE USER'S MANUAL 5.1 Initialization and Startup This section describes the initialization and startup procedures necessary to execute the software To launch the Intrusion Detector executable, type IntrusionDetector on the command line of your UNIX shell Upon startup of the System's Intrusion Detector application, the following events are performed a) The required environment variables are retrieved from the system These vanables are defined in section 4 b) The application retrieves its default configuration from the startup inmalization file "ιnιt_config lntr" This file is stored ul the directory SYSTEMHOME/coπfig Once the initialization of the application has completed, its GUI is displayed and ready for user interaction The user must configure the tool, via the menu options or loading a previously saved configuration file 5.2 User Inputs and Control The following sections descπbe the user inputs and control for the system software On-line help is provided within the application via the Help option The user's primary control is in the form of a Graphical User Interface (GUI) shown in Figure 5- 1 The GUI is provided to service the followmg operator control Figure 5-1- Top-Level GUI Environment 5.2.1 File Management The application provides the capability to save and retrieve both configuration and output log files via the GUI .APPENDIX B SOFTWARE USER'S MANUAL 5.2.2 Threshold Management The application provides the capability to view and modify all adjustable parameters required by the intrusion detection algoπthms for maximum flexibility and expansion The followmg list descπbes each of these GUI adjustable parameters Table 5-1 - Intrusion Detection Adjustable Parameters APPENDIX B SOFTWARE USER'S MANUAL Threshold Name Description 5.2.3 View Control The applicanon provides the capability to enter monitor poιnt(s) to which the protocol analyzer is connec t ed This data is used to define the local topology view displayed to the user. The monitor points are entered using the "View | Monitor Point Selecnon" menu opπon provided by the GUI 5.2.4 Start/Stop The applicanon provides the capability to staπ and stop processmg of the applicanon usmg the "Control S t aπ" and the "Control ι Stop" GUT menu options, respecnvely In order to staπ execunon, valid monitoring points must be loaded, either from the GUI or by loading a previously stored configuranon file An eπor is displayed if this condition is not met The generation and display of the local topology view immediately follows. 5.2.5 Termination The applicanon provides the capability to terminate execution of the application usmg the 'File Exit" menu option provided by the GUT 5.3 System Inputs The followmg sections descnbe the system mputs to the system and are required for the proper operanon of the applicanon 5.3.1 Protocol Analyzer The protocol analyzer selected for the system is the INET Turbo-7 protocol analyzer. Up to four (4) SS7 lmks can be monitored at one time by this device. The message format, shown m Table 5-2, is expected from the analyzer via the TCP IP poπ. Table 5-2 - LNET MSU Record Format 5.3.2 Input MSU Test File This secnon descπbes the MSU formats used by the input test file. The test file injects the test MSU mto the real-time path for the purpose of diagnosncs. Table 5-3 details the different formats expected for the different SS7 MSU types. Table 5-3 - Input Test File MSU Formats MSU Type MSU Function MSU Data Fields Comments APPENDIX B SOFTWARE USER'S MANUAL NOT FURNISHED UPON FILING NO PRESENT ADO(A) EN EL MOMENTO DE LA PRESENT ACION NON SOUMIS(E) AU MOMENT DU DEPOT APPENDIX B SOFTWARE USER'S MANUAL occurrence of an anomaly, the event and background information is logged and stored in the Intrusion Detection log Table 5-4 - Output Anomaly Messages Anomaly SS7 Protocol Code Description of Anomaly Effected 100 LINK NEAREST NEIGHBOR FAILURE - A SS7 MTP message was received where MTP the OPC and DPC did not correspond to the required link. 101 EXCESSIVE CHANGEOVER - The occurrences of CHANGEOVER messages to a MTP link exceeded the operator's adjustable threshold. 102 EXCESSIVE EMERGENCY CHANGEOVER - The occurrences of EMERGENCY MTP CHANGEOVER messages to a link exceeded the operator's adjustable threshold. 103 CHANGEOVER REQUEST TIMEOUT - A timeout has been detected after a MTP CHANGEOVER message was detected on a monitored link. NO corresponding acknowledgment was detected. 104 EXCESSIVE NODE TRANSFER PROHIBITS - The occurrences of node TRANSFER MTP PROHIBIT messages to a link exceeded the operator's adjustable threshold. 105 EXCESSIVE CLUSTER TRANSFER PROHIBITS - The occurrences of cluster MTP TRANSFER PROHIBIT messages to a link exceeded the operator's ad j ustable threshold. 106 EXCESSIVE NODE TRANSFER RESTRICTS - The occurrences of node TRANSFER i MTP RESTRICT messages to a l nk exceeded the operator's adjustable threshold. 107 EXCESSIVE CLUSTER TRANSFER RESTRICTS - The occurrences of cluster MTP TRANSFER RESTRICT messages to a link exceeded the operator's adjustable threshold. 108 EXCESSIVE NODE TRANSFER CONTROL - The occurrences of node TRANSFER MTP CONTROL messages to a link exceeded the operator's adjustable threshold. 109 EXCESSIVE CLUSTER TRANSFER CONTROL - The occurrences of cluster MTP TRANSFER CONTROL messages to a link exceeded the operator's adjustable threshold. 1 10 EXCESSIVE LINK INHIBITS - The occurrences of node LINK INHIBIT messages to MTP a link exceeded the operator's adjustable threshold. 1 1 1 INVALID SLC INHIBIT PATTERN - The pattern of inhibit SLCs observed on a link MTP was not random and exceeded the operator's adjustable threshold. π: INVALID CHANGEOVER - A CHANGEOVER message was received while the same monitored link was already in a CHANGEOVER state. 1 13 INVALID CHANGEOVER ACKNOWLEDGE • A CHANGEOVER message was MTP received with NO corresponding CHANGEOVER message detected on the same monitored link. 1 14 INVALID DIRECTION ON CHANGEOVER ACKNOWLEDGE - A CHANGEOVER MTP ACKNOWLEDGE message was received from the wrong direction reladve to the last corresponding MSU message. 1 15 INVALID EMERGENCY CHANGEOVER . An EMERGENCY CHANGEOVER message was received while the same monitored link was already in a CHANGEOVER state. 1 16 INVALID EMERGENCY CHANGEOVER ACKNOWLEDGE - An EMERGENCY MTP CHANGEOVER message was received with NO corresponding CHANGEOVER message detected on me same monitored link. INVALID DIRECTION ON EMERGENCY CHANGEOVER ACKNOWLEDGE - .An MTP APPENDIX B SOFTWARE USER'S MANUAL 36 SUBSTITUTE SHEET CRULE 26) APPENDIX B SOFTWARE USER'S MANUAL APPENDIX B SOFTWARE USER'S MANUAL APPENDIX B SOFTWARE USER'S MANUAL 5.4.3 (U) Operational Error and Warning Messages This secnon idennfies all error messages output by the system, the meaning of each error message, and the acnon to be taken when each message appears. These messages are displayed to the user via the GUI In addmon, faults are logged by the each individual process into its correspondmg flat file. Each fault log can be enabled/disabled by ώe system configuranon file previously loaded. Table 5-5 - Operational Error and Warning Messages .APPENDIX B SOFTWARE USER'S MANUAL APPENDIX B SOFTWARE USER'S MANUAL APPENDIX B SOFTWARE USER'S MANUAL 6. (U) Vulnerability Analyzer Execution Procedure This section descπbes the mformation and instrucftons necessary for user interaction with the System Vulnerability Analyzer It gives the step-by-step procedures for executing the software and identifies the options available to the user 6.1 Initialization and Startup This section descπbes the ininalization and startup procedures necessary to execute the software To launch the Vulnerability Analyzer executable, type Vulnerability Analysis on the command line of your UNIX shell Upon startup of the System's Vulnerability Analyzer applicanon, the followmg events are performed a) The required environment vaπables are retπeved from the system These vaπables are defined in section 4 b) The application retπeves its default configuranon from the startup lninalizaπon file "ιnιt_config vtiln" This file is stored in the directory SYSTEMHOME/config Once the ininalization of the application has completed, its GUI is displayed and ready for user interaction The user must configure the tool, via the menu options or loading a previously saved configuration file 6.2 User Inputs and Control The following sections descnbe the user inputs and control for this applicanon On-line help is provided within the applicanon via the Help opnon The user's primary control is in the form of a Graphical User Interface (GUI) shown in Figure 4 2 The GUI is provided to service the followmg operator control APPENDIX B SOFTWARE USER'S MANUAL Figure 6-1 - Vulnerability Analysis Top Level GUI 6.2.1 File Management The applicanon provides the capability to save and remeve both configuranon and analysis result files via the GUI under the File selecnon 6.2.1.1 File Save The Save selection allows the user to save the current analysis results to a user specified file name Also the user may select to save the current configuranon to a user specified file name for later retrieval 6.2.1.2 File Retrieve The remeve selecnon allows the user to remeve an analysis results log or to remeve an existing configuranon file When the Remeve / Configuranon is selected, the File window appears. The user may then enter a filter selection and click on the Filter burton to narrow his selecnon, and click on a file name in the files secnon The selected file is displayed under Selecnon and the user chcks on OK to load the file in memory In order to view the loaded configuranon file, the user must select Remeve Analysis Note that the file is not editable via the GUI The parameters contained in the configuranon file are descπbed in Table 6- 1 Table 6-1 - Vulnerability Configuration Parameters APPENDIX B SOFTWARE USER'S MANUAL APPENDIX B SOFTWARE USER'S MANUAL 6.2.2 Rankings Management The application provides the capability to view and modify the rankings of individual SSPs and services Refer to Figure 4 2 to see the format of the windows If the operator selects the SSP ranking then he must provide a SSP pomt code, and an integer ranking between one and ten inclusive. The SSP point code is of the format xxx-xxx-xxx. wnere x is an integer If the user selects the services rankings then a Services window pops up with the default POTS service selected If he changes the services selecnon to SCP Services, then he must supply an integer ranking between one and ten inclusive for each of the services identified in Table 6-2 Bv entering a high ranking for a service, the user is assigning a higher pπoπty to the service for his analvsis Table 6-2 - Vulnerability Adjustable Rankings 6.2.3 Controls The applicanon provides the user with the capability to start and stop processmg of the application usmg the "Control Stan" and the "Control | Stop" GUI menu opπons, respectively 6.2.4 Termination The application provides the capability to terminate execution of the application using the "File Exit ' ' menu option provided by the GUI (sunilar to the Intrusion Detecnon). 6.3 System Inputs The following sections describe the system mputs to the system and are requu-ed for the proper operaπon of the application. 6.3.1 Topology Database The topology database is the repository of mformanon related to the configuration and the individual characteπsπcs of each element of the GTE propπetary SS7 network. 6.3.2 Help Files Several HELP flat files are required by the application m support of the HELP opnon within the GUI These files must be installed at the path denned by the SYSTEMHELP environment vaπable (similar to the Intrusion Detector) The required help files are APPENDIX B SOFTWARE USER'S MANUAL a) file_help - This is the flat file containing the help text for the "File" menu options b) servιces_help - This is the flat file containing the help text for the "Rankings , Services" menu option. vuln_monιtor_help - This is the flat file containing the help text for the "Rankings SSP" menu opπon. d) vulnerabilit _helρ - This is the flat file containing the help text for the main Vulnerability Analysis menu 6.4 Outputs The followmg secnons descnbe the expected outputs provided by the System Vulnerability Analyzer application. 6.4.1 Operator's Vulnerability Analysis Display and Analysis Log The Vulnerability Analysis results are output to a log file and then displayed to the operator in a scrollable window Both cnπcal nodes and the most vulnerable links for attacking the cπncal nodes are recorded in the analysis ouφut file and displayed to the user The cππcal nodes are displayed in a descending order based on the score Both the node cπncality score and the link vulnerability score fall within the scale of one to ten inclusive The following informanon is displayed in the log- a) Cπncal SCP node point code and office name Note that the cπncal SCP node is not applicable for POTS b) Number of cπncal nodes. c) Cπncal node charactensncs including the office name, point code, cπncaliry score, and the raw cnncaliry score. d) L nk informanon referenced to the cπncal node including the link ideπnficanon, connecting node office names, and the vulnerability score. e) Five most cππcal SSPs for each SSP type - tandem, end office, and telephone operator posiπon service (TOPS). 6.4.2 (U) Operational Error and Warning Messages The operanonal error and warning indicanons which are specific to the Vulnerability Analyzer, and displayed to the user via the GUI are descπbed in Table 6-3 General System error messages in Table 5-5 which apply to the Vulnerability Analyzer are identified as either Process Manager or Display Management. Table 6-3 - Vulnerability Operational Error and Warning Messages APPENDIX B SOFTWARE USER'S MANUAL In addiπon. faults are logged by the Vulnerability Analysis process mto its coπesponding flat file with a default name of ulnerabiliry_analyzer_class.log. The fault log can be enabled or disabled by the system configuranon file previously loaded. Refer to Table 6-4 for a list of possible messages that may appear in the fault log Table 6-4 - Vulnerability Fault Log Messages APPENDIX B SOFTWARE USER'S MANUAL 7. (U) Notes This section contains general mformation that aids in understanding this specification (e g , background information, glossary) 7.1 (U) Abbreviations and Acronyms All abbreviations and their meanings, as used in this document, are presented in the following alphabetical listing DPC Designation Pomt Code GMT Greenwich Mean Time GUI Graphical User Interface ISDN Integrated Services Digital Nerwork ISUP ISDN User Part MTP Message Transfer Part OPC Oπgmation Pomt Code POTS Plam Old Telephone Service SCP Service Control Pomt SS7 Signalling System 7 SSP Service Switching Pomt STP Signalling Transfer Pomt SUM Software User's Manual O 00/07312 APPENDIX B SOFTWARE USER'S MANUAL (U) Topology Database Schema and Procedures This section describes the information and instructions necessary for user setup and control of the Topology Database The following is the step-by-step procedure required for use with the System prototype Prerequisites: LOGIN sa PASSWORD "" Minimum size of tempdb database 24MB Data device named data_devιce_ 1 Index device named ιndex_devιce_ 1 Run the following scπpt to create the system_db database. % $ S ΪSTEMHOME/db/db_schema/system_db_inι . sql Run the following scπpt to create the tables in the systern_db database % $ S YSTEMHOME/db/db_scnema/creat e_al l_system_db_tables Run the followmg script to create the requu-ed stored procedures for the Intrusion Detector and the Vulnerability Analyzer in the system db database i $5ϊSTE HOME/db/db_procs / create_al l_system_scored_proceαures System Database Schema The following tables descnbe the System database schema used by both the Intrusion Detection and Vulnerability Analysis tools The highlighted rows within the tables mdicate a umque primary key Table 7-1 - Nodes Table Description Table 7-2 - Node Types NODE ΥPES Table Description APPENDIX B SOFTWARE USER'S MANUAL Table 7-3 - Links Table Description APPENDIX B SOFTWARE USER'S MANUAL Table 7-4 - Link Services Table Description APPENDIX B SOFTWARE USER'S MANUAL Table 7-6 - SCP Services Table Description Table 7-8 - STP Services Table Description APPENDIX B SOFTWARE USER'S MANUAL Table 7-9 - SSP Table Description Table 7-10 - SSP Service Table Description Table 7-11 - Network Codes Description Table 7-12 - Trunk Neighbor Description Table 7-13 - Locations Table Description LOCATIONS Table Description APPENDIX B SOFTWARE USER'S MANUAL O 00/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT TABLE OF CONTENTS 1. SCOPE 4 1.1 SYSTEM OVERVIEW 4 1.2 DOCUMENT OVERVIEW 4 2. REFERENCES 4 3. CSCI-WTDE DESIGN DECISIONS 5 3.1 INTERPROCESS COMMUNICATION (IPC) 5 3.1.1 Message Queue 5 3. 1.2 Semaphore 7 3.1.3 Shared Memory 7 4. ARCHITECTURAL DESIGN OVERVIEW 7 4.1 INTRUSION DETECTOR 11 4.1.1 Display Management Process // 4. 1.1.1 Interfaces 12 4.1.1.1.1 Intrusion Detector Operator Console 12 4.1.1.1.2 Intrusion Detection Process 13 4.1.1.1.3 Data Collection Process 14 4.1.1.1.4 Topology Database 14 4.1.1.2 Concept of Execution 15 4.1.1.2.1 GUI Management 15 4.1.2 Data Collection Process 16 4.1.2.1 Interfaces 16 4.1.2.1.1 SS7 Input Message 17 4.1.2.1.2 Intrusion Detection Process 18 4.1.2.1.4 UNIX Files 18 4.1.2.2 Concept of Execution 18 4.1.3 Intrusion Detection Process 20 4.1.3.1 Interfaces 20 4.1.3.1.3 Network Topology Database 21 4.1.3.1.4 UNIX Files 21 4.1.3.2 Concept of Execution 21 4.2 VULNERABILITY ANALYZER 22 4.2.1 Display Management Process 22 4.2.1.1 Interfaces 22 4.2.1.1.1 Vulnerability Analyzer Operator Console 23 4.2.1.1.2 Vulnerability Analysis Process 24 4.2.1.2 Concept of Execution 24 4.2.2 Vulnerability Analysis Process 24 4.2.2.1 Interfaces 24 4.2.2.1.2 UNIX Files 25 4.2.2.1.3 Network Topology Database 25 4.2.2.2 Concept of Execution 25 4.3 NETWORK TOPOLOGY DATABASE 26 4.3.1 Interfaces 26 4.3.2 Concept of Execution 27 INTRUSION DETECTION ALGORITHMS 27 LINKSET D3ENTIFIER NAMING CONVENTION 34 APPENDIX C SOFTWARE DESIGN DOCUMENT TABLE OF CONTENTS LIST OF FIGURES FIGURE 3- 1 - CLASS DIAGRAM MESSAGE QUEUE 6 FIGURE 3-2 - SCENARIO DIAGRAM PASSING A MESSAGE EXAMPLE 7 FIGURE 4- 1 - DATA FLOW DIAGRAMS 10 FIGURE 4-2 - SYSTEM CLASS CATEGORY DIAGRAM 11 FIGURE 4-3 - CONTEXT DIAGRAM INTRUSION DETECTOR DISPLAY MANAGER 12 FIGURE 4-4 - DATA COLLECTOR CONTEXT DIAGRAM 17 FIGURE 4-5 - CLASS DIAGRAM DATA COLLECTOR 19 FIGURE 4-6 - SCENARJO DIAGRAM DATA COLLECTOR INITIALIZATION 20 FIGLRE 4-7 - CONTEXT DIAGRAM INTRUSION DETECTOR 21 FIGURE 4-8 - CONTEXT DIAGRAM VULNERABILITY ANALYSIS PROCESS DISPLAY MANAGER 23 FIGURE 4-9 - CONTEXT DIAGRAM VULNERABILITY ANALYSIS PROCESS 25 FIGURE 4-10 - NETWORK TOPOLOGY DATABASE DOMAIN DIAGRAM 26 APPENDIX C SOFTWARE DESIGN DOCUMENT LIST OF TABLES TABLE 4-1 - INCOMING SS7 MESSAGE FORMAT 17 APPENDIX C SOFTWARE DESIGN DOCUMENT 1. Scope 1.1 System Overview The System Network and Signal Infrastructure Vulnerability Analysis and Intrusion Detection System (hereafter referred to as the system) is a software application capable of providing real-time protection to the U S telecommunications Signaling System No 7 (SS7) infrastructure The goal of the system is to perform the following- a) Determine the vulnerability of the SS7 network based on its topology and identify the network elements most vulnerable to intrusion, a) Detect intrusions to SS7 links bemg monitored a) Provide a User Interface for operator control and status display in support of the above processes The system uses a Sun Microsystems 's SPARC-20 platform, running the Solans 2 5 operating system 1.1 Document Overview This Design Descπption (SDD) descπbes the design for the system The system CSCIs is being modeled with the Object Modeling Technique (OMT) Object-Oπented Analysis/ Design methodology, usmg the Rational Rose/C++ Computer-aided Software Engineering (CASE) tools. This system software includes the followmg Computer Software Configuration Items (CSCIs): a) Intrusion Detector (including SS7 Monitoring, User Interface, Anomaly Detection process) a) Vulnerability Analyzer (User Interface, Vulnerability Analysis processes) a) Topology Database 1. References The documents identified below provide background mateπal and are incorporated herein by reference DOCUMENT No. TITLE [ 1 ] ISO 9001 International Organization of Standards 9001 [2] ANSI Tl 1 11-1996 Signaling System Number 7, Message Transfer Part (MTP), Amencan National Standards Institute Inc., 1996 [3 ] ANSI T 1.112- 1996 Signaling System Number 7, Signaling Connection Control Part (SCCP), Amencan National Standards Institute Inc., 1996 [4] ANSI T1 1 13-1995 Signaling System Number 7, Integrated Services Digital Network User Part (ISDN), Amencan National Standards Institute Inc , 1995 [5] ANSI T1 114-1996 Signaling System Number 7, Transaction Capacity Application Part (TCAP), Amencan National Standards Institute Inc , 1996 [6] ANSI Tl 1 16-1990 Signaling System Number 7, Operations, Maintenance and Administration Part (OMAP), Amencan National Standards Institute Inc., 1990 APPENDIX C SOFTWARE DESIGN DOCUMENT 1. CSCI-wide Design Decisions T is section presents the CSCI-wide design decisions, that is, the decisions common to all the CSCI's behavioral design and those of its software subunits. The following functionality resides in the Common Infrastructure of the software architecture, accessible to all other CSCIs 1.1 Interprocess Communication (IPC) These section details the UNIX System V IPC methods used to implement interprocess communication , whereby two or more processes communicate with each other to perform tasks. These three mechanisms, listed below, are available for use in the design as needed. a) Message Queues a) Semaphores a) Shared Memory Message queues are a prefened method for IPC smce they are easier to manage and are easily ported to other processmg environments. Shared memory is used when higher performance is requu-ed, since the data is shared rather than copied between the different data regions as is done in the implementation of message queues. The followmg subsections give an overview of each of the three IPC options 1.1.1 Message Queue The message queue allows multiple processes on the same machme to exchange formatted data by sendmg and receivmg messages among themselves. The messages stored m a message queue are persistent, even when there is no process referencmg the queue. Messages are removed from a queue only when processes explicitly retπeve them. Within the Common Infrastructure library, a MessageQueue class is provided to mterface to the embedded message queues of the UNIX kernel. It is through this mterface that two independent processes are able to pass messages between each other. A typical class hierarchy utilizing the MessageQueue class is shown m Figure 0-1. Here, we see classes of different processes, the SERVER class and the CLIENT class, and then- relationships with the MessageQueue class usmg the OMT notation. APPENDIX C SOFTWARE DESIGN DOCUMENT Client ExecuteMessage() PassMessageO MessageQueue State int 0 Message Queue( ) StatusOK( ) RemoveQueueO SendMessage() GetMessageO Figure 0-1 - Class Diagram: Message Queue Figure 0-2 is an example scenaπo diagram showing how two independent processes can utilize the MessageQueue class. The SERVER and CLIENT objects must, first, mstannate their own MessageQueue objects usmg the MessageQueue constructor funcπon. At this time, the IPC link is established. The status of the queue is then veπfied by the StatιsOK() function. By usmg the SendMessageQ and GetMessage() operations of MessageQueue class, the processes are able to pass messages between them. APPENDIX C SOFTWARE DESIGN DOCUMENT theServer the MessageQueue iheClieni Process MessageQueue Process I ) Figure 0-2 - Scenario Diagram: Passing a Message example The followmg system- imposed limits on the manipulation of messages are defined in the <sys/msg h> header file. a) the maximum number of messages queues a) the maximum number of bytes of data allowed for a message a) the maximum number of bytes for all messages allowed in a queue a) the maximum number of messages in all queues allowed in a system 1.1.1 Semaphore Semaphores provide a method to synchronize the execution of multiple processes. Semaphores are frequently used along with shared memory to establish a method for IPC. Like messages, semaphores are persistent, despite their creator process's termination. 1.1.1 Shared Memory Shared Memory allows multiple processes to map a portion of their virtual address space to a common memory region. Thus, any process can wnte data to a shared memory region and the data are readily available to be read and modified by other processes. The data m a shared memory region are persistent. The memory space is not deallocated even if the process creatmg the shared memory region temunates. Also, shared memory does not provide any access control method for processes that use it, semaphores are used with the shared memory to implement this interprocess communication media. 1.1 Process Management This section outlmes the high-level geneπc process management scenanos of the System's Intrusion Detector. The followmg scenanos are addressed: APPENDIX C SOFTWARE DESIGN DOCUMENT a) Initialization a) Self-test operations 1.1.1 Initialization Upon launching the System Intrusion Detector application, there are a set of generic software configuration and control scenarios that are performed. The following defines what is required and conforms to the setup procedures of the system. a) The Process Manager (within the Display Management) creates the following child processes: 1) the Intrusion Detection process 1) the Data Collection process a) When the Process Manager (within the parent process) creates a child process, the Process Manager stores followmg mformation about the child: i) the child's process identification assigned by the UNIX kernel 1) the system time at the time of creation 1) the file name EXECuting in the process 1) zero out statistics unique to the process a) Once a child process is created, the child process initializes itself m the followmg matter 1) prepares to send heart beat messages to the Process Manager. 1) close all unnecessary file descnptors 1) change working directory to ROOT. This allows unmounting of filesystem 1) reset the file access creation mask 1) run m background 1) disassociate from inhented process group by making the process group ED equal to process ED. Daemon no longer susceptible to signals sent to entire process group. 1) ignore terminal I/O signals 1) signals, process groups and control terminals revisited 1) disassociate from control terminal 1) don't reacquire a control terminal 1) handle SIGCLD signals a) All processes open/create and initialize its message queue for IPC operations. Veπfy that the message queue status is operational. a) Read relevant configuration mformation, if any, and configure based on that mformation. a) At the completion of the process's initialization, each process waits for an indication (semaphore) from the parent process. 1.1.1 Self-Test The section defines the implementation of the System's self-test requirements 1.1.1.1 Process Verification This section defines the requirements for process veπfication and management for the System applications Each process will be monitored by the parent process usmg a heaπ beat IPC messagmg. APPENDIX C SOFTWARE DESIGN DOCUMENT a) Once a child process is created, the child process prepares to send heart beat messages to the Process Manager at a fixed time interval of TBD seconds. The format of the heart beat message is as follows- 1) Message Type - indicating it is a heart beat message i) Process Identification - assigned to the sendmg process during its creation i) Tune of transmission - system tune when the message was queued to the parent 1) Process Stats - unique to the particular process. a) Once the child process sends the heat beat message to the Process Manager (parent), the child process repeats the scenaπo m preparation for its next heart beat message when the next time interval is reached. a) The Process Manager veπfies that the child's operation is NORMAL usmg this heart beat message i) If the heart beat is received successfully, the Process Manager records the occurrence and stores the process's statistics for later reference 1) If the heart beat is not received successfully, the Process Manager a) records this occurrence, via a counter a) sends a KILL signal to the child a) resets/restarts that process. a) notifies the operator, via the GUI a) records the event in a error log file. 1.1.1.1 Common Functional Verification This section defines the implementation for software functional veπfication and management for the System applications. Each process will be momtored by the parent process usmg a heart beat IPC messagmg. a) Veπfy the status of the queues and check for OVERFLOW condition. The error is flagged and wπtten to the local Operator Interface Status Queue. a) Veπfy data for out-of-bounds condition. APPENDIX C SOFTWARE DESIGN DOCUMENT Architectural Design Overview This section details the overall software architecture for the System Figure 0-1 shows the da t a flow between the different processes and the external interfaces of the Intrusion Detector and t he Vulnerabili t y applications The architecture includes two ( 2) mdependent applicanons, the Intrusion Detector and the Vulnerabili t y Analyzer, each with its own GUI environment These processes and the interfaces are discussed in grea t er Figure 0-1 - Data Flow Diagrams detail within the next subsections a) The Intrusion Detector A real-time application, including three concurrent processes, the Data Collection, the Intrusion Detection and lfs Display Management processes a) The Vulnerability Analyzer mcludes two processes - the Vulnerability Analysis and it's Display Management processes The system's class category dιagτam is shown in Figure 0-2 usmg the OMT notation The class category diagram illustrates the logical collections of classes used by the applications. It maps well to the software architecture diagram presented earlier, however, the significance of this diagram shows the relationships and dependencies between these logical class groupings, including the Common Infrastructure category /07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Figure 0-2 - System Class Category Diagram The Common Infrastructure is an abstraction layer, used to isolate the rest of the applicanon from the details of the low-level, operating system-specific funcfionality for portability to other platforms It is a repository of common funcπonaliry of multiple processes (IPCs and database mterfaces) It is implemented as a domain-specific framework or library, available to the higher-level subsystems to maximize reuse and standardization. 1.1 Intrusion Detector This section descnbes the concept of execunon and the IPC mterfaces of the different processes that make up the System Intrusion Detector. The Intrusion Detector's architecture is partitioned into three (3) independent processes - the Data Collecnon, the Intrusion Detection and it's Display Management processes. 1.1.1 Display Management Process The Display Management process is the top-level or parent process of the Intrusion Detector and is available duπng system operation. This process mcludes the graphical user mterface, designed usmg the Sparc Work's Visual GUI builder and the Motif libraπes, as well as operanons for prepaπng the incoming data for user display. The look-and-feel of the environment is similar to that of the Open Windows environment. APPENDIX C SOFTWARE DESIGN DOCUMENT 1.1.1.1 Interfaces The following subsections identify the external interfaces of the Display Management process, as shown in the context diagram Figure 0-3. The message queue is the method used for all interprocess communication to and from the Display Management process. 1.1.1.1.1 Intrusion Detector Operator Console Operator Console ■ Control and J • Statistics Configuration ■ Fault Reports ■ Control and Network Data Configuration Topology ■ Control and Collection Configuration Database ■ Statistics Display - Fault Reports Management ■ Statistics ■ Fault Reports Process ■ Control and Intrusion Configuration Detection ■ File Management UNIX Files Figure 0-3 - Context Diagram: Intrusion Detector Display Manager The operator console of the Intrusion Detector application is the GUI environment that allows the operator to change the application's operating parameters and observe predefined statisncs, as well as overall system status. 1.1.1.1.1.1 Control and Configuration In response to operator selecnon (via a pull-down menu), the followmg control and configuranon options for the mtrusion detecnon process are available. A dialog box is provided to the operator to enter the desired selecnon mputs. a) File and Configuration Management: The control opnons for the system's configuranon are listed below When selected, another dialog box is displayed, prompting the operator for the desired filename: APPENDIX C SOFTWARE DESIGN DOCUMENT i) Retπeve Configuration - retrieves a previously saved configuration file from the disk dnve. i) Save Configuration File - saves the cunent configuration settings to a file on the disk dnve. 1) Retneve Analysis File- retπeves a previously saved log file from the disk drive 1) Save Analysis File - saves the most recent analysis results to a log file on the disk dnve 1) Exit - Aborts the application and all its associated processes. a) View Management: The control options for the operator's viewing area are listed below When selected, another dialog box is displayed, prompting the operator for the desired mput(s): 1) Enter Monitoring Pomt(s): The operator mdicates the current hnk(s) being monitored by the System. The node is entered usmg its pomt code designation and the links are identified by its linkset number. This acnon is acknowledged by a view of the local SS7 network topology displayed to the operator. Bold solid lme(s), drawn to the coπesponding far end node, indicates the links being monitored a) Configuranon Parameters: With these opnons the operator is able to adjust and define the threshold values used by this applicanon. When selected, another dialog box is displayed, prompting the operator for the desired inputs). a) Opflons: Miscellaneous opnons for test stimulus mjecnon. 1.1.1.1.1.1 Statistics and Status Display In response to an operator selecnon, the operator can view the followmg status/stansncs. These stansncs are maintained constantly by the Display Management process. a) Network Topology Informanon: By clicking the mouse's πght button on the desired node displayed on the topology view This node mformanon is provided to the operator m a scrollable text wmdow From that wmdow, the operator can select a particular linkset of that node and view its charactensttcs. a) Network Stansncs: From the environment's mam menu bar, the operator can request to view the capacity measurements listed below Informanon is provided from the Intrusion Detecnon process at a fixed interval. A fault is logged if this message is not received the expected time. a) Anomaly Detecnon Indicanon. Informanon is provided from the Intrusion Detecnon process. 1.1.1.1.1 Intrusion Detection Process This secnon details the Display Management process's mteφrocess commumcanon to and from the Intrusion Detecnon process. 1.1.1.1.1.1 Control and Configuration The followmg IPC messages are sent to the Intrusion Detection Process- a) Operator Programmable Configuranon Parameters 0 MTP operanon parameters. APPENDIX C SOFTWARE DESIGN DOCUMENT ι) SCCP operanon parameters 1) ISUP operanon parameters. 1.1.1.1.1.1 Statistics and Status Display The following IPC messages are sent from the Intrusion Detecnon Process: a) Anomaly Detection: In the event that any of the predefined anomaly rules or a combinanon of these rules are sansfied (indicating a detecnon), a message is sent to the Display Management process for display The message will mdicate the following mformanon about the anomaly- 1) the SS7 message i) a time stamp generated by the Data Collecnon process 1) the error code(s) assigned to the rule(s) fired which caused the anomaly report i) the link affected i) the Alarm type a) NORMAL operanon (minal display) a) MINOR a) MAJOR a) CATASTROPHIC a) Network Stansncs: The followmg measurements are provided to the Display Management process at a fixed time interval. This message is also used by the Display Management process as a heartbeat indicanon from the Intrusion Detecnon process 1) Total number of messages received per time nek 1) Number of MTP type messages received per time nek 1) Number of SCCP type messages received per time nek 1) Number of ISUP type messages received per time nek 1.1.1.1.1 Data CoUection Process This secnon details the Display Management process's mteφrocess communicanon to and from the Data Collecnon process 1.1.1.1.1.1 Control and configuration The followmg IPC messages are sent to the Data Collecnon Process- a) Enable/disable test stimulus from file- When enabled, the Data Collecnon process will inject the test stimulus data mto the real-time data stream. a) Operator Programmable Configuranon Parameters. 1.1.1.1.1.1 Status and Statistics The followmg IPC messages are sent from the Data Collecnon Process. This message is also used by the Display Management process as a heartbeat indicanon from the Data Collecnon process. a) Total number of messages per sec. a) SS7 Link "Heart Bear" mdicanon (as received from the Momtoπng Analyzer) 1.1.1.1.1 Topology Database The node and link mformanon are retneved by the Display Management process from the Topology database when the monitoring pomt is specified by the operator This node and link mformanon are detailed below APPENDIX C SOFTWARE DESIGN DOCUMENT a) Nodal Descπption i) Type (R_STP, STP. SSP, SCP, etc ) 1) Point Code i ) CLLI Code i) Office Name (city, state) l) Vendor Name (ATT, GTE, Spπnt, etc ) I) Vulnerability Ranking of node (based on result of Vulnerability Analyzer) a) Link Descπption I) Linkset Name (See Appendix 0) i) Type (A link, , F link) I) Number of links in Linkset i) Occupancy (percentage usage) i) Media Type (copper, fiber, radio, etc ) I) Vulnerability Ranking of link (based on result of Vulnerability Analyzer) 1.1.1.1 Concept of Execution The Display Management process implements the followmg funcnonality a) Operator Console Management a) Process Management 1.1.1.1.1 Operator Console Management Upon uunalizanon. the Display Management process displays its operator console with all configuration parameters set to the factory default values ( thresholds, etc ) It then waits for operator interacnon The operator will need to provide the configuranon mformanon listed below This mformanon can be loaded manually or via loading a pre-defined configuranon flat file a) File Maintenance a) Monitoring Pomt a) Threshold values (if different from defaults) 1.1.1.1.1.1 Initialization The Display Management process a) Remeve configuranon file informanon 1.1.1.1.1.1 Initial Topology View Generation Once entered, the monitoring points) are used to generate and display the local nerwork topology view The network topology view is based on topology informanon remeved from the topology database (nodes, signal links, etc ) To implement, the GUI performs the followmg a) get the topology linkset for the first pomt-code entered from the operator a) if a monitoring pomt is an A-line, get its correspondmg A-hne mate to the end node and include in the drawing a) if a monitor pomt is of a mated STP, draw the interconnecting lines of the STP mated a) draw local network - all direct links to the monitoring pomt are represented by a regular solid line For claπry, the Imk(s) selected as being momtored. are represented by a bold solid line APPENDIX C SOFTWARE DESIGN DOCUMENT 1.1.1.1.1.1 Topology Maintenance Once the local topology is drawn, the nerwork view reflects the current state of each link of the local network to the operator using color cod g. The link status is color coded, indicatmg the anomaly ranking (BLUE, YELLOW, ORANGE or RED): This anomaly rankmg or sute is based on the "Alarm type" data field from the anomaly detection message. a) In response to an anomaly detecnon message from the Intrusion Detecnon process: i) the corresponding link's anomaly status is updated and displayed m real-time on the topology view. a) BLUE - normal operation (initial display) a) YELLOW - caused by the recepnon of the "MINOR" alarm a) ORANGE - caused by the recepnon of the "MAJOR" alarm a) RED - caused by the reception of the "CATASTROPHIC" alarm a) As the link's anomaly state is updated, the corresponding ano aiy(ιes) that caused the condinon are buffered for operator display. The highest anomaly status of each link persists on the display uπnl the operator acknowledges the correspondmg alarms. a) The operator acknowledgment clears the alarm buffer for that link and resets the link's anomaly state to "NORMAL operanon" (BLUE). 1.1.1.1.1.1 Test Message Control 1.1.1 Data Collection Process The Data Collector accepts pre-formatted SS7 message data from the SS7 monitoring source (via the commumcanon port) and or a UNIX file containing test messages. It is a real-time operanon. whose primary funcnon is to manage the communicanon port, as needed, and prepare the data for output to the next process in the real-time pipe -- the Intrusion Detecnon process. 1.1.1.1 Interfaces The mterfaces of Data Collector are shown in Figure 0-4. Each of these mterfaces is detaded in the followmg subsecnons. APPENDIX C SOFTWARE DESIGN DOCUMENT Figure 0-4 • Data Collector Context Diagram 1.1.1.1.1 SS7 Input Message The incoming SS7 message, from the monitonng anaiyzer, is pre-formaπed such that each message is of a fixed length with fixed informanon fields. The expected format for the SST message input is shown in Table 0-f Table 0-1 - Incoming SS7 Message Format BYTES 1 j Nerwork Indicator, Pπoπty, Service Indicator 6 OPC DPC 1 Message Type 5 Called Address (ISLT called digits) 5 Calling Address (ISUP called digits) 1 Called Party Subsystem Number 1 Global Title Translaπon Indicator (Boolean) 3 Called Parry Point Code 1 Calling Party Subsystem Number 1 Global Tide Translanon Indicator (Boolean) 3 Calling Parry Point Code 1 Data Type (UDT Messages) 1 Monitored link message originated 1 CIC (ISUP Message only) 1 CAUSE CODE ( REL Message only) 3 Desnnanon (MTP Transfer Message only) 1 Affected SSN (SCCP Management Message only) 3 Affected Point code (SCCP Management Message only) 1 Return Cause(SCCP Umdata Service Message only) 1 DCE or DTE indicanon APPENDIX C SOFTWARE DESIGN DOCUMENT 1.1.1.1.1 Intrusion Detection Process The messaging to the Intrusion Detecnon Process includes the reformaπed SS7 messages to be used in t he intrusion determination The output message format to the Intrusion Detecnon includes the following components a) the pre-formatted SS7 input message a) a tune stamp generated by the Data Collecnon process 1.1.1.1.1 UNIX Files The Data Collection process will read and inject the test SS7 messages mto the real-time message stream for puφoses of testing The format and the content of these test messages are idenncal to those from the monitonng analyzer 1.1.1.1 Concept of Execution With the continuing mcommg SS7 messages from the commumcanon poπ. it is a requirement that the data collecnon operate in rcal-πme mode Upon lπiπalizanon of this process, the mcommg SS7 messages are rune stamped, reformatted and queued for the Intrusion detecnon process The top-level class diagram for the Data Collecnon process is shown is Figure 0-5 The followmg is a list of the classes, their responsibihnes and the collaboranons with the other classes. a) The Data Collector class is the mam class of this process. Its responsibility is to create and control its subclasses at a high level a) The MessageQueue class resides in the Common Infrastructure category. It is this class that represents the IPC method used by the Data Collector. a) The CommPort class's responsibility is the control commumcanon poπ and manages the data flow from the port. The SS7 message data structures are made available to the Data Collector class, mdependent of protocol used by the poπ. a; The File class is the Data Collector's mterface to the Unix files The data structures of the test SS7 messages are made available to the Data Collector class, idenncal to that of the CommPort class. a) The Clock class is used by the Data Collector as the mam tuner of the process O 00/07312 A ;NDIX C SOFTWARE DESIGN DOCUMENT Figure 0-5 - Class Diagram: Data Collector Figure 0-6 is the high level scenaπo diagram for minalizmg the of the Dau Collecnon process. The funcnon theDataCollector::Inιπaiιze() is called first and performs the required uunalizanon unplementanon for the DataCoUector class, as well as its subclasses. The followmg list details the funcnon calls for Data Collector uunalizanon: a) ώeCommPort::CommPortO - this is the constructor of the CommPoπ class, which sets up the communicanon port for the specified protocol it is to implement, a) thelntrusionQueue:: MessageQueueO - this is the constructor of the Intrusion Detecnoπ's MessageQueue class, which sets up the IPC link between the two processes, a) theFile::FileDetected() - The DataCoUector object veπfies the existence of the test message file for injecπoπ. theDataCollector::EnableFileMsgs() is then called to set the proper local flags to enable this operanon. a) theClock::SetTimer() - The timer is setup and used to control the test message lπjecnon mto the SS7 message stream from the UNIX file. 00/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Network Data Topology Collection L Database Figure 0-7 - Context Diagram: Intrusion Detector 1.1.1.1.1 Nerwork Topology Database The Nerwork Topology Database provides the mtrusion detection algoπthms with the required relevant infrastructure data (node and link mformanon) of the SS7 network. The network topology information and its format, as required for the mtrusion detecnon, is identical to that used by the Display Managemen t process. 1.1.1.1.1 UNIX Files The Intrusion Detection process logs all anomalies detecnons, as well as the resultant mtrusion decision. The filename is specified by the operator via the Display Management process. 1.1.1.1 Concept of Execution The Intrusion Detecnon process reacts to an IPC message mto its message queue. The thread of execunon performed is based primarily on the type of this message. Any message type determined to be invalid are logged and discarded. The following messages are valid by this process: a) Stansncs Enable/Disable: a) Fault Log Enable Disable a) Process Start/Stop: a) Process Shutdown: a) Monitor Points: a) SS7 MSU Record: 1.1.1.1.1 SS7 MSU Record SS7 message is passed into its message queue from the Data Collecnon process. With every new message received, a determinanon is made whether any anomalies have indeed occurred. 0/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Along with the information contained within the newly received SS7 message itself, the detector uses t he information from previously captured SS7 messages, as well as nerwork topology informanon It then correlates it results to predefined conditions or rules that would indicate the presence of an anomaly ( ιes ) The following condinons are tested at different levels of the protocol a) ISDN User Part (ISUP) messages i) Improper RELEASE l) Improper BLOCKING and/or CIRCUIT GROUP BLOCKING 1) Improper RESET and/or CIRCUIT GROUP RESET a) Message Transfer Part (MTP) messages i) Improper CHANGEOVER (mcludmg Emergency Changeover) i) All improper TRANSFER PROHIBIT/HESTRICTED/CONTROLLED i) Improper LINK INHIBIT a) Signaling Connecnon Control Part (SCCP) messages i) Improper Subsystem Prohibited 1) Improper Subsystem Out of Service Whether there was an anomaly detected or not, the current SS7 message is stored and used in fu t ure anomaly tests The Intrusion Detecnon process logs all anomalies detecnons. as well as the resultant intrusion decision. 1.1 Vulnerability Analyzer This secnon descπbes the concept of execunon and the IPC mterfaces of the different processes that make up the System Vulnerability Analyzer. The Vulnerability Analyzer's architecture is pamnoned mto two (2) mdependent processes, the Vulnerability Analysis and Display Management processes The primary responsibility of the Vulnerability Analyzer is to evaluate an SS7 network topology and determme the locaπons most vulnerable to SS7 nerwork mtrusion. 1.1.1 Display Management Process The Display Management process is the top-level or parent process of the Vulnerability Analyzer and is available duππg system operanon. This process mcludes a wmdow-based environment, smular to that used in the Intrusion Detector This was purposefully done for two reasons 1 It is hoped that smular environments (look-and-feei and posiπoning the control opnons under sunilar pull-downs) may make the tools more user-friendly 2. Maximize standardizanon and reuse of the design. 1.1.1.1 Interfaces The followmg subsecnons identify the external mterfaces of the Vulnerability Analyzer's Display Management process, as shown in the context diagram Figure 0-8. The Message queue is the method used for all interprocess communicanon to and from the Display Management process. /07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Operator Console • Control and J ■ Statistics Conjuration . faull Rtpo/l3 Display Management Process ■ Control and Vulnerability Configuration Analyzer file Management UNIX Files Figure 0-8 - Context Diagram: Vulnerability Analysis Process Display Manag Jer 1.1.1.1.1 Vulnerability Analyzer Operator Console The operator console of the Vulnerability Analyzer applicanon is the GUI environment that allows the opera t or to change the app caπon's operating parameters and observe predefined stansncs. as well as overall system status. 1.1.1.1.1.1 Control and Configuration In response to operator selecnon (via a pull-down menu), the followmg control and configuranon opnons for t he Vulnerability Analysis process are available. A dialog box is provided to the operator to enter the desired selecnon mputs. a) File and Configuranon Management: The control opnons of this pull-down menu is idenncal to that of the Intrusion Detector. a ) Thresholds: With these opnons the operator is able to adjust and defined the threshold values used by this applicanon. When selected, another dialog box is displayed, prompting the operator for the desired inputs). a) Analyze- The GO indicanon from the operator, is the signal to begin a new analysis of the network. 1.1.1.1.1.1 Nerwork Vulnerability Display 0/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT In response to the ANALYZE COMPLETE message from the Vulnerability Analysis Process (indica t ing the analysis is complete), the Display Management process will then retrieve the vulnerability log UNIX fiat file for operator display The data fields of the display include the following informanon. a) the Link or Node name and office name a) the cπtena satisfied indicatmg vulnerability a) its vulnerability ranking 1.1.1.1.1 Vulnerability Analysis Process This secnon details the Display Management process's interprocess communicanon to and from t he Vulnerability Analysis process. 1.1.1.1.1.1 Control and Configuration The followmg IPC messages are sent to the Vulnerability Analysis Process: a) Operator Programmable Thresholds. These threshold parameters are used by t he Vulnerability Analysis process in suppoπ of its algoπthms. a) Operanonal Control Messagmg The following indicanons are sent to the V ulnerabili t y Analysis Process to control its flow of operanon i) ANALYZE message - This indicates to begin its analysis usmg its curren t threshold set. 1.1.1.1.1.1 Status and Statistics The followmg IPC messages are sent from the Vulnerability Analysis Process its Display Management process - a) Operanonal Control Messagmg: The followmg indicanons are sent from the Vulnerability Analysis Process, reflecting its operaπon status: I) COMPLETE message - This indicates that its analysis has been completed and the log file is ready for operator display 1.1.1.1 Concept of Execution In response to an ANALYZE indicanon from the operator, the Vulnerability Analyzer's Display Management process sends its own ANALYZE indicanon to the Vulnerability Analysis Process. Upon recepnon of the COMPLETE message from the Vulnerability Analysis Process, the Display Management process retπeves the specified Unix flat file contammg the vulnerability log informanon, just calculated. It is then displayed to the operator via its own scrollable text display wmdow. 1.1.1 Vulnerability Analysis Process The Vulnerability Analysis evaluates the cunent SS7 network topology and ranks the each ennty of the nerwork infrastructure, based on its vulnerability to potennal intrusions. 1.1.1.1 Interfaces The context diagram, shown m Figure 0-9, idennfies the mulnple EPCs needed by this subsystem. The followmg subsecπons address these mterfaces. 07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Figure 0-9 - Context Diagram: Vulnerability Analysis Process 1.1.1.1.1 UNIX Files Once the analysis of the network is complete, the Vulnerability Analysis process records its results mto a UNIX flat file for future retπeval and display by the Display Management process. The text fields in this text file are as follows: a) the Link or Node name and office name a) the cπteπa sansfied indicating vulnerability a) its vulnerability ranking 1.1.1.1.1 Network Topology Database The Network Topology Database provides the vulnerabihty analysis algoπthms with the required relevant infrastructure dau of the SS7 network . The nerwork topology informanon and its format, as required for the vulnerability analysis, are listed below: a) Numeπcal weights for Physical Accessibility of the each link and node. a) Numeπcal weights for Funcnonal Accessibility of the each link and node. a) Numeπcal weights for Secuπty Capability of the each link and node. a) Numeπcal weights for Node Criticality of the each node, relanve to the surrounding network. a) Link and node informanon. 1.1.1.1 Concept of Execution In response to an ANALYZE mdicanon from the Display Management Process, this process analyzes and ranks each link and node within the GTE SS7 nerwork on its potennal vulnerability to mtrusion. O 00/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT Information about the network's infrastructure is retrieved from its database (topology and link/node vulnerability relationships) and used in its algorithms. The following aspects of the network are analyzed for each vulnerability determination: a) Physical characteπstics - the media type used (copper, fiber, etc.) a) Functional characteπsπcs - the services provided on the link, node a) Secuπry characteπstics - the existing screening measures (on-line, eπcrypnon, observanon, etc.) a) Node Criticality - the importance of the network element with respect to the its usage and capacity, a) Redundancy - availability of alternate routmg around element. As a network entry is evaluated, a resulUnt message is sent to the specified text log file (UNIX flat file) This is the file that the Display Management Process retneves for operator display. At the completion of the analysis, a COMPLETION message is sent to the Display Management process, indicating that the analysis results are available for display. 1.1 Network Topology Database The Network Topology Database is the persistent storage for the GTE SS7 network infrastructure. It contains all the nodal and link mformanon requu-ed to implement both the Intrusion Detector and the Vulnerability Analyzer processes. 1.1.1 Interfaces The context diagram, shown in Figure 0-10, idennfies the mulnple IPCs needed by this subsystem Access to the topology daubase, via the SYBASE SQL Server, is accomplished usmg the SYBASE "Open Display Management - Contra and ConΛguntϋon J Network Topology Ota ■ Topology Requests Topology Reouests Vulnerability Intrusion [~» Topology Requests Analysis Detection Network Topology Network Topology Oete Topology .Database Figure 0-10 - Network Topology Database Domain Diagram 0/07312 ( . PPENOIX C SOFTWARE DESIGN DOCUMENT Client" Library This three parry library is a collecnon of utility routines that is our main interface to this database 1.1.1 Concept of Execution from the C — environment, the Topology database is accessed via the Databaselnterface class, whose external interface satisfies the operational requu-ements of the other processes The Databaselnterface class is a wrapper class, isolating the Open Client library funcnon calls within itself and from the rest of the design. In response to a funcπon call, by a client process, to the Databaselnterface class, the database returns the required dau set as defined by its external interface functional signature Intrusion Detection Algorithms This section presents a high-level deuil of the specific algoπthms used in determining the possibility of an anomaly ev ent within the GTE SS" nerwork. MTP Message Validation Λll SS MSU messages of type MTP are analyzed for inconsistencies within their dau fields as compared to the SS7 ANSI specificaπon The MTP tests descπbed within this secnon are only performed on links currently being monitored by the Secure? IDS. a) The following SS" MSU of type MTP are suppoπed by the System Intrusion Detector i) Changeover (CHANGEOVER. CHANGEOVER ACKNOWLEDGE. CHANGEBACK. CHANGEBACK ACKNOWLEDGE, EMERGENCY CHANGEOVER. EMERGENC * . CHANGEOVER ACKNOWLEDGE) i) Transfer Proαibit Restnct i) Signaling Route Set Test i) Transfer Allowed i) Transfer Control I) Signaling Route Set Congesnon Test i) Management Inhibit (Link Inhibit, Link Inhibit Acknowledge, Link Local Test Signal. Link Remote Test Signal, Link Force L'nmhibit, Link Uninhibit) a) For ail SS7 MSU messages, the followmg acnons and checks will be performed. 0 Mainuin and threshold the number of occurrences of each of the MSU types and funcπons. on each SLC, to their correspondmg adjusuble threshold. An alarm is declared to the GUI and log file if the number of occurrences exceed its correspondmg threshold. 0 Validate SS7 routing label of each MSU. The Imk connecnon, based on the message's OPC and DPC. is veπfied against the informanon of the GTE Network topology database (LINK NEAREST NEIGHBOR test). An alarm is declared to the GUI and log file if a link reiaπonship does not exist. This check will also veπfy onginaπng pomt code (OPC) does not equal the designanon point code (DPC). MTP Messages Upon recepnon, the followmg tests will be performed on ail MTP messages. a) Changeover - Upon recepnon of a CHANGEOVER MTP message, no addinonal tests are performed. APPENDIX C SOFTWARE DESIGN DOCUMENT a) Emergency Changeover - Upon recepnon of an EMERGENCY CHANGEOVER MTP message , no additional tests are performed a) Changeover/Emergency Changeover Acknowledge - Upon recepnon of a CHANGEOVER ACKNOWLEDGE MTP message, the followmg tests are performed. 1) Veπfy that a coπespoπdmg CHANGEOVER or EMERGENCY CHANGEOVER was previously detected on the same Imk. An alarm is declared to the GUI and log file if no previous Changeover was not detected. a) Transfer Prohibit/Restrict - Upon recepnon of a TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message, the followmg tests are performed. The tests related to the destmation point code, referred to by this message, is only done if that Imk is also bemg monitored 1) Relanve to the thresholding the number of occurrences of nodal and node cluster prohibits and restricts are mainuined separately and thresholded to its coπesponding ad j usuble threshold An alarm is declared to the GUT and log file if the number of occurrences exceed its coπesponding threshold. 1) Veπfy the OPC of this message, corresponds to a Signaling Transfer Pomt (STP) These message types are only expected to oπgmate from a STP 1) Veπfy the destinanoπ pomt code, referred to by this message, corresponds to a node directly connected to the oπginanng STP in which the message was sent. i) Veπfy that at least one of the followmg message types was previously detected on the destinanon Imk, referred to by this message. An alarm is declared to the GUI and log file if none of the followmg messages are detected (If the destinanon link, referred to by this message, is not part of the local topology defined, then this item will not be checked) ( 1 ) EMERGENCY CHANGEOVER CHANGEOVER - its DPC should be the same as the OPC of the ongmal TRANSFER PROHIBIT RESTRICT message on the other link ( 1 ) LINK Γ HT ΓΓ - its direcnon is irrelevant ( 1 ) TRANSFER PROHIBIT - due to a STP broadcasting a Imk redirecnon. a) Signaling Route Set Test - Upon recepnon of a SIGNALING ROUTE SET TEST MTP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE: l) Venfy that a TRANSFER PROHIBIT or TRANSFER RESTRICT message was previously detected on the same link m the opposite direcnon (OPCs and DPCs are reversed) a) Transfer Allowed - Upon recepnon of a TRANSFER ALLOWED MTP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg condinons are FALSE: 0 Veπfy that a SIGNALING ROUTE SET message was previously detected on the same Imk in the opposite direcnon (OPCs and DPCs are reversed). i) Venfy that the toul number of SIGNALING ROUTE SET TEST messages detected on this link, before a TRANSFER ALLOWED message, is greater than one (1) (SOFT ALARM) APPENDIX C SOFTWARE DESIGN DOCUMENT i) Check for INVALID SLC ΓN ' HIBIT patterns - This test analyzes the SLC inhibi t pa tt erns of each linkset and identifies any non-random inhibiπng of consecutive SLCs of a linkse t An adjustable number of consecutive SLCs inhibited are identified as an INTRUSION a) Link Local Test Signal - Upon reception of a Management Inhibit a LIN'K LOCAL TEST SIGNAL MTP message, the followmg tests are performed An alarm is declared to the GUI and log file if any of t he followmg condinons are FALSE: i) Veπfy that a LINK INHIBIT ACKNOWLEDGE message was previously detected on t he same link the opposite direcnon (OPCs and DPCs are reversed) This message mus t follow a LINK INHIBIT ACKNOWLEDGE message within the T20 timer period plus a processing delu nme. i) Veπfy that at least two ( 2 ) consecunve LINK LOCAL TEST SIGNAL messages are de t ec t ed on the same Imk. The second message must follow the first LINTC LOCAL TEST SIGNAL message within the T20 timer peπod plus a processmg delu tune a) Link Remote Test Signal - Upon recepnon of a Management Inhibit a LINTC REMOTE TEST SIGNAL MTP message, the following tests are performed. An alarm is declared to the GUI ana log file : f an> of he followmg condinons are FALSE. i) Venfy that a LINK INHIBIT ACKNOWLEDGE message was previously detected on t he same link in the same direcnon (OPCs and DPCs are the same). i) A LINTC REMOTE TEST SIGNAL message must follow a LINK INHIBIT ACKNOWLEDGE message within the T21 rimer peπod plus a processmg delta nme i) Veπfy that at least two (2) consecunve LINK REMOTE TEST SIGNAL messages are detected on the same Imk. The second message must follow the first LINTC REMOTE TEST SIGNAL message within the T21 tuner peπod plus a processmg delu nme. a) Link Force Uniπhibit - Upon recepnon of a Management Inhibit a LINK FORCE UNTNTHBiT MTP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg condinons are FALSE: l) Verify that a LINK LOCAL TEST SIGNAL message was previously detected on the same link in the opposite direcnon (OPCs and DPCs are reversed). l) A LINK FORCE UNTNHTBIT message must follow the LINK LOCAL TEST SIGNAL message within the T20 timer peπod plus a processmg delu nme. a) Link Uninhibit - Upon recepnon of a Management Inhibit a LINK UNINHΓBIT MTP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg condinons are FALSE: i) Veπfy that a LINK REMOTE TEST SIGNAL message was previously detected on the same link in the opposite direcnon (OPCs and DPCs are reversed). i) A LINK UNINHIBΓT message must follow the LINK REMOTE TEST SIGNAL message within the T21 timer peπod plus a processmg delu nme. APPENDIX C SOFTWARE DESIGN DOCUMENT ISUP Message Validation All SSJ MSU messages of t ype ISLT are analyzed for mconsistenc.es wi t hin their dau field, « -„ t o t he SS7 ANSI specification. The ISLT tests descπbed within t his sec t ion are onl y fn l ? ^ currently being monitored by the Secure? IDS. y erformed °" 'wks a ) The followmg SS7 MSU of type ISUP are suppoπed by t he Secure? IDS 0 Ininal Address n) Address Complete ιu) Release ιv) Release Complete b) For all SS7 MSU messages , t he followmg acπoπs and checks will be performed . . ) Ma i nu i n and t hreshold t he number of occurrences of each of the MSU rv p es and funct i ons t o it s correspondmg adjusuble threshold. An alarm ,s declare^, GUI and log file i f t he number of occurrences exceed its correspondmg t hreshold i n Val i da t e SS7 t runk connection between the message's OPC and DPC , TR l " W NE A REST NEIGHBOR t est ) An alarm ,s declared to the GUT an d Toe m ^nπϋ relanonship does not exist. This check w,H a l so venfy oπ * ^ ^ not equal t he des i gnanon pomt code (DPC). ^ u ^ ' does ISUP Messages Upon recepnon. the following tests will be performed on all ISUP messages. a ) Initial Address - Upon recepnon of a INITIAL ADDRESS ISLT message, the follow,™ t es t s ar e performed. An alarm ,s declared to the GUI and log file ,f any of the followmg conlons are FALSE . ) Venfy t ha t t he CIC , referenced by t he INITIAL ADDRESS message , was no t curren t ly alloca t ed a ) Address Complete- Upon reception of a ADDRESS COMPLETE ISLT message , no add iti onal a ) U 0 Ma i n t a i n t he number of occurrences of each of the followmg cause codes and threshold w it h t he i r correspond i ng adjusuble threshold. An alarm is declared to the GUI and log file i f t he number of occurrences exceed its corresponding threshold. Code 1 UNALLOCATED NUMBER Code 3 NO ROUTE Code 5 MTS-DAΓLLED TRUNK PREFLX Code 28: ADDRESS INCOMPLETE Code 79: SERVICE OR OPΗON NOT IMPLEMENTED Code 81 : INVALID CALL REFERENCE Code 95: UNSPECIFIED uWALID MESSAGE APPENDIX C SOFTWARE DESIGN DOCUMENT Code 97 MESSAGE TYPE NON-EXISTENT Code 99, 100: INVALID PARAMETER Code 1 1 1 UNSPECIFIED PROTOCOL ERROR n) A response (a RELEASE COMPLETE message) must follow a RELEASE message within the predefined time period plus a processing delta nme. in) Check for INVALID CIC RELEASE patterns - This test analyzes the CIC release patterns of each trunk and identifies any non-random releasing of consecunve CICs of a trunk. An adjusuble number of consecutive CICs released are identified as an INTRUSION. b) Release Complete - Upon recepnon of a RELEASE COMPLETE ISUP message, the following tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE 0 Veπfy that a RELEASE or a RESET message was previously detected on the same link as the RELEASE COMPLETE message. n) Venfy that a BLOCK message was previously detected on the same link, routed in the opposite direction (OPCs and DPCs are reversed) of the RELEASE COMPLETE message The same direcnon indicates possible RESET inseπed at far-end. c) Group Reset • Upon reception of a GROLT RESET ISUP message, the following tests are performed An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE. 0 Venfy that at least two (2) consecutive GROUP RESET messages are detected on the same link in the same duection (OPCs and DPCs are the same). u) The second message must follow the first GROUP RESET message within a five (5) second nme penod plus a processmg delu time. d) Reset - Upon reception of a RESET ISUP message, the followmg tests are performed An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE. 0 Venfy that no RELEASE COMPLETE message was previously detected on the same Imk from the opposite direcnon (DPC and OPC are reversed) of the RESET message. ti) Check for INVALID CIC RESET paπems - This test analyzes the CIC reset patterns of each trunk and identifies any non-random resetting of consecutive CICs of a trunk. An adjusuble number of consecutive CICs released are identified as an INTRUSION. in) A response (a UNEQUIPPED message) must follow a RESET message within the predefined nme peπod plus a processmg delu nme. e) Group Blocking - Upon recepnon of a GROUP BLOCKING ISUP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE I) Veπfy that at least two (2) consecutive GROUP BLOCKING messages are detected on the same Imk in the same duecπon (OPCs and DPCs are the same). n) The second message must follow the first GROUP BLOCKING message within a five (5) second nme penod plus a processmg delu nme. f) Block - Upon recepnon of a BLOCK ISUP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg condinons are FALSE: O 00/07312 APPENDIX C SOFTWARE DESIGN DOCUMENT ι) Verify that no UNBLOCK ACKNOWLEDGE message was previously detected on the same link from the opposite direction (DPC and OPC are reversed) within fifteen (15) seconds of -the BLOCK message. n) Check for INVALID CIC BLOCKING patterns - This test analyzes the CIC block patterns of each trunk and identifies any non-random blocking of consecutive CICs of a trunk. An ad j usuble number of consecutive CICs released are identified as an INTRUSION. g) Block Acknowledge - Upon reception of a BLOCK ACKNOWLEDGE ISUP message, the following tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE 1) Veπfy that a BLOCK or a GROUP BLOCK message was previously detected on the same link from the opposite direction (DPC and OPC are reversed). n) A response (a UNBLOCK message) must follow a BLOCK ACKNOWLEDGE message within a five (5) minute time peπod plus a processmg delu time. h) Group Block Acknowledge - Upon reception of a GROUP BLOCK ACKNOWLEDGE ISLT message, the following tests are performed. An alarm is declared to the GUI and log file if any of the following conditions are FALSE: i) Veπfy that a BLOCK or a GROUP BLOCK message was previously detected on the same Imk from the opposite direction (DPC and OPC are reversed). n) A response (a UNBLOCK message) must follow a GROUP BLOCK ACKNOWLEDGE message within a five (5) minute time penod plus a processmg delu time. i) Unblock - Upon reception of a UNBLOCK ISUP message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the following condinons are FALSE: I) Veπfy that a correspondmg BLOCK ACKNOWLEDGE or a GROUP BLOCK ACKNOWLEDGE message was previously detected on the same link from the opposite direction (DPC and OPC are reversed) with the followmg time restncts: ti) No UNBLOCK message should not be received within fifteen (15) seconds of the BLOCK ACKNOWLEDGE message. in) The UNBLOCK message should be received within five (5) minutes of the BLOCK ACKNOWLEDGE message j) Unblock Acknowledge - Upon reception of an UNBLOCK ACKNOWLEDGE ISLT message, the followmg tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE: l) Veπfy that an UNBLOCK or GROUP UNBLOCK message was previously detected on the same Imk from the opposite direction (DPC and OPC are reversed). k) Unequipped Circuit - Upon reception of an UNEQUIPPED CIRCUIT ISUP message, the following tests are performed. An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE i) Verify that a RELEASE, RESET, GROUP RESET, BLOCK or GROUP BLOCK message was previously detected on the same nk from the opposite direction (DPC and OPC are reversed). APPENDIX C SOFTWARE DESIGN DOCUMENT n) Check for INVALID UNEQUIPPED CIRCUIT CIC patterns - This test analyzes the unequipped CIC patterns of each trunk and identifies any non-random blocking of consecunve CICs of a t runk. An adjusuble number of consecunve CICs released are identified as an INTRUSION. I) Circuit Query - Upon reception of a CIRCUIT QUERY ISUP message, the followmg tests are performed An alarm is declared to the GUI and log file if any of the followmg conditions are FALSE 1) Veπfy that no RELEASE COMPLETE message was previously detected on the same Imk from the opposite direcnon (DPC and OPC are reversed) of the CIRCUIT QUERY message Also, that the CIRCUIT QUERY message is not within a five (5) second peπod of the RELEASE COMPLETE message. Nerwork Analysis This secnon deals with a penodic analysis of the network as a result of the message flow and its effect of that nerwork. a) If a Imk is prohibited or restricted, as a result of a TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message, the followmg tests are performed, but only if the Imk to the destinanon pomt code, referred to by the a TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message, is being momtored. I) veπfy that no traffic (of any protocol) is detected on the link to the destination pomt code, specified by the TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message u) veπfy that no ISUP messages are detected to and from the node correspondmg to the destinanon pomt code specified by the TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message. b) Node Cluster unavailability acnvity is monitored. Maintain and threshold the number of occurrences of the followmg: l) number of clusters down (network total). ti) number of clusters down by destination. in) number of node down by destination. This is incremented with each node and cluster TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message c) Check for INHIBIT TIMEOUT VIOLATION Linkset Identifier Naming Convention This section outlmes the NOC's linkset identifiers for each linkset in GTE's SS7 network. The 8-dιgιt identifiers are assigned usmg the followmg convention: 1 1 st Character - Link Type a) A - A links from SP/SSP/SCP to an STP pair b) B - B links between non-mated STPs on the same level (peers) c) C - C links between STPs in a mated pair d) D - D links between non-mated STPs on different levels e) local and regional pairs) 0 E - E links from SP/SSP to an additional STP APPENDIX C SOFTWARE DESIGN DOCUMENT g) F - F links between STPs SSPs (not connected to STPs) h) X - Test links 2nd Character - Link Destination a) C - Mated STP b) G - Gateway c) I - Independent Company d) L - Another LEC STP e) M - Mobile/Cellular 0 N - Non-mated STP g) P - SCP h) Q - AIN SCP i) R - RBOC STP J) S - SSP Access Tandem Switch k) T - Operator Services SSP switch 1) U - SP/SSP End Office m) X - MGTS (test links) n) Z - Protocol Converter 3rd, 4th, 5th characters (idennfies the GTE STP): 000 LNCLILXC01W 012 DRHMNCXM19W 001 BLTNILXD01W 013 DRHMNCXF19W 002 MRHDKYXA19W 014 FTWYTNXA02W 003 LXTNKYXAl lW 015 GRRTINXA01W 004 TAMPFLXAOOW 016 MARNOHXCOIW 005 CLWRFLXAOOl 017 DLWROHXA01W 008 OCQNVAXA19W 018 MRFDWDCA01W 009 MNSSVAXA19W 019 WAUSWΓXAOIW 010 ERIEPAXMOIW 020 MSKGMLXK01W 011 EDNBPAXE01W 021 THRRMLXT01W 400 OFLNMOXA01W 510 BVTNORXBOOW 401 WNVLMOXAOIW 511 TGRDORXAOOW 402 OFLNMOXA02W 512 PNHOHICOOOW 403 WNVLMOXA02W 513 WPHUHICOOOW 500 SNMNCAXPOOW 514 DCSNTXXA01W 501 ONTRCAXPOOW 515 BYTWTXXAOIW 502 DNTNTXXAOIW 516 LNBHCAXPOOW 503 ΓRNGTXXAOIW 517 ONTRCAXP01W 504 BOTH AXB01W 518 SANGTXXA01W 505 EVRTWAXAOOW 519 BWWDTXXA02W 506 PLSPCAXGOOW 520 SNMNCAXPOIW 507 INDICAXGOOW 521 LNBHCAXPOIW APPENDIX C SOFTWARE DESIGN DOCUMENT 508 SNBBCAXF00W 524 EVRTWAXA06W 509 SNTMCAXF01W 525 BOTHWAXB06W 0/07312 APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS Overview 1 Link Vulnerability- Where is the most desirable luιk(s) from which to gam access to the Most Cπncal Node in the SS7 Network. a) Lmk Vulnerability is esublished based on inherent lmk attributes only such as. 1) media type u) provisioner: due to luruunons, the provisioners by Linkset ID was assumed to be the same as the company owning the Far-end Node - this is generally NOT the case (GTE to GTE linksets likely use IXC carriers when traversing across LATA bouπdaπes) b) Fmal rankings of the Lmk Vulnerability is suppose to de-rate the ranking based on the number of hops away from the Cπncal Node. 2 Node Cπncality What is the most important asset to the SS7 Nerwork Operanon based on the anack scenaπo. 3 The followmg User Inputs are used to influence the analysis a) Designanon of either POTS or AIN services as the mode of analysis I) due to the way STPs are "homed" (routed) based on the type of service be g provided, certain attnbutes are effected by the selecnon ιι) The node cπncahry calculanons are direcdy effected: a) determines the SCP node cπncahry (or SCPs not considered when POTS only specified) b) the rollup of numbers of nodes gaining access via each STP for a particular service b) Designanon of specific SSP(s) of particular importance: I) in order to evaluate impact to specific switches which may have VIP customers homed to them u) effects the SSP node cπncality only 4 The followmg assumpnons and simpiificanons have been mcorporated mto the Vulnerability Analysis. a) all Test Linksets have been removed from the daubase (Linkset Ids = XX = MGTS Test links) b) C-linksets have been removed from the daubase Linkset Ids = CC ) i) it is understood that all STPs have mated pairs for loadshare and fail-over ii) # links with C-linksets may be a distinguishing factor among STP pairs c) the following SSP types were defaulted to SSP EOs - attributes /algoπthms need development: l) Mobile SSPs (Linkset Ids = AM ) n) other LEC SSPs (Linkset Ids = AL ) in) Gateway SSPs (Linkset Ids = AG = Intemanonal Gateway switches m HI) d) Site Personnel Occupancies unknown at this rune all defaulted to midrange Vulnerability Ranking = 5 LINKS Phvsical-media- ype: • ALL links will = FIBER APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS Phvsical-media-provider Functional-services (attack desirability based on user scenano- USER INPUT ) Funcnonal-Capacιty-%-Unlιzaπon 0/07312 .APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS Functιonal-capacιty-% internally generated Funcrional-secuπty-eπcryprion: • If the link is encrypted, then the overall Secuπty Ranking = 1 (no other influences to Security) Funcnonal-secunty-screening: Currently screenmg ALL on EXTERNAL links.(far end Point Code NOT GTE (NOT= 240 ) use: Logical-number-LinksPerLinkset: APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS Note if data becomes av ilable on automatic alt routmg and multiple Linksets then these attnbutes will need to be reconsidered. Currently, the multiplicity of routes will only be accounted for by the number of Links in each Linkset Attribute Relationships (Algorithms) Physical-media-tvpe &.&. Phvsical-Media-provider • Funcπonal-Services-Mulnple may use a formula such as. POTS only Functional Service = 5 1 service only = Service Rankmg 2 non-cπtical (3 or 4) = most cπncal +1 M && L = M M && M = M + 1 M &.& H = H 1 non-cππcal && 1 cπtical = cπtical + 1 (max = 10) 2 cππcal (8 or 9) = 10 3 or more non-cπncal = most cπncal + 2 APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS LSTP-B-Links to non-GTE = POTS only Functional-Services && %Uttlιzatιon by Service E911 ttaffic >10% of toul Unlizanon is considered high πsk Functional Capacity && %-Unlιzanon && Loadshare Links- • high &UtιIιzanon is far more senous on lmks with only 1 loadshare nk, whereas, high %Utιhzatιon lmks with numerous loadshare lmks become have the vulnerability reduced (ideally m a 1/N relaπonship) • Smce Funcnonal Capacity Rankmg is = %-Utιlιzanon Rankmg at this pomt, then the mulnplicity of Loadshare Links will only act to reduce the Funcnonal Capacity Rankmg Phvsical-Connecnvitv-Intemal && %Unlιzanon && %GeneratedExternal- • Internal Connecnvity = GTE for Transmission Provider • % Generated External = 0% for Far pomt code = GTE =240 (default of Tranmission Provider = Far Node Owner) APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS • Physical-Connectivi v-Extemal && %Unlιzanon &&. %Generated-Extemal- • External Connecnvity = NOT GTE for Transmission Provider • % Generated External = 50% for Far pomt code NOT= GTE NOT=240 (default of Tranmission Provider = Far Node Owner) • Funcnonal-Capacity && Secuπtv-Monitoπng- • Even though a hnk may be momtored, When a lmk is momtored, the Capacity rankmg is decreased (less Vulnerability) but the degree to which the rankmg is decreased snll follows the O ic that it is easier to hide mtrusion messages m a higher occupancy lmk The mcrease of traffic load and performance parameters on the link by inserted message traffic is agam, less sigmficant on a higher occupancy lmk. (where the occupancy is represented within the Capacity rankmg - the higher Occupancy the higher the Capacity rankmg ) • Whether Monitoring exists or not is influencing the Capacity (% Uhlization) rankmg • Funcnonal-Secuπtv-Screenmg && Funcπonal-Secuπtv-Monitonng- APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS Functional-Services &.&. Funcnonal-Secuntv Service Rankmg is mfluenced by Secunty only m the middle rankings Link Level Relationships When physical access difficult then Vulnerability is not very mfluenced by other factors • Physical Media Access <= 3 && Functional Services 8,9,10 && Functional Capacity 8,9,10 = Physical Media Access +1 • Physical Media Access <= 3 && any other influences Lmk Vulnerability = Physical Media Access When physical access is mid-range Vulnerabihty is most heavily mfluenced by Secuntv- • Physical Media Access >=4 , <=7 && Funcnonal Services 8,9,10 && Funcnonal Capacity 8,9,10 && Secunty 1,2,3 Lmk Vulnerability = Secuπty + 1/2 When physical access is mid-range and Secuπtv is also mid-range Vulnerability is influenced by Funcnonal Services and Funcnonal Capacity equallv • Physical Media Access >=4 , <=7 &&Secunty >= , <=7 Lmk Vulnerabihty = APPENDIX D VULNERABILI TY ANALYSIS ATTRIBUTES AND ALGORITHMS When physical access is mid-range and Secuπtv is high-range Vulnerability is influenced bv Functional Services and Funcnonal Capacity equally but further degraded bv poor Security • Physical Media Access >=4 , <=7 &&Secuπty >=8 , <=10 Lmk Vulnerability = When physical access is high-range Vulnerability is not influenced very heavily but is modified as follows APPENDIX D VULNERABIL1 TY ANALYSIS ATTRIBUTES AND ALGORITHMS M M Physical Access Score- 2 M H Physical Access Score- 1 M Physical Access Score - 2 M Physical Access Score - 3 H M Physical Access Score -2 Correlation of the Node Criticality Ranking into the overall Link Vulnerability: • The inherent vulnerabihnes of each lmk should be reconciled with the desirability of intruding upon the lmk to gam access to the most desirable node m the network. Ideally, it is more desirable to intrude onto a lmk directly connected to the most desirable node, Hence , the further away from the most desirable node the less desirable (less vulnerable) the link becomes Locanon-N'umber-σansfers-to-cπncal-node- (Cπncal Node must first be determined) this rankmg uses the concept that the further from the mtrusion occurs from the desired target, the less likely the attack has at success due to routmg screenmg, etc Node Attributes Default Node Rankmgs Node-criticality: SCP Node Criticality =( Average of Service Desirability Rankmgs) * ∑ (SSPs w/ access via SCP to desired service) * (Normalized Node Capacity) • ∑ (SSPs w/ access via SCP to desired service) = 100% smce each service is implemented only m one place * • EXCEPT CNAME (CA and Ft Wayne) •* => need to have routing mfo in place for CNAME service - East / West division follows • when POTS is defined, the SCP Node Cπticality is null APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS • Average of Service Desirability = ∑(score of all services) / (nu of services at SCP) • Normalized Node Capacity = ∑(lmk occupancy for all links at node) / ∑(hnk occupancy for all links region ) Node-criticaliry STP Node Criticality: • is mfluenced by the User Input of the Cntical Service Rankmgs. • Cπncal Service Rankmg is used to determine SCP locations providmg access to the (N) highest ranked servιce(s) - • Determinmg Most cπtical SCP must account for combmed rankmg(s) of the (each) service accessed by the SCP (Average of Service Desirability Rankmgs at that SCP) • Cπncal SCP Location is then used to determme the Number of Hops to the Cπtical Service from each STP • Number of Hops to the Cπt. al Service is used to determme the STP Node Cnticahty • STP Node Criticality = ∑- rvt , - ." ( Service Ranking * !„„., (SSPs κτ tct ) * Normalized Node Occupancy Mrrt J / ( ∑ ιU (SSPs) * Number of Hops to Critical SCP ) • POTS STP Node Criticality = ∑ (SSPs w/ access via STP to desired service) * (Normalized Node Capacity) • Normalized Node Occupancy j ^ ,,, = Σ κrγto (Hnk occupancy for all links at node) / (Total Link Occupancy), Average of Service Desirability = ∑( score of all services) / (number of services via STP) / (number of STPs at same number of hops from cntical service) • when POTS is defined, number of hops replaced by number of STPs at same level m network (if node is LSTP then divide by number of LSTPs connected to parent RSTP, if node is RSTP then divide by number of RSTPs ) • determining the Number of Hops to Cπncal Service may be determined by starting at the location of the Cπtical SCP and working backward mto the network traversing each chain of lmks back through each RSTP to each LSTP- as each STP is encountered, the count for the number of hops is to be noted for each STP for LSTPs. ∑ SSPs are those SSPs directly connected to STP for RSTPs ∑ SSPs are all SSPs connected to the subtended LSTPs Node-criticalitv (cont'd): SSP Node Criticality = Default Node type Score * Customer Importance * Normalized Node Capacity • Customer Importance = rankmg put by user to mdicate a high pπonty user homed to specific swιtch(es) APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS • Normalized Node Capacity = ∑(lιnk occupancyTor all links at node) / ∑(hnk occupancy for all links in region ) Overall Node-Criticalitv : Capacitv -number-alternates- (how many other nodes can provide same funcnon in auto alt routing- ignore SSPs) implies all other directly connected STPs at same level with routes toward same service Secuπty-physical APPENDIX D VULNERABILu Y ANALYSIS ATTRIBUTES AND ALGORITHMS Secuπty-observanon: Physical secunty alarming momtormg: access, door open, logon reporting APPENDIX E INTRUSION DETECTION ALGORITHMS MTP: Changeover (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • Threshold number of occurrences • LINK_NEAREST_NEIGHBOR (check OPC and DPC are on collected link) Changeover Ack (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • CORRELATE_TO_CHANGEOVER || CORRELATE_TO_EMER_CHANGEOVER (no previous Changeover mdicates Changeover requested from another source) Emergency Changeover Ack (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • CORRELATE_TO_CHANGEOVER (no previous Changeover mdicates Changeover requested from another source) Emergency Changeover (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • Threshold number of occurrences (very low ) • (check OPC and DPC are on collected lmk) Transfer Prohibit (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, DESTINATION) • Node and Cluster cases • LINK ^EAREST_NEIGHBOR (check OPC and DPC are on collected lmk) && OPC_STP (only sen t from STPs) • CORRELATE_TO JDESTTNATION (if DESTINATION pomt code is momtored) • check DESTINATION pomt code is 1 removed from OPC node • CORRELATE_TOJ 1ANGEOVER (check link to the DESTINATION pomt code for • previous Changeover • || LSSU • || FISU) • CORRELATE_TO J-INKJNHrBrr (outgomg case check lmk to the DESTINATION pomt code for receipt of Link Inhibit from an adjacent STP referencmg a hnk toward particular node) • CORRELATE_TO_TRANSFERJ J ROHΓBIT ( outgomg case- check lmk to the DESTINATION pomt code for receipt of Transfer Prohibit from an adjacent STP) • case B or D-links CHECK _OPCs • Scenario: Once the STP sends a Transfer Prohibit or Transfer Restnct message additional message traffic from the DESTINATION node should not occur Therefore, any messages to/from (especially from) the STP with the OPC = DESTINATION mdicates that the Transfer message probably was not sent by the STP and may have been inserted on the link. { • if OPC or DPC of any message = DESTINATION then ALARM } Transfer Restrict (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, DESTINATION) • Node and Cluster cases • LINK vTEARESTJMEIGHBOR (check OPC and DPC are on collected link) && OPC.STP (only sent from STPs) • CORR£LATE_TO J3ESTTNAΗON (if momtored) • check DESTINATION pomt code is 1 removed from OPC node • CORR£LATE_TOJTHANGEOVER (check link to the DESTINATION pomt code for • previous Changeover • || LSSU • !| FISU) APPENDIX E INTRUSION DETECTION ALGORITHMS • CORRELATE TO J-INKJNHIBIT (outgoing case check link to the DESTINATION point code for receipt of Link Inhibit from an adjacent STP referencing a link toward the DESTINATION node) • CORRELATE JO T*ANSFERJ>ROHIBIT ( outgomg case- check link to the DESTINATION pomt code for receipt of Transfer Prohibit from an adjacent STP) • case B or D-links CHECK OPCs • Scenario: Once the STP sends a Transfer Prohibit or Transfer Restnct message additional message traffic from the DESTINATION node should not occur Therefore, any messages to/from (especially from) the STP with the OPC = DESTINATION mdicates that the Transfer message probably was not sent by the STP and may have been inserted on the lmk. { • if OPC or DPC of any message = DESTINATION then ALARM Signaling Route Set Test (T10 expires) (TTMESTAMP, LINKJD, DIRECTION, OPC, DPC, DESTINATION) • Scenario: When an STP sends a Transfer Prohibit or Transfer Restnct message the receiv mg node will initiate a Test Message transaction over the same link as the Transfer message Therefore a Test Message should always be preceded by a Transfer message Once the STP sends a Transfer Prohibit or Transfer Restnct message additional message traffic to or from the DESTINATION node bemg refened should not occur Also, if a Transfer Allowed is the immediate response to the 1" Test Message then this may mdicate that the Test Message may have been the result of an inserted Transfer Prohibited or Transfer Restπcted message at the Test Message OPC node. • COUNT_CONSECUTTVΕ count the number of consecutive Test Messages which did not receive a Transfer Allowed response • CORRELATE_TO TRANSFER { • case: Test for Prohibit { • CORRELATE_TO_TRANFERJ>ROHTBIT(ιf a previous Transfer was not SENT by STP re: Destination, mdicates far-end got bogus Transfer) } • case: Test for Restnct { • CORRELATE TO TRANFERJIESTRICT (if a previous Transfer was not SENT by STP re: Destination, mdicates far-end got bogus Transfer) • if FAIL of BOTH correlations then ALARM Transfer Allowed (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, DESTINATION) • CORRELATE JΌ ΓRANSFER • Scenario: If a Transfer Prohibit or Restπcted message the same direction, did not precede a Transfer Allowed message this may mdicate that a Transfer Prohibit or Restπcted message was inserted at the Allowed OPC node on a different link { • if FAIL then ALARM } • CORRELATE_TO_l^TESTJvlESSAGE APPENDIX E INTRUSION DETECTION ALGORITHMS • Scenario: If a Transfer Allowed is the immediate response to the 1" Test Message then t his may indicate that the Test Message may have been the result of an inserted Transfer Prohibited or Transfer Restπcted message at the Test Message OPC node if Test Message counter- = 1 then ALARM Threshold Number of occurrences of Transfer Allowed reply to 1" Test Message } Link Unihibit (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • CORRELATE TOJNHTBIT ACK_T14 { • if occurs before Ack or Denied or Timeout then =>ALARM (possible Unmhibit insertion or Response to mserted Lmk Inhibit) } • CORRELATE TO REMOTE J.INK TEST { • if no Remote Link Test || if response to Local Lmk Test • => ALARM (possible Response to mserted Link Inhibit from different lmk or Uninhibit inser t ed) > • Threshold number of times Link Unmhibit is response to 1" Test cycle Link Force Unihibit (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • CORRELATE _TOJNHTBIT_ACK_T14 (no Uninhibit unnl Inhibit Ack or timeout) • CORRELATE _TO J-OCAL J.INK_TEST { • if no Local Lmk Test || if response to Remote Lmk Test • => ALARM (possible Response to mserted Link Inhibit from different link or Uninhibit inserted) } • Threshold number of times Lmk Force Unmhibit is response to 1" Test cycle Link Inhibit (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC • Threshold number of occurrences within Timepeπod • CHECK J^ORJΑTTERNS LC • LINK NEARESTJ TEIGHBOR (check OPC and DPC are on collected link) • case. LOCAL JNHIBIT (Lmkjnhibit sent from node) { • while T14 not expired && (Inhibit Ack or Inhibit Denied ) not received { • If Unmhibit or Inhibit sent: then => ALARM } • elsewbile Uninhibit not sent nor ForcedJJninhibit received: • The Inhibit was accepted and we are within the Test Message cycle • Scenario: If a Local Inhibit message was mserted we should see the ACK from the Remote node. Then when the T20 expires, no Local Inhibit Test message will be sent. However, at the remote end, T21 expires and a Remote Inhibit Test message will be sent to the local node. Smce the Local Node is not m the Inhibit mode, the Local node will respond with an Unmhibit message. This is the indicator that the oπgmal Lmk Inhibit message was mserted (or passed through the local node) to the Remote node. APPENDIX E INTRUSION DETECTION ALGORITHMS • when T20 expires check for lack of Local Inhibit Test AND • when T21 expires: check for Remote Inhibit Test received followed by Uninhibit sent • => soft alarm for 1" T20/T21 cycle • => threshold for multiple occurrence of I" cycle Unmhibit } OR { • when T20 expires: check for Local Inhibit Test sent followed by no reacnon received (snll remote inhibited) • when T21 expires, check for no action received (now remote UNinhibited) • when T20 expires 2 nd nme check for Local Inhibit Test sent followed by Forced JJninhibit received • => ALARM ( the Remote node should have sent a Forced JJnmhibit if it mi h a t ed the Unmhibit procedure Smce it only sent a Forced JJninhibit as a response t o t he Local Inhibit test this may mdicate the Remote node may be toggled back t o an Uninhibited mode via alternate path) } } • case- REMOTE JNHD3IT (Linkjnhibit received by node) { • while T14 not expued && Inhibit Ack not sent { • if Unmhibit received- ALARM • elsewhile ForcedJJmnhibit not sent || Uninhibit not received: (the INHIBIT has been accepted) { • (Same conditions as LOCAL CASE only reverse sent and received designators) Link Inhibit Ack (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • Scenario: no action is taken at the Local node when an unsolicited ACK is received (due to an inserted Lmk Inhibit => Tl .111 4-38. no action • LINK NEAREST ^EIGHBOR (check OPC and DPC are on collected link) • CORRELATE _TO JNHIBiT Link Inhibit Denied (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • LINK_NEARESTJMEIGHBOR (check OPC and DPC are on collected link) • CORRELATE _TOJNHIBIT_T14 • Threshold Consecutive Attempts { • if >2 then ALARM Link Local Test Signal (T20 expires) (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) • CORRELATE _TO JNHIBIT_T20 (no Inhibit sent is ALARM) • if 1 st Test && Forced Unmhibit received: soft ALARM Link Remote Test Signal (T21 expires) • CORRELATE _TO JNHIBIT T21 (no Inhibit received is ALARM) • if 1 st Test && Uninhibit received- soft ALARM 00/07312 APPENDIX E INTRUSION DETECTION ALGORITHMS Transfer Controlled (congestion throttling) • LINK _NEAREST_ EIGHBOR (check OPC and DPC are on collected link) && OPC 3TP (only sent from STPs) Signaling Route Set Congestion Test (T15/ T16 expires) • CORRELATE TO TRANSFER CONT ISUP Initial Address (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) • Scenario: store by CIC and TIMESTAMP use for correlation to REL. Illegal IAM messages in of t hemselves are not a significant threat to the network from a Service Disrupπon Denial aspect unless a flooding attack was minated to overwhelm network resources. Address Complete (TIMESTAMP. LINKJD, DIRECTION, OPC, DPC, CIC) store by CIC and TIMESTAMP use for correlanon Release (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC. CIC, CAL'SE_CODE) Threshold * Occurrences check for VALID JDPC on link check for VALID JDPC on link check TRUNK JvTEARESTJvΕIGHBOR CORRELATE_TOJAM check CAUSE JTODE Code 1 : unallocated number Code 3: no route Code 5 : misdialled trunk prefix Code 28: address incomplete Code 31 : normal unspecified { • CORRELATE TO_ACM (ACM must occur pπor to Normal Release) I Code 79: service or option not implemented Code 81 : invalid Call Reference Code 95: unspecified invalid message Code 97- message type non-existent Code 99, 100: invalid parameter Code 1 1 1. unspecified protocol error CHEC ΌR ΆTTER S ^C • Scenario: We are looking for the possibdity that an attack on tearing down calls would have a pattern in the voice trunk numbers under attack. This would be found by looking for non- random patterns in the CIC parameter of consecutive REL messages. One possibility is to attack starting at low CIC numbers since calls are assigned from low to high • sequential numbering 0,1,2,3...N • switch specific numbering (accounting for switch specific card /shelf distributions) Release Complete (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) CORRELATE JO REL || CORRELATE_TOJtESET || CORRELATE JTOJ3LO • Scenario: RLC is possible response to receiving any above. So, if none of these messages preceded the RLC then it is an indicator that any of these messages was inserted at the RLC OPC node over a APPENDIX E INTRUSION DETECTION ALGORITHMS different link. Furthermore, a Reset or Circuit Query response from the RLC indicates that the RLC was an unexpected message This is further evidence that the RLC OPC node did not send the Release, Reset, or Blocking message I • start timer and check for RESET || CIRCUIT QUERY (possible response to out of sequence RLC received at unaffected xchange due to mserted BLO) • case: BLO sent in same duection. ALARM • Scenario. A Blockmg message followed by an RLC observed in the same direction would occur only if the RLC OPC node received a Reset in a particular call state Therefore the Reset message should have been observed before the BLO If the Reset was not observed before this sequence than this mdicates that the Reset was inserted at the RLC OPC node over a different lmk. } } Group Reset (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC, RANGE) Check for pair of Group Resets within 5 seconds check for VALID JDPC/DPC check TRUNK_NEAREST_NEIGHBOR Threshold number of Occurrences within Timepeπod Reset (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) check for VALID OPC/DPC check TRUNK_NEAREST_NEIGHBOR Threshold number of Occurrences within Timepenod CHECK J^ORJ>ATTERNS_CIC • sequential numbering 0, 1,2,3...N • switch specific numbering (accounting for switch specific card /shelf distπbutions) set timer ( 15 seconds) and wait for Unequipped CORRELATE JOJU.C • Scenario A Reset or Circuit Query response from the RLC indicates that the RLC was an unexpected message. This is possible evidence that the RLC was the result of an mserted Release, Reset, or Bloc mg message at the RLC OPC node over a different lmk. Group Blocking (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC, RANGE) Check for pair of Group Blockmg within 5 seconds check for VALID JDPC DPC check TRUNK_NEAREST_NEIGHBOR Threshold number of Occurrences within Timepeπod Blocking (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) check for VALID J3PC DPC check TRUNK_NEAREST_NEIGHBOR Threshold number of Occurrences within Timepenod set timer (5 mm) and CORRELATE JO JJNBLOCK (should not be held longer) CHECK J : ORJ , ATTERNS iC sequennal numbeπng 0, 1,2,3...N • switch specific numbeπng (accounting for switch specific card /shelf distnbunons)- CORRELATEJΓOJJBLA • Scenario- An Blockmg message sent in response to an Unblocking Acknowledgment message mdicates that the UBLA was unexpected smce the CIC was not in a Local Unblocked state This could APPENDIX E INTRUSION DETECTION ALGORITHMS indicate that the UBLA was caused by an inserted Unblock to the UBLA OPC node over a different link • Threshold number of occurrences Blocking Ack (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) CORR£LATE_TOJ3L0 ( fail then- ALARM) • Scenario If a BLA received without see g a previous BLO then this mdicates that a BLO may hae been inserted at the BLA OPC node Unblock (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) • Scenario The system monitors for this message pnmaπly as indicator that some other message mav not be legitunate An illegal Unblockmg message in of itself would only serve to bring CICs back INTO service prematurely; this is not perceived as a significant threat to the network. CLEAR J3LO_TIMER • Scenario- a circuit should only remam m a Blocked condition for no longer than approximately 5 minutes (usually due to maintenance actions) CORRELATE_TOJ3LA • Scenario An Unblockmg message sent m response to a Blockmg Acknowledgment message mdica t es that the BLA was unexpected smce the CIC was not in a Local Blocked state This could mdica t e t ha t the BLA was caused by an mserted BLO to the BLA OPC node over a different link • Threshold number of occurrences Alarm aggregate to FAIL of BLA conelaπon to BLO Unequipped Circuit (TIMESTAMP. LINKJD, DIRECTION, OPC, DPC, CIC) • Scenario Unequipped response mdicates that the Release, Reset or Blockmg message was invalid smce there is no circuit to reset. This is not very common smce it mdicates that the trunk sta t us t ables are out of sync or that the Release, Reset or Blockmg messages are coming from a surce which has no knowledge of the trunking status. Therefore, a low threshold on the Unequipped messages is wananted CORRELATE _TO IEL || CORR£LATE_TO JIESET || CORRELATE JTOJ3LO Threshold number of Occurrences within Timepeπod per CIC (low threshold) CHECK J^ORJ^TTERNSJ IC sequennal numbeπng 0,1,2,3...N • switch specific numbeπng (accounting for switch specific card /shelf distnbuπons) Circuit Query (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) • Scenario- Circuit Query sent as a response to a particular message (vice on a penodic polled basis) mdicates a loss of sync in the trunking status tables. This is an event which should happen mfrequently. It could also mdicate that the node sendmg the offending message is not legitimate and is attempting to perform actions which are inconsistent with the actual trunk status. Alternatively, unsolicited Circuit Queπes can mdicate a "fishing expedition" by someone trying to build a database on the nerwork trunking. check for VALID OPC/DPC check TRUNK J EARESTJVEIGHBOR Threshold number of Occurrences within Timepeπod CORRELATE_TOJU.C • Threshold number of occurrences by CIC • Scenario: A Reset or Cucuit Query response from the RLC mdicates that the RLC was an unexpected message. This is possible evidence that the RLC was the result of an mserted Release, Reset, or Blockmg message at the RLC OPC node over a different nk. CORELLATE TO IAM (assuming momtormg A- lmk at STP) { O 00/07312 APPENDIX E INTRUSION DETECTION ALGORITHMS for both A-links { • lookup in Table IAM enter CIC, look for previous collected coπesponding IAM • where (IAM_TTMESTAMP < REL_TIMESTAMP) • && ((OPC = IAMJ3PC && DPC = IAM 3PC) || (OPC = LAM J3PC && DPC = IAMJ3PC) ) • if found • ( return PASS} • else • {return FAIL ALARM} TRUNK VEARESTJVEIGHBOR (This is based on mdividual C7RTE tables in the database) Overall. Check to see that the OPC and DPC of the ISUP messages: • have valid ISUP trunking relationships • were collected on the proper lmks Query database for C7RTE table for Pomt Code equal to either the message OPC or DPC • if Table Point Code = OPC (check for C7RTE Table for OPC) • ( • search for record entry with DPC • if found { Check_CurreπtJLink(RETURNJ-inkJD) ( veπfy A-link ID = Current Lmk ID) } case B-hnk: { Lookup JJ-LinkfRETURNJDPC) (Query SΪT _C7RTE Table with DPC to obtain proper B-hnk ID for route to DPC) Check rurrentJ πk(RETURNJ.ιnkTD) ( venfy B-link ID = Current Lmk ID) } else {RETURN } PC _NOTJ^7RTE} (the DPC was not a valid ISUP signaling partner) elseif Table Pomt Code = DPC (check for C7RTE Table for DPC) { search for record entry with OPC • if found • { • case A-hnk: • { • Cb∞k_CurrentJJnk(RETURNJ-ιnJcID) • ( veπfy A-hnk ED = Current Link ID) • { • LookupJJ-LinkfRETURNJ PQ • (Query STP T7RTE Table with OPC to obtain proper B-link ID for route to OPC) Ch∞k_CurreπtJJιri (RETURNJ,ιnkID) APPENDIX E INTRUSION DETECTION ALGORITHMS • ( verify B-link ID = Current Link ID) • } • else { RETURN J3PCJVOT C7RTE} (the OPC was not a valid ISUP signalmg partner) • } • else (Table Pomt Code did not match either OPC or DPC of message) • { RETUR JNVALID J>C} SCCP UDT: • case: GTT = TRUE ( lookup in GTE sWITCH: enter DPC, look for correspondmg CALLING PARTY PC if found { return pass} else {return fail} • case: UDT GTT = TRUE (SSN = 0) • { • lookup in Table IAM: enter CIC, look for previous collected eonespondmg IAM • where: (IA JTMESTAMP < R£L_TTMESTAMP) • case: REL_TOWARDJ5SP (IAM toward STP) • { • && (DPC = IAM OPC || lAMJDPC = STPJ>C) • if found • { return PASS} • else • {return FAIL ALARM } • } • case: REL_TOWARD STP (IAM toward SSP) • { • && (OPC = IAM _DPC II VJAM OPC = STP PC? 1 *) • if found • { return PASS} • else • {return FAIL ALARM } Algoπthms • Lmk Level • error message responses • FSN out of sequence • occurrence threshold • thresholding on each lmk by message type • number of occurrences • frequency of occurrences • patterns of circuits (REL , BLO) • sequential numbeπng 0, 1,2,3...N • switch specific numbering (accounting for card /shelf distnbuπons) • messages out of sequence ( • patterns of links (Changeover, Transfer Prohibit/Restnct) APPENDIX E INTkuSION DETECTION ALGORITHMS Level • correlate messages across links/linksets • look for FISU LSSU on links (Changeover, Transfer Prohibit Restrict) • look for low level outages across links/linksets

Claims: Claims: 1. An apparatus for providing indications of attempted intrusion in a telecommunications signaling network, comprising: means for receiving messages related to communications in the telecommunications signaling network; means for applying intrusion rules to the messages in order to order to detect anomalies in the messages; and means for reporting an indication of the detected anomalies. 2. The apparatus of claim I wherein the receiving means includes means for receiving predefined test messages. 3. The apparatus of claim 1 wherein the receiving means includes means for parsing and formatting the messages as required for the application of the intrusion rules. 4. The apparatus of claim I wherein the applying means includes means for comparing the messages with information related to a known protocol for the telecommunications signaling network. 5. The apparatus of claim I wherein the reporting means includes means for presenting in a user interface a topological representation of a portion of the telecommunications signaling network. 6. The apparatus of claim 5 wherein the reporting means includes means for presenting in the user interface indications of alarms representing the attempted intrusions. 7. An apparatus for determining a vulnerability of a telecommunications signaling network to attempted intrusions, comprising: means for receiving rankings for particular parameters related to elements of the telecommunications signaling network; means for applying vulnerability rules to the rankings in order to determine a i n likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network; and means for reporting an indication of the likelihood of the attempted intrusions. 8. The apparatus of claim 7 wherein the receiving means includes means for presenting a user interface for receiving the rankings. 9. The apparatus of claim 7 wherein the applying means includes means for combining the rankings according to particular criteria in order to produce numerical results providing indications of the likelihood of the attempted intrusions relative to the corresponding elements in the telecommunications signaling network. 10. The apparatus of claim 7 wherein the reporting means includes means for reporting a most vulnerable node and a most vulnerable link in the telecommunications signaling network. 11. A method for providing indications of attempted intrusion in a telecommunications signaling network, comprising: receiving messages related to communications in the telecommunications signaling network; applying intrusion rules to the messages in order to order to detect anomalies in the messages; and reporting an indication of the detected anomalies. 12. The method of claim 11 wherein the receiving includes receiving predefined test messages. 13. The method of claim 1 1 wherein the receiving includes parsing and formatting the messages as required for the application of the intrusion rules. 14. The method of claim 11 wherein the applying includes comparing the messages with information related to a known protocol for the telecommunications signaling network. 15. The method of claim 1 1 wherein the reporting includes presenting in a user interface a topological representation of a portion of the telecommunications signaling network. 16. The method of claim 15 wherein the reporting includes presenting in the user interface indications of alarms representing the attempted intrusions. 17. A method for determining a vulnerability of a telecommunications signaling network to attempted intrusions comprising: receiving rankings for particular parameters related to elements of the telecommunications signaling network, applying vulnerability rules to the rankings in order to determine a likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network; and reporting an indication of the likelihood of the attempted intrusions. 18. The method of claim 17 wherein the receiving includes presenting a user interface for receiving the rankings. 19. The method of claim 17 wherein the applying includes combining the rankings according to particular criteria in order to produce numerical results providing indications of the likelihood of the attempted intrusions relative to the corresponding elements in the telecommunications signaling network. 20. The method of claim 17 wherein the reporting includes reporting a most vulnerable node and a most vulnerable link in the telecommunications signaling network. AMENDED CLAIMS [received by the International Bureau on 20.December 1999 (20.12.99); original claims 1,2,4,5,7,11 and 17 replaced by amended claims bearing the same number; new claims 21 to 26 added; remaining claims unchanged (5 pages)] 1. An apparatus for providing indications of attempted intrusion in a telecommunications signaling network, comprising: means for receiving messages related to communications in the telecommunications signaling network; means for applying intrusion rules to the messages in order to detect anomalies in the messages; means for classifying the detected anomalies according to particular criteria; and means for reporting an indication of the classifications of the detected anomalies. 2. The apparatus of claim 1 wherein the receiving means includes means for receiving predefined test messages. 3. The apparatus of claim 1 wherein the receiving means includes means for parsing and formatting the message as required for the application of the intrusion rules. 4. The apparatus of claim 1 wherein the applying means includes means for comparing the messages with information related to a known protocol for the telecommunications signaling network. 5. The apparatus of claim 1 wherein in the reporting means includes means for presenting in a user interface a topological representation of a portion of the telecommunications signaling network. 6. The apparatus of claim 5 wherein the reporting means includes means for presenting in the user interface indications of alarms representing the attempted intrusions. 7. An apparatus for determining a vulnerability of a telecommunications signaling network to attempted intrusions, comprising: means for receiving rankings for particular parameters related to elements of the telecommunications signaling network; means for applying vulnerability rules to the rankings in order to determine a likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network, including means for determining a particular type of vulnerability of the corresponding elements; and means for reporting an indication of the likelihood of the attempted intrusions, including means for determining, based upon the particular type of vulnerability, an action ■ affecting the corresponding elements in order to reduce the likelihood of the attempted intrusion in the corresponding elements. 8. The apparatus of claim 7 wherein the receiving means includes means for presenting a user interface for receiving the rankings. 9. The apparatus of claim 7 wherein the applying means includes means for combining the rankings according to particular criteria in order to produce numerical results providing indications of the likelihood of the attempted intrusions relative to the corresponding elements in the telecommunications signaling network. 10. The apparatus of claim 7 wherein the reporting means includes means for reporting a most vulnerable node and a most vulnerable link in the telecommunications signaling network. 11. A method for providing indications of attempted intrusion in a telecommunications signaling network, comprising; receiving messages related to communications in the telecommunications signaling network; applying intrusion rules to the messages in order to detect anomalies in the messages; classifying the detected anomalies according to particular criteria; and reporting an indication of the classifications of the detected anomalies. 12. The method of claim 1 1 wherein the receiving includes receiving predefined test messages. 13. The method of claim 11 wherein the receiving includes parsing and formatting the messages as required for the application of the intrusion rules. 14. The method of claim 1 1 wherein the applying includes comparing the messages with information related to a known protocol for the telecommunications signaling network. 15. The method of claim 11 wherein the reporting includes presenting in a user interface a topological representation of a portion of the telecommunications signaling network. 16. The method of claim 15 wherein the reporting includes presenting in the user interface indications of alarms representing the attempted intrusions. 17. A method for determining a vulnerability of a telecommunications signaling network to attempted intrusions, comprising: receiving rankings for particular parameters related to elements of the telecommunications signaling network; applying vulnerability rules to the rankings in order to determine a likelihood of an attempted intrusion into the corresponding elements of the telecommunications signaling network, including determining a particular type of vulnerability of the corresponding elements; and reporting an indication of the likelihood of the attempted intrusions, including determining, based upon the particular type of vulnerability, an action affecting the corresponding elements in order to reduce the likelihood of the attempted intrusion in the corresponding elements. 18. The method of claim 17 wherein the receiving includes presenting a user interface for receiving the rankings. 19. The method of claim 17 wherein the applying includes combining the rankings according to particular criteria in order to produce numerical results providing indications of the likelihood of the attempted intrusions relative to the corresponding elements in the telecommunications signaling network. 20. The method of claim 17 wherein the reporting includes reporting a most vulnerable node and a most vulnerable link in the telecommunications signaling network. 21. The apparatus of claim 1 wherein the reporting means includes means for generating, based upon the intrusion rules, a time-stamped listing of the classifications of anomalies and the corresponding messages. 22. The apparatus of claim 1 wherein the reporting means includes means for generating statistics, based on particular criteria, concerning the messages. 23. An apparatus for providing indications of attempted intrusion in a telecommunications signaling network, comprising: means for receiving a first message related to communications in the telecommunications signaling network and referring to a particular link in the network; means for applying an intrusion rule to the first message in order to detect anomalies in the first message, including determining if a second message of a predefined type was previously detected on the particular link; and means for reporting an indication of the detected anomalies. 24. The method of claim 11 wherein the reporting includes generating, based upon the intrusion rules, a time-stamped listing of the classifications of anomalies and the corresponding messages. 25. The method of claim 11 wherein the reporting includes generating statistics, based on particular criteria, concerning the messages. 26. A method for providing indications of attempted intrusion in a telecommunications signaling network, comprising: receiving a first message related to communications in the telecommunications signaling network and referring to a particular link in the network; applying an intrusion rule to the first message in order to detect anomalies in the first message, including determining if a second message of a predefined type was previously detected on the particular link; and reporting an indication of the detected anomalies.

Inventors: CATHERINE GREGORY J, CONRAD BEVERLY, GEARHART G DUANE, GORMAN DAVID B, MOY DAVID, PERAGINE RICHARD, CATHERINE, GREGORY, J., CONRAD, BEVERLY, GEARHART, G., DUANE, GORMAN, DAVID, B., MOY, DAVID, PERAGINE, RICHARD
Applicants: GTE GOVERNMENT SYST, GTE GOVERNMENT SYSTEMS CORPORATION
Application year: 1999
Main classification: H04J3
IPC codes: G06F13, H04L12, H04L29, H04M3, H04Q3