Question
On a scorecard, I can see findings attached to an IP that is attributed to me, but after checking the attribution reason on the Digital Footprint (in this scenario DNS attribution), the attribution is not valid anymore, the DNS entry stated as evidence does not resolve to this IP anymore, it resolves to another IP. The IP is dynamically assigned and was rotated yesterday. The findings present for that IP are negatively impacting the Scorecard score.
Answer
Because our overall Scoring process takes several days to complete, if an IP address only has a short TTL of 1 day (ex: IP dynamically assigned, IP rotated...) we may attribute the IP and show its findings for more than 1 day on the scorecard. These findings will drop automatically when the TTL of the attribution is reached. Until then, we understand that the findings and attribution of the IP can cause confusion. Our Product and Engineering teams are aware of this current limitation, please contact your Account Team to voice your feedback.
Current date *** | Data being gathered | Data being processed | Data visible on Platform |
Day 1 | Data from Day 1 | ||
Day 2 | Data from Day 2 | Data from Day 1 | |
Day 3 | Data from Day 3 | Data from Day 2 | Data from Day 1 |
Day 4 | Data from Day 4 | Data from Day 3 | Data from Day 2 |
... | ... | ... | ... |
*** Simplified timeline for illustrative purposes, due to many factors, It is possible that the processing of the data may last more than 1 day. The data visible on the Platform does not update on any specific time during the day.
Note: While the IP and its findings are going to drop automatically as observation TTL expires, the new observed IP is likely to also exhibit the same findings which will be arriving when the new IP is attributed. This behaviour can lead to frequent arriving and departure of findings, and score swings.
Example
On Thu Jun 12 2025 11:35:10 GMT+0100, I check the tls_weak_protocol finding for 3.165.113.101.
- The finding
- The attribution evidence is dated from Mon Jun 09 2025 06:27:20 GMT+0100 . The IP 3.165.113.101 is attributed because the DNS api.rubberducky.com was resolving to it.
- The verification by nslookup as of Thu Jun 12 2025 11:35:10 GMT+0100. The DNS api.rubberducky.com now resolves to 3.165.113.66. I know the IPs were rotated on Wed Jan 11 2025, yesterday.
Details of the example above:
There are several elements in the scenario faced, all related to the date of the data and how long we consider the attribution data valid:
- When the data is gathered.
Using the example above, while the current date is Thu Jun 12 2025, the latest data used is from Mon Jun 09 2025. Indeed the attribution of 3.165.113.101 is based on a DNS evidence dated of Mon Jun 09 2025 06:27:20 GMT+0100. - When the data is processed.
Using the example above, while the current date is Thu Jun 12 2025, the processing date is Tue Jun 10 2025. This is also called the scoring date, Tue Jun 10 2025. - When the data is presented on the platform.
Using the example above and point 1 and 2, the data gathered on Mon Jun 09 and processed on Tue Jun 10, is presented on the platform on Thu Jun 12 2025. - The time to live (TTL) of the attribution evidence.
SecurityScorecard attribution processes checks the DNS evidence for DNS attributed assets on a daily basis. This DNS attribution observation has a time to live (TTL) of 1 day, which keeps the observed IP on the Scorecard for 1 day after the observation was last made.
Using the example above and previous points, the observation was done on Mon Jun 09 2025, the IP 3.165.113.101 was rotated on the Wed Jun 11 2025 which translates into:
Data gathered on Wed Jun 11 2025 => no IP attribution to 3.165.113.101
Data processed on Friday Jun 13 2025 => TTL has been reached, 3.165.113.101 and its associated findings are not included in the scoring data.
Data is presented on the platform on Sun 15 Jun 2025 => 3.165.113.101 and its associated findings is dropped.
Current date *** | Data being gathered | Data being processed | Data visible on Platform |
Mon Jun 09 2025 | Data from Mon Jun 09 2025 | ||
Tue Jun 10 2025 | Data from Tue Jun 10 2025 | Data from Mon Jun 09 2025 | |
Wed Jun 11 2025 | Data from Wed Jun 11 2025 | Data from Tue Jun 10 2025 | Data from Mon Jun 09 2025 |
Thu Jun 12 2025 | Data from Thu Jun 12 2025 | Data from Wed Jun 11 2025 | Data from Tue Jun 10 2025 |
Fri Jun 13 2025 | Data from Fri Jun 13 2025 | Data from Thu Jun 12 2025 | Data from Wed Jun 11 2025 |
Sat Jun 14 2025 | Data from Sat Jun 14 2025 | Data from Fri Jun 13 2025 | Data from Thu Jun 12 2025 |
Sun Jun 15 2025 | Data from Sun Jun 15 2025 | Data from Sat Jun 14 2025 | Data from Fri Jun 13 2025 |
... | ... | ... | ... |
*** Simplified timeline for illustrative purposes, due to many factors, It is possible that the processing of the data may last more than 1 day. The data visible on the Platform does not update on any specific time during the day.
Note applied to this example: While 3.165.113.101 and its tls_weak_protocol finding are going to drop automatically as observation TTL expires, the new observed IP 3.165.113.66 also exhibit the tls_weak_protocol finding which will be arriving when 3.165.113.66 is attributed. This behaviour can lead to frequent arriving and departure of findings, and score swings.
Comments
0 comments
Article is closed for comments.