Patent Description:
During the last years, digitization has become more and more relevant and is an integral party in our daily lives. It is beyond dispute that security is a core need for digitization, Industry <NUM> and Internet of Things (IoT), and with <NUM> - the digital life - the "attack surface" is to become larger due to the new dimensions of connected entities.

According to the source "https://github. com/BishopFox/eyeballer", there are <NUM> billion IoT connected devices in <NUM>, while <NUM> billion devices are forecasted by <NUM>. Meanwhile, the number of successful large-scale cyber-attacks is rising, e.g., Emotet and WannaCry, and the asymmetry in the cyberwarfare is increasing. Here, skilled hacker ability increases to harm enterprises, organizations and even states despite more investments in the defense line.

Thereby, a fundamental question the driver of digitization and <NUM> needs to answer is: How adopters of digitization and <NUM> can be well prepared against security threats?.

Especially the following three points pose an immense challenge, with which existing security measures and tools have not been able to cope:.

Due to these facts and the limitation of existing solutions, even malicious users with low level of expertise have become capable to hack large organizations, internet service provider and/or internet capable devices.

<CIT> teaches an computer-implemented method for mapping Internet Protocol addresses for an organization may include receiving information for an organization from an organizational server, extracting data from a plurality of server data sources associated with the information, mapping the data from the plurality of sever data sources to the information, and determining, based at least in part on the mapped data, a list of IP addresses identifying one or more relationships associated with the organization thereby facilitating performing a security posture analysis against a malicious attack.

In the view of above, it is an object of the present invention to provide a method, a computer and a computer program product that enable organizations, internet service provider and/or internet capable devices to efficiently perform security investigations.

A netblock is a range of consecutive IP addresses, for instance: <NUM>. <NUM>-<NUM>. Netblocks are sometimes displayed in Classless InterDomain Routing (CIDR) notation. For instance, <NUM>. <NUM>-<NUM>. <NUM> is <NUM>. <NUM>/<NUM>. The list of organization names and main domain names (and substrings of these) are collected in previous steps about an enterprise. These are fed to regional Internet registry (RIR) databases (online available) and all netblocks having this information are gathered. For several reasons like inaccurate, outdated or invalid data in the RIRs' databases, it is necessary to validate the netblocks. The validation is also necessary to verify if the netblocks, even when they belong to an enterprise, are really being used by that enterprise and not by one of its customers. An IP address of netblock is considered being valid if this IP address belongs to the company in question. Basic aspects of the validating step are taught in the <CIT>. Searching, clustering and validating netblocks has the advantage that other active IT systems and/or IT services that may belong to the entity can be effectively identified in order to obtain a comprehensive and up-to-date overview of the attack surface of the entity. Netblocks can comprise the IP addresses of IT services that are not related to webpages for example. Therefore, the invention enables the validating of netblocks that can be used in further security assessments. The validating insurers that the netblocks really belong to that company in question. The valid marked netblocks can be clustered into "similar" groups and then efficiently be tested with respect to security issues.

In an embodiment, the steps of the method are looped over list of netblocks. This has the advantage that not only one netblock but multiple netblocks can efficiently be validated and marked accordingly, too.

In an embodiment, the netblock or the list of netblocks is generated by transferring organization names, main domains and/or other information about the company into a netblock data source. Hence, a netblock searching step is performed, wherein a list of netblocks is generated by using an initial target name (e.g. Telekom, Amazon), additional target names, main domains of the companies and/or the subdomains as input to the netblock data source, in particular a Regional Internet Registry or a Whois database. An algorithm can be configured to search for appropriate search strings within these databases. This provides the advantage of an efficient way to generate a netblock or the list of netblocks by means of information which are easy accessible.

In an embodiment, the validation step comprises an advance checking step. In particular, the advance checking step is executed before other parts of the validation step are performed. The advance checking step checks if a predefined number of IP addresses, in particular if two IP addresses within the same net block, are valid in the same net block. Only if this is true, the validation process continues. This offers the advantage that computational resources of the validation process are only used if there is an indication that the net block really belongs to the company. This increases the efficiency of the method.

In an embodiment, the validation step comprises a determination of the number of responsive IP addresses of the netblock, nresp, because only responsive IP addresses can be validated. Therefore, this provides the advantage of an efficient validation process by excluding nonresponsive IP addresses from further validation tests.

