Asset Inventory for Network Perimeter: from Declarations to Active Scanning

In the previous post, I shared some of my thoughts about the good Asset Inventory system. Of course, for me as a Security Specialist, it would be great if IT will provide such magical system. 🙂 But such an ideal situation is rarely possible. So now let’s see how to build an Asset Inventory system using the resources of Information Security team.

There are no special secrets. It’s necessary to get information about the assets from all available IT systems and then get the rest of the data using our own Assessment tools. I would like to start with hosts on Network Perimeter. The Network Perimeter targets are available at any time for hacker attacks, that’s why this part of the network is the most critical.

Asset Inventory for Network Perimeter

Network Perimeter is like the Wall in the Game of Thrones. The same white walkers are hiding behind the wall and our task is to find the breaches in the wall faster than potential intruders. “Night gathers, and now my watch begins”. (c)

Perimeter is changing constantly. And we should understand at any time what hosts are currently exposed in every office and every external hosting platform.

We can get information about external hosts using some Vulnerability Scanner located on external host in the Internet. I have already wrote about it briefly in  Vulnerability Management for Network Perimeter. Here I would like focus on how we can understand which hosts should be scanned and what useful information we can get from the raw scan results.

Declarations

The target for active scanning may contain IP addresses and FQDNs. So, where can we get them?

IP Addresses

In many organizations information about external IP addresses is only available on some Confluence (or another Wiki) pages. Or even in Excel spreadsheets or Word files.

Confluence external IPs

Example of the typical IP list:

1. hostname1 55.71.93.179
2. hostname2 55.71.93.180 – liquidated

And if we need to know which external IP addresses are in use, we need to create a parser of any type of these pages. See “Confluence REST API for reading and updating wiki pages” and “Processing .docx and .xlsx files with Python” for more.

Of course, it would be great to have these data stored in a more formalized way. But, on the other hand, in practice the IT team will not update the information about the assets if they find the process uncomfortable. I think it’s better to adapt to existing formats, than trying to force IT to use CMDB or something like that, if they don’t want to.

FQDNs

Also, targets can be presented by host names (FQDNs). It is natural to take them from the external DNS server.

DNS Server data

There can be, of course some, difficulties.

  • Most likely not all of your domains are parked at your external DNS server. Some may be parked somewhere elsewhere and you should track them as well.
  • The services with our domain can be in fact provided by third-party, for example some messaging service or payment gateway. We should not actively scan them in this case.

It is useful to compare IP addresses from DNS A-records with the lists of external IP addresses, I mentioned before. So, you can find some hostings that are not described anywhere.

Scan Task

Based on IP addresses and FQDNs, we can generate a task for scanning. We can send it to an external scanner and launch the scan. But just looking at the changes of IP addresses and FQDNs in scan task (even without scanning) can be quite interesting.

Here you can see the tables that I generate several times a day:

Target updates

You can see here which IP addresses and domain names were added or excluded from the scan tasks. I also try to indicate WHY is this happening. For example, a new ip-address was added on a specific Confluence page or a new domain was added to the DNS server. I also track that the domain names are referring to our IP addresses (AtoOurIP). Otherwise it’s an incident that should be investigated.

When the domains or IP addresses were excluded, I also try to display why we think that it is no longer necessary to scan them. For example, we could use some host in the cloud for a while, then stopped and the “liquidated” mark appeared for this IP address in the related table.

We can also see some new services that were published without our approval. This is a good reason to find out how could this happened.

The results of Active Scanning

By analyzing the raw scan results, you can see what new services have appeared on network perimeter since the last scan. You can see new open ports, services, vulnerabilities, and related scan tasks:

New ports, services and vulnerabilities

Here are  the services that were discovered for the first time during the latest scan (First scan and Last Scan numbers and dates are the same). Of course, in the overall table we will see how long the service was active, when it was detected for the first time and when it disappeared from the network perimeter.

There are also dynamic vulnerability reports. The diagram shows the number of exploitable and potential vulnerabilities, how some of them have been fixed and how new ones have appeared.

Vulnerability dynamics

The diagrams also show the types for exploited and potential vulnerabilities. Getting such a classification is not a simple task and we will talk about this next time. 😉

Finally, the list of tables I make from the raw Nessus scans (it can be done for scan results of any Vulnerability Scanner as well):

  • Dynamics (Vulnerability, Hosts, Services)
  • Web Servers
  • SSL Certificates
  • Websites (Domain Expiration, Classification)
  • Vulnerabilities (Exploitable, Potential)
  • Most Vulnerable Hosts (Exploitable, Potential)
  • Most Common Vulnerabilities (Exploitable, Potential)
  • Fixed Since The Last Scan
  • New Since The Last Scan

In conclusion

You can buy a really great solution for Active Vulnerability Scanning. But will it explain what you need to scan and what you can get from the scan results? Probably not. This part will always depend on the specific organization and require specific automation. So, develop your own scripts. 😉

External scans may not be very reliable, comparing with internal authenticated scans. Read more about it in “Non-reliable Nessus scan results“. On the other hand, this is a good way to emulate the attacker’s actions. So, it is very useful when we can go from external IP addresses to internal ones, scan hosts with authentication and compare internal and external scan results. But for this, again, we will need a good integration with the existing IT systems.

4 thoughts on “Asset Inventory for Network Perimeter: from Declarations to Active Scanning

  1. Ian Tibble

    Hi Alexander – how about this… just out of interest maybe. It doesn’t do everything you’re looking for of course. You can define groups of targets and set a schedule for testing – it sends you email alerts if there’s a change in host availability or services (false positive detection for both host availability and services – it checks the service history also before alerting).

    https://www.seven-stones.biz/blog/the-art-of-the-security-delta-netdelta/

    Basically testing for changes in perimeters with a very low chance of false positives.

    Regards, Ian

    Reply
    1. Alexander Leonov Post author

      Hi Ian! Thanks for the great comment. NetDelta seems like a very interesting project. I will give it a try.

      With best regards,
      Alexander

      Reply
  2. Pingback: Asset Inventory for Internal Network: problems with Active Scanning and advantages of Splunk | Alexander V. Leonov

  3. Pingback: CyberThursday: Asset Inventory, IT-transformation in Cisco, Pentest vs. ReadTeam | Alexander V. Leonov

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.