System and method for enabling remote registry service security audits

[0001] This application is related to co-pending U.S. patent application Ser. No. 10/863,238, entitled “System and Method for Managing Network Vulnerability Analysis Systems,” filed Jun. 9, 2004, co-pending U.S. patent application Ser. No. 11/016,761, entitled “System and Method for Scanning a Network,” filed Dec. 21, 2004, and U.S. patent application Ser. No. 11/313,710, entitled “System and Method for Managing Events,” filed Dec. 22, 2005, now abandoned, the contents of which are hereby incorporated by reference in their entirety.

[0002] The invention relates to a system and method for enabling remote registry service security audits, and in particular, to analyzing characteristics describing various devices in a network to determine whether a remote registry service has been enabled on the devices, performing credentialed policy scans to enable the remote registry service for certain devices that have disabled the remote registry service, auditing the devices in response to enabling the remote registry service, and then disabling the remote registry service on the devices.

[0003] In many network environments, illegal or unauthorized users may exploit vulnerabilities in the network to gain access, deny access, or otherwise attack systems in the network. As such, to detect and remediate such network vulnerabilities, existing network security systems typically conduct vulnerability analysis in the network through manual inspection or network scans. For example, as discussed in co-pending U.S. patent application Ser. No. 11/016,761, the contents of which are incorporated by reference above, passive and active vulnerability scans may be conducted separately or in combination with one another to identify vulnerabilities in a network. In particular, active vulnerability scanners typically send packets or other messages to various devices in the network that the active vulnerability scanners may be auditing. In many instances, to effectively perform a vulnerability scan, the active vulnerability scanners typically need access to certain information in the audited devices, including a registry that contains settings and configurations associated with operating systems, kernels, device drivers, or other applications that may be running on the audited devices.

[0004] As such, because vulnerability scans typically involve an active vulnerability scanner remotely accessing a device that the active vulnerability scanner may be auditing, the active vulnerability scanner must access the registries for such devices remotely. However, improper or malicious manipulation of the information contained in the registry for any particular device in a network can cause many different problems or other vulnerabilities in the device and the network. Thus, many networks disable services that enable remote access to device registries to protect the devices and the network from undesirable, unauthorized, or malicious activity. Furthermore, many operating systems (e.g., Windows Vista™) have default configurations that automatically disable the services that enable remote access to device registries. For example, U.S. Patent Application Pub. No. 2004/0003266, entitled “Non-Invasive Automatic Offsite Patch Fingerprinting and Updating System and Method,” the contents of which are hereby incorporated by reference in their entirety, notes that services that provide registry information to remote computers can present security risks because such services can expose information that can be referenced to facilitate network infiltration or other network attacks.

[0005] Accordingly, many existing network systems tend to avoid using services that enable remote access to a device registry due to the security risks that such services can introduce to a network. However, the device registry often contains vital information that may be necessary to perform a complete network audit. For example, as noted above, the device registry can contain information that describes an operating system version, system file locations, or other information that be valuable to identifying vulnerabilities needed to properly and completely audit the network. Therefore, because existing network security systems tend to disable or restrict access to services that can be used to remotely access device registries, existing network security systems often cannot obtain important information from the device registries that may be needed to suitably audit a network. Furthermore, when existing network security systems enable the services provide remote access to the device registries, attackers or other malicious users may exploit the security risks that such services introduce.

[0006] Therefore, a need exists for a network security system that can remotely scan device registries during a network audit without exposing the device registries to malicious activity.

[0007] Accordingly to one aspect of the invention, the system and method for enabling remote registry service security audits described herein may include scanning a network to construct a model or topology of the network. In particular, the model or topology of the network may include characteristics describing various devices in the network, which may be analyzed to determine whether a remote registry service has been enabled on the devices. For example, the security audits may include performing one or more credentialed policy scans to enable the remote registry service for certain devices that have disabled the remote registry service, auditing the devices in response to enabling the remote registry service, and then disabling the remote registry service on the devices. Thus, the system and method described herein may enable remotely scanning information contained in device registries during a security audit without exposing the device registries to malicious activity.

[0008] According to one aspect of the invention, the system and method described herein may include a vulnerability management system that maintains a model of a network, wherein the model of the network may include a plurality of devices discovered in the network that have a remote registry service. Further, an active vulnerability scanner may actively scan the network to detect one or more vulnerabilities in the network. For example, the active vulnerability scanner may identify one or more of the devices discovered in the network that have disabled the remote registry service and then communicate activation messages to the identified devices to enable the remote registry service on the identified devices. The active vulnerability scanner may then interact with the remote registry service enabled on the identified devices to obtain registry information from the identified devices and then communicate deactivation messages to the identified devices in response to obtaining the registry information from the identified devices. As such, the deactivation messages may disable the remote registry service on the identified devices, which may prevent subsequent malicious or unauthorized attempts to manipulate the remote registry service.

[0009] Other objects and advantages of the invention will be apparent to those skilled in the art based on the following drawings and detailed description.

[0018] The system and method for enabling remote registry service security audits described herein may remotely scan various devices in a network to obtain information contained in registries associated with the devices. In particular, the system and method described herein may employ one or more active vulnerability scanners and one or more passive vulnerability scanners during the remote registry service security audits to identify vulnerabilities or otherwise manage the network. In one implementation, the active vulnerability scanners and the passive vulnerability scanners may collect information describing the devices in the network and services actively running in the network. For example, in one implementation, the information collected from the network may be analyzed to identify one or more devices having a remote registry service, wherein the active vulnerability scanner may temporarily enable the remote registry service on the identified devices to obtain information from the registries associated with such devices and then disable the remote registry service to prevent unauthorized or malicious activity from remote users. Furthermore, the information obtained from the active and passive vulnerability scanners may be used to build a model or topology of the network, detect vulnerabilities in the network, and otherwise manage the network. For example, the passive and active vulnerability scanners may continually or periodically inspect the network to identify new ports, new hosts, or other changes in the network, identify vulnerabilities in the network, and detect events that may target the identified vulnerabilities.

