(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0004689 A1
`Gupta et al.
`(43) Pub. Date:
`Jan. 2, 2003
`
`US 20030004689A1
`
`(54) HIERARCHY-BASED METHOD AND
`APPARATUS FOR DETECTING ATTACKS
`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
`ATTN: Patent Group
`Five Palo Alto Square
`3000 El Camino Real
`Palo Alto, CA 94.306-2155 (US)
`(21) Appl. No.:
`(22) Filed:
`
`10/172,764
`Jun. 13, 2002
`27 \
`
`
`
`Related U.S. Application Data
`(60) Provisional application No. 60/298,220, filed on Jun.
`13, 2001.
`
`Publication Classification
`
`(51) Int. Cl. ................................................. G06F 15/00
`(52) U.S. Cl. .............................................................. 702/188
`(57)
`ABSTRACT
`A method of provisioning a computer against computer
`attacks includes constructing a hierarchy characterizing dif
`ferent computer attacks and counter measures, and travers
`ing this hierarchy to identify computer attacks and counter
`measures relevant to a target platform. Detection and
`protection measures are collected in response to this travers
`ing. These detection and protection measures are then down
`loaded to a Security Sensor associated with the target plat
`form.
`This application claims priority to provisional patent appli
`cation 60/298,220, which was filed on Jun. 13, 2001.
`
`22-1
`
`Global Sensor
`Management
`System
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 1 of 18
`
`US 2003/0004689 A1
`
`
`
`Global Sensor
`Management
`System
`
`Firewall
`
`Update
`Server
`
`36
`
`38
`
`FIG. I.
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 2 of 18
`
`US 2003/0004689 A1
`
`40-1
`
`22
`40-N /
`
`44
`
`42
`
`50-N
`
`Sensor Management Module
`
`Packet Decoder
`
`Load Balancer
`
`Statistical Analysis
`and DDOS Detection
`Module
`
`Anomaly Detector
`
`Fixed-Field Detector
`
`Protocol Parser
`
`
`
`Stream Orderer
`
`Token Detector
`Attack Detector
`
`
`
`
`
`Classification and Pattern-Matching
`Module
`
`
`
`Intrusion
`Signatures
`
`Encrypted Session
`Monitoring Module
`
`Data Stream Processor
`
`Path Marker Insertion
`Module
`
`Failover Switch Module
`
`80
`
`52
`
`54
`Protected Key
`Information
`
`56
`58
`
`63
`
`64
`66
`67
`
`51
`
`53
`
`55
`
`68
`
`70
`
`72
`
`74
`
`61
`
`78
`
`FIG. 2
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 3 of 18
`
`US 2003/0004689 A1
`
`#8
`
`£8
`
`
`
`
`
`
`
`JOSu3S
`
`QUIQUIQ3eue W.
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 4 of 18
`
`US 2003/0004689 A1
`
`IDd
`
`
`youroyy”Was
`
`
`
`AY/TAO‘(auejdyorgLd’uonnjossissey))
`
`WVudsadddng
`
`VRDid
`
`joauuo7)
`80CT78
`SOR]IO}U]
`sopnpoy,
`
`wo
`
`BIOS
`
`Ws
`
`SOlIV
`
`wor
`
`yoouuo7
`aoeysoyuy
`
`80E1T8
`soTNpoy]
`
`BIOS
`
`wWsud
`
`sold@
`
`wo1y
`
`yoauuo7)
`SORTINUY
`
`80C178
`soTnpoy]
`
`BIDS
`
`wislid
`
`8914O
`
`wor]
`
`yoouuo’)
`
`JORTIOUT
`
`8078
`soTnpoy]
`
`BIDS
`
`tsud
`
`soldid
`
`
`
`ajOsuos[eLlag
`
`
`
`
`
`
`
`wrayskgxnur’]9ggipeppoquryvodTaN34
`
`Redacted
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003. Sheet 5 of 18
`
`US 2003/0004689 A1
`
`r - • • • • • • • • • • • • • • •*
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 6 of 18
`
`sindjngsjnduy
`
`
`
`peneONSpeypomndiyu0s
`
`so[qe|,wosLiedwu0;
`
`
`
`areygjueun)
`
`
`
`gyeB1SponsyuEd
`
`
`
`g[qu,WonTsuel
`
`
`ouyeyeaye\syUSLIND-Redwo19910(]
`SUOT}VOO]BVPJOa1819~-eeene,
`yorneyeyoxoRg-Udo,;7
`youyeyeusyO]-anrsty
`
`
`yoenyJoke]uoreoryddy-UdyO|,
`
`US 2003/0004689 A1
`
`CDIA
`
`suoneso'TBieg-69
`
`Redacted
`
`
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003. Sheet 7 of 18
`
`US 2003/0004689 A1
`
`9 {OI.H.
`
`
`
`
`
`Suo?pooT 01pCT
`
`68
`
`Z8
`
`88
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 8 of 18
`
`US 2003/0004689 A1
`
`One Column/State
`
`A
`
`B
`
`C
`
`<>
`
`
`
`GET
`
`&
`HTTP/1.0
`Accept:
`
`<token n>
`
`FIG. 7
`
`16
`
`24
`
`31
`
`O
`
`
`
`8
`
`AIB
`operation Code
`Vlievalue
`HValue —
`
`FIG. 8
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 9 of 18
`
`US 2003/0004689 A1
`
`SOTIVJ010040CI
`
`
`
`
`
`
`
`
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 10 of 18
`
`US 2003/0004689 A1
`
`
`
`
`
`-- Iz Kdoo
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 11 of 18 US 2003/0004689 A1
`
`
`
`if LocB70
`compare LocA to LocB
`else
`compare LocA to Value field
`if LocA < Value
`execute following ops
`else
`skip following ops
`endif
`endif
`
`if LocBz 0
`compare LocA to LocB
`else
`compare Locato Value field
`if LocA (Value
`execute follwoing ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB 70
`compare LocA to LocB
`else
`compare Locato Value field
`if LocAF Value
`execute following ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB 70
`compare Loca to LocB
`else
`compare Locato Value field
`if LocA = Value
`execute following ops until next else or fi
`else
`skip following ops
`endif
`endif
`if LocB7- 0
`compare Loca to LocB
`else
`compare LocA to Value field
`if LocAD Value
`
`FIG. 1 1A
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 12 of 18 US 2003/0004689 A1
`
`execute following ops until next else or fi
`else
`skip following ops
`endif
`endif
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`else
`f
`
`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
`| endif
`
`
`
`
`
`FIG. I. IB
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003. Sheet 13 of 18
`
`US 2003/0004689 A1
`
`
`
`
`
`
`
`
`
`31.KRIS
`
`
`
`VOdIH
`OHIH/9 IH
`9) KAIS
`
`Kueu]@,
`
`J010913CI
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`?OJ. 01?RIS
`
`
`
`XISBAL CICI[]
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 14 of 18 US 2003/0004689 A1
`
`-
`
`100
`
`I/O Devices
`
`
`
`106
`
`N
`
`Sensor Control Module
`
`
`
`
`
`
`
`
`
`VIDS Provisioning Module
`
`Realtime Signature Update
`Module
`
`110
`
`II 2
`
`FIG. 13
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 15 of 18 US 2003/0004689 A1
`
`122
`
`I/O Devices
`
`
`
`r
`
`System Management
`Module
`
`VIDS Provisioning
`Module
`
`DDOS Tracking
`Monitor
`
`FIG. 14
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 16 of 18 US 2003/0004689 A1
`
`-"
`
`142
`
`40
`
`te
`
`
`
`
`
`
`
`
`
`Secure Update Download
`Module
`Attack File
`Hierarchical Attack
`Categorization
`Module
`
`
`
`
`
`SMS Alert Notification
`Module
`
`149
`
`I50
`
`I52
`
`FIG. 15
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 17 of 18 US 2003/0004689 A1
`
`
`
`All attacks
`
`Compromised auth.
`
`Policy violation
`
`-
`
`Windows
`
`Solaris
`
`V2.5
`
`V2.6 5:-
`
`FIG. I6
`
`Redacted
`
`

`

`Patent Application Publication
`
`Jan. 2, 2003 Sheet 18 of 18 US 2003/0004689 A1
`
`re
`
`I60
`
`162
`
`I64
`
`I66
`
`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
`
`
`
`
`
`
`
`
`
`Download the detection and
`protection measures to a security
`sensor associated with the target
`platform
`
`FIG. 1 7
`
`Redacted
`
`

`

`US 2003/0004689 A1
`
`Jan. 2, 2003
`
`HIERARCHY-BASED METHOD AND APPARATUS
`FOR DETECTING ATTACKS ON A COMPUTER
`SYSTEM
`
`tem must have high performance, including the capacity to
`efficiently detect and protect against known and unknown
`computer attacks.
`
`BRIEF DESCRIPTION OF THE INVENTION
`0001. 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
`0002 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.
`0003. 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.
`0004 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.
`0005 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.
`0006 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.
`0007. 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
`
`SUMMARY OF THE INVENTION
`0008. A method of provisioning a computer against com
`puter attacks includes constructing a hierarchy characteriz
`ing different computer attacks and counter measures, and
`traversing this hierarchy to identify computer attacks and
`countermeasures relevant to a target platform. Detection and
`protection measures are collected in response to this travers
`ing. These detection and protection measures are then down
`loaded to a Security Sensor associated with the target plat
`form.
`0009. 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
`0010. The invention is more fully appreciated in connec
`tion with the following detailed description taken in con
`junction with the accompanying drawings, in which:
`0011 FIG. 1 illustrates a computer network environment
`implementing the network Security techniques of the inven
`tion.
`0012 FIG. 2 illustrates a network security sensor imple
`mented in accordance with an embodiment of the invention.
`0013 FIG. 3 illustrates processing steps performed by an
`embodiment of the network security sensor of the invention.
`0014 FIG. 4A illustrates an embodiment of a hardware
`Sensor management module utilized in accordance with an
`embodiment of the invention.
`0015 FIG. 4B illustrates a specific hardware implemen
`tation of a network Security Sensor of the invention.
`0016 FIG. 5 illustrates input and output information
`asSociated with the protocol parsing State machine of the
`invention.
`0017 FIG. 6 illustrates general state machine processing
`operations performed in accordance with an embodiment of
`the invention.
`0018 FIG. 7 illustrates a state machine transition table
`implemented in accordance with an embodiment of the
`invention.
`0019 FIG. 8 illustrates a transition operation specifica
`tion format utilized in accordance with an embodiment of
`the invention.
`0020 FIG. 9 illustrates a signature processing architec
`ture utilized in accordance with an embodiment of the
`invention.
`0021
`FIG. 10 illustrates an example of state machine
`processing performed in accordance with an embodiment of
`the invention.
`
`Redacted
`
`

`

