It should be noticed, that we recommend checking the outer perimeter of the network on every-day basis, to minimize the harm from 0-day (just discovered) vulnerabilities. The recommendation also applies to public web-sources of a customer.
The week from the scheduled starting date of scanning of a particular group of devices, we contact the person responsible for that group, inform him about the dates of the scanning and send the whole list of the devices we are going to scan. On this stage, the area of the scan can be adjusted if needed. It is done to minimize the risks of incorrect recognition of a device in a network.
After the scanning is done the person in charge is being informed again. This means that the parties of interest are ALWAYS aware of what is going on.
We use a few different scanners, including specific tools to detect vulnerabilities in Web-systems. By doing this, we get more data for analysis and can potentially detect more threats.
To optimize the expenses we can limit ourselves with representational sample of 30 to 50 %% of devices from a group of devices or 30 to 50 %% of devices from every office's location, instead of scanning the whole given group. In case of a critical vulnerability detection within a sample, we can start the search for particular vulnerabilities on the whole group of the devices. Thus, we get the widest coverage in the least amount of time.
It should be noticed, that there are several vulnerabilities that are not detected by regular tools. When we start the scanning process of the particular group of the devices, we check all publicly known vulnerabilities and make sure, that our scanners are able to find them. If we understand that the standard tools are not enough, we check for particular vulnerabilities manually or develop our own unique tools scanning for those vulnerabilities.
The most important, when an information about new dangerous threat appears in a public space, we are not waiting for a scheduled date of scan. All customers, that might be vulnerable to such threat will be promptly informed about a problem, and an unscheduled inspection would be held.
In general, detailed description of the technology we use to detect vulnerabilities slightly goes beyond the scope of the current article, but you can get yourselves familiar with it by the presentation, that we made at SOC-Forum in 2017.
Analysis of the results of the scanning
If you ever run a vulnerabilities scanner in a corporate network of 100+ hosts, you should probably remember that feeling, which arises from look at the kilometer-long list of same-type entries, the content of which is hardly understandable. Without a proper knowledge it is quite hard to make an adequate assessment of what to leave unchanged, what to fix and in which order.
We take this step on ourselves, as we look at the results, choose really crucial problems, which can do a real harm to a customer's business.
We estimate such parameters as:
- Availability of vulnerable devise/service for a potential offender;
- The presence of a public exploit;
- The complexity of execution of the exploit;
- The potential risks for a business;
- The chance of a false alarm;
- The difficulty of troubleshooting;
After the processing, vulnerabilities, that we "have checked and approved", are being published in an incident management system(which we will talk about separately), where the employees of the customer can look for them, ask the questions, take or decline the job in case of risk taking.
If necessary, we can appoint the consultation with a person responsible for vulnerable devices and tell in detail, what was found, what does it threaten and what are the ways to minimize risks.
After we pass the vulnerabilities into the elaboration, the customer takes the lead, and we continue the scanning with the next group of devices.
However, the process for the first group doesn't end here.
Vulnerabilities elimination management
In a system, a status and a removal deadline for any published vulnerability can be set. We track the change of the statuses, and the approach of the deadlines.
If a vulnerability was removed by a client, we can see that and run the inspection to make sure that the vulnerability is actually gone. As the inspection is running only for one specific vulnerability, it doesn't take a lot of time, and the result can be received in a day for hundreds of thousands of hosts or even within a few seconds for a small group of devices.
If the vulnerability is closed, we confirm that. If the vulnerability is still present on the part of or the whole group for devices, we return it for a revision.
The cycle of the vulnerability elaboration is closed only when we confirm that it is removed from all the vulnerable devices.
The complete scheme looks like this: