(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0009699 A1
`Gupta et al.
`(43) Pub. Date:
`Jan. 9, 2003
`
`US 2003OOO9699A1
`
`(54) METHOD AND APPARATUS FOR
`DETECTING INTRUSIONS ON A
`COMPUTER SYSTEM
`
`(76) Inventors: Ramesh M. Gupta, San Jose, CA (US);
`Parveen K. Jain, San Jose, CA (US);
`Keith E. Amidon, Fremont, CA (US);
`Fengmin Gong, Livermore, CA (US);
`Srikant Vissamsetti, Fremont, CA
`(US); Steve M. Haeffele, Los Gatos,
`CA (US); Ananth Raman, San Jose,
`CA (US)
`
`Correspondence Address:
`COOLEY GODWARD, LLP
`3000 EL CAMINO REAL
`5 PALO ALTO SQUARE
`PALO ALTO, CA 94.306 (US)
`
`(21) Appl. No.:
`(22) Filed:
`
`10/172,756
`
`Jun. 13, 2002
`
`Related U.S. Application Data
`(60) Provisional application No. 60/298,220, filed on Jun.
`13, 2001.
`
`Publication Classification
`
`G06F 11/30
`5
`51) Int. Cl."
`; G06F 15/173
`1) Int. Cl. ..........................
`(52) U.S. Cl. ............................................ 713/201; 709/223
`
`ABSTRACT
`(57)
`A method of detecting intrusions on a computer includes the
`Step of identifying an internet protocol field range describing
`fields within internet protocol packets received by a com
`puter. A connectivity range is also established which
`describes a distribution of network traffic received by the
`computer. An internet protocol field threshold and a con
`nectivity threshold are then determined from the internet
`protocol field range and connectivity range, respectively.
`During the operation of the computer, values are calculated
`for the internet protocol field range and connectivity range.
`These values are compared to the internet protocol metric
`threshold and connectivity metric threshold so as to identify
`an intrusion on the computer.
`
`
`
`
`
`seniors /
`
`t
`
`20
`
`Redundant Sensor
`
`Global Sensor
`Management
`System
`
`34
`
`36
`
`38
`
`Juniper Ex. 1028-p. 1
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 1 of 18
`
`US 2003/0009699 A1
`
`re
`
`28-
`( ISP 1 )
`
`22-1
`27-1 -A
`F- s - arz-
`20
`EEI -25 /
`J. Redundant Sensor 1 r
`
`l
`
`SO
`
`L
`
`
`
`
`
`Global Sensor
`Management
`System
`
`Firewall
`
`Update
`Server
`
`34
`
`36
`
`38
`
`FIG. I.
`
`Juniper Ex. 1028-p. 2
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 2 of 18
`
`US 2003/0009699 A1
`
`40-1
`
`2/18
`40-N
`
`22
`/
`
`44
`
`42
`
`50 N Sensor Management Module
`
`Packet Decoder
`
`Load Balancer
`
`Statistical Analysis
`and DDOS Detection
`Module
`
`Anomaly Detector
`
`Fixed-Field Detector
`
`Protocol Parser
`
`
`
`
`
`
`
`
`
`o
`
`Classification and Pattern-Matching
`Module
`Intrusion
`Signatures
`
`Encrypted Session
`Monitoring Module
`
`Path Marker Insertion
`Module
`
`Failover Switch Module
`
`-
`
`52
`
`54
`
`80
`
`Information
`
`56
`58
`
`60
`
`62
`
`63
`64
`66
`
`67
`
`51
`53
`55
`
`68
`
`70
`
`72
`
`74
`
`61
`
`78
`
`FIG. 2
`
`Juniper Ex. 1028-p. 3
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`US 2003/0009699 A1
`
`98
`
`Z8
`
`
`
`
`
`
`
`Juniper Ex. 1028-p. 4
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 4 of 18
`
`US 2003/0009699 A1
`
`199uuOO
`
`80€IZ8
`
`103UuoO
`
`808 IZ8
`
`BI3) IS
`
`UUS?J?
`
`- - - - - • • • • • • • • •
`
`80€IZ8
`
`100UuoO
`ULIOIH
`
`S9IH CI
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Vf7 '91-I
`
`Juniper Ex. 1028-p. 5
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 5 of 18
`
`US 2003/0009699 A1
`
`r • • • • • • • • • • • • • • • •*
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Juniper Ex. 1028-p. 6
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 6 of 18
`
`US 2003/0009699 A1
`
`
`
`
`
`
`
`Juniper Ex. 1028-p. 7
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 7 of 18
`
`US 2003/0009699 A1
`
`9 ’91, H.
`
`
`
`
`
`
`
`68
`
`QUOCI
`
`----?
`
`NZ6
`
`86
`
`66
`
`96
`
`oinooxã T Z6KHL
`
`uo?sistien
`
`96
`
`
`
`21p15 1u2,umno
`
`
`
`suo?p307 pyp?I
`
`[6
`
`Juniper Ex. 1028-p. 8
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 8 of 18
`
`US 2003/0009699 A1
`
`One Column/State
`
`&
`
`<token n>
`
`
`
`O
`
`8
`
`16
`
`24
`
`31
`
`operation code.A.B.
`Val-AVB
`HValue -
`
`FIG. 8
`
`Juniper Ex. 1028-p. 9
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 9 of 18
`
`US 2003/0009699 A1
`
`SJØIV
`
`
`
`
`SCIISS) SCIIqnS QumbuïS|| prog-pox{J
`JO133)3CI
`
`SCIIV
`
`x{oemv
`J010919.GI| ||
`
`
`
`
`
`6 {OICH
`
`S10Xoed
`
`Juniper Ex. 1028-p. 10
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 10 of 18
`
`US 2003/0009699 A1
`
`
`
`
`
`
`
`-- Iz“ Kdoo
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Juniper Ex. 1028-p. 11
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 11 of 18 US 2003/0009699 A1
`
`
`
`if LocB70
`compare LocA to LocB
`else
`compare Locato Value field
`if LocA < Value
`execute following ops
`else
`skip following ops
`endif
`endif
`
`if LocBz 0
`compare Locato LocB
`else
`compare Loca to Value field
`if LocA3Value
`execute follwoing ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB 70
`compare LocA to LocB
`else
`compare LocA to Value field
`if LocA = Value
`execute following ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB 70
`compare Loca to LocB
`else
`compare Loca to Value field
`if LocA = Value
`execute following ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB 7: 0
`compare LocA to LocB
`else
`compare Loca to Value field
`if LocA> Value
`
`FIG. 1 IA
`
`Juniper Ex. 1028-p. 12
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 12 of 18 US 2003/0009699 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`else
`
`execute following ops until next else or fi
`else
`skip following ops
`endif
`| endif
`
`
`
`if LocBA 0
`compare Locato LocB
`else
`compare LocA to Value field
`if LocA > Value
`execute following ops until next else or fi
`else
`skip following ops
`endif
`| endif
`
`if (locA = ValueA) and (LocB = ValueB)
`execute following ops until next else or fi
`else
`skip following ops
`endif
`halt/resume instruction exection
`
`
`
`
`
`FIG. I. IB
`
`Juniper Ex. 1028-p. 13
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 13 of 18
`
`US 2003/0009699 A1
`
`
`
`
`
`©InpOWN
`osuodsºYI
`
`Xog?V
`
`JO1O349CI
`
`
`
`
`
`
`
`
`OHI H/9IH
`9) KAIS
`
`
`
`Z I ’91, H.
`
`Juniper Ex. 1028-p. 14
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 14 of 18 US 2003/0009699 A1
`
`100
`
`- 102
`
`I/O Devices
`
`
`
`
`
`106
`
`N
`
`Sensor Control Module
`
`VIDS Provisioning Module
`
`Realtime Signature Update
`Module
`
`
`
`
`
`
`
`
`
`
`
`
`108
`
`I 10
`
`112
`
`FIG. 13
`
`Juniper Ex. 1028-p. 15
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 15 of 18 US 2003/0009699 A1
`
`122
`
`
`
`I/O Devices
`
`r System Management
`
`Module
`
`VIDS Provisioning
`Module
`
`DDOS Tracking
`Monitor
`
`FIG. I.4
`
`Juniper Ex. 1028-p. 16
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 16 of 18 US 2003/0009699 A1
`
`-"
`
`142
`
`140
`
`I/O Devices
`
`ter
`
`
`
`
`
`
`
`
`
`Secure Update Download
`Module
`Attack File
`Hierarchical Attack
`Categorization
`Module
`
`SMS Alert Notification
`Module
`
`I49
`
`150
`
`
`
`152
`
`FIG. 15
`
`Juniper Ex. 1028-p. 17
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 17 of 18 US 2003/0009699 A1
`
`
`
`All attacks
`
`Dos
`
`Compromised auth.
`
`Policy violation
`f
`
`Windows
`
`solaris
`
`V2.5
`
`V2.6
`
`s
`
`FIG 16
`
`Juniper Ex. 1028-p. 18
`Juniper v Huawei
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 18 of 18 US 2003/0009699 A1
`
`re
`
`Construct a hierarchy characterizing
`different computer attacks and
`COuntermeasureS
`
`Traverse the hierarchy to identify
`computer attacks and countermeasures
`relevant to a target platform
`
`Collect detection and protection
`Measures for the target platform
`
`160
`
`I62
`
`I64
`
`
`
`
`
`
`
`Download the detection and
`protection measures to a security
`sensor associated with the target
`platform
`
`166
`
`
`
`FIG. I. 7
`
`Juniper Ex. 1028-p. 19
`Juniper v Huawei
`
`

`

`US 2003/0009699 A1
`
`Jan. 9, 2003
`
`METHOD AND APPARATUS FOR DETECTING
`INTRUSIONS ON A COMPUTER SYSTEM
`0001. This application claims priority to provisional
`patent application No. 60/298,220, which was filed on Jun.
`13, 2001.
`
`BRIEF DESCRIPTION OF THE INVENTION
`0002 This invention relates generally to computer net
`WorkS. More particularly, this invention relates to network
`Security Sensors and distributed network Security Sensor
`architectures used to implement intrusion detection and
`protection.
`
`BACKGROUND OF THE INVENTION
`0003. The prevalence of computer vulnerabilities and
`malicious computer hackerS is well documented. Thus, there
`are ongoing concerns about computer Security. Computer
`Security anxieties span a spectrum of computer configura
`tions, including individual computers, local area networks,
`and wide area networks.
`0004. There are a number of problems associated with
`current computer Security technologies. For example, while
`there is available information on different computer attacks
`and countermeasures, there are inadequate techniques for
`developing, deploying, and managing this information.
`Another computer Security problem relates to the distribu
`tion of evolving network Security information, Such as new
`computer attack profiles and signatures. It would be highly
`desirable to provide an efficient and rapid mechanism for
`distributing this information throughout a network.
`0005. As computer network traffic continues to grow,
`there are increasing demands to improve the processing
`efficiency of computer Security tasks. In order to achieve
`gigabit and higher intrusion detection Speeds, new methods
`and techniques are required for packet inspection and pro
`cessing. Ideally, Such methods and techniques would be
`Scalable and Support dynamic Signature Set updates.
`0006 Another problem with current computer security
`technologies is that they require a Single organization to
`own, maintain and control their own computer Security
`equipment. It would be highly desirable to allow different
`organizations to share computer Security resources through
`a Subscription-based intrusion detection platform.
`0007 Distributed denials of service attacks are a common
`problem in networked environments. A distributed denial of
`Service attack may take many forms. One common form of
`a distributed denial of Service attack is for a single computer
`to Send a message to a group of computers instructing the
`computers to access a target computer. The group of com
`puters then forwards the same message on to a Supplemental
`group of computers. Ultimately, the target computer is
`inundated with access requests and effectively shuts down.
`It would be highly desirable to identify a technique for
`detecting, tracing, and countering distributed denial of Ser
`Vice attackS.
`0008. In order to provide effective protection for existing
`computers and computer networks, it is necessary to address
`these numerous computer Security problems. Ideally, a
`Single platform and architecture could be deployed to
`address these problems. Such a System should be easy to
`
`deploy and manage, thereby providing a low cost of own
`ership. Notwithstanding these cost considerations, the Sys
`tem must have high performance, including the capacity to
`efficiently detect and protect against known and unknown
`computer attacks.
`
`SUMMARY OF THE INVENTION
`0009. A method of detecting intrusions on a computer
`includes the Step of identifying an internet protocol field
`range describing fields within internet protocol packets
`received by a computer. A connectivity range is also estab
`lished which describes a distribution of network traffic
`received by the computer. An internet protocol field thresh
`old and a connectivity threshold are then determined from
`the internet protocol field range and connectivity range,
`respectively. During the operation of the computer, Values
`are calculated for the internet protocol field range and
`connectivity range. These values are compared to the inter
`net protocol metric threshold and connectivity metric thresh
`old So as to identify an intrusion on the computer.
`0010. The invention provides a single platform and archi
`tecture to address a variety of network Security problems.
`The System of the invention is easy to deploy and manage,
`and thereby provides a low cost of ownership. However, the
`System of the invention also has high performance, includ
`ing the capacity to efficiently detect and protect against
`known and unknown computer attackS.
`
`BRIEF DESCRIPTION OF THE FIGURES
`0011. The invention is more fully appreciated in connec
`tion with the following detailed description taken in con
`junction with the accompanying drawings, in which:
`0012 FIG. 1 illustrates a computer network environment
`implementing the network Security techniques of the inven
`tion.
`0013 FIG. 2 illustrates a network security sensor imple
`mented in accordance with an embodiment of the invention.
`0014 FIG. 3 illustrates processing steps performed by an
`embodiment of the network security sensor of the invention.
`0.015 FIG. 4A illustrates an embodiment of a hardware
`Sensor management module utilized in accordance with an
`embodiment of the invention.
`0016 FIG. 4B illustrates a specific hardware implemen
`tation of a network Security Sensor of the invention.
`0017 FIG. 5 illustrates input and output information
`asSociated with the protocol parsing State machine of the
`invention.
`0018 FIG. 6 illustrates general state machine processing
`operations performed in accordance with an embodiment of
`the invention.
`0019 FIG. 7 illustrates a state machine transition table
`implemented in accordance with an embodiment of the
`invention.
`0020 FIG. 8 illustrates a transition operation specifica
`tion format utilized in accordance with an embodiment of
`the invention.
`
`Juniper Ex. 1028-p. 20
`Juniper v Huawei
`
`

`

`US 2003/0009699 A1
`
`Jan. 9, 2003
`
`FIG. 9 illustrates a signature processing architec
`0021
`ture utilized in accordance with an embodiment of the
`invention.
`0022 FIG. 10 illustrates an example of state machine
`processing performed in accordance with an embodiment of
`the invention.
`0023 FIGS. 11A & 11B illustrate exemplary state
`machine instructions to be carried out in accordance with an
`embodiment of the invention.
`0024 FIG. 12 illustrates an exemplary hardware con
`figuration for carrying out Signature processing operations in
`accordance with an embodiment of the invention.
`0.025
`FIG. 13 illustrates a sensor control system utilized
`in accordance with an embodiment of the invention.
`0.026
`FIG. 14 illustrates a global sensor management
`System implemented in accordance with an embodiment of
`the invention.
`0.027
`FIG. 15 illustrates an update server implemented
`in accordance with an embodiment of the invention.
`0028 FIG. 16 illustrates a hierarchical attack categori
`Zation Structure constructed and utilized in accordance with
`an embodiment of the invention.
`0029 FIG. 17 illustrates processing steps performed in
`accordance with a hierarchical attack categorization proceSS
`utilized in accordance with an embodiment of the invention.
`0.030. Like reference numerals refer to corresponding
`parts throughout the Several views of the drawings.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`FIG. 1 illustrates an exemplary computer network
`0.031
`20 incorporating network Security devices and processes
`associated with the invention. The network 20 includes a set
`of network Security Sensors 22 configured in accordance
`with the invention. Each Sensor 22 operates as a platform to
`implement local and distributed Security operations per
`formed in accordance with the invention. FIG. 1 illustrates
`a set of primary Sensors 22 and redundant Sensors 24.
`Preferably, a dedicated link 25 is positioned between the
`primary Sensors 22 and the redundant Sensors 24. AS dis
`cussed below, the primary Sensor 22 updates the redundant
`Sensor 24 with changes in the configuration data. This
`ensures that the primary Sensor 22 and the redundant Sensor
`24 are Synchronized and that the redundant Sensor 24 can be
`activated in the event of the failure of the primary sensor 22.
`0032. A sensor management system 26 is associated with
`a Sensor 22 or Set of Sensors 22 and 24. The Sensor
`management System provides Supervisory control of a Sen
`Sor 22. The Sensor management System 26 may be used to
`implement a shared-resource Virtual intrusion detection SyS
`tem, as discussed below. A Single Sensor management Sys
`tem 26 may be used to control multiple Sets of primary
`Sensors 22 and redundant Sensors 24.
`0033. The combination of the sensor 22, redundant sen
`Sor 24, and Sensor management System 26 is referred to as
`a local sensor security module 27. As shown in FIG. 1, local
`sensor security modules 27 may be distributed throughout a
`network. In this example, local Sensor Security modules
`
`271 through 27 N are positioned between an enterprise
`network 30 and Internet service providers 281 through
`28 N. In addition, a local sensor security module 27 0 is
`positioned between the enterprise network 30 and a pro
`tected server 32.
`0034. The operations of the local sensor security modules
`27 may be coordinated through a global Sensor management
`System 34. The global Sensor management System 34 per
`forms distributed System management operations and pro
`vides a global consolidated view of all Sensors and all the
`traffic these Sensors are monitoring. In addition, the global
`Sensor management System 34 Supports the implementation
`of a global shared-resource virtual intrusion detection Sys
`tem. In addition, the global Sensor management System 34
`tracks information from the local Sensor Security modules 22
`to identify and respond to distributed denial of service
`attackS.
`0035 FIG. 1 illustrates that the network 20 includes an
`update server 38. The update server 38 is used to coordinate
`the delivery of Signature and Software updates to the local
`sensor security modules 27, as discussed below. Preferably,
`the update server 38 is protected by a firewall 36.
`0036) The overall architecture of an embodiment of the
`invention has been described. Attention is now directed
`toward a more particular description of the individual com
`ponents of the architecture.
`0037 FIG. 2 illustrates a sensor 22 configured in accor
`dance with an embodiment of the invention. Preferably, the
`sensor 22 includes a set of processor 401 through 40 N,
`with each processor optimized to perform a different func
`tion, as discussed below. The processors 40 are connected to
`a System bus 42 or a Set of buses or a Switching fabric, which
`are represented by the Single System buS 42. Also connected
`to the system bus 42 is a set of input/output ports 44. The
`ports 44 provide interfaces for routing network traffic. In
`addition, they include interfaces for the Sensor management
`system 26.
`0038. In one configuration, the system bus 42 is also
`connected to a memory 50, which includes primary and/or
`secondary memory. The memory 50 stores a set of execut
`able programs utilized to implement functions of the inven
`tion. In an alternate embodiment of the invention, the
`executable programs are Stored in memory associated with
`each processor that executes a program.
`0039. In the embodiment of FIG. 2, the memory 50
`Stores a Sensor management module 52, which coordinates
`overall Sensor operations. Alternately, the Sensor manage
`ment module 52 may be implemented in a separate proces
`Sor or processor board used to coordinate overall Sensor
`operations. In the embodiment of FIG. 2, the memory 50
`Stores a response module 54 for coordinating responses to
`processing exceptions.
`0040. A packet decoder 56 is also stored in memory 50.
`The packet decoder 56 coordinates the decoding of network
`packets and performs protocol conformance verification.
`Alternately, the functionality of the packet decoder 56 is
`implemented with a dedicated processor 40. A load balancer
`58 is preferably used to distribute processing responsibilities
`acroSS the processors 40.
`0041
`FIG. 2 also illustrates a statistical analysis and
`distributed denial of Service detection module 60. This
`
`Juniper Ex. 1028-p. 21
`Juniper v Huawei
`
`

`

`US 2003/0009699 A1
`
`Jan. 9, 2003
`
`executable program analyzes Statistical patterns associated
`with processed traffic. In addition, it identifies distributed
`denial of Service attacks. A path marker insertion module 61
`is used to insert path markers into network traffic. The path
`markers are used to identify the actual path traversed by the
`distributed denial of Service attacks, as discussed below.
`0042. The memory 50 also stores an anomaly detector 62,
`which is used to identify network traffic anomalies indica
`tive of an attack. A fixed-field detector 63 and a protocol
`parser 64 are also stored in the memory 50. The protocol
`parser 64 is implemented with a set of State machines 66 and
`asSociated tables 67. AS discussed below, the State machines
`process a data Stream by generating intrusion detection
`information with each State transition. In combination, the
`fixed-field detector 63 and the protocol parser 64 operate as
`a signature processing System, as discussed below. Support
`ing this signature processing System is a Stream orderer 51
`that organizes data Streams for a token detector 53. In turn,
`this token detector 53 transmits tokens containing State
`information and other instructions for the protocol parser 64.
`0043. The memory 50 also stores a classification and
`pattern-matching module 68. This module has an associated
`set of intrusion signatures 70. The module is used to
`compare incoming network traffic with the Set of intrusion
`signatures 70, as discussed below.
`0044) The memory 50 also stores an encrypted session
`monitoring module 72. This module 72 allows the sensor 22
`to decrypt otherwise Secure network traffic in a non-intrusive
`manner. As discussed below, protected key information 76
`Stored within the Sensor 22 is used to implement the opera
`tions performed by the encrypted Session monitoring module
`72.
`004.5 The memory 50 also stores a data stream processor
`74. The data stream processor 74 reassembles IP fragments
`and sends the reassembled IP fragments back to the load
`balancer. In addition, the data Stream processor 74 reas
`sembles TCP streams and forwards the reassembled streams
`to the Signature and anomaly detection module 62.
`0046) The memory 50 also stores a fail-over Switch
`module 78. The fail-over Switch module 78 is used to
`Synchronize information between a primary Sensor 22 and a
`redundant Sensor 24 and to Switch control from the primary
`sensor 22 to the redundant sensor 24 in the event that the
`primary Sensor 22 fails.
`0047 The processing performed by the sensor 22 is more
`fully appreciated in connection with FIG. 3. FIG. 3 illus
`trates processing Steps performed by the Sensor 22. Incom
`ing traffic to the Sensor 22 is processed for packet decoding,
`protocol conformance verification and load balancing 81.
`The packet decoder 56 and load balancer 58 are used for this
`operation.
`0.048. The traffic is then processed for statistical analysis
`and distributed denial of service detection 82. These opera
`tions may be performed by module 60. Stream processing is
`then performed 83. This operation may be implemented with
`the data Stream processor 74. Signature and anomaly detec
`tion 84 is then performed. The anomaly detector 62 may
`perform these anomaly detection operations.
`0049. The overall processing is supervised through sen
`Sor management 86, which is implemented with the Sensor
`
`management module 52. A response module handles
`response processing 85. In particular, the response processor
`54 determines the response actions for the Specific attack.
`The response processor 54 is configured by the System
`administrator. Once configured, the response processor 54
`responds to specific attacks.
`0050 AS previously indicated, the sensor 22 may be
`implemented with a set of processors. The different software
`modules stored in memory 50 run on selected processors of
`the Set of processors. Thus, for example, the Sensor man
`agement module 52 has been implemented to run on a X86
`Single board computer, an example of which is illustrated in
`FIG. 4A. The packet decoder and load balancer have been
`implemented to run on two network processors (Sitera Prism
`IQ2000). The response processor 54 has been implemented
`to run on a set of high performance CPUs (e.g., the SiByte
`Mercurian SB-1250). The statistical analysis and distributed
`denial of service (DDOS) detection module has been imple
`mented to run on a co-processor (e.g., the FastChip Poli
`cyEdge processor). The classification and pattern-matching
`module has been implemented with a co-processor (e.g., the
`Switch-On PM2329). The anomaly detector 62 has been
`implemented to run on a set of high performance CPUs (e.g.,
`the Sitera Prism Connect 821308). FIG. 4B illustrates a
`Specific circuit topology used to implement an embodiment
`of the sensor 22. In this embodiment, Software modules
`executed by a processor are Stored in the primary memory
`asSociated with the processor.
`0051
`Returning to FIG. 3, after packet decoding and
`load balancing 80, statistical analysis and DDOS detection
`84 is performed. The statistical analysis and DDOS detec
`tion module 60 operates in connection with a path marker
`insertion module 61. The path marker insertion module 61
`inserts DDOS identification information into the network
`traffic processed by the sensor 22. The module 60 also
`monitors the DDOS identification information received
`from other upstream sensors in the network. When viola
`tions of DDOS detection profiles are observed, appropriate
`DDOS attack flags are set. This can result in remedial action
`performed at the Sensor 22. In addition, the attack flag signal
`is transported across the network to the protected computer
`32, which takes additional remedial actions to prevent the
`DDOS attack. Various techniques for implementing these
`operations are discussed below.
`0052 Returning to FIG. 2, the anomaly detector 62 is
`used to identify computer attacks. In this context, anomaly
`means any event, State, or behavior that is considered to be
`abnormal by certain pre-defined Standards. For example, the
`existence of a remote root shell on a System that only
`expected console root login is an anomaly. Seeing large
`numbers of Successive Small IP fragments is an anomaly. A
`web server suddenly seeing a lot of requests from new IP
`addresses may also be considered an anomaly.
`0053 Anomaly-based intrusion detection approaches
`complement the Signature-based approaches by offering a
`means to detect attacks whose Signatures are not yet known
`or attacks that exhibit modified behavior (e.g., intentionally
`Stealthy attacks or variants of existing attacks in new envi
`ronments). The term system refers to any entity whose
`relevant State or behavior is under observation. For example,
`it can be a host or Server, a given network application, or a
`perSon. The anomaly detector 62 is typically implemented in
`
`Juniper Ex. 1028-p. 22
`Juniper v Huawei
`
`

`

`US 2003/0009699 A1
`
`Jan. 9, 2003
`
`accordance with a number of operations. First, measures (or
`observations) of normalcy are defined for a given System.
`Next, a characterization of the normalcy of the System is
`created. This characterization is generally in a form of
`distributions for these measures or their derivatives. This
`may require a learning or training process. Next, an algo
`rithm for building a run-time characterization of the System
`is defined. Measures of discrepancy between the normalcy
`and the run-time characterization are then defined. Once
`again, this may require learning or training. The measure of
`discrepancy and the way the actual measurement is obtained
`can introduce inherent differences that are accounted for in
`the threshold determination Step. Finally, anomaly thresh
`olds for generating appropriate alarms are defined. This
`approach can be implemented using multiple techniques,
`including Statistical, neural nets, and other forms of learning
`mechanisms.
`0.054 The anomaly detector 62 creates a characterization
`of the normal behavior of the system in order to achieve
`accurate anomaly detection (i.e., with low false positive and
`low false negative rates). Since different Systems have
`different behaviors, a new characterization needs to be
`created for each new System to be protected through
`anomaly detection. In one embodiment of the invention, the
`anomaly detector 62 operates in two phases. In a training
`phase the target System needs to be in an attack-free State.
`Depending on the resource availability, training can be
`conducted either online or offline. In the online case, training
`data comes directly from the real-time traffic captured while
`the System is in operation. In the offline case, training data
`comes from previously captured traffic traces, which are
`Stored in a file. The length of the training phase will typically
`depend on the inherent variability of the System. Training
`can Stop automatically when certain Stability criteria have
`been met. However, the user should be able to turn on the
`training mode at any time.
`0055. After the conclusion of training, the anomaly
`detector 62 operates in a detection phase. The detection
`phase produces anomaly Scores for the observed packets
`based on the characteristic similarity between the observed
`and normal profile. A higher Score will indicate a higher
`degree of deviation from the normalcy and thus a Stronger
`intrusion alert.
`0056 While the training accounts for the difference in
`characteristics from System to System, there is also variabil
`ity in time (e.g., the time of day) that may be significant
`enough to require new profiles for effective detection. The
`anomaly detection module Supports the following general
`means for adaptation. First, an interface for human analysts
`is Supplied to allow the input of final alert assessment results
`and to keep track of the false alarm rate changes. In the case
`where the false alarm rate increases and Stays at a higher
`level, this is a good indication of a System/environment
`change that can be accounted for by re-training the anomaly
`detector 62. In the case where false alarm rates fluctuate
`periodically with time, it is a good indication that a new Set
`of profiles with a different periodicity is required.
`0057 Another adaptive technique that can be imple
`mented by the anomaly detection module 62 is to Support
`multiple profiles that can be dynamically updated with time,
`or equivalently one profile that adapts continuously but more
`quickly. To better Support creation of new profiles dynami
`
`cally, the anomalous packets should be kept in a log file until
`it is determined that they were normal, or to be moved to
`long-term archive. At that time, these logged packets can be
`used to create the new profiles or to re-train existing profiles.
`0058. The anomaly detector 62 has been implemented to
`detect two types of anomalies. The first type of anomaly is
`identified based upon a normal profile of non-attack Internet
`packets. This method helps detect those attacks that are
`realized through specially crafted packets or other attack
`packets, such as denial of service or DDOS attacks. The
`Second type of anomaly is identified based upon the normal
`traffic profile of a target domain, which may be a single
`host/Sever, a Sub-net, or an enterprise network. The detection
`is based on the change of traffic patterns over network linkS.
`0059. The first technique of profiling typical non-attack
`packets relies upon the occurrence or co-occurrence of
`values in a Selected Set of fields. That is, in the absence of
`active attacks, there are generally defined patterns or ranges
`of values taken by the header fields of a packet. These
`patterns can be identified through Statistical analysis or
`learned by artificial neural networks. These patterns can then
`be compared against the actual field values of a packet on the
`wire to detect abnormal packets. In one embodiment, this
`comparison is carried out by establishing a threshold at one
`extreme of the range or pattern in question, and checking to
`see if a packet's field value exceeds this threshold. In
`addit