The Desktop Software and Mobile Software risk vectors are considered as endpoint data. These risk vectors are similar to Server Software, but are for end-user systems that are using outdated (unsupported) operating systems or versions of web browsers. Newer versions of operating systems and web browsers typically address stability issues, bugs, and exploits.
Download the endpoint OS-browser versions (25-SEP-2024) list.
Use Cases for Endpoint Data
- Identify devices that are at-risk in order to apply system updates, apply software updates, and reduce an organization's attack surface.
- Understand how devices at an insured are a risk for known vulnerabilities and other threats.
- Verify questionnaire data from vendors.
Example: Verify claims that their organization is free of a particular operating system.
- Verify other contractual agreements with clients or vendors.
Example: Verify that they've adhered to a policy of keeping end-user operating systems up-to-date.
Resources
- Data Collection Methods
- Software Support Life Cycle & End-of-Life Policy
- User Count Thresholds for Grading Endpoint Risk Vectors
| Desktop Software | Mobile Software |
|---|---|
Frequently Asked Questions
How come I’m not observing any data for these risk vectors?
The worldwide Internet Privacy legislation has a limit on the geographical scope of data that can be gathered. We are continuously expanding the geographical scope of endpoint data in order to include information on operating systems and browsers that are available for a larger set of countries.
How does my outdated guest network software affect these risk vectors?
Since data is externally collected, we are unable to determine if a network is being used for guest networks. Guest networks are not differentiated from business networks and still pose a risk to an organization, even if they’re completely segregated from the business networks.
Does endpoint data include Bring Your Own Device (BYOD)?
Connecting a personal device to a corporate network infrastructure is a risk and adds another potential surface of attack for a threat actor to gain access to company data and sensitive information.
Given the Meltdown and Spectre vulnerabilities, we are continuing to see an increasing interest in endpoint data, as they help to identify companies who have not yet implemented patches or updates to protect against the vulnerabilities.
- September 26, 2024: Updated attached sheet containing OS-browser versions.
- August 22, 2024: Updated attached sheet containing OS-browser versions.
- July 30, 2024: Updated attached sheet containing OS-browser versions.
Feedback
15 comments
Very relevant feature esp. in context of present day risk environment.
How do you determine the risk?
It looks like this would include BYOD as well, is that correct?
Appears to be a great addition. Looking forward for actual data and its usefulness.
How do you capture this information?
Hi Chuck,
Great question. We have a data provider that has a vast network of sensors deployed throughout the internet that captures user-agent string data. These user-agent strings include both browser and operating system version as well as an IP address, which are then associated back to companies.
These risk vectors do include BYOD and we believe they should. Connecting a personal device to corporate network infrastructure is a risk and adds another potential surface of attack for a threat actor to gain access to company data and sensitive information.
Given the recent Meltdown and Spectre vulnerabilities, we are continuing to see an increasing interest in these risk vectors as they help to identify companies who have not yet implemented patches or updates to protect against the vulnerabilities.
Please do let us know if you have any other questions!
Not a fan of this factor. We accommodate a guest network that uses an outbound IP address that is within our BitSight-detected block. We don't control our guests' choice of hardware and OS, and we aren't about to assign a wholly separate (not attributed to us) IP block to them so that their endpoints don't get included in our rating. We have controls on that network severely restrict what can happen on these networks; no connections to our nonpublic internal systems, no peer-to-peer, restricted outbound protocols, etc.
I have similar feelings toward the "desktop browser" and "desktop OS" ratings, although the volume of managed (internal) endpoints helps us keep the impact of guests minimal.
Perhaps BitSight should consider allowing those of us who subscribe to the service to designate "guest" IP ranges that are treated separately?
I completely agree with @Steve Kurutz, this factor for Mobile and Desktop software doesn't take into account the way we segregate and secure our guest networks. There has to be a way to fix this factor to take these mitigating controls under consideration.
I can't force guests to use current software or hardware, but I can keep them from accessing my internal devices.
Also, being unable to identify which device is being scanned is wholly unhelpful-- anything on the guest network may never come back again, whereas with anything that is company owned, how are we supposed to find it? We use a standard image, which means that any given time we have dozens to hundreds of very similar machines that access the network via the same visible ip addresses. Yes, they should all be up to date, but sometimes a scheduled browser upgrade push comes (far) behind an emergency zero day patching effort.
what is the decay off period for this issue type ?
Will an MDM resolve this? Additionally, plus one on separate guest network part, visitors actually connect via this and these will definitely contribute to a ratings downgrade.
Information related to Compromised (Botnet, Torrent, etc) findings is misleading with regards to companies that provide GuestNet access. Guest Networks are in effect, public and segregated from the main corporate network. Public, in that anyone can connect; there are no security control requirements around GuestNet access; and Segregated, In that, these networks are complete isolated from the main corporate business network. The inability to suppress GuestNet access creates misleading and inaccurate results. The negative affect is a loss of credibility of your entire platform altogether. Happy to help improve this perception.
Hi Ainsley,
Thanks for the feedback, we do not want rating to be misleading. We've presently included guest wireless networks in the rating for a number of philosophical reasons. 1) We cannot externally validate the efficacy of the segmentation/segregation between guest networks and corporate networks. 2) Employees often join guest wifi networks specifically to circumvent security controls in place on corporate wifi and before rejoining the corporate wifi. To the extent that happens, the employee machines and data may be exposed to a security issues in the guest wifi. We are looking at ways we can enhance our communication of guest wifi information in the platform, please reach out to me, brian.mulligan@bitsighttech.com if you'd like to discuss further.
Hi Brian,
We have the same concern with the usage of the guest network. How do you propose that companies offer a guest network and not get a bad rating in this category? In order for us to efficiently do business with third party visitors, we need to offer this service. It appears that those who have commented are nearly all in agreement.
Thank you,
Elaine T.
Hi Elaine,
Many organizations create a self published company that excludes the infrastructure for their guest networks and designate it as their Primary Rating. We introduced the Primary Rating capability since the comment above (and in response to feedback like this) and it has become a popular way to improve communication around these kinds of issues.
Please sign in to leave a comment.