In an embodiment, the determination of the number of responsive IP addresses comprises an evaluation of the IP address range, ntot. This provides the advantage that an algorithm can run over all IP addresses within the network ntot in order to test if they are responsive IP addresses.

In an embodiment, based on the IP address range the responsive IP addresses are obtained by a complete port scan or can be obtained by inspecting an external data source. A complete port scan uses frequently used ports like <NUM>, <NUM>, <NUM> and/or <NUM>. Especially in case of IPv4 netblocks, a port scan for a single port can be performed within five minutes. On the other hand if the address space is very large, as it is the case with IPv6, it can be more efficient to access the external data source of a provider that performs regular scans on the whole Internet address range (e.g. Censys, Shodan or Project Sonar Port Scan) to obtain the responsive ports. Using the external data source has the downside that one does not know about the up-to-dateness of the data.

In an embodiment, validation features are extracted to perform the validation step. To this end, a set of netblocks validation features are defined that can also be used in a clustering algorithm to get clusters based on those features (example of netblocks validation features are netname, description, registrant contact, registrant contact email address, administrative contact, administrative contact email address, etc.). These communication features are easy accessible.

In an embodiment, the evaluation is based on statistical methods. This provides the advantage that users can define how to set the confidence level in order to judge if the netblock is valid or not. If more netblocks shall be marked as valid, the user can set a lower confidence level for the statistical evaluation. Setting the confidence level lower also results in the fact that less IP addresses need to be tested. Of course, the former statements are vice versa if the user chooses a higher confidence level, e.g. of <NUM>%. It follows that the statistical methods provide a flexible method to judge if the netblock is valid, invalid or not determinable.

In an embodiment, a needed number out of the total number of responsive IP addresses, i.e. subset, is determined to achieve significant results in the evaluation step. This provides the advantage that the method can be performed very efficiently without testing unnecessary IP addresses.

In an embodiment, the subset is expanded up to the total number of responsive IP Addresses until the evaluation is statistically significant. This provides the advantage of having an alternative strategy if the number of IP addresses of the subset is not sufficient to achieve a significant result in order to mark the netblock valid or invalid. However, because this alternative strategy of using the total number of responsive IP addresses is only used if the subset is not sufficient, the method first tries the most efficient approach. First using the subset of responsive IP addresses and then expanding it to the total number of responsive IP addresses does in principle not demand more computational resources then using the total number of responsive IP addresses in the first place. This shows the benefits of the step-by-step approach.

<FIG> shows an overview of a modular solution approach <NUM> to mitigate cyberattacks, wherein the invention represents one module of the solution approach.

The modular solution approach <NUM> is a novel combination of systems/modules for identifying and evaluating the attack surface of a company in real time. It automatically retrieves a comprehensive inventory of the IT infrastructure of a company/internet service provider. Based on an innovative framework, the modular solution approach <NUM> interconnects different systems in a recursive manner to efficiently collect all in-scope information. Moreover, it is enhanced in time vulnerability analysis of a company's IT infrastructure makes the modular solution approach <NUM> an attractive solution for risk management of oneself and of contractual partners. The information gathered by the modular solution approach <NUM> is relevant for any company to accelerate management discussions and to take appropriate IT security decisions.

A first module <NUM> focuses on creating a list of all comprehensive inventory/list of the IT infrastructure of a company/internet service provider as a starting point in an automatic fashion. In principle, all cyber risks could be determined manually from this comprehensive list. However, especially in the case of large companies this list is likely to be so large and the individual risk of each IT-unit and/ or IT-services could change so dynamically that an efficient risk assessment is only possible if the large number of IT-unit and/or IT-services, e.g. websites and/or internet capable devices, is clustered in groups having similar properties. The next module is a classification and clustering module <NUM> of the modular solution approach <NUM>, which leads to a significant improve of the overall performance of the modular solution approach <NUM>, in particular it provides better attack surface evaluation and an overview of higher transparency and accuracy.

The third module <NUM> serves the purpose to evaluate the vulnerabilities of each cluster, which is very efficient because that each IT-unit and/or each IT-service within the same cluster shows a similar vulnerability.

The box <NUM> shows possible insights that the company gets from the modular solution approach <NUM>, namely: How effective are my implemented security measures? How is my security posture in comparison to other companies in the same sector? What (alternative or new) security measures shall be implemented and which results are to expect? Which IT-unit and/or which IT-service needs immediate care?.

In the following it might happen due to ease the reading of the text that only the term IT-service will be used. However, the described techniques can be applied to the IT-units, too.

Given the large number of assets (IT systems) per enterprise and the different indicators of security issues in general, it is imperative to have (semi-) automated methods to discover relevant security issues on a large scale. One major step towards increasing the detection coverage and rate of security issues is to gain a more transparent and accurate overview of the network. <FIG> shows a schematic overview of the method for automatic and dynamic determination of IT systems and/or IT-services belonging to an entity, respectively a company, an enterprise, an organization or the like. The method starts with the initial step <NUM>, wherein an initial target name is defined. The initial target name can be the name or title of the entity, e.g. "Deutsche Telekom". A user can enter the initial target name by an input device of a computer system <NUM> that performs the method, or it could be defined automatically by the computer system <NUM>.

The process of automatic and dynamic determination of IT systems and/or IT-services belonging to an entity is described in the <CIT>.

On basis of the initial target name a target name searching step <NUM> is performed, wherein a list of additional target names is generated. In order to search for the additional target names the computer system <NUM> uses the initial target name as input for a request to a first database <NUM>. The first database <NUM> is for example a merge and acquisition database, such as S&P Capital IQ, Amadeus, official register (e.g. Bundesanzeiger) or the like. By access to the first database <NUM> the computer system <NUM> retrieves subsidiaries of the entity as additional target names and saves them within the list of additional target names.