`US 2003/0004689 A1
`
`Jan. 2, 2003
`
`0022 FIGS. 11A & 11B illustrate exemplary state
`machine instructions to be carried out in accordance with an
`embodiment of the invention.
`0023 FIG. 12 illustrates an exemplary hardware con
`figuration for carrying out Signature processing operations in
`accordance with an embodiment of the invention.
`0024 FIG. 13 illustrates a sensor control system utilized
`in accordance with an embodiment of the invention.
`0.025
`FIG. 14 illustrates a global sensor management
`System implemented in accordance with an embodiment of
`the invention.
`0.026
`FIG. 15 illustrates an update server implemented
`in accordance with an embodiment of the invention.
`0.027
`FIG. 16 illustrates a hierarchical attack categori
`Zation Structure constructed and utilized in accordance with
`an embodiment of the invention.
`0028 FIG. 17 illustrates processing steps performed in
`accordance with a hierarchical attack categorization proceSS
`utilized in accordance with an embodiment of the invention.
`0029. Like reference numerals refer to corresponding
`parts throughout the Several views of the drawings.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`0030 FIG. 1 illustrates an exemplary computer network
`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.
`0.031) 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.
`0.032 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.
`0033. 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.
`0034 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.
`0035) 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.
`0036 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 40 1 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.
`0037. 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.
`0038. 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.
`0039) 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.
`0040 FIG. 2 also illustrates a statistical analysis and
`distributed denial of Service detection module 60. This
`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.
`
`Redacted
`
`

`

`US 2003/0004689 A1
`
`Jan. 2, 2003
`
`0041. 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.
`0042. 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.
`0043. 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.
`0044) 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.
`0045. 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.
`0046) 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.
`0047 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.
`0.048. 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.
`
`0049 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.
`0050 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.
`0051
`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.
`0052 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
`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
`
`Redacted
`
`

`

`US 2003/0004689 A1
`
`Jan. 2, 2003
`
`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.
`0053. 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.
`0.054
`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.
`0055 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.
`0056. 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.
`0057 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.
`0058. 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
`addition, some “forbidden' rules are manually introduced to
`ensure that certain packets are always flagged due to their
`potential damaging impact. For example, a ping packet
`(ICMPECHO REQ) with multicast/broadcast destinations is
`a cause for concern, and is thus an anomaly.
`0059 Advantageously, such normal profiles can be cre
`ated from packet traces generated entirely from known
`non-attack implementations of the protocols. Thus, it is not
`necessary to learn the profiles during a guaranteed attack
`free Session.
`0060. By way of example, three types of packets can be
`characterized: TCP, UDP, and ICMP. In the case of TCP and
`UDP packets, one embodiment of the invention establishes
`normal profiles characterizing the contents of (or, in Some
`cases, simply checking certain values of) one or more packet
`fields. The first of such fields, which can also b