WO2000007312A1 - System for intrusion detection and vulnerability analysis in a telecommunications signaling network - Google Patents

System for intrusion detection and vulnerability analysis in a telecommunications signaling network Download PDF

Info

Publication number
WO2000007312A1
WO2000007312A1 PCT/US1999/017408 US9917408W WO0007312A1 WO 2000007312 A1 WO2000007312 A1 WO 2000007312A1 US 9917408 W US9917408 W US 9917408W WO 0007312 A1 WO0007312 A1 WO 0007312A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
messages
signaling network
intrusion
telecommunications signaling
Prior art date
Application number
PCT/US1999/017408
Other languages
French (fr)
Inventor
David B. Gorman
Gregory J. Catherine
Richard Peragine
Beverly Conrad
G. Duane Gearhart
David Moy
Original Assignee
Gte Government Systems Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gte Government Systems Corporation filed Critical Gte Government Systems Corporation
Priority to EP99937710A priority Critical patent/EP1101304A1/en
Priority to JP2000563018A priority patent/JP2002521775A/en
Priority to AU52488/99A priority patent/AU5248899A/en
Publication of WO2000007312A1 publication Critical patent/WO2000007312A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling

Definitions

  • the present invention relates to a system and method for detecting intrusion into, and for assessing the vulnerability of, a telecommunications signaling network.
  • 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.
  • 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.
  • 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.
  • intrusions create an undesirable situation for communications service providers and for customers using the network.
  • the disruptions or denials of service may inconvenience customers and potentially cause a loss in revenue for the communications service provider.
  • a service provider may attempt to locate the disruption and determine a cause of the intrusion.
  • 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.
  • 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.
  • 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
  • FIG. 7 is an exemplary user interface for displaying information related to a vulnerability analysis of a telecommunications signaling network.
  • 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.
  • 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.
  • intrusion detection and vulnerability analysis are 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.
  • 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.
  • 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.
  • 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
  • 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.
  • intrusion detection process 206 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.
  • 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.
  • 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.
  • 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.
  • a percent utilization 401 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.
  • 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.
  • 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.
  • 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.
  • the system 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.
  • 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.
  • 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
  • Appendix E includes a description of exemplary intrusion detection algorithms including intrusion rules.
  • GUI Graphical User Interface
  • 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
  • SS7 Signaling System 7
  • PSTN Public Switched Telephone Network
  • 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.
  • 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.
  • 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
  • ISUP ISDN User Part
  • the current SS7 message is finally stored, to be used in t he next anomaly test
  • GUI Graphical User Interface
  • 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
  • a nerwork topology display depicts the network elements (m this case SS7 nodes and links).
  • the GUI 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
  • 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
  • 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
  • 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.
  • 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).
  • the Data Collector can manage inputs from a live message stream from a protocol analyzer source, or from a test file, or both.
  • the Message Parser is invoked to reformat the SS7 data into a condensed format needed by the Intrusion Detector process.
  • 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 strig ⁇ os without the need to inject anomalies onto the actual network.
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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
  • 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:
  • a N Advanced Intelligent Network
  • POTS Plain Old Telephone Service
  • 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
  • the nodes are p ⁇ ma ⁇ ly evaluated to determme their c ⁇ cality to the overall nerwork operanons and thus desirability to attack
  • 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
  • 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
  • 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
  • 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 , ⁇ . .
  • 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
  • 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
  • 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
  • the Network Topology Database provides the Vulnerability Analyzer algo ⁇ thms with the required relevant infrastructure data of the SS7 network.
  • 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.
  • 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.
  • the database 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.
  • 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.).
  • 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.
  • FIGURE 6- 1 VULNERABILITY ANALYSIS TOP LEVEL GUI 20
  • 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
  • This Software Users Manual 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)
  • $(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
  • 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.
  • GUI Graphical User Interface
  • the application provides the capability to save and retrieve both configuration and output log files via the GUI .APPENDIX B SOFTWARE USER'S MANUAL
  • 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
  • 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
  • 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
  • the applicanon provides the capability to terminate execution of the application usmg the 'File Exit" menu option provided by the GUT
  • 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 ⁇ .
  • 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.
  • 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
  • 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.
  • 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
  • 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
  • GUI Graphical User Interface
  • the applicanon provides the capability to save and remeve both configuranon and analysis result files via the GUI under the File selecnon
  • 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
  • the remeve selecnon allows the user to remeve an analysis results log or to remeve an existing configuranon file
  • 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
  • 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
  • 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
  • the applicanon provides the user with the capability to start and stop processmg of the application usmg the "Control Stan” and the "Control
  • 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).
  • 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.
  • 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 enclosed 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.
  • vulnerabilit _hel ⁇ - This is the flat file containing the help text for the main Vulnerability
  • the followmg secnons descnbe the expected outputs provided by the System Vulnerability Analyzer application.
  • 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.
  • 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
  • FIGURE 3-2 SCENARIO DIAGRAM PASSING A MESSAGE EXAMPLE 7
  • FIGURE 4-2 SYSTEM CLASS CATEGORY DIAGRAM 11
  • FIGURE 4-3 CONTEXT DIAGRAM INTRUSION DETECTOR DISPLAY MANAGER 12
  • 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
  • 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
  • This Design Desc ⁇ ption 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.
  • ONT Object Modeling Technique
  • 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
  • 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
  • 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
  • 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.
  • 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.
  • Figure 0-2 is an example strig ⁇ 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.
  • 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
  • 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.
  • 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.
  • 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.
  • Process Manager stores followmg mformation about the child: i) the child's process identification assigned by the UNIX kernel
  • the section defines the implementation of the System's self-test requirements
  • 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.
  • the architecture includes two ( 2) mdependent applicanons, the Intrusion Detector and the Vulnerabili t y
  • 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
  • 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.
  • 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.
  • 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.
  • the message queue is the method used for all interprocess communication to and from the Display Management process.
  • 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.
  • 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.
  • 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-
  • This message is also used by the Display Management process as a heartbeat indicanon from the Intrusion Detecnon process
  • 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.
  • 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)
  • 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
  • the Display Management process implements the followmg funcnonality a) Operator Console Management a) Process Management
  • the Display Management process 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)
  • 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 )
  • 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
  • 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 Rin is based on the "Alarm type" data field from the anomaly detection message.
  • 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.
  • the mterfaces of Data Collector are shown in Figure 0-4. Each of these mterfaces is detaded in the followmg subsecnons.
  • 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
  • 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
  • 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
  • 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.
  • the Data Collector class is the mam class of this process. Its responsibility is to create and control its subclasses at a high level
  • the MessageQueue class resides in the Common Infrastructure category. It is this class that represents the IPC method used by the Data Collector.
  • 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
  • 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
  • the Clock class is used by the Data Collector as the mam tuner of the process
  • Figure 0-6 is the high level strig ⁇ 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.
  • 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.
  • theClock::SetTimer() The timer is setup and used to control the test message l ⁇ jecnon mto the SS7 message stream from the UNIX file.
  • 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.
  • 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.
  • 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:
  • 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
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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
  • This secnon details the Display Management process's interprocess communicanon to and from t he Vulnerability Analysis process.
  • 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
  • the Vulnerability Analyzer's Display Management process sends its own ANALYZE indicanon to the Vulnerability Analysis Process.
  • the Display Management 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.
  • 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.
  • 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
  • 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.
  • this process analyzes and ranks each link and node within the GTE SS7 nerwork on its potennal vulnerability to mtrusion. O 00/07312
  • 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.
  • 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.
  • a COMPLETION message is sent to the Display Management process, indicating that the analysis results are available for display.
  • 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.
  • This three parry library is a collecnon of utility routines that is our main interface to this database
  • 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.
  • the database 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
  • 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.
  • ⁇ 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.
  • Ve ⁇ fy the OPC of this message corresponds to a Signaling Transfer Pomt (STP)
  • STP Signaling Transfer Pomt
  • Ve ⁇ fy the destinano ⁇ pomt code 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)
  • 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:
  • 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
  • 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.
  • Logical-number-LinksPerLinkset APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS
  • 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
  • SCP Node Criticality ( Average of Service Desirability Rankmgs) * ⁇ (SSPs w/ access via SCP to desired service) * (Normalized Node Capacity)

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 to 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 disruption 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 industrv 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 existing 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 the goals of the system program has been to base rtv , .
Figure imgf000017_0001
2. References
The following documents provide background information and are incoφorated herein by reference
DOCUMENT No. TITLE
[ 1 ] ANSI T1 1 1 1-1992
Signaling System Number 7, Message Transfer Part (MTP), American National Standards Institute Inc , 1992
[2] ANSI T1 1 13- 1995
Signaling System Number 7, ISDN User Part (ISUP), Ameπcan National Standards Institute Inc , 1995
3. Intrusion Detection Tool 3.1 Concept of Operation
Figure imgf000017_0002
mdicated to the user by coloring the links on the topolog,c7n p § m0m0Te D"ee*d
3.1.1 Concept of Execution
The Intrusion Detector analyzes each new messaee rec ^ A
Figure imgf000017_0003
The following conditions 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)
Figure imgf000017_0004
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 the 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 imgf000018_0001
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 imgf000020_0001
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 SS7 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 imgf000022_0001
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 inherent vulnerabihty attribute scores At the end of the inherent link vulnerab.l.tv ,n,ι . . modified one last time by the number of hops the link ,s from the cπtica not Z « , * "" greater number of hops from me arget e less . e,y me inseπed ^^ ffi^ ^
The majority of the link attributes relate to inherent vulnerabilities of the links to SS7 m«« aimed at affecting 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
• whether the transmission faci πes are operated bv a non f.TF ,„,,„, .« .
• amount message traffic oπgmatmg external to the GTE network anH th^ -Λ, unknown sources. d *erefore c°™ng from potentially
• whether STP screenmg is voked and the robustness of the screening logic
4.2 Interfaces
The context diagram, shown in Figure 4-4, idennfies the mult [Prt „~ A _. followmg subsections address these interfaces. P "^ by ώ'S Subsystem ™e
Network
Topology
Database
Figure imgf000023_0001
Figure 4-4 - Vulnerability Analyzer Context Diagram 4.2.1 User Interface
The User Interface is the mechanism used for control and receive analysis results for display 4.2.1.1 Control and configuration
In response to a control message from the GUI subsystem, the Vulnerability Analyzer accepts the followmg lnformaπ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 imgf000025_0001
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
Figure imgf000026_0001
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
Figure imgf000030_0001
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 the 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 imgf000032_0001
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
Figure imgf000033_0001
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 connected 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 Staπ" 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
Figure imgf000034_0001
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
Figure imgf000035_0001
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 adjustable 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
Figure imgf000038_0001
36
SUBSTITUTE SHEET CRULE 26) APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000039_0001
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000040_0001
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000041_0001
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
Figure imgf000041_0002
.APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000042_0001
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000043_0001
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 imgf000045_0001
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
Figure imgf000046_0001
APPENDIX B
SOFTWARE USER'S MANUAL
Figure imgf000047_0001
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
Figure imgf000047_0002
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
Figure imgf000048_0001
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000049_0001
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
Figure imgf000049_0002
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
Figure imgf000051_0001
Table 7-2 - Node Types
NODE ΥPES Table Description APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000052_0001
Table 7-3 - Links Table Description
Figure imgf000052_0002
Figure imgf000052_0003
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000053_0002
Table 7-4 - Link Services Table Description
Figure imgf000053_0001
Figure imgf000053_0003
APPENDIX B SOFTWARE USER'S MANUAL
Table 7-6 - SCP Services Table Description
Figure imgf000054_0001
Figure imgf000054_0003
Table 7-8 - STP Services Table Description
Figure imgf000054_0002
APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000055_0004
Table 7-9 - SSP Table Description
Figure imgf000055_0001
Table 7-10 - SSP Service Table Description
Figure imgf000055_0002
Table 7-11 - Network Codes Description
Figure imgf000055_0005
Table 7-12 - Trunk Neighbor Description
Figure imgf000055_0003
Table 7-13 - Locations Table Description
LOCATIONS Table Description APPENDIX B SOFTWARE USER'S MANUAL
Figure imgf000056_0001
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 imgf000063_0001
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 data flow between the different processes and the external interfaces of the Intrusion Detector and the Vulnerability applications
The architecture includes two (2) mdependent applicanons, the Intrusion Detector and the Vulnerability
Analyzer, each with its own GUI environment These processes and the interfaces are discussed in greater
Figure imgf000066_0001
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 imgf000067_0001
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
Figure imgf000071_0001
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 imgf000073_0001
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 the 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 imgf000075_0001
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 imgf000076_0001
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 Management 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 the 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 future 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 operator 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 the 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 (indicating 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 the 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 the
Vulnerability Analysis process in suppoπ of its algoπthms. a) Operanonal Control Messagmg The following indicanons are sent to the V ulnerability
Analysis Process to control its flow of operanon i) ANALYZE message - This indicates to begin its analysis usmg its current 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 imgf000080_0001
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 adjusuble 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 inhibit patterns of each linkset and identifies any non-random inhibiπng of consecutive SLCs of a linkset 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 the followmg condinons are FALSE: i) Veπfy that a LINK INHIBIT ACKNOWLEDGE message was previously detected on the same link the opposite direcnon (OPCs and DPCs are reversed) This message must 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 detected 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 the 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 type ISLT are analyzed for mconsistenc.es within their dau field, « -„ to the SS7 ANSI specification. The ISLT tests descπbed within this section are only fn l ? ^ currently being monitored by the Secure? IDS. y erformed °" 'wks a) The followmg SS7 MSU of type ISUP are suppoπed by the Secure? IDS
0 Ininal Address n) Address Complete ιu) Release ιv) Release Complete b) For all SS7 MSU messages, the followmg acπoπs and checks will be performed.
.) Mainuin and threshold the number of occurrences of each of the MSU rvpes and functions to its correspondmg adjusuble threshold. An alarm ,s declare^, GUI and log file if the number of occurrences exceed its correspondmg threshold in Validate SS7 trunk connection between the message's OPC and DPC , TR l "W
NEAREST NEIGHBOR test) An alarm ,s declared to the GUT andToe m ^nπϋ relanonship does not exist. This check w,H also venfy oπ * ^ ^ not equal the designanon 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,™ tests are performed. An alarm ,s declared to the GUI and log file ,f any of the followmg conlons are FALSE
.) Venfy that the CIC, referenced by the INITIAL ADDRESS message, was not currently allocated a) Address Complete- Upon reception of a ADDRESS COMPLETE ISLT message, no additional
a)
Figure imgf000085_0001
U
Figure imgf000085_0002
0 Maintain the number of occurrences of each of the followmg cause codes and threshold with their corresponding adjusuble threshold. An alarm is declared to the GUI and log file if the 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 adjusuble 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 trunk. 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
Figure imgf000092_0001
Phvsical-media-provider
Figure imgf000092_0002
Functional-services (attack desirability based on user scenano- USER INPUT )
Figure imgf000092_0003
Funcnonal-Capacιty-%-Unlιzaπon
Figure imgf000092_0004
0/07312
.APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS
Functιonal-capacιty-% internally generated
Figure imgf000093_0001
Funcrional-secuπty-eπcryprion:
• If the link is encrypted, then the overall Secuπty Ranking = 1 (no other influences to Security)
Figure imgf000093_0002
Funcnonal-secunty-screening:
Currently screenmg ALL on EXTERNAL links.(far end Point Code NOT GTE (NOT= 240 ) use:
Figure imgf000093_0003
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
Figure imgf000094_0001
Attribute Relationships (Algorithms)
Physical-media-tvpe &.&. Phvsical-Media-provider
Figure imgf000094_0002
• Funcπonal-Services-Mulnple
Figure imgf000094_0003
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
Figure imgf000095_0001
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
Figure imgf000095_0002
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
Figure imgf000096_0001
• 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)
Figure imgf000096_0002
• 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
Figure imgf000096_0003
• Funcnonal-Secuπtv-Screenmg && Funcπonal-Secuπtv-Monitonng-
Figure imgf000096_0004
APPENDIX D VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS
Functional-Services &.&. Funcnonal-Secuntv
Figure imgf000097_0001
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 =
Figure imgf000097_0002
APPENDIX D VULNERABILI TY ANALYSIS ATTRIBUTES AND ALGORITHMS
Figure imgf000098_0001
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 =
Figure imgf000098_0002
When physical access is high-range Vulnerability is not influenced very heavily but is modified as follows
Figure imgf000098_0003
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)
Figure imgf000099_0001
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
Figure imgf000099_0002
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 OccupancyMrrtJ / ( ∑ι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 :
Figure imgf000101_0001
Capacitv -number-alternates- (how many other nodes can provide same funcnon in auto alt routing- ignore SSPs)
Figure imgf000101_0002
implies all other directly connected STPs at same level with routes toward same service
Secuπty-physical
Figure imgf000101_0003
APPENDIX D VULNERABILu Y ANALYSIS ATTRIBUTES AND ALGORITHMS
Secuπty-observanon:
Figure imgf000102_0001
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 )
•
Figure imgf000103_0001
(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 sent 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_TRANSFERJJROHΓ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 this 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 inserted)
>
• 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 2nd nme check for Local Inhibit Test sent followed by Forced JJninhibit received
• => ALARM ( the Remote node should have sent a Forced JJnmhibit if it mihated the Unmhibit procedure Smce it only sent a Forced JJninhibit as a response to the Local Inhibit test this may mdicate the Remote node may be toggled back to 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 themselves 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
Figure imgf000108_0001
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 mdicates that the BLA was unexpected smce the CIC was not in a Local Blocked state This could mdicate that 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 status tables 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
Figure imgf000110_0001
{ 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)
Figure imgf000110_0002
• {
• 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.
PCT/US1999/017408 1998-07-31 1999-07-30 System for intrusion detection and vulnerability analysis in a telecommunications signaling network WO2000007312A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP99937710A EP1101304A1 (en) 1998-07-31 1999-07-30 System for intrusion detection and vulnerability analysis in a telecommunications signaling network
JP2000563018A JP2002521775A (en) 1998-07-31 1999-07-30 Intrusion detection and vulnerability analysis system in telecommunication signal network
AU52488/99A AU5248899A (en) 1998-07-31 1999-07-30 System for intrusion detection and vulnerability analysis in a telecommunications signaling network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/127,241 1998-07-31
US09/127,241 US6711127B1 (en) 1998-07-31 1998-07-31 System for intrusion detection and vulnerability analysis in a telecommunications signaling network

Publications (1)

Publication Number Publication Date
WO2000007312A1 true WO2000007312A1 (en) 2000-02-10

Family

ID=22429056

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/017408 WO2000007312A1 (en) 1998-07-31 1999-07-30 System for intrusion detection and vulnerability analysis in a telecommunications signaling network

Country Status (6)

Country Link
US (1) US6711127B1 (en)
EP (1) EP1101304A1 (en)
JP (1) JP2002521775A (en)
KR (1) KR100718023B1 (en)
AU (1) AU5248899A (en)
WO (1) WO2000007312A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000054521A (en) * 2000-06-09 2000-09-05 김상돈 System and method for blocking an attack from hacking robot program
KR20010103201A (en) * 2000-05-06 2001-11-23 조용학 The checking system against infiltration of hacking and virus
KR20010105490A (en) * 2000-05-10 2001-11-29 이영아 Hacking detection and chase system
KR100383224B1 (en) * 2000-05-19 2003-05-12 주식회사 사이젠텍 Linux-Based Integrated Security System for Network and Method thereof, and Semiconductor Device Having These Solutions
EP1488316A2 (en) * 2002-03-08 2004-12-22 Ciphertrust, Inc. Systems and methods for enhancing electronic communication security
US7036148B2 (en) 2001-05-08 2006-04-25 International Business Machines Corporation Method of operating an intrusion detection system according to a set of business rules
US7739082B2 (en) 2006-06-08 2010-06-15 Battelle Memorial Institute System and method for anomaly detection
US8214497B2 (en) 2007-01-24 2012-07-03 Mcafee, Inc. Multi-dimensional reputation scoring
US8549611B2 (en) 2002-03-08 2013-10-01 Mcafee, Inc. Systems and methods for classification of messaging entities
US8561167B2 (en) 2002-03-08 2013-10-15 Mcafee, Inc. Web reputation scoring
US8631495B2 (en) 2002-03-08 2014-01-14 Mcafee, Inc. Systems and methods for message threat management
US8763114B2 (en) 2007-01-24 2014-06-24 Mcafee, Inc. Detecting image spam
WO2019004859A1 (en) * 2017-06-30 2019-01-03 Siemens Aktiengesellschaft Method for monitoring an analytical system for stream data
WO2022161607A1 (en) * 2021-01-27 2022-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Computer-implemented method and arrangement for classifying anomalies
US11582249B2 (en) 2019-11-27 2023-02-14 Telefonaktiebolaget Lm Ericsson (Publ) Computer-implemented method and arrangement for classifying anomalies

Families Citing this family (128)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL143573A0 (en) 1998-12-09 2002-04-21 Network Ice Corp A method and apparatus for providing network and computer system security
US7346929B1 (en) * 1999-07-29 2008-03-18 International Business Machines Corporation Method and apparatus for auditing network security
US7073198B1 (en) 1999-08-26 2006-07-04 Ncircle Network Security, Inc. Method and system for detecting a vulnerability in a network
US8006243B2 (en) * 1999-12-07 2011-08-23 International Business Machines Corporation Method and apparatus for remote installation of network drivers and software
US6957348B1 (en) * 2000-01-10 2005-10-18 Ncircle Network Security, Inc. Interoperability of vulnerability and intrusion detection systems
WO2001084775A2 (en) * 2000-04-28 2001-11-08 Internet Security Systems, Inc. System and method for managing security events on a network
US7574740B1 (en) 2000-04-28 2009-08-11 International Business Machines Corporation Method and system for intrusion detection in a computer network
JP4700884B2 (en) * 2000-04-28 2011-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーション Method and system for managing computer security information
US7380272B2 (en) * 2000-05-17 2008-05-27 Deep Nines Incorporated System and method for detecting and eliminating IP spoofing in a data transmission network
US7058976B1 (en) 2000-05-17 2006-06-06 Deep Nines, Inc. Intelligent feedback loop process control system
US20040073617A1 (en) 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
AU2001281150A1 (en) * 2000-08-07 2002-02-18 Xacct Technologies Limited System, method and computer program product for processing network accounting information
US7181769B1 (en) 2000-08-25 2007-02-20 Ncircle Network Security, Inc. Network security system having a device profiler communicatively coupled to a traffic monitor
US9280667B1 (en) 2000-08-25 2016-03-08 Tripwire, Inc. Persistent host determination
US9027121B2 (en) 2000-10-10 2015-05-05 International Business Machines Corporation Method and system for creating a record for one or more computer security incidents
US7146305B2 (en) * 2000-10-24 2006-12-05 Vcis, Inc. Analytical virtual machine
US7130466B2 (en) * 2000-12-21 2006-10-31 Cobion Ag System and method for compiling images from a database and comparing the compiled images with known images
US6850253B1 (en) * 2000-12-26 2005-02-01 Nortel Networks Limited Representing network link and connection information in a graphical user interface suitable for network management
US20020147803A1 (en) * 2001-01-31 2002-10-10 Dodd Timothy David Method and system for calculating risk in association with a security audit of a computer network
JP2002330177A (en) * 2001-03-02 2002-11-15 Seer Insight Security Inc Security management server and host sever operating in linkage with the security management server
DE60135449D1 (en) * 2001-06-14 2008-10-02 Ibm Intrusion detection in data processing systems
US7657419B2 (en) * 2001-06-19 2010-02-02 International Business Machines Corporation Analytical virtual machine
US6513122B1 (en) 2001-06-29 2003-01-28 Networks Associates Technology, Inc. Secure gateway for analyzing textual content to identify a harmful impact on computer systems with known vulnerabilities
EP1280298A1 (en) * 2001-07-26 2003-01-29 BRITISH TELECOMMUNICATIONS public limited company Method and apparatus of detecting network activity
US20030084319A1 (en) * 2001-10-31 2003-05-01 Tarquini Richard Paul Node, method and computer readable medium for inserting an intrusion prevention system into a network stack
US20030084328A1 (en) * 2001-10-31 2003-05-01 Tarquini Richard Paul Method and computer-readable medium for integrating a decode engine with an intrusion detection system
US8266703B1 (en) 2001-11-30 2012-09-11 Mcafee, Inc. System, method and computer program product for improving computer network intrusion detection by risk prioritization
US6546493B1 (en) 2001-11-30 2003-04-08 Networks Associates Technology, Inc. System, method and computer program product for risk assessment scanning based on detected anomalous events
US7673137B2 (en) * 2002-01-04 2010-03-02 International Business Machines Corporation System and method for the managed security control of processes on a computer system
US7694128B2 (en) * 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for secure communication delivery
US7458098B2 (en) * 2002-03-08 2008-11-25 Secure Computing Corporation Systems and methods for enhancing electronic communication security
US7693947B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for graphically displaying messaging traffic
US8132250B2 (en) * 2002-03-08 2012-03-06 Mcafee, Inc. Message profiling systems and methods
US7903549B2 (en) * 2002-03-08 2011-03-08 Secure Computing Corporation Content-based policy compliance systems and methods
US6941467B2 (en) * 2002-03-08 2005-09-06 Ciphertrust, Inc. Systems and methods for adaptive message interrogation through multiple queues
US7124438B2 (en) * 2002-03-08 2006-10-17 Ciphertrust, Inc. Systems and methods for anomaly detection in patterns of monitored communications
US8578480B2 (en) 2002-03-08 2013-11-05 Mcafee, Inc. Systems and methods for identifying potentially malicious messages
US7870203B2 (en) 2002-03-08 2011-01-11 Mcafee, Inc. Methods and systems for exposing messaging reputation to an end user
US7737134B2 (en) * 2002-03-13 2010-06-15 The Texas A & M University System Anticancer agents and use
US6715084B2 (en) * 2002-03-26 2004-03-30 Bellsouth Intellectual Property Corporation Firewall system and method via feedback from broad-scope monitoring for intrusion detection
US7370360B2 (en) * 2002-05-13 2008-05-06 International Business Machines Corporation Computer immune system and method for detecting unwanted code in a P-code or partially compiled native-code program executing within a virtual machine
US20030229703A1 (en) * 2002-06-06 2003-12-11 International Business Machines Corporation Method and apparatus for identifying intrusions into a network data processing system
US20060010209A1 (en) * 2002-08-07 2006-01-12 Hodgson Paul W Server for sending electronics messages
KR100456635B1 (en) * 2002-11-14 2004-11-10 한국전자통신연구원 Method and system for defensing distributed denial of service
US6834409B2 (en) * 2002-12-23 2004-12-28 Nordock, Inc. Dock leveler
US7913303B1 (en) 2003-01-21 2011-03-22 International Business Machines Corporation Method and system for dynamically protecting a computer system from attack
WO2004084083A1 (en) * 2003-03-19 2004-09-30 Unisys Corporation Server consolidation analysis
US7730175B1 (en) 2003-05-12 2010-06-01 Sourcefire, Inc. Systems and methods for identifying the services of a network
US8201249B2 (en) * 2003-05-14 2012-06-12 Northrop Grumman Systems Corporation Steady state computer intrusion and misuse detection
US7926113B1 (en) * 2003-06-09 2011-04-12 Tenable Network Security, Inc. System and method for managing network vulnerability analysis systems
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US9118711B2 (en) * 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US20070113272A2 (en) 2003-07-01 2007-05-17 Securityprofiling, Inc. Real-time vulnerability monitoring
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
JP2005108099A (en) * 2003-10-01 2005-04-21 Hitachi Ltd Information security policy evaluation system and its control method
US7657938B2 (en) * 2003-10-28 2010-02-02 International Business Machines Corporation Method and system for protecting computer networks by altering unwanted network data traffic
CA2733172C (en) * 2004-05-07 2011-10-25 Sandvine Incorporated Ulc A system and method for detecting sources of abnormal computer network messages
US8171555B2 (en) 2004-07-23 2012-05-01 Fortinet, Inc. Determining technology-appropriate remediation for vulnerability
US20060018478A1 (en) * 2004-07-23 2006-01-26 Diefenderfer Kristopher G Secure communication protocol
US7665119B2 (en) 2004-09-03 2010-02-16 Secure Elements, Inc. Policy-based selection of remediation
US7761920B2 (en) * 2004-09-03 2010-07-20 Fortinet, Inc. Data structure for policy-based remediation selection
US7774848B2 (en) 2004-07-23 2010-08-10 Fortinet, Inc. Mapping remediation to plurality of vulnerabilities
US7539681B2 (en) * 2004-07-26 2009-05-26 Sourcefire, Inc. Methods and systems for multi-pattern searching
US7672948B2 (en) * 2004-09-03 2010-03-02 Fortinet, Inc. Centralized data transformation
US7703137B2 (en) * 2004-09-03 2010-04-20 Fortinet, Inc. Centralized data transformation
US7451486B2 (en) * 2004-09-30 2008-11-11 Avaya Inc. Stateful and cross-protocol intrusion detection for voice over IP
US20060080738A1 (en) * 2004-10-08 2006-04-13 Bezilla Daniel B Automatic criticality assessment
US8635690B2 (en) 2004-11-05 2014-01-21 Mcafee, Inc. Reputation based message processing
US20060168193A1 (en) * 2004-11-23 2006-07-27 Gerald Starling Methods, computer program products, and systems for detecting incidents within a communications network
US7602731B2 (en) * 2004-12-22 2009-10-13 Intruguard Devices, Inc. System and method for integrated header, state, rate and content anomaly prevention with policy enforcement
US7626940B2 (en) * 2004-12-22 2009-12-01 Intruguard Devices, Inc. System and method for integrated header, state, rate and content anomaly prevention for domain name service
US9167471B2 (en) 2009-05-07 2015-10-20 Jasper Technologies, Inc. System and method for responding to aggressive behavior associated with wireless devices
US7937480B2 (en) * 2005-06-02 2011-05-03 Mcafee, Inc. Aggregation of reputation data
US20080209566A1 (en) * 2005-06-30 2008-08-28 Raw Analysis Ltd. Method and System For Network Vulnerability Assessment
US7733803B2 (en) * 2005-11-14 2010-06-08 Sourcefire, Inc. Systems and methods for modifying network map attributes
US8046833B2 (en) * 2005-11-14 2011-10-25 Sourcefire, Inc. Intrusion event correlation with network discovery information
US7681132B2 (en) * 2006-07-13 2010-03-16 International Business Machines Corporation System, method and program product for visually presenting data describing network intrusions
US7948988B2 (en) * 2006-07-27 2011-05-24 Sourcefire, Inc. Device, system and method for analysis of fragments in a fragment train
US7701945B2 (en) * 2006-08-10 2010-04-20 Sourcefire, Inc. Device, system and method for analysis of segments in a transmission control protocol (TCP) session
EP2076866A2 (en) * 2006-10-06 2009-07-08 Sourcefire, Inc. Device, system and method for use of micro-policies in intrusion detection/prevention
US8266702B2 (en) * 2006-10-31 2012-09-11 Microsoft Corporation Analyzing access control configurations
US7949716B2 (en) 2007-01-24 2011-05-24 Mcafee, Inc. Correlation and analysis of entity attributes
US8179798B2 (en) * 2007-01-24 2012-05-15 Mcafee, Inc. Reputation based connection throttling
US7779156B2 (en) * 2007-01-24 2010-08-17 Mcafee, Inc. Reputation based load balancing
US8069352B2 (en) * 2007-02-28 2011-11-29 Sourcefire, Inc. Device, system and method for timestamp analysis of segments in a transmission control protocol (TCP) session
WO2008134057A1 (en) * 2007-04-30 2008-11-06 Sourcefire, Inc. Real-time awareness for a computer network
US8185930B2 (en) 2007-11-06 2012-05-22 Mcafee, Inc. Adjusting filter or classification control settings
US8045458B2 (en) * 2007-11-08 2011-10-25 Mcafee, Inc. Prioritizing network traffic
US8458648B2 (en) * 2007-12-10 2013-06-04 International Business Machines Corporation Graphical modelization of user interfaces for data intensive applications
US8589503B2 (en) 2008-04-04 2013-11-19 Mcafee, Inc. Prioritizing network traffic
US8474043B2 (en) * 2008-04-17 2013-06-25 Sourcefire, Inc. Speed and memory optimization of intrusion detection system (IDS) and intrusion prevention system (IPS) rule processing
PL2157731T3 (en) * 2008-08-18 2011-12-30 Abb Technology Ag Analysing communication configuration in a process control system
US8272055B2 (en) 2008-10-08 2012-09-18 Sourcefire, Inc. Target-based SMB and DCE/RPC processing for an intrusion detection system or intrusion prevention system
JP2011123781A (en) * 2009-12-14 2011-06-23 Seiko Epson Corp Electronic apparatus and method of controlling the same
US8438270B2 (en) 2010-01-26 2013-05-07 Tenable Network Security, Inc. System and method for correlating network identities and addresses
US8302198B2 (en) 2010-01-28 2012-10-30 Tenable Network Security, Inc. System and method for enabling remote registry service security audits
US8707440B2 (en) * 2010-03-22 2014-04-22 Tenable Network Security, Inc. System and method for passively identifying encrypted and interactive network sessions
EP2559217B1 (en) 2010-04-16 2019-08-14 Cisco Technology, Inc. System and method for near-real time network attack detection, and system and method for unified detection via detection routing
US8549650B2 (en) 2010-05-06 2013-10-01 Tenable Network Security, Inc. System and method for three-dimensional visualization of vulnerability and asset data
US8621638B2 (en) 2010-05-14 2013-12-31 Mcafee, Inc. Systems and methods for classification of messaging entities
US8433790B2 (en) 2010-06-11 2013-04-30 Sourcefire, Inc. System and method for assigning network blocks to sensors
US8671182B2 (en) 2010-06-22 2014-03-11 Sourcefire, Inc. System and method for resolving operating system or service identity conflicts
US8938531B1 (en) 2011-02-14 2015-01-20 Digital Defense Incorporated Apparatus, system and method for multi-context event streaming network vulnerability scanner
US8601034B2 (en) 2011-03-11 2013-12-03 Sourcefire, Inc. System and method for real time data awareness
US9367707B2 (en) 2012-02-23 2016-06-14 Tenable Network Security, Inc. System and method for using file hashes to track data leakage and document propagation in a network
US9043920B2 (en) 2012-06-27 2015-05-26 Tenable Network Security, Inc. System and method for identifying exploitable weak points in a network
US9088606B2 (en) 2012-07-05 2015-07-21 Tenable Network Security, Inc. System and method for strategic anti-malware monitoring
WO2014105995A1 (en) * 2012-12-27 2014-07-03 Jasper Wireless, Inc. A system and method for responding to aggressive behavior associated with wireless devices
US9467464B2 (en) 2013-03-15 2016-10-11 Tenable Network Security, Inc. System and method for correlating log data to discover network vulnerabilities and assets
US9172721B2 (en) 2013-07-16 2015-10-27 Fortinet, Inc. Scalable inline behavioral DDOS attack mitigation
US9973528B2 (en) 2015-12-21 2018-05-15 Fortinet, Inc. Two-stage hash based logic for application layer distributed denial of service (DDoS) attack attribution
US10764321B2 (en) * 2016-03-24 2020-09-01 Lenovo Enterprise Solutions (Singapore) Pte. Ltd Identifying and remediating at-risk resources in a computing environment
US10367846B2 (en) 2017-11-15 2019-07-30 Xm Cyber Ltd. Selectively choosing between actual-attack and simulation/evaluation for validating a vulnerability of a network node during execution of a penetration testing campaign
US10581802B2 (en) 2017-03-16 2020-03-03 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems, and computer readable media for advertising network security capabilities
EP3632009A1 (en) * 2017-05-31 2020-04-08 Telefonaktiebolaget LM Ericsson (publ) Methods and apparatus for maintenance in an optical communication network
US10382473B1 (en) * 2018-09-12 2019-08-13 Xm Cyber Ltd. Systems and methods for determining optimal remediation recommendations in penetration testing
US11283827B2 (en) 2019-02-28 2022-03-22 Xm Cyber Ltd. Lateral movement strategy during penetration testing of a networked system
US11206281B2 (en) 2019-05-08 2021-12-21 Xm Cyber Ltd. Validating the use of user credentials in a penetration testing campaign
US10637883B1 (en) * 2019-07-04 2020-04-28 Xm Cyber Ltd. Systems and methods for determining optimal remediation recommendations in penetration testing
US10880326B1 (en) 2019-08-01 2020-12-29 Xm Cyber Ltd. Systems and methods for determining an opportunity for node poisoning in a penetration testing campaign, based on actual network traffic
US11533329B2 (en) 2019-09-27 2022-12-20 Keysight Technologies, Inc. Methods, systems and computer readable media for threat simulation and threat mitigation recommendations
US11005878B1 (en) 2019-11-07 2021-05-11 Xm Cyber Ltd. Cooperation between reconnaissance agents in penetration testing campaigns
US11575700B2 (en) 2020-01-27 2023-02-07 Xm Cyber Ltd. Systems and methods for displaying an attack vector available to an attacker of a networked system
US11582256B2 (en) 2020-04-06 2023-02-14 Xm Cyber Ltd. Determining multiple ways for compromising a network node in a penetration testing campaign

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5440723A (en) * 1993-01-19 1995-08-08 International Business Machines Corporation Automatic immune system for computers and computer networks
US5586254A (en) * 1992-02-13 1996-12-17 Hitachi Software Engineering Co., Ltd. System for managing and operating a network by physically imaging the network
US5621889A (en) * 1993-06-09 1997-04-15 Alcatel Alsthom Compagnie Generale D'electricite Facility for detecting intruders and suspect callers in a computer installation and a security system including such a facility
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5757924A (en) * 1995-09-18 1998-05-26 Digital Secured Networks Techolognies, Inc. Network security device which performs MAC address translation without affecting the IP address

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586254A (en) * 1992-02-13 1996-12-17 Hitachi Software Engineering Co., Ltd. System for managing and operating a network by physically imaging the network
US5440723A (en) * 1993-01-19 1995-08-08 International Business Machines Corporation Automatic immune system for computers and computer networks
US5621889A (en) * 1993-06-09 1997-04-15 Alcatel Alsthom Compagnie Generale D'electricite Facility for detecting intruders and suspect callers in a computer installation and a security system including such a facility
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5757924A (en) * 1995-09-18 1998-05-26 Digital Secured Networks Techolognies, Inc. Network security device which performs MAC address translation without affecting the IP address

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010103201A (en) * 2000-05-06 2001-11-23 조용학 The checking system against infiltration of hacking and virus
KR20010105490A (en) * 2000-05-10 2001-11-29 이영아 Hacking detection and chase system
KR100383224B1 (en) * 2000-05-19 2003-05-12 주식회사 사이젠텍 Linux-Based Integrated Security System for Network and Method thereof, and Semiconductor Device Having These Solutions
KR20000054521A (en) * 2000-06-09 2000-09-05 김상돈 System and method for blocking an attack from hacking robot program
US7036148B2 (en) 2001-05-08 2006-04-25 International Business Machines Corporation Method of operating an intrusion detection system according to a set of business rules
US8561167B2 (en) 2002-03-08 2013-10-15 Mcafee, Inc. Web reputation scoring
US8631495B2 (en) 2002-03-08 2014-01-14 Mcafee, Inc. Systems and methods for message threat management
EP1488316A4 (en) * 2002-03-08 2010-07-28 Mcafee Inc Systems and methods for enhancing electronic communication security
US8549611B2 (en) 2002-03-08 2013-10-01 Mcafee, Inc. Systems and methods for classification of messaging entities
EP1488316A2 (en) * 2002-03-08 2004-12-22 Ciphertrust, Inc. Systems and methods for enhancing electronic communication security
US7739082B2 (en) 2006-06-08 2010-06-15 Battelle Memorial Institute System and method for anomaly detection
US8763114B2 (en) 2007-01-24 2014-06-24 Mcafee, Inc. Detecting image spam
US8214497B2 (en) 2007-01-24 2012-07-03 Mcafee, Inc. Multi-dimensional reputation scoring
US9009321B2 (en) 2007-01-24 2015-04-14 Mcafee, Inc. Multi-dimensional reputation scoring
US9544272B2 (en) 2007-01-24 2017-01-10 Intel Corporation Detecting image spam
US10050917B2 (en) 2007-01-24 2018-08-14 Mcafee, Llc Multi-dimensional reputation scoring
WO2019004859A1 (en) * 2017-06-30 2019-01-03 Siemens Aktiengesellschaft Method for monitoring an analytical system for stream data
US11582249B2 (en) 2019-11-27 2023-02-14 Telefonaktiebolaget Lm Ericsson (Publ) Computer-implemented method and arrangement for classifying anomalies
US11838308B2 (en) 2019-11-27 2023-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Computer-implemented method and arrangement for classifying anomalies
WO2022161607A1 (en) * 2021-01-27 2022-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Computer-implemented method and arrangement for classifying anomalies

Also Published As

Publication number Publication date
KR20010072141A (en) 2001-07-31
KR100718023B1 (en) 2007-05-14
EP1101304A1 (en) 2001-05-23
AU5248899A (en) 2000-02-21
US6711127B1 (en) 2004-03-23
JP2002521775A (en) 2002-07-16

Similar Documents

Publication Publication Date Title
WO2000007312A1 (en) System for intrusion detection and vulnerability analysis in a telecommunications signaling network
US7360090B1 (en) Method of and apparatus for authenticating control messages in a signaling network
EP0866626B1 (en) Method for querying replicated databases
US6333931B1 (en) Method and apparatus for interconnecting a circuit-switched telephony network and a packet-switched data network, and applications thereof
US6151390A (en) Protocol conversion using channel associated signaling
US5764955A (en) Gateway for using legacy telecommunications network element equipment with a common management information protocol
AU702328B2 (en) Mediation of open advanced intelligent network in SS7 protocol open access environment
US5953404A (en) Method and system for providing mediated access between signaling networks
US7594009B2 (en) Monitoring network activity
US7046778B2 (en) Telecommunications portal capable of interpreting messages from an external device
EP0804841B1 (en) Method for comparing attribute values of controllable object expressions in a network element
US7043000B2 (en) Methods and systems for enhancing network security in a telecommunications signaling network
US7401360B2 (en) Methods and systems for identifying and mitigating telecommunications network security threats
JPH09512976A (en) How to test an intelligent network
US8505087B2 (en) Signal transfer point front end processor
EP0792075A2 (en) Message modification apparatus for use in a telecommunication signalling network
WO1994005112A1 (en) System and method for creating, transferring, and monitoring services in a telecommunication system
EP1974282A2 (en) Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment
WO2001019010A1 (en) Ss7 firewall system
US7184538B1 (en) Method of and apparatus for mediating common channel signaling message between networks using control message templates
US7224686B1 (en) Method of and apparatus for mediating common channel signaling messages between networks using a pseudo-switch
US7218613B1 (en) Method and apparatus for in context mediating common channel signaling messages between networks
Cisco Appendix A Result Type Definitions
Cisco Appendix A
Cisco MML Command Reference Chapter of the Cisco MGC Software MML Command Reference Guide

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 1020017001333

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 1999937710

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999937710

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1020017001333

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 1020017001333

Country of ref document: KR