SYSTEMS AND METHODS FOR AGGREGATING ASSET VULNERABILITIES

Abstract

In a system for determining vulnerabilities associated with a web property, a network accessible server associated with the property is identified. One or more software components/subsystems associated with that server and, optionally, one or more versions of that component/subsystem are identified. For the identified components and versions thereof, vulnerability information is obtained from a database and compiled to determine vulnerability of the web property, without requiring access to any code of the software components/subsystems.

Description

FIELD OF THE INVENTION

This disclosure generally relates to vulnerability assessment of computer systems and, more particularly, to systems and methods for identifying and aggregating vulnerabilities associated with a network accessible server such as a web server.

BACKGROUND OF THE INVENTION

A web property often includes a network accessible server such as a web server for providing a web service, a secure shell server (SSH), etc. In general, a network accessible server is a system that receives requests from client computers such as laptops, tablets, smart phones, etc., of Internet users and also from other servers in a network, and responds to such requests by providing content and/or one or more functionalities to the clients. For example, a web server may: stream audio/video files, perform a web search, run a database query in response to a client request to provide the requested information, monitor and control a physical system, translate the rendered content from one language into another, etc. A web server may be distributed across several physical computers/servers and a single physical server can be configured as two or more web servers. An SSH server may permit a client computer to access protected computing resources.

In order to provide a service, a network accessible server typically runs one or more software applications. In some instances, one software application may invoke another software application, e.g., to delegate to the other software application a part of the operations corresponding to the requested service. Some of these different software applications associated with a network accessible server may include vulnerabilities such as allowing unauthorized access to client data, commonly called data breach, permitting the network accessible server to be hijacked by a malicious user in furtherance of attacks against other web properties, etc. In some instances, a software application used by a network accessible server may include malware, viruses, etc., and the execution of such a software application in the course of rendering a requested service to a client, therefore, can cause harm to the client.

A web property such as a network accessible server can be owned directly or indirectly by an entity. Usually, the owner entity is liable for any problems associated with a web property, such as those that can be caused by one or more software applications used by a network accessible server. Direct ownership generally occurs when the entity develops or contracts a third party to develop a web property. For example, the owner entity may develop or contractually acquire various software applications to be used in rendering one or more web services. As such, under direct ownership, the owner entity can typically enforce procedures to minimize any problems occurring with a web property/server for which the owner entity may be liable. Problems of which the owner entity is not aware may nevertheless exit in association with some directly owned web properties in part because a typical web service often uses a number of software applications/components that are interrelated in a complex manner, and several of these components may be obtained from different third parties. As such, in some instances, the owner is unaware of all of the software applications/components that are used by a particular web property/server, and some of these software applications/components may have vulnerabilities.

Indirect ownership can occur when an entity may not actively develop and/or manage a web property/server and may not actively control such development/management, but may acquire rights to the web property/server through business/legal transactions such as mergers, acquisitions, etc. As such, an indirect owner often does not know the software applications/components contents, attributes, implementation details, security details, or other characteristics of the indirectly owned web property/server, so as to implement procedures that can minimize the occurrence of problems with that web property/server. In some instances, an indirect owner may not even know the existence of some of the owned web properties/servers. Nevertheless, an indirect owner entity may be responsible or liable for any problems associated with any indirectly owned web property/server, including the consequences of any failures of the web property/server, the consequences of attacks against the web property/server, and any harmful operations performed by the web property/server.

Certain vulnerabilities in both directly owned and acquired software applications/components can be identified by analyzing source and/or machine-readable code of the software. Such testing, however, can be time consuming and onerous, and may need to be repeated when any of the software applications/components is changed substantially. Moreover, a web property owner may not be willing to or may even be unable to grant access to the software code to a third party tester.

SUMMARY OF THE INVENTION

Various embodiments described herein feature identifying any vulnerabilities associated with a network accessible server without analyzing source and/or machine-readable code of any of the software applications/components used by the network accessible server. This is achieved, at least in part, by recording one or more responses to one or more requests to a network accessible server, and by analyzing the received responses to identify the software components (which may include software applications, subsystems, components, etc.) used by the network accessible server. Particular versions of various software components may also be identified. Information on vulnerabilities associated with each software component and particular versions thereof, if identified, is then obtained from a database. That vulnerability information is aggregated to determine the vulnerability of a network accessible server.

