This article addresses some of the most frequently asked questions associated with lifetime period logic and how offline assets are handled. Some risk vectors also operate differently than others, which is something that will also be covered.
For more specific details on the lifetimes of each risk vector, please refer to the risk vector assessment articles in the Ratings Methodology section.
- Why do remediated findings still have a lifetime period?
- What is the difference between a lifetime with full impact and a lifetime with linear decay?
- The IP/domain of the finding is now offline. Is Bitsight able to scan it?
- What is the difference between the lifetime of TLS/SSL Configurations and TLS/SSL Certificates?
- Which risk vectors don’t support manual scans?
- How is the Patching Cadence Risk Vector Assessed?
- Why do TCP and UDP ports have different lifetime periods?
- I remediated a finding, but it still has the same grade. What should I do?
- What is the criteria for a finding to be created separately in Compromised Systems?
Why do remediated findings still have a lifetime period?
We attempt to provide a complete picture of the cybersecurity risk posture of a company over time. Without a lifetime, ratings would change drastically on a daily basis.
Lifetimes ensure that findings—both positive and negative—continue to impact your rating. Companies that monitor you are able to assess whether your security posture is proactive or reactive based on the presence of recurring findings.
For more details, see Why do findings have a decay and lifetime period?
What is the difference between a lifetime with full impact and a lifetime with linear decay?
Although risk vectors like Patching Cadence and Compromised Systems have long lifetimes (180 and 300 days, respectively), the impact of the findings is not the same over that period of decay.
Linear decay refers to this reduction in the overall weight of a finding over time. After the “Last Seen” date, the finding’s weight slowly reduces on a daily basis until it reaches 0 on the last day of its lifetime. This means that there wouldn’t be a single major point recovery on the last day, but instead a gradual improvement over time.
Conversely, in other risk vectors findings fully impact your rating until they are dropped at the end of the lifetime. These lifetimes with full impact do not decay and will result in a single recovery once they drop.
The IP/domain of the finding is now offline. Is Bitsight able to scan it?
Regardless of the risk vector, if an asset is offline, Bitsight is not able to scan it successfully and create a replacement for the old observation. In those circumstances, the finding will always have to undergo its lifetime period.
What is the difference between the lifetime of TLS/SSL Configurations and TLS/SSL Certificates?
The TLS/SSL Configurations risk vector analyzes the existing configurations of a domain or IP on a specific port. Unique domain:port or IP:port combinations can only impact the rating once. If the scan sees something different, a new finding is created and immediately replaces the original. The same is true for domains; if a domain is observed resolving to a different IP, that generates a separate finding, regardless of the number of issues that remain the same.
For the TLS/SSL Certificates risk vector, the scan is instead looking at certificates that differ based on their serial number, which is displayed in the finding details under the Certificate 1 field. Remediation implies that the old certificate was revoked and a new one was issued. In this case, the old certificate ceases to exist and we're no longer able to scan it. We see the new certificate if one was issued, but it will have a different serial number and a separate finding. The old finding will remain in the list of impacting findings similar to any other offline asset and will undergo its lifetime separately.
Which risk vectors don’t support manual scans?
The following risk vectors don’t currently support manual scans, either due to the method of collection or being a current implementation:
- In the Compromised Systems and Insecure Systems risk vectors, Bitsight is actively listening to communications to our sinkholing infrastructure, among others, on a daily basis, as opposed to reaching out to the host.
- The Desktop Software and Mobile Software Risk Vectors are based on cookie data that is collected weekly. Findings are dependent on the interaction of machines from the company’s infrastructure with the global network of ads on websites managed by our data partners. More details on this process can be found in How are the Desktop Software and Mobile Software Risk Vectors Observed?
- The Patching Cadence risk vector doesn’t currently support manual scans. Many of the unremediated findings are checked weekly or, at a maximum, every 30 days. The 300-day lifetime will always start from the Last Seen date of the vulnerability, regardless of when the finding is marked as remediated.
- File Sharing findings are based on torrent activity originating from the company’s infrastructure. This data is published daily as it occurs.
Why do TCP and UDP ports have different lifetime periods?
TCP and UDP port findings are verified in different ways. We use a three-way handshake to connect to TCP ports and determine whether they are closed. This method is used in a TCP/IP network to create a connection between a local host/client and server. It is designed to allow both communicating ends to initiate and negotiate the parameters of the network TCP socket connection at the same time before any data is transmitted.
When we confirm that a TCP port is closed, a timestamped notification is added to its finding details. The finding stops impacting your rating within 10 days, although most of them are dropped in 2-3.
UDP ports only communicate in one direction, so the handshake is not an option. This means the port may just not be responding at that point in time. To verify that these ports are really closed, these findings need to undergo a 60-day lifetime period. If we don’t see any further data originating from the port within that timeframe, the finding stops impacting. More details on this topic can be found in Remediation Verification: Open Ports.
I remediated a finding but it still has the same grade. What should I do?
The “Last Seen” date of each finding indicates the last time we saw that particular combination of issues for that IP/domain. If you believe the remediation was performed before that date, that could mean it was not properly applied. Unless something different is seen, new scan requests will simply update the same finding’s “Last Seen” date.
Double-check the finding details and remediation instructions to understand what the issue is and how to correct it. You can reach out to Bitsight Support with any further questions.
What is the criteria for a finding to be created separately in Compromised Systems?
A finding in Compromised Systems is distinct based on the uniqueness of the IP address, the type of infection, and the days on which it was seen. There's a 3-day tolerance for each finding that ensures that if an infection on a single IP is only seen again after 3 days, it results in the creation of a separate finding. If it’s seen within the 3-day period, the original finding’s “Last Seen” date is updated.