The initial target name and the additional target names are used as basis for a main domain query step <NUM>, wherein a list of main domains is generated. In order to obtain the main domains, the computer system <NUM> uses the initial target name and the additional target names as input for a request to a second database <NUM>. The second database <NUM> is for example web certificate data base (e.g. https://crt. sh) or a search engine (e.g. google or wikipedia-api). By access to the second database <NUM> the computer system <NUM> retrieves main domains of the entity, including their subsidiaries. Main domains are in particular second level domains, e.g. "telekom. de" or "systems.

By usage of the queried main domains a subdomain enumeration step <NUM> is performed, wherein a list of subdomains is generated in addition to the existing list main domains. In order to enumerate the subdomains, the computer system <NUM> uses the main domains as input for a request to a third database <NUM>. The third database <NUM> is for example a certificate data base (e.g. https://crt. sh), a subdomain enumeration tool or a passive domain name server database. By using the third database <NUM> the computer system <NUM> retrieves subdomains of the entity. Subdomains are in particular lower level domains, like "admin. de" or "test. The list of subdomains could be a part of the list of main domains, or a separate list.

The domains of the list of main domains and the list of subdomains are validated with a domain validation step <NUM>, wherein the domains are considered as valid (belonging to entity), invalid (not belonging to entity) or not determinable, when the validity could not be determined.

For the determination of the validity of the domains validation features are extracted from the domains. Validation features of the domains are information of the owner and/or assignee of the domain, like a Whois information, a certificate information, an imprint information and/or a privacy policy information. On basis of validation feature (hard criteria), the validity of the domains could be evaluated.

In addition, supportive features are extracted from the domains and evaluated by a supervised machine learning unit <NUM> in order to determine the validity of the domains. Supportive features of domains are information that relate to the appearance of the domain, like a Cascading Style Sheet information, a vocabulary information and/or a Favicon information of the domain. On basis of supportive validation features (soft criteria), the validity of the domains could be evaluated by usage of the supervised machine learning unit <NUM>.

The supervised machine learning unit <NUM> is implemented within the computer system <NUM> and corresponds to a machine algorithm, for example a random forest algorithm or the like. The machine learning unit <NUM> is trained by supportive features extracted from valid domains, wherein the validity was determined on basis of the validation features. By usage of the machine learning unit <NUM> a link between the validation features and the supportive features is realized.

Within the domain name searching step <NUM> new main domains and/or new subdomains are searched on the basis of the valid domains of the list of main domains and/or the list of subdomains. For the search of new main domains and/or subdomains the valid domains are used as input for reverse searching techniques. Examples for these techniques are: Reverse Whois, Reverse Name Server, Reverse Mail Server, Buit-With and/or a search engine, like a Shodan Favicon Search. The found new main domains and/or new subdomains are preferably added to the list of main domains and/or the list of subdomains and validated by usage of the domain validation step <NUM>.

A list of IP addresses is generated on basis of the list the domains of the list of main domains and/or the list of subdomains within an IP address searching step <NUM>. The computer system <NUM> uses the domains as input for a fourth database <NUM> in order to obtain the corresponding IP addresses. The fourth database <NUM> is preferably a domain name system (DNS) server, wherein the IP addresses are resolved on the basis of the domains. In a preferred embodiment the validity of the IP addresses is also evaluated within the IP address searching step <NUM>. For that it is checked whether the IP address corresponds to a valid or invalid domain. The IP addresses of the list of IP addresses are considered as valid (belonging to entity), invalid (not belonging to entity), not determinable (when the validity could not be determined) or non-validatable.

A main idea of this invention is about a generation and validation of a list of netblocks or IP blocks in a netblock searching step <NUM>. In the example of <FIG>, the netblock searching step <NUM> is performed after all the other processes. However, in principle can be performed as the first step. Therefore, details about the other processes can be found in the <CIT>, wherein the netblock searching and validation step <NUM> will be described in detail in the following.

The computer system <NUM> uses the initial target name, the additional target names, the main domains and/or the subdomains as input for a fifth database <NUM>. The fifth database <NUM> is also named as the netblock database <NUM>. The netblock database <NUM> is preferably an IP Whois database and/or a Regional Internet Registry, like the RIPE for Europe and Middle East. Preferably, all netblocks or IP blocks are collected and validated on basis of netblock validation features, such as netname, description, registrant contact, registrant contact e-mail address, administrative contact or administrative contact e-mail address.

The target name searching step <NUM>, the main domain query step <NUM>, the subdomain enumeration step <NUM>, the domain validation step <NUM>, the domain name searching step <NUM>, the IP address searching step <NUM> and/or the netblock searching step <NUM> are repeated within iteration loops. The further iteration loop is stopped when no new active IT systems, respectively assets, are found.

<FIG> show schematic flow charts of a netblock searching step <NUM>.

The flow chart of <FIG> is performed when the netblock searching step <NUM> is performed for the first time. Here, netblocks containing known domains, target names and/or IP-addresses of a company are searched (step <NUM>) in order to find netblocks of this company and then to classify clusters of netblocks (step <NUM>).

The flow chart of <FIG> is executed when further iterations are performed. Valid IP addresses within the netblock are checked (step <NUM>) by evaluating whether a certain number of (preferably two) IP addresses of the netblock are valid (step <NUM>); if yes, the validity of a first number N<NUM> of random IP addresses of the netblock is checked by performing the validation part of the IP address searching step <NUM> (step <NUM>); when all IP addresses are valid (<NUM>), the netblock is considered as valid (step <NUM>). The first number N<NUM> is set as to ensure that one can trust the validation of step <NUM> with a confidence of over <NUM> %. If not all of the first number N<NUM> of IP addresses are valid, then the netblock is tagged as not determinable.

Invalid IP addresses within the netblock are checked (step <NUM>) by evaluating whether a certain number of (preferably two) IP addresses of the netblock are invalid (step <NUM>); if yes, the validity of a second number N<NUM> of random IP addresses of the netblock is checked by performing the validation part of the IP address searching step <NUM> (step <NUM>). When all IP addresses are invalid (<NUM>), the netblock is considered as invalid (step <NUM>). The number N<NUM> is set as to ensure that one can trust the validation of step <NUM> with a confidence of over <NUM> %. If not all of the second number N<NUM> of IP addresses are invalid, then the netblock is tagged as not determinable.

In the next steps, the netblocks within the same cluster are analyzed. Preferably, the valid, invalid and the not determinable tags or flags of the netblocks in the same cluster are checked (step <NUM>). Then, it is checked whether one or more netblocks are positive and whether one or more netblocks are negative (step <NUM>) - if this is the case, then the features that were used to cluster those two netblocks within the same cluster led to contradictory results, i.e. a valid and an invalid netblock.

Hence, those misleading features are removed and the netblocks are re-clustered (step <NUM>); if no, it is checked whether a defined threshold of netblocks in a cluster is valid and no netblocks are invalid (step <NUM>). If the result of step <NUM> is yes, the netblocks within a cluster are set to valid (step <NUM>); if no, it is checked whether two or more netblocks in the same cluster are valid (step <NUM>). If two or more netblocks in the same cluster are valid, the validity of random IP addresses of the netblock is checked by performing the validation part of the IP address searching step <NUM> (step <NUM>). If all IP addresses are valid (step <NUM>), the netblock is set to valid (step <NUM>).

In the following, the validation step <NUM> of validating the individual netblocks and/or the IP addresses within those netblocks, respectively, will be described in more detail.

<FIG> shows schematic flow chart of a netblock validation.

With respect to the algorithm in <FIG>, there exist two challenges to validate the netblocks. To address this issue, inventive statistical methods will be taught in the following.

Challenge <NUM>: Netblocks address spaces can be huge. , in the Internet Protocol version <NUM> (IPv4), Amazon has a netblock address space, which corresponds to a total of <NUM>,<NUM>,<NUM> IP addresses and thereby to a <NUM>,<NUM>,<NUM> potential hosts. A complete validation of these would be time-consuming, and this is just one netblock. This leads to the need of having an efficient validation method.

Challenge <NUM>: IP address validation is based on some ports/services, which are scanned but not all IP addresses in a netblock do have running ports/services. Besides, even if they have running services, these cannot be always validated. Thus, validateable IP addresses are only a subpart of the responsive IP addresses of a netblock. This makes it difficult to decide how many valid IP addresses are needed to tag a netblock space as valid. This leads to the need of having a method with predictive power.

Statistical methods are capable of providing solutions to solve both challenge <NUM> and challenge <NUM>.

The steps <NUM> - <NUM> of <FIG> are in principle identical to the steps <NUM> - <NUM> of <FIG>. However, the validation procedure is being "refined".

Step <NUM>: As an input to the method, an IP address space/netblock is provided, which starts with a first IP address ipstart and ends with a last IP address ipend (or alternatively the address space is given in Classless InterDomain Routing (CIDR) notation, which implies these two parameters). Thereby, the total number of IP addresses in the address space or the netblock is calculated as ntotal = ipend - ipstart.

For IPv4 netblocks or address spaces, there exist two possibilities to identify the IP addresses that have open ports and could hence potentially be validated, the open ports are used to get a feedback of a certain IP address. In IT-systems, which are in principle active, the status if a port is open or not can change dynamically. Typically, a computer comprises multiple thousands of those ports. The first possibility is performing a port scan on the whole netblock range. The second possibility is using passive data from providers that perform regular scans on the whole internet address range (e.g. Censys, Shodan, or Project Sonar Port Scans). The second possibility has the advantage over the first possibility in terms of time, as solely a lookup in the passive database must be performed. On the other hand, there is no warranty on the accuracy of the data.

Thereby, and as nowadays a scan of the complete IPv4 Internet address space can be performed for a single port in under <NUM> minutes, the method introduced here recommends performing port scans. If a single port is selected to be scanned, it makes sense to choose a port number that is associated to those ports that have the highest likelihood to be open and active. Hence, it would be beneficial to use port number <NUM> or <NUM>. The following list gives an overview about the most common paorts that make sense to use regarding the first possibility along with their assignment:.

For IPv6 netblocks or address spaces, the number of IP addresses is in general too large to perform a complete port scan. This is a well-known problem in recent literature on internet-wide scanning. For tackling it, several studies have proposed the use of target lists of IPv6 addresses, called IPv6 "hitlists". The IPv6 addresses belonging to the hitlist have the highest likelihood to be actively used. The goal is to create hitlists based on statistical considerations and active and passive sources. Hence, the IPv6 addresses represented a small subset of the IPv6 address space that can efficiently be scanned. These hitlists can be used to find the existing IP addresses in a given address space by port scanning only the addresses from the given address space that occur in the hitlist.

Hence, step <NUM> starts with a port scan on the ntotal address space or netblock, in particular when dealing with a IPv4 netblock, or by extracting passive data from providers, in particular when dealing with a IPv6 netblock. The port scan is designed to determine a number of responsive IP addresses of the netblock nresp.

Then with the known number of responsive IP addresses nresp in the address space, a calculation is started to determine an estimated number of validatable IP addresses as nvble = nresp * pvble, wherein pvble is the probability that a responsive IP address can be validated. This probability can be estimated based on previous experiments or can be arbitrarily set and then adjusted accordingly after each netblock validation. Hence, as a first guess pvble can be set to <NUM> or to <NUM>,<NUM>.

Not all of the responsive IP addresses can be validated, which is basically the meaning of pvble. The question remains which number IP addresses that can be validated is at least required to achieve a certain statistical significance that the whole netblock is valid.

Hence, step <NUM> determines the minimum required number of validated IP addresses nmin according to the following formula: <MAT> wherein n' equals the following: <MAT>.

If an address space is considered as being valid if it has a portion of more than <NUM> % of IP addresses that can be validated this leads to the following numbers of the parameters: P<NUM> = <NUM>; P<NUM>= <NUM>; zα= <NUM>; zβ = <NUM> for a confidence interval of <NUM> % and a statistical power of <NUM>. Of course, if the evaluation is performed and other assumptions and requirements, these numbers can be adapted accordingly by common statistical calculations.

Then a required number of IP addresses for the validation is calculated as nreq = nmin / pvble. The rational behind this is that if pvble is being smaller than one, the actual number required for the validation needs to be larger than nmin.

The decision <NUM> then checks if the found number of responsive IP addresses that can be validated nvbl is larger or equal than the minimum number required to be validated nreq, which is nvbl ≥ nreq. If true, then the found number of responsive IP addresses is sufficient that the following evaluation fulfills the demands for the statistical significance. In this case, step <NUM> randomly selects nreq IP addresses from the responsive IP addresses and continues with a step <NUM>, because already the subset nreq is sufficient for statistical significance. By using only this subset, the calculation is more efficient. If false, then the number of responsive IP addresses is too low in order to use only a subset of all the found responsive IP addresses nvbl. Hence, all found responsive IP addresses nvbl need to be used in the validation step <NUM>. To be clear, the decision <NUM> serves only the purpose to evaluate a possible reduction of the IP addresses that need to be validated in step <NUM>. The requirement remains that the address space or netblock is only considered to be valid if it has a portion of valid IP addresses of more than a first threshold value, wherein this first threshold value can be set to <NUM>%.

Decision <NUM> checks if the found portion of valid IP addresses "p" fulfilled one of the following equations, with the parameter n being the number of validated IP addresses:
If the equation <MAT> is true netblock or the address space is tagged valid.

On the other hand, if the equation <MAT> is true, then the netblock or the address space is tagged invalid.

In one of these cases the method proceeds with step <NUM> and marks the respective netblock or address space as valid or invalid and no further steps are required for the validation process.

If none of these equations is true, then the method continues with step <NUM>.

Step <NUM>: if not all found IP addresses have been validated, which was the case for nvble ≥ nreq, then step <NUM> is repeated in step <NUM> and decision <NUM> does the same as decision <NUM>. Hence, if one of these equations is true then step <NUM> marks the respective netblock or address space as valid or invalid and no further steps are required for the validation process.

If none of these equations is true, then the method continues with step <NUM>. Step <NUM> tries to find more IP addresses within the netblock to achieve statistical significance in the following steps. Hence, a low rate mass scan is started to find all IP addresses and validate them as in step <NUM>.

The additional found IP addresses yield different numbers for the "z" equation. Hence, the same evaluation as in decision <NUM> is performed in decision <NUM>. As before, if one of these equations is true then step <NUM> marks the respective netblock or address space as valid or invalid and no further steps are required for the validation process.

Claim 1:
A method of automated validation of netblocks of IT-services and/or IT-systems of a company, comprising the following steps performed by a computer system:
- as an inputting step (<NUM>): inputting a netblock, wherein the netblock comprises multiple IP addresses as an address range;
- as a validation step (<NUM>): validating IP Addresses of the netblock, wherein an IP Address of a netblock is considered valid if this Address belongs to the company, and calculate the number of valid IP Addresses to the number of invalid IP Addresses as a first result;
- as an evaluation step (<NUM>): evaluating based on the outcome of the first result if a netblock is valid or invalid;
- as a marking step (<NUM>, <NUM>, <NUM>, <NUM>): marking the netblock as valid, invalid or not determinable based on evaluation.