SecurityScorecard does a great job at detecting publicly visible assets (domains and IP addresses). We then relate these assets to various data feeds to come up with weighted measurements that are used to generate a security score. In today's world of dynamically assigned IP address spaces in Cloud infrastructure, how are we able to reflect ownership of an address space?
When we analyze the ownership of an asset displayed on an organization's digital footprint, and its related finding (sometimes called "measurement"), the critical pieces of information in our observation are the metadata and "observed_at" fields.
For example, if an issue was first observed on 2021-01-13 and was a result of a signal detection service that detected a certificate that was owned by an organization related to that IP at that point in time.
To understand why it was on your scorecard now, it is important to understand the duration SecurityScorecard scans and updates results for display. Our scoring methodology whitepaper provides quite a bit of detail regarding the scanning rates and issue decay periods. For example, in the case of malware, this information is updated daily, and will "age out" after 30 days. "Aging out" means that when we last observed there was no malware associated with the asset, it will drop from the scorecard after 30 days.
To expand, consider this scenario:
- Your company owns IP 100.100.100.100 on January 1, 2021.
- Malware is observed by SecurityScorecard related to 100.100.100.100 on January 8, 2021.
- Your company no longer owns IP as of January 10, 2021 (IP is cycled by provider).
- Malware report from January 8, 2021 ages out after 30 days.
In the above scenario, you may ask "If the IP is no longer assigned to me, then why the need for Step 4"? The answer has to do with the underlying philosophy that SecurityScorecard's product offers. Through our product, we are communicating cyber risk in a holistic manner, not at a single point in time. Using the above example, at some point, there was indeed a detection of a malware event related to a known company asset. As a result, the finding is displayed on your scorecard and decays as per the schedule outlined in our scoring methodology whitepaper.
With the preceding said, if you have evidence that the asset was not owned by your organization at the time of detection, you may submit the issue for resolution as explained in our Issue Resolution Process. Also, to prevent any further issues from being raised against this asset, ensure that your digital footprint is updated as described in the digital footprint mapping Help Center article.
Note: Content delivery network (CDN) IPs appear in the Digital Footprint, but they do not impact the score.
Resources
For details on how our scoring works, see our Scoring Methodology Whitepaper.