[0019] In contrast, FIG. 1 illustrates a schematic diagram of an exemplary prior art system 100 that does not enable remote registry service security audits. More particularly, the prior art system 100 shown in FIG. 1 may generally include a network having multiple routers 130, various network hosts or other devices 120, an active vulnerability scanner 110, and an interface to one or more other networks 140 (e.g., the Internet). In the prior art system 100, the active vulnerability scanner 110 may send packets or other messages to the hosts or devices 120 in the network through the routers 130 to identify one or more of the hosts or devices 120 actively running in the network and one or more of the hosts or devices 120 that may be inactive. However, in scenarios where one or more of the hosts or devices 120 have a remote registry service that has been disabled, the prior art system 100 typically prevents the active vulnerability scanner from remotely obtaining information from registries that may describe important settings, configurations, or other information associated with the hosts or devices 120. Accordingly, although the active vulnerability scanner 110 in the prior art system 100 can obtain certain information describing the network, the prior art system 100 does not enable remote registry service security audits that could otherwise yield important information relevant to identifying vulnerabilities in the network, building a complete model or topology of the network, or otherwise managing the network.

[0020] According to one aspect of the invention, FIG. 2 illustrates a schematic diagram of an exemplary system 200 for enabling remote registry service security audits. In particular, the system 200 shown in FIG. 2 may generally include one or more passive vulnerability scanners 270 that can observe traffic in a packet stream 280 travelling in a network to identify vulnerabilities in the network and detect activity that may target the identified vulnerabilities, and may further include one or more active vulnerability scanners that can communicate packets or other messages within the network to detect new or changed information describing various routers 240, hosts 230, servers 230, or other devices 230 in the network. For example, in one implementation, the active vulnerability scanners may include active vulnerability scanners 410 and 420 (e.g., illustrated in FIG. 4), which may temporarily enable a remote registry service on certain hosts, servers, or other devices 230 in the network and then scan registries associated with such devices 230 during a security audit. The active vulnerability scanner may then disable the remote registry service to prevent unauthorized or malicious activity from remote users (e.g., originating from a remote network 260, such as the Internet). The information obtained from remotely scanning the registries associated with the devices 230 may then be analyzed to identify potential vulnerabilities in the network, and the passive vulnerability scanner 270 may then observe packet streams 280 traversing the network to detect activity that potentially targets the vulnerabilities identified in the remote registry scan.

[0021] In one implementation, the passive vulnerability scanner 270 may observe as many sessions in the network as possible to provide optimal visibility into the network and the activity that occurs in the network. For example, in one implementation, the passive vulnerability scanner 270 may be deployed at a network hub, a spanned switch port, a network tap, a network choke point, a dial up node, a server farm, behind a firewall, or any other suitable location that enables the passive vulnerability scanner 270 to observe incoming and outgoing traffic in the network. Alternatively (or additionally), the passive vulnerability scanner 270 may be deployed directly in or adjacent to an intrusion detection system (IDS), as shown and discussed below in connection with FIG. 5. Furthermore, in one implementation, the IDS may include an open source network intrusion prevention and detection system (e.g., Snort), a packet analyzer, or any other suitable system that can detect and prevent intrusions in the network, and the passive vulnerability scanner 270 may be deployed on a server running an open source operating system (e.g., a Red Hat Linux operating system, a FreeBSD operating system, etc.), or any other suitable operating system.

[0022] In one implementation, as noted above, the active vulnerability scanner may generally communicate various packets or other messages within the network to illicit responses from hosts, servers, or other devices 230 in the network. In contrast, the passive vulnerability scanner 270 may generally observe (or “sniff”) various packets in the packet stream 280 traversing the network to passively scan the network. In particular, the passive vulnerability scanner 270 may reconstruct one or more sessions in the network from information contained in the packets sniffed in the packet stream 280, wherein the reconstructed network sessions may then be used to build a model or topology describing the network (e.g., any routers 240, hosts, servers, or other devices 230 actively running in the network, any services actively running on the routers 240, hosts, servers, or other devices 230, etc.). In one implementation, the passive vulnerability scanner 270 may further apply various signatures to the information observed in the packet stream 280 to identify vulnerabilities in the network and determine whether any packets in the packet stream 280 potentially target such vulnerabilities. In one implementation, the passive vulnerability scanner 270 may observe the packet stream 280 continuously, at periodic intervals, on a pre-configured schedule, or in response to determining that certain criteria or conditions have been satisfied. The passive vulnerability scanner 270 may then automatically reconstruct the network sessions, build or update the network model, identify the network vulnerabilities, and detect the traffic potentially targeting the network vulnerabilities in response to detecting any new or changed information in the network.

[0023] According to one aspect of the invention, FIG. 3 illustrates a flowchart of an exemplary method 300 for scanning a network using a passive vulnerability scanner. In particular, as noted above, the passive vulnerability scanner may perform the method 300 continuously, at periodic intervals, on a pre-configured schedule, or in response to determining that certain criteria or conditions have been satisfied. In one implementation, the method 300 shown in FIG. 3 may include an operation 310, wherein the passive vulnerability scanner may sniff various packets in a packet stream travelling across the network and build a model or topology of the network from information contained in the sniffed packets. In one implementation, the passive vulnerability scanner may build or update the network model in operation 310 continuously (i.e., anytime new or changed information has been discovered), at periodic intervals, at predetermined times, or in response to determining that certain criteria or conditions have been satisfied.

[0024] For example, in one implementation, the model or topology may be automatically updated to include any active devices that send or receive the packets in the packet stream (e.g., routers, hosts, servers, etc.), and further to include any active services running on the active devices that interact with the packets in the packet stream (i.e., operation 310 generally includes the passive vulnerability scanner observing traffic in the network and building the model to represent the devices active in the network and the services actively running on the active devices). For example, in response to observing a Transmission Control Protocol (TCP) SYN-ACK packet originating from port twenty-five on a particular device, the model may be updated in operation 310 in response to determining that the SYN-ACK packet represents new information to the model. Thus, from analyzing SYN and SYN-ACK packets in the packet stream, the passive vulnerability scanner may determine a status, identity, or other information describing active devices in the network.

[0025] In one implementation, the active devices that the passive vulnerability scanner discovers in the network may generally represent server devices and client devices. In particular, the active devices that provide services to other devices may represent the server devices (e.g., web servers, File Transfer Protocol servers, etc.), and the active devices that connect to the services provided on the server devices may represent the client devices. For example, in a context where a user machine connects to a particular web site (e.g., Google), the web site may generally include one or more server devices that provide services that can respond to requests received from the user machine, while the user machine, which typically does not provide any services within a local or remote network, may represent a client device. Thus, the server devices may generally provide the services on numbered ports, wherein each service available on the server devices may have a different port number, while the client devices may connect to particular services on the server devices using certain network addresses and port numbers. For example, a server device may provide a File Transfer Protocol (FTP) service on port twenty-one, while a client device may connect an Internet Protocol (IP) address for the server device on port twenty-one to access the FTP service.

[0026] In one implementation, the SYN and SYN-ACK packets described above may further provide information that can be used to identify operating systems running on the devices active in the network. For example, different operating systems (e.g., Linux, Windows XP, Solaris, etc.) tend to build SYN packets that can be uniquely distinguished from SYN packets originating from other operating systems, whereby the passive vulnerability scanner may analyze a structure for SYN packets originating from a certain device to determine an operating system running on the device. In one implementation, the passive vulnerability scanner may further analyze applications running on the devices to uniquely identify the operating systems running on the devices. For example, certain web browsers (e.g., Internet Explorer), email applications (e.g., Eudora), and other applications typically include information describing an underlying operating system (e.g., Windows XP) directly into various protocols, and the passive vulnerability scanner may detect such information from the traffic observed in the packet stream to identify the underlying operating system associated with the traffic. Alternatively (or additionally), an active vulnerability scanner may directly interrogate the device to identify the operating system running on the device.

[0027] In the context of remote registry service security audits, knowing the operating systems running on the devices in the network may be important to obtaining information from registries associated with the devices. For example, certain operating systems (e.g., Windows Vista™) automatically disable a service that provides remote access to the registry, whereby knowing that a certain device runs the Windows Vista™ may be relevant to determining the manner for remotely accessing the registry on the device. Thus, in response to recognizing the active devices in the network and services and operating systems running on the active devices, an operation 320 may include the passive vulnerability scanner searching and/or scanning the network model to identify vulnerabilities in the network. In particular, operation 320 may include the passive vulnerability scanner performing simple banner analysis to identify any known vulnerability signatures in the traffic previously observed to build the network model. For example, in one implementation, the passive vulnerability scanner may reference a table stored in memory that correlates various known vulnerabilities with particular service versions, or the passive vulnerability scanner may forward information describing the service versions to a correlation engine or another suitable system that can recognize known vulnerabilities for the service versions from the forwarded information.

[0028] For example, in one implementation, to identify the vulnerability signatures, the passive vulnerability scanner may reconstruct various network sessions from the previously observed traffic in the network (e.g., sessions that include conversations or other messages exchanged between various server devices and client devices). Thus, in response to reconstructing the network sessions, operation 320 may include the passive vulnerability scanner analyzing the traffic associated with the reconstructed network sessions to identify any evidence relevant to particular vulnerabilities in the server devices and the client devices that communicate in the network sessions. In particular, the passive vulnerability scanner may recognize the known vulnerability signatures using simple banner analysis to identify services and versions of services that have known vulnerabilities. For example, packets communicated over certain protocols (e.g., Hypertext Transfer Protocol (HTTP), Simple Mail Transport Protocol (SMTP), FTP, etc.) typically have unique strings with text that can be used to identify a service version associated with the packets, whereby the passive vulnerability scanner may perform the simple banner analysis to identify the communication protocols and service versions involved in the network sessions. Consequently, in response to determining the communication protocols and the service versions involved in the network sessions, the passive vulnerability scanner may further identify any known vulnerabilities associated therewith.

[0029] However, in one implementation, certain communication protocols may have more complexity, whereby the simple banner analysis performed in operation 320 may not suitably identify the communication protocols or the service versions involved in the network sessions. Rather, more complex communication protocols (e.g., Domain Name System protocols, Simple Network Management Protocol, etc.) may require additional processing and analysis to suitably identify the versions for the services used to communicate the packets or other messages involved in the network sessions. As such, in one implementation, an operation 330 may include the passive vulnerability scanner performing intelligent banner analysis to handle any network sessions that involve more complex communication protocols. In particular, the passive vulnerability scanner may employ a signature language that defines various techniques for creating regular expression macros that can represent information communicated over more complex protocols. For example, the regular expression macros may include one or more text lines to represent patterns that the information communicated over the complex protocols typically include (e.g., knowledge obtained from monitoring communications over the complex protocols may be used to effectively write signatures for such protocols). As such, the passive vulnerability scanner may match signatures from packets communicated over complex protocols to the regular expression macros to identify service versions associated with such packets and correlate the signatures and service versions with known vulnerabilities.

[0030] Thus, the passive vulnerability scanner may generally recognize vulnerabilities in the network through a combination simple and intelligent banner analysis that can be used to identify signatures in the network traffic that match certain predetermined patterns. In particular, the passive vulnerability scanner may initially identify the signatures using simple banner analysis in operation 320, and then proceed to intelligent banner analysis in operation 330 to handle increasingly complex signatures. For example, in one implementation, operation 320 may include the passive vulnerability scanner identifying a web service running on a particular port at a particular network address (e.g., “Web service running at 10.20.30.40 on port 80”). In addition, operation 330 may then include the passive vulnerability scanner identifying a particular version of the web service (e.g., “Apache web server running at 10.20.30.40 on port 80”) and a particular vulnerability for the version of the web service, whereby the vulnerability may then be reported in an operation 340 (e.g., the report may indicate that “The Apache web server running at 10.20.30.40 on port 80 has Apache version 2.1.3, which includes the following vulnerabilities . . . ”).

