This application is related to U.S. patent application Ser. No. 10/456,837, filed Jun. 6, 2003, which is a continuation-in-part of: U.S. patent application Ser. No. 09/757,963, filed Jan. 10, 2001, U.S. patent application Ser. No. 09/757,872, filed Jan. 10, 2001, and U.S. patent application Ser. No. 09/648,211, filed Aug. 25, 2000. The related applications are incorporated herein by reference.
1. Field of the Invention
This invention relates generally to computer networks and, more specifically, to identifying a host through changes in the configuration of a dynamic network.
2. Description of the Related Art
Network security systems need an accurate snapshot of a network in order to provide optimal protection. Some devices on the network are configured to use static Internet Protocol (IP) addresses, allowing the network security system to easily track those devices. For example, a record or log of host characteristics, vulnerabilities, past attacks, and the like can be consistently associated with a device having a given address.
However, some networks and devices are configured to use dynamic IP addresses, which can cause the device to be disassociate from its record or log. Using techniques such as Dynamic Host Configuration Protocol (DHCP), a DHCP server can dynamically assign IP addresses on an as-needed basis from a pool. As a result, fewer IP addresses are needed. On the other hand, the network security system is unable to leverage off previously gathered information concerning a device that is not new to the network, but has merely been assigned a different IP address. Reassignment of IP addresses is not uncommon, occurring as a result of, for example, rebooting either the network security system or a device, physically unplugging a device from the network, manual configuration, and the like.
Problematically, the network security system performance is degraded in a dynamic network as it no longer has an accurate snapshot of the network. For example, if the device record contains a list of vulnerabilities present on the device, but the network security system is unable to retrieve this information because the address of the device has changed, the device may not be protected against those vulnerabilities. Nor is a network administrator able to make informed security decisions.
Additionally, self-identification of devices is unreliable and can further degrade performance. One way for a device to self-identify is through a service banner. However, hackers can easily compromise and edit service banners to misidentify the device. Furthermore, service banners often contain insufficient information concerning, for example, application version numbers and patch levels.
Therefore, what is needed is a robust network security system capable of persistently identifying a device through changes on a dynamic network. Furthermore, a network security system should be capable of providing the same level of security to a dynamic network as it does to a static network.
The present invention meets these needs with systems, methods, and computer program products for persistent host recognition in a network application such as a security system. In one embodiment, the system comprises a security manager to scan a network for host instances representing hosts on the network at that time, and record characteristics of the host instances in a host record. In another embodiment, the security manager scans the network for host instances in order to identify persistent hosts based on the host records. Advantageously, this technique allows a security system to provide the same level of security to a dynamic network as to a static network.
In one embodiment, the security manager comprises a host profiling module. The host profiling module takes snapshots of the network to generate host instances based on characteristics such as IP addresses, NetBIOS names, DNS names, MAC addresses, and the like. Host instances can include persistent (or previously existing) hosts and/or new hosts. Another embodiment of the host profiling module determines additional characteristics such as an operating system running on the host including the version and/or patch level, and network service applications running on the host including version and/or patch levels. The host profiling module can profile hosts by interrogating the host with data packets and analyzing responses to the data packets for inferential information. Thus, the system is able to reliably gather information about a host for matching.
In another embodiment, the security manager comprises a host matching module. The host matching module correlates host instances from different snapshots. The host matching module can use weighted rules (predetermined or customized) to discriminate between multiple potential matching host instances. For example, a matching NetBIOS name might have significantly more influence than a matching IP address, especially when the two characteristics are inconsistent. When the network reconfigures hosts, for example through dynamically reassigning IP addresses, the security manager is able to correlate a host to its existing host record. The host record can contain, for example, a security policy, vulnerability information, unique host characteristics, and the like.
In yet another embodiment, the security manager comprises security logic. The security logic makes security decisions based on data including persistent host information. For example, a network administrator can view charts that summarize host security configurations of the network. In another example, an intrusion detection system can monitor network traffic based on vulnerability information. In still another example, the security logic can manage a host's ability to access the network, i.e., configure network switches to block or allow packet exchanges with outside networks.
The features and advantages described in this summary and the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
Systems, methods, and computer program products for persistent host recognition in a network application such as a security system are disclosed. Some embodiments of the system are set forth in
The processes, features, or functions of the present invention can be implemented by program instructions that execute in an appropriate computing device. The program instructions can be distributed on a computer readable medium, within a semiconductor device, or through a public network. Program instructions can be in any appropriate form, such as source code, object code, or scripts.
The security manager 110 provides network security functions to the hosts 130 such as vulnerability analysis, intrusion detection, and the like. The security manager 110 further comprises a host determination module 112 and a security logic module 114. Generally, the host determination module 112 uses host characteristics to match host instances from snapshots of the network with records of persistent hosts. The security logic 114 can access information from the host determination module 114 to make security decisions. For example, the security logic 114 can check network traffic for vulnerabilities of a particular persistent host, based on the persistent host's current network address. In another example, a network administrator can view charts that summarize host security configurations of the network. Of course the described ‘modules’ are only exemplary groupings of functionality. Consequently, alternate groupings of functionality within the scope of the present invention are contemplated, such as a security manager 110 distributed around the network 195, or having multiple instances executing on hosts 130.
In one embodiment, the host determination module 112 comprises a host profiling module 220 to determine characteristics of the discovered hosts 130. The host profiling module 112 receives host characteristics such as IP address, NetBIOS names, DNS names, MAC addresses, and the like. Another embodiment of the host profiling module 112 interrogates the hosts 130 to determine different and/or additional characteristics such as operating systems running on the hosts including the versions and/or patch levels, and applications running on the hosts including versions and/or patch levels. The records manager 240 stores host records identifying the hosts and containing the host characteristics. A host record can also contain, for example, a security policy, vulnerability information, unique host characteristics, and the like.
In one embodiment, the host determination module 112 comprises a host matching module 230. The host matching module 230 correlates a host 130 currently being scanned to a record of a previously scanned host 130, if possible. The host matching module 230 can use weighted rules to discriminate between multiple potential matches. When the network experiences change, for example through dynamically assigned IP addresses, the system 100 is able to correlate a host 130 to its existing host record stored in the records manager 240. If the host 130 does not correlate with an existing host record, one embodiment of the host determination module 230 creates a new host record.
Referring again to
Still referring to
In one embodiment, the profiling module 220 interrogates the hosts 130 to inferentially determine the operating systems and/or network service applications running on the hosts. This network-based profiling makes independent determinations rather than relying on the host 130 to self-identify through a banner or other often unreliable methods. The profiling module 220 can examine OSI (Open Systems Interconnection) layer 5, layer 6 and/or layer 7 aspects of the host 130 to determine running applications and other characteristics of the host 130. For example, telnet applications typically run on port 23. Responsive to port 23 being open, the profiling module 220 attempts to open a telnet session on the port and sends general or application-specific command line instructions to the telnet application. The profiling module 130 examines responses to the instructions that are unique to a type of telnet application. The profiling module 130 can further examine the telnet application for responses that are unique to a version and/or patch level of that particular application.
In one embodiment, the profiling module 220 examines layer 3 and/or layer 4 aspects of the host 130 for responses to anomalous data packets to determine an operating system and other characteristics of the host 130. Anomalous data packets are nonconforming relative to RFC (Request For Comment) protocols promulgated by the Internet Engineering Task Force. The host 130 typically responds to conforming data packets with conforming responses. By contrast, the host 130 may have unique responses to anomalous data packets since such responses are not standardized. The profiling module 130 examines responses to determine the operating system, and its version and/or patch level. The inferential process is described in further detail in commonly-owned U.S. patent application Ser. No. 10/456,837.
The host matching module 230 determines 330 persistent hosts by correlating host instances detected in the snapshot with host records. A flow chart in
To determine which new host instances match previous host instances as indicated by the host records, the host matching module 230 calculates 430 a host correlation metric. In one embodiment, this calculation uses weighted rules so that reliable characteristics have a greater influence. A sum of the weighted rules can operate as a fuzzy match function to categorize a new host instance into a state such as a positively established host (or persistent host), a negatively established host (or new host), or an ambiguously established host.
More specifically, one embodiment of the host matching module 230 categorizes the sum of weighted rules based on thresholds. If the sum exceeds an association threshold 440, the new host instance is considered a persistent host 445 and can be associated with the record of its previous host instance. If the sum falls fellow a creation threshold 450, the new host instance is considered a new host 455 and a new host record is created in one embodiment. Otherwise, the new host instance is considered an ambiguous host 465. In one embodiment, ambiguous hosts can be retested, for example, based on a subsequent snapshot against subsequent host instances. Also, ambiguous hosts can be retested responsive to a change in rule weightings. The host matching module 230 can use generalized rule weights or customized rule weights.
According to the examplary summary view 500, the persistent host having NetBIOS name HYDROGEN was located at sub-network address 10.0.0.1 for the first two snapshots 515, 525, but changed to sub-network address 10.0.0.2 before the third snapshot 535, and again changed to sub-network address 10.0.0.3 before the fourth snapshot 545. However, during each snapshot, the persistent host maintained its NetBIOS name. Similarly, persistent hosts HELIUM, LITHIUM, and BERYLLIUM also maintained consistent NetBIOS names. In this configuration, the network administrator can more heavily weight NetBIOS matching rules since they are a reliable aspect of the 10.0.0.0/24 network. In another embodiment, the NetBIOS name is not consistent. For example, HYDROGEN can be assigned its NetBIOS name just prior to the fourth snapshot 545, causing the host matching module 230 to rely on other characteristics such as applications identified on the host 130.
Referring again to
Number | Name | Date | Kind |
---|---|---|---|
5136523 | Landers | Aug 1992 | A |
5278901 | Shieh et al. | Jan 1994 | A |
5388211 | Hornbuckle | Feb 1995 | A |
5440723 | Arnold et al. | Aug 1995 | A |
5557742 | Smaha et al. | Sep 1996 | A |
5699403 | Ronnen | Dec 1997 | A |
5796942 | Esbensen | Aug 1998 | A |
5798706 | Kraemer et al. | Aug 1998 | A |
5802320 | Baehr et al. | Sep 1998 | A |
5850516 | Schneier | Dec 1998 | A |
5892903 | Klaus | Apr 1999 | A |
5919257 | Trostle | Jul 1999 | A |
5923646 | Mandhyan | Jul 1999 | A |
5925126 | Hsieh | Jul 1999 | A |
5931946 | Terada et al. | Aug 1999 | A |
5958015 | Dascalu | Sep 1999 | A |
5961644 | Kurtzberg et al. | Oct 1999 | A |
5991881 | Conklin et al. | Nov 1999 | A |
6006328 | Drake | Dec 1999 | A |
6088804 | Hill et al. | Jul 2000 | A |
6101606 | Diersch et al. | Aug 2000 | A |
6185689 | Todd, Sr. et al. | Feb 2001 | B1 |
6199181 | Rechef et al. | Mar 2001 | B1 |
6263444 | Fujita | Jul 2001 | B1 |
6269447 | Maloney et al. | Jul 2001 | B1 |
6279113 | Vaidya | Aug 2001 | B1 |
6282546 | Gleichauf et al. | Aug 2001 | B1 |
6298445 | Shostack et al. | Oct 2001 | B1 |
6301668 | Gleichauf et al. | Oct 2001 | B1 |
6321338 | Porras et al. | Nov 2001 | B1 |
6324656 | Gleichauf et al. | Nov 2001 | B1 |
6330562 | Boden et al. | Dec 2001 | B1 |
6343362 | Ptacek et al. | Jan 2002 | B1 |
6347376 | Attwood et al. | Feb 2002 | B1 |
6359557 | Bilder | Mar 2002 | B2 |
6363489 | Comay et al. | Mar 2002 | B1 |
6370648 | Diep | Apr 2002 | B1 |
6408391 | Huff et al. | Jun 2002 | B1 |
6415321 | Gleichauf et al. | Jul 2002 | B1 |
6470384 | O'Brien et al. | Oct 2002 | B1 |
6473800 | Jerger et al. | Oct 2002 | B1 |
6477651 | Teal | Nov 2002 | B1 |
6484203 | Porras et al. | Nov 2002 | B1 |
6484315 | Ziese | Nov 2002 | B1 |
6490626 | Edwards et al. | Dec 2002 | B1 |
6502135 | Munger et al. | Dec 2002 | B1 |
6574737 | Kingsford et al. | Jun 2003 | B1 |
6578147 | Shanklin et al. | Jun 2003 | B1 |
6584569 | Reshef et al. | Jun 2003 | B2 |
6609205 | Bernhard et al. | Aug 2003 | B1 |
6687833 | Osborne et al. | Feb 2004 | B1 |
6708212 | Porras et al. | Mar 2004 | B2 |
6711127 | Gorman et al. | Mar 2004 | B1 |
6735169 | Albert et al. | May 2004 | B1 |
6735702 | Yavatkar et al. | May 2004 | B1 |
6771597 | Makansi et al. | Aug 2004 | B2 |
6775657 | Baker | Aug 2004 | B1 |
20020133721 | Adjaoute | Sep 2002 | A1 |
20040049586 | Ocepek et al. | Mar 2004 | A1 |
20050038827 | Hooks | Feb 2005 | A1 |
20050050357 | Jeng et al. | Mar 2005 | A1 |
20050086473 | Barkley et al. | Apr 2005 | A1 |
20050188419 | Dadhia et al. | Aug 2005 | A1 |
20050216957 | Banzhof et al. | Sep 2005 | A1 |
20050289219 | Nazzal | Dec 2005 | A1 |
20060064619 | Wen et al. | Mar 2006 | A1 |
Number | Date | Country |
---|---|---|
WO 0131420 | May 2001 | WO |
WO 0184270 | Nov 2001 | WO |
WO 0219661 | Mar 2002 | WO |
WO 0245380 | Jun 2002 | WO |
WO 03100617 | Dec 2003 | WO |
Entry |
---|
Abstract, W. Erhard, et al., “Network Traffic Analysis and Security Monitoring With UniMon”, Proceeding of the IEEE Conference on High Performance Switching and Routing, 2000, ATM 2000, pp. 439-446 (Jun. 2000). |
Abstract, Dept. of Comput. Sci., California Univ., Davis, CA, USA, “A Methodology for Testing Intrusion Detection Systems”, IEEE Transactions on Software Engineering, vol. 22, Issue 10, pp. 719-729 (Oct. 1996). |
Abstract, Mounji A. Le Charlier, et al., “Distributed Audit Trail Analysis”, Proceeding of the Symposium on Network and Distributed System Security, 1995, pp. 102-112 (Feb. 16-17, 1995). |
Abstract, L.T. Heberlein, et al., “A Network Security Monitor” Proceeding of the 990 IEEE Computer Society Symposium on Research in Security and Privacy, pp. 296-304, (May 7-9, 1990). |
Abstract, Xinzhou Quin et al., “Integrating Intrusion Detection and Network Management”, Network Operation and Managemer Symposium, 2002. NAOMS 2002. 2002 IEEE/IFIP, pp. 329-344 (Apr. 15-19, 2002). |
Abstract, D.G. Schwartz et al., “A Case-Based Approach to Network Intrusion Detection”, Proceeding of the 5th International Conference on Information Fusion, 2002. vol. 2 pp. 1084-1089 (Jul. 8-11, 2002). |
Abstract, “Open Source Security: Opportunity or Oxymoron?” Computer, vol. 35, Issue 3, pp. 18-21 (Mar. 2002). |
Abstract, Liu Dihua, et al. “Data Mining for Intrusion Detection”, Proceedings ICII 2001—Beijing 2001 International Conference on Info-Tech and Info-Net, 2001, vol. 5, pp. 7-12, (Oct. 29-Nov. 2001). |
Abstract, Kai Hwang & M. Gangadharan, “Micro-Firewalls for Dynamic Network Security With Distributed Intrusion Detection”, NCA 2001 IEEE International Symposium on Network Computing and Applications, 2001. pp. 68-79, (Oct. 8-10, 2001). |
Abstract, Wenke Lee Stolfo, et al., “Real Time Data Mining-Based Intrusion Detection”, Proceedings DARPA Information Survivability Conference & Exposition II, 2001, DISCEX '01. vol. 1, pp. 89-100 (Jun. 12-14, 2001). |
Abstract, J. Bums, et al. Automatic Management of Network Security Policy, Proceedings DARPA Information Survivablity Conference & Exposition II 2001, DISCEX '01. vol. 2, pp. 12-26, (Jun. 12-14, 2001). |
Abstract, Heberlein, et al. “A Network Security Monitor”, 1990, Proceedings Research in Security & Privacy 1990 IEEE Computer Society Symposium on, pp. 296-304, (May 7-9, 1990). |
Anderson, Teresa, “Hunting for Holes,” Security Management, Arlington, Apr. 1996, 2 pages. |
Anonymous, Microsoft Computer Dictionary, 2002, Microsoft Press, Fifth Edition, p. 291. |
Bace, Rebecca, An Introduction to Intrusion Detection & Assessment, ICSA, Inc., 1999, pp. 1-38. |
Breyfogle, Stacey, “Don't Stop at Your Servers,” Software Magazine, Englewood, Jan. 1998, pp. 1-3. |
Fyodor, Remote OS Detection Via TCP/IP Stack FingerPrinting, Oct. 18, 1998, pp. 1-10. |
Johnson, Johna Till, “Simulated Attack for Real Network Security,” Data Communications, Nov. 2, 1995, pp. 31-32. |
“Microsoft Computer Dictionary Fifth Edition,” 2002, 6 pages. |
Phipatanasuphorn et al., Vulnerability of Sensor Networks to Unauthorized Traversal and Monitoring, IEEE Transactions On Computers, Mar. 2004, pp. 364-369. |
Ristenbatt, Martin P., Methodology for Network Communication Vulnerability Analysis, IEEE, 1988, pp. 493-499. |
Skaggs, B., et al., Network Vulnerability Analysis, IEEE, 2002, pp. 493-495. |
Thatcher, Michelle, Keeping Your Technology Secure, Technology & Learning, Apr. 2002, pp. 38, 40, 42 and 44. |
Yurcik, William, Controlling Intrusion Detection Systems by Generating False Positives: Squealing Proof-of-Concept, Proceedings of the 27th Annual IEEE Conference on Local Computer Networks, 2002, pp. 134-135. |