How SecurityScorecard scans and attributes cloud IPs

In this article:

Read this article to understand how we scan cloud IPs and then attribute them to your Scorecard's Digital Footprint. 

To understand how and why this process works, it is helpful to first understand the attribution process and how we reconcile attribution with the fact that cloud IPs often change ownership several times in a day.

How attribution works

The attribution process is all about associating digital assets, applications, APIs, domains and IPs with Scorecards. The result is a Digital Footprint for each Scorecard. Various sources and detection methods, such as SSL scanning, DNS resolution scanning, passive DNS, ARIN updates, feed into the attribution system throughout each week on their own cadence.

Each day, we compute the latest of these data inputs, or observations and update the Digital Footprints for all scorecards accordingly.

Associating issue findings with assets

There is also a collections process that associates findings and issues with an IP address or domain, depending on the type of issue. Collection includes various signals from external data sources as well as measurements from our measurement scanning. Collections are separate from attribution and the creation of the Digital Footprint. One of the measurement inputs is to scan all IPv4 IP addresses for issues. The results of those measurement scans associate findings with IP addresses.

How issues are added to Scorecards

Every day, the resulting Digital Footprint for each Scorecard is compared to the issues data associated with each IP or domain. This is how issues end up on Scorecards. The Issues tab displays all the findings that matched with an IP or domain in the Digital Footprint for that same day. The Digital Footprint information appears in the Digital Footprint tab.

Time to live for attribution observations

Each type of attribution observation has a time to live (TTL), which keeps the observed domain or IP on the Scorecard for a specified time after the observation was last made. The purpose of the TTL is to avoid high-volatility changes for the Scorecards with the same digital assets continually being removed and added to the Digital Footprint.

For many attribution methods TTL is 12 days. This means that an IP associated with a Scorecard stayed on that Scorecard for 12 days after the last attribution observation. For example, a new observation event confirming the attribution three days into the 12-day TTL will reset the TTL for the attribution of that IP.

If a new attribution observation changes the Scorecard associated with a particular IP, the IP will be removed from the previous Scorecard and added to the new Scorecard. The TTL on the previous Scorecard will be automatically expired as part of the removal of the IP due to new attribution with a different Scorecard.

How we handle attribution for cloud IPs

Ideally, attribution for assets and systems provided by cloud vendors such as Amazon or Microsoft should take into account how these assets can change ownership, sometimes several times in a day. The key is to sync the timing of measurement scans and attribution.

Our dedicated cloud IP scanning process augments the lower-frequency attribution data sources and directly scans those known cloud service provider IPs daily, so SSC could better attribute cloud IPs to scorecards. This daily scanning improved accuracy and visibility for most scorecards that use a Cloud IP for longer than a day. However, it also created a potential issue for some organizations that use cloud IPs for very short periods of time. Increased scanning frequency delivered increased visibility but also dramatically increased the number of attribution observations, of which a portion were misattributed due to temporary usage.

The challenge with temporary cloud IPs

Due to the daily granularity of attribution for cloud service provider IPs and the separate timing of measurement scanning, it is possible for misattribution to occur. When an issue is found on a temporary cloud IP used for a short period of time, it is attributed to whichever organization was last observed; so it is attributed with that IP address for the same date.

You may use a given cloud IP for an hour or two and then discard it. Having an issue on your Scorecard for that discarded IP on the day that you used it amounts to a false positive due to misattribution. If that issue causes a significant score drop, you have the added task of resolving an issue that no longer applies to your Scorecard.

For example, an attribution scan, accurately attributes cloud IP address 109.107.38.54 to Organization 1, which at the time may be running a short term autoscalingoverflow Linux web server process. Then, at a different time on the same day, the collections process identifies a Windows 10 vulnerability issue on that IP. At that point in the day, the IP address belongs to Organization 2. Without a syncing of the scanning and attribution processes, the Windows 10 issue could appear on Organization 1's Scorecard and cause a drop in their score. 

How our cloud scanning and attribution solves the challenge

To addresses this potential misattribution problem, we have tuned our dedicated cloud IP scanning process, giving it a several key characteristics:

Higher-frequency scanning

We scan the cloud IP range multiple times each day to confirm that the attribution of the cloud IP is being utilized for the majority of the day by the same Scorecard. We specifically seek infrastructure IPs and omit the short-duration usage.

Majority-day attribution threshold

We only attribute an IP when the same organization has multiple attribution observations for most of a 24-hour window. If the threshold is not met for an IP, no Scorecard gets the IP attribution.

Low TTL for cloud IP attribution

Cloud IP attribution observations only remain on the Scorecard for two days after the most recent attribution event. 

Note: We currently only use SSL for cloud IP attribution. We are not using DNS attribution, so we are under-reporting some cloud IPs that do not expose an SSL certificate that matches a domain. We will be adding DNS scans for cloud attribution in the near future.

Cloud IP Scenario examples

In the first diagram, multiple organizations utilize the same IP address. The cloud IP attribution scan identifies Organization 2 as the owner and attributes the IP to the Digital Footprint for Organization 2. At a later time in the day, an issue is associated with that IP address which was actually in use by Organization 3 at the time. The IP and its associated issue were taken down and Organization 4 picked up the IP address later. The resulting issue shows up on the Scorecard for Organization 1.

The second diagram illustrates the new higher frequency scanning and threshold resulting in no attribution of the cloud IP. Since multiple organizations were observed using the same IP and no single organization met the 20 hour threshold, the cloud IP is not attributed to any scorecard. The issue that was identified is irrelevant because the service it was found on was taken down and removed long before it would show up on any scorecard.

The third diagram is an example where the same organization is observed using the same IP address for the majority of the day (at least 20 hours). The IP is correctly attributed to company 1 and so is the associated issue found on that IP address during the same day.

FAQ

Which cloud providers are being scanned and included in the cloud IP range?

SSC covers over 70 million IPs in the cloud IP scanning range. Some cloud providers do not publish or provide their dedicated cloud ranges, making it difficult to add them to the list. We are always interested in augmenting the cloud IP range, including smaller clouds and those who do not publish, if they are willing to partner with us. Currently we scan all major cloud providers. For more details, contact your Customer Success manager or submit a support request ticket.

How does a cloud IP get removed from a Scorecard?

A cloud IP will naturally drop off or get removed from a scorecard when the TTL expires. For a two-day TTL, if the IP is scanned multiple times and meets the threshold, and is attributed on the first day of the month, it will be on the scorecard Digital Footprint for the first day and the second day. If, on the second day, the threshold is not met and the observation is not refreshed, the cloud IP will drop and no longer be part of the digital footprint for the third.

You can initiate a manual request to remove the Cloud IP from your digital footprint. The IP will drop off the digital footprint the next day after the daily attribution processing.

When an IP or domain is removed from the Digital Footprint, when does the associated issue drop off the Scorecard?

Findings associated with an IP address or domain will be removed from the Scorecard on the same date that the IP or domain is effectively removed from the Digital Footprint. The issues and Digital Footprint are synchronized for the same processing date. We refer to this date as the scoring date.

The scoring date shown in the platform may be a couple of days Digital Footprint change. For example, a Digital Footprint change on the 15th of the month, resulting in findings being removed from a Scorecard, may not be reflected in the platform until the 18th day of the month.