[0031] In one implementation, as noted above, the passive vulnerability scanner may report the activity observed in the network and any vulnerabilities identified from the activity in operation 340. In one implementation, the passive vulnerability scanner may be configured to generate or communicate the report in response to observing a number of network sessions that meets or exceeds a predetermined threshold. Furthermore, in one implementation, the passive vulnerability scanner may be configured to require a minimum number of network sessions involving particular ports prior to identifying the port as active in the network. In one implementation, the minimum number of network sessions that must be observed prior to reporting a new active port may provide a level of sensitivity that can prevent the passive vulnerability scanner from reporting false positives and/or false negatives (e.g., a higher minimum number of sessions may cause the passive vulnerability scanner to only report services that have a large numbers of sessions, while a lower minimum number may cause the passive vulnerability scanner to report every observed network session).

[0032] For example, FTP applications, peer-to-peer file sharing application, instant message applications, and other similar applications often temporarily open ports on connections that may not be well known. Thus, the passive vulnerability scanner may observe the connection on the unknown port that has been temporarily opened and identify a new server on the port. Thus, requiring the minimum number of sessions for certain ports may enable the passive vulnerability scanner to avoid detecting temporary servers or services. In particular, because FTP, peer-to-peer, and instant message applications seldom establish communication channels on unknown ports in comparison to web servers that can establish many connections per second, the minimum number of network sessions may eliminate false positives that report temporary servers or services. Nonetheless, the passive vulnerability scanner may be configured to monitor and report any activity in the network, including temporary activity, in which case the minimum number of network sessions may be one or another low number.

[0033] According to one aspect of the invention, FIG. 4 illustrates another schematic diagram of the system 400 for enabling remote registry service security audits. In particular, the system 400 shown in FIG. 4 may include a passive vulnerability scanner 470 that can passively observe traffic in a network to build a model or topology of the network, identify vulnerabilities in the network, and detect activity that may potentially target the vulnerabilities. In addition, the system 400 may further include one or more active vulnerability scanners (e.g., active vulnerability scanner 410, active vulnerability scanner 420, etc.), which may interrogate devices in the network to further build the model or topology of the network and identify further vulnerabilities in the network. Thus, the information obtained from the passive vulnerability scanner 470 and the active vulnerability scanners 410 and 420 may be combined to comprehensively model the network and the vulnerabilities in the network, whereby the passive vulnerability scanner may then passively observe traffic in the network to detect activity potentially targeting the vulnerabilities.

[0034] In one implementation, the active vulnerability scanners 410 and 420 and the passive vulnerability scanner 470 may be distributed across the network to reduce stress on the network. For example, in one implementation, the active vulnerability scanners 410 and 420 may scan limited portions of the network in parallel, whereby an amount of time to perform the active vulnerability scans may be reduced (i.e., because any particular active vulnerability scanner 410 or 420 can be distributed closer in distance to scanning targets 430, and because any particular active vulnerability scanner 410 or 420 only scans a certain portion of the network rather than the entire network). Furthermore, in one implementation, the passive vulnerability scanner 470 may supplement the information that the active vulnerability scanners 410 and 420 obtain from actively scanning the network (e.g., to obtain information that the active vulnerability scanners 410 and 420 may be unable to access).

[0035] For example, the passive vulnerability scanner 470 may depend on traffic that can be observed in the network to detect network devices or identify vulnerabilities in the network. As such, because the passive vulnerability scanner 470 can only detect devices or vulnerabilities from communications observed in the network, the active vulnerability scanners 410 and 420 may interrogate any device in the network to obtain information from inactive or non-communicative devices, whereby the active vulnerability scanners 410 and 420 and the passive vulnerability scanner 470 may provide a more comprehensive vulnerability analysis. Similarly, the active vulnerability scanners 410 and 420 may require substantial resources and/or time to complete active scans in the network, whereby active scanning results may become stale between the active scans. Thus, the passive vulnerability scanner 470 may continuously observe traffic on the network between the active scans to supplement the information obtained in the active scans without further stressing the network.

[0036] In one implementation, the system 400 may therefore further include a log correlation engine 450 (referred to as “Lightning Console” in FIG. 4), wherein the log correlation engine 450 may employ various techniques to provide a comprehensive vulnerability analysis system, as described in further detail in co-pending U.S. patent application Ser. No. 10/863,238, the contents of which are incorporated by reference above. In particular, the information obtained from the passive vulnerability scanner 470 and the active vulnerability scanners 410 and 420 may be forwarded to the log correlation engine 450, which may then aggregate the information to obtain active scanning information and passive scanning information that collectively encompasses the entire network. As such, the log correlation engine 450 may generally organize, distribute, manage, and report information relating to activity detected and remediated during network security audits to various entities across various organizations. For example, the log correlation engine 450 may aggregate information from the passive vulnerability scanner 470, the active vulnerability scanners 410 and 420, or other information sources, wherein the log correlation engine 450 may then analyze the information to identify vulnerabilities in the network, correlate events and other activity in the network with the vulnerabilities, and otherwise manage the network. Further, the information that the log correlation engine 450 analyzes may include the information that the active vulnerability scanners 410 and 420 obtains from the registries on the devices in the network to identify vulnerabilities and otherwise manage the network.

[0037] Furthermore, as noted above, the information obtained from the passive vulnerability scanner 470 and the active vulnerability scanners 410 and 420 may include information for identifying services that can be used to access registries associated with the network devices (e.g., operating system versions), which may enable certain types of security audits and vulnerability analysis. For example, in one implementation, the active vulnerability scanners 410 and 420 may include a publicly available active vulnerability scanner (e.g., Nessus, available from Tenable Network Security), an active vulnerability scanner with a complimentary license (e.g., NeWT, also available from Tenable Network Security), or a professionally licensed active vulnerability scanner (e.g., NeWT Pro, also available from Tenable Network Security). Further, the active vulnerability scanners 410 and 420 may include one or more plug-ins that can enable and disable the remote registry service on certain network devices, and may further include an interface to incorporate customized plug-ins that enable similar functionality. For example, the active vulnerability scanners 410 and 420 may employ a Nessus Attack Scripting Language (NASL), which may enable the active vulnerability scanners 410 and 420 to interact services that provide remote access to registries on devices running Windows XP, Windows 2002 Unix, MacOS X, FreeBSD, Linux, Solaris, or other suitable operating systems.

[0038] Thus, in one implementation, to access the registry on any particular device in the network, the active vulnerability scanners 410 and 420 may interact with a remote registry service associated with an operating system running on the device. In particular, the remote registry service may generally permit the active vulnerability scanners 410 and 420 to remotely access the registry on the device in response to determining that the active vulnerability scanners 410 and 420 have proper credentials, which may conveniently enable security audits based on information that may be contained in the registry. However, in many cases the remote registry service may be disabled (e.g., certain operating systems may automatically disable the remote registry service, an administrator may disable the remote registry service to reduce security risks, etc.), whereby the active vulnerability scanners 410 and 420 may be unable to remotely read keys, values, and other information from the registries, even with fully authorized credentials.

[0039] Accordingly, in one implementation, the active vulnerability scanners 410 and 420 may be configured to temporarily enable the remote registry service on any suitable device that has disabled the remote registry service, which may enable remote security audits on the information contained in the registries. For example, the remote registry service audits may include checking file levels, locating system files, auditing patches, determining remote operating system versions, or otherwise analyzing information contained in the registry that may be relevant to performing a complete audit that identifies and remediates vulnerabilities in the network. Thus, the active vulnerability scanners 410 and 420 may temporarily enable or activate the remote registry service on certain devices in the network prior to and/or during a credentialed scan or security audit, and may further temporarily enable administrator accounts on any devices that automatically disable administrator access. For example, devices in the network may generally be configured to permit entities having administrator or other suitable credentials to temporarily enable or activate the remote registry service, whereby temporarily enabling administrator accounts may be required to temporarily enable the remote registry service. Thus, in response to performing any steps needed to temporarily enable or activate the remote registry service, the active vulnerability scanners 410 and 420 may obtain any information that may be relevant to a security audit or credentialed scan from the registries and then disable the remote registry service to prevent unauthorized or malicious users from remotely gaining access to the registries.

[0040] According to one aspect of the invention, FIG. 5 illustrates another schematic diagram of the system 500 for enabling remote registry service security audits. In particular, the system 500 shown in FIG. 5 may provide distributed network security, wherein a passive vulnerability scanner 570 and a plurality of active vulnerability scanners 510 and 520 may be integrated with a log correlation engine 550 (referred to as “Lightning Console” 550 in FIG. 5) and a log aggregator 590 to manage security and vulnerability information across a network. In one implementation, the passive vulnerability scanner 570 may generate one or more alerts in response to detecting new or changed information in the network from traffic observed in the network between active scans that the active vulnerability scanners 510 and 520 perform in the network. For example, the passive vulnerability scanner 570 may generate an alert in response to discovering a new vulnerability in the network from traffic observed in the network traffic and then forward the alert to the log correlation engine 550. In particular, the passive vulnerability scanner 570 may maintain a model describing active devices, services, and vulnerabilities in the network from traffic that actually travels across the network, whereby the passive vulnerability scanner 570 may continuously record information describing devices, services, and vulnerabilities associated with such traffic. As such, the passive vulnerability scanner 570 may detect the new or changed information in the network from comparing traffic describing devices, services, and vulnerabilities currently active in the network to the model that describes devices, services, and vulnerabilities active in the network at a previous time.

[0041] For example, in response to launching the passive vulnerability scanner 570, the passive vulnerability scanner 570 may observe traffic that describes a newly discovered router 540, internal firewall 580, external firewall 584, IDS sensor 515, remote hosts in a remote network 560 (e.g., the Internet), or other devices that communicate with the network. Further, the passive vulnerability scanner 570 may identify network addresses for the newly discovered devices, wherein the passive vulnerability scanner 570 may forward alerts describing the newly discovered devices and the network addresses associated therewith to the log correlation engine 550. Similarly, in response to the active vulnerability scanners 510 and 520 detecting new or changed information, the active vulnerability scanners 510 and 520 may generate a suitable alert and forward the same to the log correlation engine 550. In one implementation, the log correlation engine 550, which may generally manage the network model from the information obtained from the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520, may then compare the alerts forwarded from the passive vulnerability scanner 570 to a master database that describes the devices, services, and vulnerabilities in the network model. As such, the log correlation engine 550 may analyze the alerts forwarded from the passive vulnerability scanner 570 and suitably update the master database in response to determining that the alerts indeed describe new or changed information. However, in response to the log correlation engine 550 recognizing the network address and/or the newly discovered device, the log correlation engine 550 may determine that the alert represents a false positive rather than a new host, in which case the log correlation engine 550 may discard the alert without updating the master database.

[0042] In one implementation, as noted above, the active vulnerability scanners 410 and 420 and the passive vulnerability scanner 470 may be distributed across the network to reduce stress on the network. For example, in one implementation, the active vulnerability scanners 510 and 520 may be deployed inside the internal firewall 584 to actively scan devices in the network located therein (e.g., active vulnerability scanner 510), between the internal firewall 580 and the external firewall 584 to actively scan devices in the network located therein (e.g., active vulnerability scanner 520), outside the external firewall 584 to actively scan devices in the network located therein and/or in the remote network 560 (e.g., between an interface from the external firewall 584 to the remote network 560), or any suitable combination thereof. Similarly, the passive vulnerability scanner 570 may be deployed inside the internal firewall 584 to observe traffic travelling within the network (e.g., passive vulnerability scanner 570), between the internal firewall 580 and the external firewall 584 to observe incoming and outgoing traffic in the network (e.g., between the router 540 and the external firewall 584), outside the external firewall 584 to observe traffic originating from or travelling to the remote network 560 (e.g., between an interface from the external firewall 584 to the remote network 560), or any suitable combination thereof.

[0043] As such, in one implementation, deploying the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520 at different locations in the network may provide the log correlation engine 550 with passive and active scanning information that can be used to comprehensively model the devices, services, and vulnerabilities in the network. In particular, in response to the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520 actively or passively scanning the network, one or more alerts may be forwarded to the log correlation engine 550 in response to the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520 may detecting any new or changed information within an area of the network that the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520 may be responsible for scanning. Thus, the log correlation engine 550 may aggregate the information forwarded from the passive vulnerability scanner 570 and the active vulnerability scanners 510 and 520 with any further information that the log aggregator 590 receives from devices in the network (e.g., firewall logs, authentication logs, etc.). The log correlation engine 550 may then analyze the aggregated information to build a comprehensive model of the devices, services, and vulnerabilities in the network.

[0044] In one implementation, the network model that the log correlation engine 550 builds from the aggregated information may be used to identify various devices in the network that have registries containing information that may be relevant to auditing security or vulnerabilities in the network. For example, the network model may describe any devices in the network that have a remote registry service that can be used to access the registries on such devices, including any devices that have enabled or disabled the remote registry service, any devices that run operating systems that have default settings enabling or disabling the remote registry service (e.g., devices running Windows Vista™ may have a default setting that disables the remote registry service), or other information that may be relevant to performing remote registry service security audits. In particular, as noted above, the network model may generally describe services running on devices in the network, including information identifying operating systems that run on the devices in the network, which may provide information identifying devices running the operating systems known to have default settings that typically disable the remote registry service.

[0045] For example, FIG. 6 illustrates an exemplary screenshot showing a network model 610 that the log correlation engine 550 can build using the aggregated information, wherein the network model 610 may visually illustrate various devices, services, and vulnerabilities in the network, wherein the screenshot shown in FIG. 6 may include a user interface that can be used to configure portions of the network model 610 displayed therein (e.g., to display devices that have enabled or disabled the remote registry service, devices running operating systems having default settings that enable or disable the remote registry service, etc.). In particular, FIG. 7 illustrates an interface 700 that displays operating systems 710 actively detected in the network and operating systems 720 passively detected in the network. For example, the interface 700 displayed in FIG. 7 includes an empty list describing the operating systems 710 actively detected in the network and a populated list describing the operating systems 720 passively detected in the network.

[0046] Accordingly, in one implementation, the active vulnerability scanners 510 and 520 may identify any devices that have or likely have disabled the remote registry service from the network model prior to or during any particular active scan. In one implementation, the active vulnerability scanners 510 and 520 may then communicate one or more messages to the identified devices to temporarily enable the remote registry service on such devices prior to or during the active scan. The active vulnerability scanners 510 and 520 may then interact with the remote registry service on the identified devices to remotely obtain information from the registries on such devices that may be relevant to auditing security or vulnerabilities in the network and then communicate additional messages to disable the remote registry service on such devices in response to suitably obtaining the information needed from the registries. As such, temporarily enabling the remote registry service may enable the active vulnerability scanners 510 and 520 to obtain further information relevant to remote registry service security audits, while then disabling the remote registry service may leave the remote registry service in a state that can prevent malicious users from remotely accessing or otherwise manipulating the registries on such devices.

[0047] According to one aspect of the invention, FIG. 8 illustrates another schematic diagram of a network environment 830 that includes a system 830 for enabling remote registry service security audits. In particular, the network environment 830 shown in FIG. 8 may generally include one or more hosts or other hardware devices 840, one or more routers 805, one or more active vulnerability scanners 810, one or more passive vulnerability scanners 820, a log correlation engine 850, and an interface to a remote network 860. Furthermore, the network environment 830 may generally provide substantially similar functionality to the functionality described above in connection with FIGS. 2 through 5. Further, one or more of the active vulnerability scanners 810 shown in FIG. 8 (e.g., active vulnerability scanner 810) may include one or more plug-ins 815 that the active vulnerability scanners 810 may execute to perform credentialed scans that include automatically enabling and disabling a remote registry service running on any particular device 840 in the network 800.

[0048] In one implementation, the plug-ins 815 may generally include any suitable computer program modules, software, or other computer-executable instructions that can configure the active vulnerability scanners 810 to perform the credentialed scans that automatically enable and disable the remote registry service running on the devices 840. For example, one or more of the plug-ins 815 may be configured to discover one or more of the devices 840 that have disabled the remote registry service, one or more of the devices 840 that run operating systems having default settings associated with the remote registry service, or other information that may be relevant to remotely obtaining information from registries associated with one or more of the devices 840. Furthermore, one or more of the plug-ins 815 may temporarily enable the remote registry service on one or more of the devices 840 that have disabled the remote registry service or that run operating systems with default settings that disable the remote registry service and then disable the previously enabled remote registry service in response to suitably obtaining information needed from the registries on such devices 840. In addition, one or more of the plug-ins 815 may be configured to return error messages in response to failing in an attempt to enable the remote registry service for one or more of the devices 840 or failing in an attempt to subsequently disable the previously enabled remote registry service.

[0049] In one implementation, the plug-ins 815 may be customized to interact with the remote registry service associated with certain operating systems, customized to interact with registries certain devices 840, or otherwise customized based on criteria that may be relevant to remotely interacting with the registry on any suitable device 840 in the network. For example, in one implementation, certain operating systems (e.g., Windows XP, Windows 2003, Windows Vista, Windows 7, etc.) may have default settings that disable the remote registry service. Although the remote registry service may enable remote systems with proper credentials to access the registry of a particular device 840 that the remote systems may be auditing, the fully credentialed remote systems may nonetheless be unable to read information from the registry on the device if the device 840 does not have the remote registry service running. Thus, the plug-ins 815 may enable the active vulnerability scanner 810 to temporarily activate the remote registry service on the device 840, whereby the active vulnerability scanner 810 can then read keys, values, and other information from the registry on the device. Moreover, temporarily enabling the remote registry service may further permit the active vulnerability scanner 810 to perform file level checks, perform patch auditing, determine remote operating system versions, locate system files, or otherwise audit the device 840 using information in the registry.