Accordingly, in one aspect, a method is provided for determining whether a set of assets (e.g., web properties) of an entity has one or more weaknesses. The method includes performing by a processor the steps of: (a) receiving from a first asset in the set of assets a first set of responses to one or more queries. The first set of responses may include a first set of attributes of one or more software components associated with the first asset. The one or more queries may be sent to the first asset via a network. The method also includes (b) analyzing the first set of attributes to identify the one or more software components associated with the set of assets, and (c) obtaining, from a repository, information on at least one of the one or more identified software components. The method further includes (d) determining using the information whether the first asset and, hence, the set of assets, has a weakness.

The first asset may include a web application server (also called a web server) and/or a secure shell (SSH) server. In some embodiments, the repository includes a software component properties database and/or a software component index. Obtaining information from a repository may include transmitting one or more attributes of one or more identified software components to the repository, e.g., through a network. A response in the set of responses may include a hypertext transfer protocol (HTTP) response and/or a banner. The response may include a header and a body. In some embodiments each one of the set of responses is related to a respective user agent. An attribute from the first set of attributes of software components may include one or more of: a software component name attribute, a software component version attribute, and a unique identifier (ID) corresponding to a software component.

In some embodiments, the set of responses includes a first response that includes a software component name attribute and a version attribute, and a second response that also includes a software component name attribute and a version attribute. Analyzing the first set of attributes may include designating as a first software component a software component corresponding to the name attribute in the first response. The name attribute in the second response may be compared with the name attribute in the first response. In some embodiments, if the name attribute in the second response does not match the name attribute in the first response, the method further include designating as a second software component a software component corresponding to the name attribute in the second response. If the name attribute in the second response matches the name attribute in the first response, the method may include associating the version attributes in the first and second responses with the first software component. The method may include identifying an older one of the versions indicated by the version attributes in the first and second responses.

In some embodiments, obtaining information on any one of the several software components includes receiving a first report on the first software component using the version attribute in the first response and, optionally, receiving a second report on the first software component using the version attribute in the second response. Determining whether the set of assets has one or more weaknesses may include evaluating if one or more of the first and the optional second reports indicates a vulnerability associated with the first software component. In some embodiments, the method includes identifying an additional software component from the information received from the repository, where the additional software component is implied by at least one of the several software components identified in step (b). The method may also include obtaining, from the repository, additional information on the identified additional software component, and determining using the additional information whether the set of assets has a weakness, e.g., as described above.

In some embodiments, the set of assets includes a second asset, and the method includes comprising, prior to performing step (b), (e) receiving from the second asset a second set of responses to one or more queries. The second set of responses may include a second set of attributes of one or more software components associated with the second asset. The method may also include: (f) adding to the first set of attributes the second set of attributes. In this way, when the vulnerabilities are determined by analyzing the attributes in the first set of assets, vulnerabilities corresponding to software components used by both the first and second assets may be identified. In some embodiments, the method includes receiving, in memory, a list of resources and scanning, using a resource scanner, each resource in the list, to obtain the set of assets associated with an entity. Prior to performing step (b), steps (e) and (f) may be repeated for each asset in the set of assets, to determine if the set of various assets associated with the entity has a weakness. A resource in the list of resources may include a domain name, an Internet protocol (IP) address, or a CIDR block. Resource scanning may include one or more of port scanning, idle scanning, domain name service (DNS) lookup, and subdomain brute-forcing.

In another aspect, a computer system includes a first processor and a first memory coupled to the first processor. The first memory includes instructions which, when executed by a processing unit that includes the first processor and/or a second processor, program the processing unit, that is in electronic communication with a memory module that includes the first memory and/or a second memory, to: (a) receive from a first asset in the set of assets a first set of responses to one or more queries. The first set of responses may include a first set of attributes of one or more software components associated with the first asset. The instructions also program the processing unit to: (b) analyze the first set of attributes to identify the one or more software components associated with the set of assets. Moreover, the instructions program the processing unit to: (c) obtain, from a repository, information on at least one of the one or more identified software components, and (d) determine using the information whether the set of assets has a weakness.

In some embodiments, the instructions program the processing unit to transmit the queries to the first asset, and to determine from the received first set of responses if the first asset includes a web application server or a secure shell (SSH) server. The instructions may also program the processing unit to transmit one or more of the queries according to a user agent, where one or more responses in the set of responses are related to the user agent. In some embodiments, the set of assets includes a second asset, and the instructions program the processing unit to: (e) receive from the second asset a second set of responses to one or more queries. The second set of responses may include a second set of attributes of one or more software components associated with the second asset. The instructions may also program the processing unit to: (f) add to the first set of attributes the second set of attributes, prior to analyzing by the processing unit the first set of attributes to identify the one or more software components associated with the set of assets.

In some embodiments, the instructions program the processing unit to receive in memory a list of resources, and scan, using a resource scanner, each resource in the list, to obtain the set of assets associated with an entity, to determine if the set of assets associated with the entity has a weakness. The instructions may program the processing unit to perform as the resource scanner. In various embodiments, the instructions can program the processing unit to perform one or more of the method steps described above.

In another aspect, an article of manufacture that includes a non-transitory storage medium has stored therein instructions which, when executed by a processor program the processor, which is in electronic communication with a memory, to: (a) receive from a first asset in the set of assets a first set of responses to one or more queries. The first set of responses may include a first set of attributes of one or more software components associated with the first asset. The instructions also program the processor to: (b) analyze the first set of attributes to identify the one or more software components associated with the set of assets. Moreover, the instructions program the processor to: (c) obtain, from a repository, information on at least one of the one or more identified software components, and (d) determine using the information whether the set of assets has a weakness. In various embodiments, the stored instructions can program the processor to perform one or more of the method steps described above.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the present invention taught herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which:

FIG. 1 schematically depicts a vulnerability analysis system, according to one embodiment;

FIG. 2 shows an example of intermediate results obtained using an embodiment of a vulnerability analysis system; and

FIG. 3 schematically depicts a system for identifying domains and/or subdomains likely owned by an entity, according to one embodiment.

DETAILED DESCRIPTION

With reference to FIG. 1, a domain scanner 102 identifies one or more network accessible servers (e.g., web server 104), that are associated with a specified domain/subdomain 106 such as XYZ.com, www.XYZ.com, w3.PQR.org, etc. To this end, the domain scanner 102 may send a request such as a hyper-text transfer protocol (HTTP) request, Web Request, etc., to various Internet Protocol (IP) addresses associated with the domain/subdomain 106. The domain scanner 102 may designate any server responding to such a request a network accessible server. The responses may be recorded and/or forwarded to a component analyzer 108. In one embodiment, the domain scanner 102 selects a particular network accessible server (e.g., the web server 104) and sends additional requests to the web server 104. Each request may correspond to a different user agent such as Firefox™, Internet Explorer™, Chrome™, a mobile device user agent, etc. The corresponding responses from the web server 104 and an identifier of the web server are forwarded to the component analyzer 108. In some embodiments, the domain scanner 102 selects each server designated as a network accessible server, sends additional requests thereto, and forwards the received responses and an identifier for that network accessible server to the component analyzer 108. A response may include a header and a body, and a header can be an HTTP header, a banner, etc. In some embodiments, only the header portion of a response is forwarded to the component analyzer 108. In some embodiments, another module instead of or in addition to the domain scanner 102 sends requests to one or more network accessible servers (e.g., the web server 104).

The description below refers to web servers for the sake of convenience, but it should be understood that the systems and methods described herein are not limited to web servers only and can analyze various types of network accessible servers. The component analyzer 108 analyzes the responses received from a particular web server (e.g., the web server 104) and identifies software components therein. The types or categories of components/software subsystems/technologies identified by the component analyzer 108 include but are not limited to content management systems, e-Commerce platforms, JavaScript frameworks, etc. The component analyzer 108 may also have knowledge about typical relationships between software components. For example, if the component analyzer 108 determines that the web server 104 uses Component A (e.g., Wordpress), the component analyzer 108 may determine, using a knowledgebase thereof, that the web server 104 uses Component B (e.g., PHP), as well.

