In this blog series, we will be examining the capabilities of the browser in the enterprise today. The browser has become the most used application in business, and understanding the full capabilities of this powerful app is increasingly vital to desktop, IT and security teams.
Why? Because some of the things your browser can do will be surprising to you.
The browsers that we will be discussing in this series are Google Chrome and Microsoft Edge. These robust, Chromium-based apps are among the most popular in the world and together represent a global enterprise market share of almost 80%. Better yet, these browsers are free, as one of the most fully vetted and reported apps in the world.
What you may not know is exactly how many policy-controlled capabilities these browsers have. The fact is that many of the functions that used to be embedded in the device OS are now enabled in the browser, and these capabilities may be active on the endpoint even when the user isn’t actively browsing.
Between Chrome and Edge there are literally thousands of such policies to consider, and many are enabled by default. Even more concerning, some policies must be specifically locked down to ensure that users cannot change them.
The first such policy that we will consider is DefaultWebBluetoothGuardSetting, which allows websites to communicate directly with Bluetooth devices. If you’ve ever had a Bluetooth-enabled device, such as a fitness tracker, updates have demanded that you download things like firmware updates to your computer, then send them to your Bluetooth device. With DefaultWebBluetoothGuardSetting, the website can communicate directly to your device. In a purely consumer use case, this functionality might seem quite useful. In the enterprise, however, it is something else entirely.
Why it matters
It is easy to forget how many devices are enabled by Bluetooth, as well as how much information that such devices contain. Even in the fitness tracker use case above, it is worthwhile to consider the data that such a device might contain, including details about the user’s height, weight, or heart/lung function, as well as home address, real time locations and more.
Now extrapolate those details to include Bluetooth-enabled devices that could be found in an enterprise, such as headsets, smart locks or conference speakers. Vertical industries have still more devices, including barcode scanners, PoS systems or beacons in retail or medical devices like blood pressure monitors or even patient trackers in healthcare.
Each such device contains data that may well be private or sensitive. At the very least details that could be gleaned from even the most benign seeming device could prove to be dangerous to attackers looking for that one weakness. Dangers of allowing such access, as described by the Security Technical Implementation Guide (STIG) used by the U.S. Department of Defense (DoD), include:
- Security Risks:
- Unauthorized access to Bluetooth devices could lead to data breaches, device manipulation of eavesdropping on communications between devices
- Privacy Protection:
- If websites are allowed access to Bluetooth devices, there is a very real danger of breaching privacy as well as enabling unauthorized data collection or tracking.
- Insider Threats:
- Another way that this policy could be misused is insider threats. Employees or other internal users could easily expose devices to external threats posed by malicious websites, either intentionally or inadvertently.
- Policy Compliance:
- Many regulations and guidelines, including STIG, Center for Internet Security (CIS) and others, are designed to minimize potential security risks.
What to do
This seems like an easy question to answer. Just disable the policy, right? Not so fast.
This policy is a good example of something where the fine print matters, because the answer is not a simple “yes” or “no.” This policy can be set to 2, to 3, or left unset with the following results:
- Setting 2 - Does not allow any site to request access to Bluetooth devices via the Web Bluetooth API.
- Setting 3 - Sites may ask the user to grant access to a nearby Bluetooth device.
- Unset - Sites also ask for access, though the end user can change the setting if they desire to do so and know how.
OK, you may think, that wasn’t so hard…and you’d be right. The problem is that there are still thousands of such policies left to consider. The descriptive language is not designed to be tricky, but the fact is that every policy must be looked at one-by-one.
Now think for a moment about exactly which member of your over stretched, oversubscribed team is going to do this.
There is a better way
Browser Posture Manager, from Menlo Security, makes this process simple. At Menlo we’ve spent the last ten years securing the best, most fully-featured browsers which have the added benefit of being the very browsers that 80% of enterprises around the world are already using!
With Browser Posture Manager, you can see how your current browser policies stack up against security industry benchmarks in just a few clicks. Just upload your browser settings as a .JSON file and select the benchmark you’d like to see. You’ll immediately be presented with a complete list of how your current policies stack up, along with a simple explanation of what each policy actually does. Not only will you see any circumstances where your policies have security issues in conflict with benchmarks.
In the case of the policy we’ve just been looking at, for instance, both CIS and STIG require that the policy be set to 2, or disabled.
But best of all, Menlo Brower Posture Manager does not dictate these choices for you. Our experience in securing the browser for some of the largest organizations in the world has confirmed our belief that every enterprise is different.
Find out more about how Browser Posture Manager from Menlo can make security simple here.