[0050] In one implementation, the plug-ins 815 may further provide functionality that can be used to obtain and audit information in the registry without compromising security in the network 830. For example, certain organizations may have policies that restrict running the remote registry service on certain operating system platforms because activity originating from remote networks 860 could then improperly manipulate the registries on devices within the network 830 or because public or governmental regulations recommend disabling the remote registry service. Thus, the plug-ins 815 may be used to activate or enable the remote registry service temporarily (e.g., during an audit) and then return the remote registry service to a disabled state. Accordingly, the plug-ins 815 may enable the active vulnerability scanner 810 to obtain any information that may be needed from the registry during a period of time when the remote registry service has been temporarily disabled, while limiting security risks that may result from leaving the remote registry service enabled.

[0051] Further, in one implementation, the plug-ins 815 may enforce one or more change management policies that control whether certain changes to the network may or may not be permitted. For example, the change management policies may require certain privileges for any entity that requests a change to the remote registry service, wherein the active vulnerability scanner 810 may be assigned the required privileges to permit the active vulnerability scanner 810 to obtain information from the device registries. Further, because any attacker that has obtained the required privileges would then be able to obtain information from the device registries, the passive vulnerability scanner 820 may observe traffic in the network 830 to detect any activity that includes potentially unauthorized attempts to access the device registries. In addition, the policies may further cause the active vulnerability scanner 810 to perform a subsequent active scan to ensure that the remote registry services previously enabled on any devices 840 have been properly disabled, filter any events that describe changes to the remote registry services from logs forwarded to the log correlation engine 850, temporarily disable any tools that continuously monitor the network 830 to disable running instances of the remote registry service, or identify potential vulnerabilities that may result from a remote registry scan losing connectivity or otherwise terminating before the remote registry service has been disabled or deactivated, among other things.

[0052] According to one aspect of the invention, FIG. 9 illustrates an exemplary method 900 for enabling remote registry service security audits. In particular, the method 900 shown in FIG. 9 may generally provide substantially similar functionality to the functionality described above in connection with FIG. 8 (e.g., the method 900 may generally provide functionality for temporarily enabling a remote registry service during a security audit and then disabling the remote registry service in response to suitably completing the security audit). For example, as will be described in further detail herein, the method 900 may be performed to temporarily enable the remote registry service on one or more devices in a network that have disabled the remote registry service (or devices that run operating systems with default settings that disable the remote registry service) and then disable the previously enabled remote registry service in response to suitably obtaining information needed from the registries on such devices.

[0053] For example, in one implementation, an operation 910 may include one or more active vulnerability scanners conducting an active scan in the network to discover various devices in the network, services running on the devices in the network, and vulnerabilities associated with the devices and services discovered in the network. In addition, operation 910 may further include one or more passive vulnerability scanners observing traffic in the network to discover devices actively communicating in the network, services actively running in the network, and vulnerabilities associated with the active devices and the active services discovered in the network. Thus, operation 910 may generally include conducting various active and passive scans in the network, which may be aggregated with various event logs that describe activity in the network (e.g., firewall logs, authentication logs, etc.).

[0054] In one implementation, an operation 920 may then include a log correlation engine analyzing the information aggregated during operation 910 to build a comprehensive model of the devices, services, and vulnerabilities in the network. Furthermore, in one implementation, the model may include information indicating whether certain devices in the network have a remote registry service, whether certain devices in the network run an operating system that typically has default settings associated with the remote registry service, and whether the remote registry service has been enabled or disabled on such devices, among other things. For example, as described in further detail above, the network model built in operation 620 may describe operating systems running on the devices discovered in the network, wherein certain operating systems may be known to have settings that automatically disable the remote registry service (e.g., Windows XP, 2003, Vista™, etc.). Thus, for any devices in the model that lack explicit information indicating whether the devices have a remote registry service that permits remote access to the registries on such devices, discovering the operating systems running on such devices can be used to extrapolate devices in the network that likely have disabled the remote registry service.

[0055] Thus, in one implementation, to enable the remote registry service security audits in the network, one or more credentialed policy scans may be configured in an operation 930. In particular, configuring the credentialed policy scans may include assigning permissions or other credentials to the active vulnerability scanner, whereby the credentials may permit the active vulnerability scanner to enable the remote registry service on any suitable device in the network. For example, in one implementation, operation 930 may include loading one or more the plug-ins that the active vulnerability scanner can execute to temporarily enable, start, or otherwise activate the remote registry service on any devices in the network model discovered to have the remote registry service or an operating system that has default settings disabling the remote registry service. In addition, operation 930 may further include loading plug-ins that the active vulnerability scanner can execute to disable, stop, or otherwise deactivate the previously enabled remote registry service, determine whether or not the remote registry service has been properly enabled or disabled, and enforce policies to control permissions for changing a state of the remote registry service to enabled or disabled, among other things.

[0056] In one implementation, in response to operation 930 appropriately configuring the plug-ins, remote registry scanning preferences, or other criteria for the credentialed policy scans, the active vulnerability scanner may perform the credentialed policy scans in an operation 940. In particular, operation 940 may generally include the active vulnerability scanner enabling or starting the remote registry service on any suitable devices that have the remote registry service disabled or run operating systems that automatically disable the remote registry service. For example, in operation 940, the active vulnerability scanner may communicate one or more messages that can enable the remote registry service on such devices, wherein the remote registry service may then be enabled on such devices in response to determining that the active vulnerability scanner has the appropriate authorizations, permissions, or credentials. As such, an operation 945 may include determining whether the active vulnerability scanner failed to successfully enable the remote registry service on any of the devices, wherein an error message may be generated or remedial action may be initiated in an operation 950 in response to determining that the active vulnerability scanner failed to successfully enable the remote registry service on one or more of the devices.