In identifying a software component, the component analyzer 108 typically determines one or more attributes of the component. Common attributes include the component name and the component version. In some embodiments, the component attributes that are determined include a unique identifier associated with the software component. With reference to FIG. 2, the component analyzer 108 analyzed five different responses from the web server 104 in which, from the first response, the component analyzer determined that the web server 104 uses “Component A” version “1.1.” From the next two responses, the component analyzer 108 determined again, by comparing the name attributes, that the web server 104 uses “Component A,” but determined that versions “1.6” and “1.4” thereof are used. Some web servers may in fact use different versions of the same component in different contexts, e.g., with different user agents. In some instances, different versions of the same component (e.g., jQuery) may be loaded with a single user agent. Therefore, different responses can identify different versions of the same component. From the fourth response, the component analyzer 108 determined again that the web server 104 uses “Component A,” but did not identify the particular version used from the fourth response. In some instances, the component analyzer 108 may identify a version of a software component used, but may not be able to determine the name thereof. From the fifth response, the component analyzer 108 determined by comparing the name attributes that the web server 104 uses another component, “Component B” version “1.4.”

It should be understood that the analysis of responses described with reference to FIG. 2 is illustrative only and that in general, a component analyzer may analyze any number of responses. For example, the component analyzer 108 may analyze 1, 2, 6, 10, 25, 100, 140, 200, etc., messages from each of several e.g., 2, 3, 5, 10, etc., web servers. In general, the number of software components used by a web server that a component analyzer may identify can be any number such as 1, 3, 7, 8, 10, 15, 20, etc. The identified software components may include software components implied by other identified software components. In various embodiments, the version numbers can include names and numbers, and a version number, in general, can be any character or string of any length of any letters, numbers, and/or characters. While FIG. 2 depicts that the component analyzer 108 stores the information about software components as a JSON object, different embodiments of a component analyzer may use other structures such as linked lists, arrays, trees, heaps, hash tables, etc., to store and to analyze further the extracted information.

Referring back to FIG. 1, after identifying at least some of the software components used by a web server, an aggregator 110 processes the list of identified components. For example, the aggregator 110 may remove duplicates. In some embodiments, a component is considered to be a duplicate of another component if the two components have the same name and other attributes, e.g., the same version number. From a de-duplicated list, the aggregator 110 may optionally sort the identified versions of each component, and may optionally identify the latest and/or the oldest version. To this end, the component analyzer may employ alpha-numeric sorting. In some embodiments, the aggregator 110 queries a database that provides the release date associated with a specified version of a specified component. This analysis can be useful because in some instances a vulnerability in an older version of a software component is cured in a later version. On the other hand, in some instances, a newer version has a vulnerability that did not exist in an older version or the older version was tested for vulnerabilities but the newer version was not and, hence, vulnerability information is available only for an older version. The aggregator 110 may also identify the most frequently and/or least frequently used versions of an identified software component.

For a selected version (e.g., the latest, oldest, most frequently occurring, etc.) of an identified software component, the aggregator 110 queries one or more databases 112 to obtain vulnerability information about that version of the software component. A database 112 may include a software component properties database and/or a software component index, and may be provided by a third party (e.g., Mitre.org, GitHub, etc.) or may be a proprietary database. The aggregator 110 may access the database 112 directly (e.g., through a proprietary network) and/or through a public network (e.g., the Internet). In some embodiments, the aggregator 110 obtains vulnerability information from the databases 112 for one or more selected versions (e.g., all versions) of one or more selected software components (e.g., all software components) determined to be associated with a selected web server determined to be belonging to a specified owner entity. This process may be repeated for one or more (e.g., all) other web servers determined to be belonging to that owner entity, and for other owner entities, as well. In addition to the vulnerability information, the databases 112 may provide the release dates of the specified versions of the specified software components.

For a selected web server (e.g., the web server 104), the aggregator 110 compiles the vulnerability information to determine vulnerability of the selected web server. In general, the vulnerability of a web server may depend on parameters such as the number of software components used by the web server where at least one version of the software component is reported as vulnerable by the database 112, the number of identified software components where each version or a significant number of versions are reported as vulnerable. In this context, significant can be 90% of all versions, 80% of all versions, 50% of all versions, etc. In some embodiments, the parameters may include respective degrees of vulnerabilities associated with various versions of various software components.

The parameters may also include a known or an expected frequency of use of a particular version and/or known or expected frequency at which the web server provides a service for which a particular component is used. A particular web server may provide two or more web services, where a different set of software components is used in rendering each service. As such, if a web server uses a version of a component reported to be vulnerable to facilitate a service that is provided infrequently, the web server may be designated as vulnerable, but to a lesser degree than if a version of a component reported to be vulnerable is used to facilitate a service that is provided relatively frequently.

The aggregator 110 can thus provide a measure of vulnerability of one or more web servers belonging to an owner entity. The vulnerability analysis may be performed periodically and/or when a significant change is made to a web server. The aggregator 110 performs the vulnerability analysis using responses to requests sent to a web server and, as such, the aggregator 110 can perform the vulnerability analysis remotely, without requiring access to any source code or machine-readable code of the web server.

In some situations, an owner entity may not be aware of all of the web properties owned by the entity and for which the entity may be liable. In these situations, with reference to FIG. 3, a resource scanner 302 can receive information such as domain names and/or subdomain names 304a that are known to be owned by the entity, Internet protocol (IP) addresses 304b that are associated with the entity, and/or classless inter-domain routing (CIDR) blocks 304c. Using this information, the resource scanner 302 can generate a list 306 of domains and subdomain names owned by the entity. To this end, the scanner may employ one or more of port scanning, which can include transmission control protocol (TCP) scanning, protocol scanning, etc., idle scanning, domain name search (DNS) lookup, which may include one or more of standard DNS queries, zone transfer queries, and reverse DNS lookups, search using APIs provided by search engines, and subdomain brute-forcing on domain names, to identify the domains/subdomains that may be owned by the entity. One or more network accessible servers may be associated with each identified domain/subdomain. The domain scanner 102 (described with reference to FIG. 1) can identify these servers, for which the owner entity may be liable. The procedures described above with reference to FIGS. 1 and/or 2 may be applied to each identified network accessible server associated with each identified domain/subdomain to determine weaknesses associated with various web properties.

It is clear that there are many ways to configure the device and/or system components, interfaces, communication links, and methods described herein. The disclosed methods, devices, and systems can be deployed on convenient processor platforms, including network servers, personal and portable computers, and/or other processing platforms. Other platforms can be contemplated as processing capabilities improve, including personal digital assistants, computerized watches, cellular phones and/or other portable devices. The disclosed methods and systems can be integrated with known network management systems and methods. The disclosed methods and systems can operate as an SNMP agent, and can be configured with the IP address of a remote machine running a conformant management platform. Therefore, the scope of the disclosed methods and systems are not limited by the examples given herein, but can include the full scope of the claims and their legal equivalents.

The methods, devices, and systems described herein are not limited to a particular hardware or software configuration, and may find applicability in many computing or processing environments. The methods, devices, and systems can be implemented in hardware or software, or a combination of hardware and software. The methods, devices, and systems can be implemented in one or more computer programs, where a computer program can be understood to include one or more processor executable instructions. The computer program(s) can execute on one or more programmable processing elements or machines, and can be stored on one or more storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), one or more input devices, and/or one or more output devices. The processing elements/machines thus can access one or more input devices to obtain input data, and can access one or more output devices to communicate output data. The input and/or output devices can include one or more of the following: Random Access Memory (RAM), Redundant Array of Independent Disks (RAID), floppy drive, CD, DVD, magnetic disk, internal hard drive, external hard drive, memory stick, or other storage device capable of being accessed by a processing element as provided herein, where such aforementioned examples are not exhaustive, and are for illustration and not limitation.

The computer program(s) can be implemented using one or more high level procedural or object-oriented programming languages to communicate with a computer system; however, the program(s) can be implemented in assembly or machine language, if desired. The language can be compiled or interpreted.

As provided herein, the processor(s) and/or processing elements can thus be embedded in one or more devices that can be operated independently or together in a networked environment, where the network can include, for example, a Local Area Network (LAN), wide area network (WAN), and/or can include an intranet and/or the Internet and/or another network. The network(s) can be wired or wireless or a combination thereof and can use one or more communications protocols to facilitate communications between the different processors/processing elements. The processors can be configured for distributed processing and can utilize, in some embodiments, a client-server model as needed. Accordingly, the methods, devices, and systems can utilize multiple processors and/or processor devices, and the processor/processing element instructions can be divided amongst such single or multiple processor/devices/ processing elements.

The device(s) or computer systems that integrate with the processor(s)/ processing element(s) can include, for example, a personal computer(s), workstation (e.g., Dell, HP), personal digital assistant (PDA), handheld device such as cellular telephone, laptop, handheld, or another device capable of being integrated with a processor(s) that can operate as provided herein. Accordingly, the devices provided herein are not exhaustive and are provided for illustration and not limitation.