[0057] Alternatively, in response to determining that the remote registry service was successfully enabled on each of the devices, an operation 960 may include a credentialed audit that scans or otherwise obtains information from the registries on the devices. For example, in one implementation, operation 960 may include the active vulnerability scanner interacting with the temporarily enabled remote registry services on the devices to read keys, values, and other information from the registries on the devices. Moreover, operation 960 may further include the active vulnerability scanner interacting with the temporarily enabled remote registry services to perform file level checks, audit patches, determine remote operating system versions, locate system files, or otherwise audit the devices using information contained in the registries. Thus, enabling the remote registry service in operations 940 and 945 may generally permit the active vulnerability scanner to remotely obtain information from the registries on the devices in the network, which may provide a more comprehensive understanding over the devices, services, and vulnerabilities in the network model.

[0058] Furthermore, in one implementation, various organizations may have security concerns over enabling the remote registry services or otherwise providing mechanisms to remotely access the registries on the devices in the network. In particular, remote scans that obtain information from the remote registry service may originate from external or otherwise unauthorized sources, whereby enabling the remote registry service may expose vulnerabilities in the network (e.g., because external, malicious, or unauthorized users may utilize information obtained from the registries to attack the network). As such, to prevent security vulnerabilities in the network, many public and governmental regulations recommend maintaining the remote registry service in a disabled state, while many organizations may define policies or default configurations adopting such recommendations. Thus, in one implementation, an operation 970 may address the potential security vulnerabilities that may be exposed from enabling the remote registry service.

[0059] For example, in response to operation 960 obtaining the registry information needed to audit the devices, operation 970 may include the active vulnerability scanner communicating one or more messages to disable the remote registry service on any devices that previously had the remote registry service enabled (i.e., in operation 940). As such, rather than leaving the remote registry service running or otherwise enabled, which may expose the network to security risks or other potential vulnerabilities, operation 960 may temporarily enable the remote registry service and operation 970 may then disable the remote registry service to close any security risks or other potential vulnerabilities that could otherwise result from leaving the remote registry service enabled. Furthermore, an operation 975 may then include determining whether the active vulnerability scanner failed to successfully disable the remote registry service on any device in the network.

[0060] For example, in one implementation, operation 975 may include the active vulnerability scanner performing a subsequent active scan to ensure that the remote registry services previously enabled on any devices have been properly disabled, determining whether lost connectivity or manual intervention terminated operation 960 prior to disabling the remote registry service in operation 970, or determining whether other criteria indicate that operation 970 failed to successfully disable the remote registry service. Thus, in response to determining that any of the devices in the network have the remote registry service in an enabled state, an operation 950 may include generating an error message or initiating remedial action to address the enabled state for the remote registry service (e.g., notifying a vulnerability management system that the enabled remote registry service may expose security risks, initiating action to disable the remote registry service, etc.).

[0061] In one implementation, whether the alert generated in operation 950 results in the remedial action may be analyzed in view of the network model or other knowledge of the network that can indicate whether or not to disable the remote registry service. For example, in response to a tool that continuously monitors the network to identify running instances of the remote registry service generating the alert in operation 950, the alert may be analyzed to determine whether the alert relates to a current remote registry service security audit (e.g., the alert may be discarded in response to determining that the remote registry service has been enabled on a device currently subject to the audit operation 960). In one implementation, in response to operation 975 verifying that the previously enabled remote registry services have been successfully disabled, an operation 980 may include utilizing the information gathered during the security audit in the manner described in further detail above. For example, because any attacker that has obtained the required privileges to modify the remote registry service could then use such privileges to enable the remote registry service and thereby improperly obtain information from the device registries, a passive vulnerability scanner may observe traffic in the network to detect any activity that potentially includes unauthorized attempts to access the device registries. Furthermore, the information gathered during the remote registry security audits may be integrated into the network model, whereby operation 980 may include filtering any events generated in the network that describe changes to the remote registry services, analyzing the information obtained from the device registries to identify vulnerabilities in the network, or updating the network model to describe the devices and services in the network with the information obtained from the registries, among other things.

[0062] In summary, the system and method described herein may generally include one or more active vulnerability scanners interrogating devices in the network to discover devices, services, and vulnerabilities in the network, and may further include one or more passive vulnerability scanners passively observing traffic in the network to supplement the information obtained from the active vulnerability scanners. Further, because discovering vulnerabilities in the network typically requires information from the registries associated with the devices in the network, the system and method described herein may model the devices that have disabled remote registry services or operating systems that typically disable the remote registry services. As such, the system and method described herein may temporarily enable or activate the remote registry service on such devices, interact with the enabled remote registry services enabled to obtain information from the registries on such devices, and then returning the remote registry services to a disabled state in response to obtaining the information needed from the registries. Further, as noted above, the active and passive vulnerability scanners can be integrated with a log correlation engine or other components in a vulnerability management system to comprehensively analyze security vulnerabilities in the network.

[0063] Implementations of the invention may be made in hardware, firmware, software, or various combinations thereof. The invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed using one or more processing devices. In one implementation, the machine-readable medium may include various mechanisms for storing and/or transmitting information in a form that can be read by a machine (e.g., a computing device). For example, a machine-readable storage medium may include read only memory, random access memory, magnetic disk storage media, optical storage media, flash memory devices, and other media for storing information, and a machine-readable transmission media may include forms of propagated signals, including carrier waves, infrared signals, digital signals, and other media for transmitting information. While firmware, software, routines, or instructions may be described in the above disclosure in terms of specific exemplary aspects and implementations performing certain actions, it will be apparent that such descriptions are merely for the sake of convenience and that such actions in fact result from computing devices, processing devices, processors, controllers, or other devices or machines executing the firmware, software, routines, or instructions.

[0064] Furthermore, aspects and implementations may be described in the above disclosure as including particular features, structures, or characteristics, but it will be apparent that every aspect or implementation may or may not necessarily include the particular features, structures, or characteristics. Further, where particular features, structures, or characteristics have been described in connection with a specific aspect or implementation, it will be understood that such features, structures, or characteristics may be included with other aspects or implementations, whether or not explicitly described. Thus, various changes and modifications may be made to the preceding disclosure without departing from the scope or spirit of the invention, and the specification and drawings should therefore be regarded as exemplary only, with the scope of the invention determined solely by the appended claims.