References to “a processor”, or “a processing element,” “the processor,” and “the processing element” can be understood to include one or more microprocessors that can communicate in a stand-alone and/or a distributed environment(s), and can thus can be configured to communicate via wired or wireless communications with other processors, where such one or more processor can be configured to operate on one or more processor/processing elements-controlled devices that can be similar or different devices. Use of such “microprocessor,” “processor,” or “processing element” terminology can thus also be understood to include a central processing unit, an arithmetic logic unit, an application-specific integrated circuit (IC), and/or a task engine, with such examples provided for illustration and not limitation.

Furthermore, references to memory, unless otherwise specified, can include one or more processor-readable and accessible memory elements and/or components that can be internal to the processor-controlled device, external to the processor-controlled device, and/or can be accessed via a wired or wireless network using a variety of communications protocols, and unless otherwise specified, can be arranged to include a combination of external and internal memory devices, where such memory can be contiguous and/or partitioned based on the application. For example, the memory can be a flash drive, a computer disc, CD/DVD, distributed memory, etc. References to structures include links, queues, graphs, trees, and such structures are provided for illustration and not limitation. References herein to instructions or executable instructions, in accordance with the above, can be understood to include programmable hardware.

Although the methods and systems have been described relative to specific embodiments thereof, they are not so limited. As such, many modifications and variations may become apparent in light of the above teachings. Many additional changes in the details, materials, and arrangement of parts, herein described and illustrated, can be made by those skilled in the art. Accordingly, it will be understood that the methods, devices, and systems provided herein are not to be limited to the embodiments disclosed herein, can include practices otherwise than specifically described, and are to be interpreted as broadly as allowed under the law.

Claims

1. A method of determining whether a set of assets of an entity has a weakness, the method comprising performing by a processor the steps of:

identifying a set of assets comprising at least one network accessible server by scanning at least one domain or a subdomain identified by a name, using a domain scanner;

(a) receiving from a first asset in the set of assets a first set of responses to one or more queries, the first set of responses comprising a first set of attributes describing identity of one or more potentially vulnerable software components associated with the first asset;

(b) analyzing the first set of attributes to identify the one or more potentially vulnerable software components associated with the set of assets;

(c) obtaining, from a repository, vulnerability information on at least one of the one or more identified software components; and

(d) determining using the vulnerability information and without testing the one or more identified software components subsequent to the identification thereof whether the set of assets has a weakness.

2. The method of claim 1, wherein the first asset comprises at least one of a web application server and a secure shell (SSH) server.

3. The method of claim 1, wherein a response in the set of responses comprises at least one of a hypertext transfer protocol (HTTP) response and a banner.

4. The method of claim 1, wherein each response in the set of responses is related to a respective user agent.

5. The method of claim 1, wherein an attribute from the first set of attributes of software components comprises at least one of: a software component name attribute, a software component version attribute, and a unique identifier (ID) corresponding to a software component.

6. The method of claim 1, wherein the repository comprises at least one of a software component properties database and a software component index.

7. The method of claim 1, wherein obtaining information from a repository comprises transmitting at least one attribute of at least one identified software component to the repository.

8. The method of claim 1, wherein:

the set of responses comprises a first response comprising a software component name attribute and a version attribute, and a second response also comprising a software component name attribute and a version attribute; and

analyzing the first set of attributes comprises: designating as a first software component a software component corresponding to the name attribute in the first response; and comparing the name attribute in the second response with the name attribute in the first response.

9. The method of claim 8, wherein the name attribute in the second response does not match the name attribute in the first response, the method further comprising designating as a second software component a software component corresponding to the name attribute in the second response.

10. The method of claim 8, wherein the name attribute in the second response matches the name attribute in the first response, the method further comprising associating the version attributes in the first and second responses with the first software component.

11. The method of claim 10, further comprising identifying an older version of the first software component from at least one of the version attributes in the first and second responses.

12. The method of claim 10, wherein obtaining information on at least one of the one or more software components comprises:

receiving a first report on the first software component using the version attribute in the first response; and

receiving a second report on the first software component using the version attribute in the second response.

13. The method of claim 12, wherein determining whether the set of assets has a weakness comprises evaluating if at least one of the first and second reports indicates a vulnerability associated with the first software component.

14. The method of claim 1, further comprising:

identifying an additional software component from the information received from the repository, the additional software component being implied by at least one of the one or more software components identified in step (b);

obtaining, from the repository, additional information on the identified additional software component; and

determining using the additional information whether the set of assets has a weakness.

15. The method of claim 1, wherein the set of assets comprises a second asset, the method further comprising, prior to step (b):

(e) receiving from the second asset a second set of responses to one or more queries, the second set of responses comprising a second set of attributes of one or more software components associated with the second asset; and

(f) adding to the first set of attributes the second set of attributes.

16. The method of claim 15, further comprising:

receiving, in memory, a list of resources; and

scanning each resource in the list using a resource scanner configured to provide domain and subdomain names, to obtain a list of names, each name being a domain name or a subdomain name associated with an entity, wherein:

identifying the set of assets comprises scanning using the domain scanner a domain or subdomain associated with each name in the list of names; and

determining whether the set of assets has a weakness comprises, prior to step (b), repeating steps (e) and (f) for each asset in the set of assets.

17. The method of claim 16, wherein a resource in the list of resources comprises one of a domain name, an Internet protocol (IP) address, and a CIDR block.

18. The method of claim 16, wherein resource scanning comprises at least one of:

port scanning, idle scanning, domain name service (DNS) lookup, and subdomain brute-forcing.

19. A system for determining whether a set of assets of an entity has a weakness, comprising:

a first processor; and

a first memory in electrical communication with the first processor, the first memory comprising instructions which, when executed by a processing unit comprising at least one of the first processor and a second processor, program the processing unit to:

identify a set of assets comprising at least one network accessible server by scanning at least one domain or a subdomain identified by a name, using a domain scanner;

(a) receive from a first asset in the set of assets a first set of responses to one or more queries, the first set of responses comprising a first set of attributes describing identity of one or more potentially vulnerable software components associated with the first asset;

(b) analyze the first set of attributes to identify the one or more potentially vulnerable software components associated with the set of assets;

(c) obtain, from a repository, vulnerability information on at least one of the one or more identified software components; and

(d) determine using the vulnerability information and without testing the one or more identified software components subsequent to the identification thereof whether the set of assets has a weakness.

20. The system of claim 19, wherein the instructions program the processing unit to:

transmit the queries to the first asset; and

determine from the received first set of responses if the first asset includes a web application server or a secure shell (SSH) server.

21. The system of claim 20, wherein:

the instructions program the processing unit to transmit at least one of the queries according to a user agent; and

at least one response in the set of responses is related to the user agent.

22. The system of claim 19, wherein an attribute from the first set of attributes of software components comprises at least one of: a software component name attribute, a software component version attribute, and a unique identifier (ID) corresponding to a software component.

23. The system of claim 19, wherein to obtain information from a repository, the instructions program the processing unit to transmit at least one attribute of at least one identified software component to the repository.

24. The system of claim 19, wherein:

the set of responses comprises a first response comprising a software component name attribute and a version attribute, and a second response also comprising a software component name attribute and a version attribute; and

to analyze the first set of attributes, the instructions program the processing unit to: designate as a first software component a software component corresponding to the name attribute in the first response; and compare the name attribute in the second response with the name attribute in the first response.

25. The system of claim 24, wherein:

the name attribute in the second response does not match the name attribute in the first response; and

the instructions program the processing unit to designate as a second software component a software component corresponding to the name attribute in the second response.

26. The system of claim 24, wherein:

the name attribute in the second response matches the name attribute in the first response; and

the instructions program the processing unit to associate the version attributes in the first and second responses with the first software component.

27. The system of claim 26, wherein the instructions program the processing unit to identify an older one of the version attributes in the first and second responses.

28. The system of claim 26, wherein to obtain information on at least one of the one or more software components, the instructions program the processing unit to:

receive a first report on the first software component using the version attribute in the first response; and

receive a second report on the first software component using the version attribute in the second response.

29. The system of claim 28, wherein to determine whether the set of assets has a weakness, the instructions program the processing unit to evaluate if at least one of the first and second reports indicates a vulnerability associated with the first software component.

30. The system of claim 19, wherein the instructions program the processing unit to:

identify an additional software component from the information received from the repository, the additional software component being implied by at least one of the one or more software components identified in step (b);

obtain, from the repository, additional information on the identified additional software component; and

determine using the additional information whether the set of assets has a weakness.