Security: Tradeoffs

By admin
Absolute security is simple– put your PC in a well-guarded vault, and never power it on. But that’s not what PCs are built for, and good luck finding a job that would pay you for such advice.

Security Engineering
ORG

(like all engineering) is a story of tradeoffs. Tradeoffs commonly take place across multiple dimensions:

Security

Compatibility

Performance

Ease-of-use

Privacy

Productivity

Cost

As I’ve written recently, the ease-of-use/security tradeoff in the HTML5 Full-screen API leads to a major risk of tech scams. On the other end, the ease-of-use/security tradeoff in the OnBeforeUnload

API
ORG

means that legitimate web applications are harder to use because the platform wants to limit the possibility of abuse.

Recently, an admin reached out to ask about the recommendations in the Microsoft Security Baselines for Edge. In particular, they were curious about why the baselines don’t mandate the disablement of the

WebSerial
PERSON

,

WebBluetooth
PERSON

, and WebUSB platform APIs, as each of these represents attack surface against devices from the browser, and the Filesystem Access API which could be used to abuse files on the user’s disk.

When an enterprise

Security Admin
ORG

considers whether to disable these APIs via

Group Policy
ORG

, it’s important to consider the full context to decide whether blocking browser APIs will reduce attack surface, or actually increase it.

In this case, these powerful APIs enable browsers to perform tasks that previously required downloading native applications. For example, instead of needing to download some random full-trust native code application to program my kid’s “smart” teddy bear with his name, favorite song, and favorite food:

… I can just go to a website that supports

WebUSB
GPE

, type in the desired information, manually grant the website permission to use

WebUSB
GPE

, and then update the info on the device. The overall attack surface is dramatically reduced by

WebUSB
GPE

, because my task no longer requires running

unsandboxed
GPE

/full-trust code from a teddy bear vendor, who may or may not have good secure development and deployment practices. At worst, I may have to reset my bear, but the browser sandbox means that my PC is not at risk.

Similarly,

a few years back
DATE

, I bought a cheap clock from Alibaba in

China
GPE

.

Setting the time on the clock requires configuration via

Bluetooth
ORG

. Instead of downloading some random full-trust program from an overseas vendor I’ve never heard of, I can use a trivial web app that uses Web Bluetooth to program the device.

Again, there’s no dangerous

third
ORDINAL

-party code running on my PC, and no access to any device is granted unless I specifically choose to allow it.

Ultimately, all features represent attack surface. The key question for security engineers (whether platform engineers or security admins) is whether or not a given feature reduces or improves overall security — its net security impact.

My position is that these APIs, on the whole, improve the security posture of an environment to the extent that they are able to displace higher-risk alternatives (native apps).

Threat Models Aren’t Universal

As we’ve discussed before, however, threat models aren’t

one
CARDINAL

-size-fits-all.

Security Admins must keep in mind that the security baselines are just that, baselines. If their environment is such that they’ve locked down their PCs such that users cannot run native apps of their choosing, then blocking advanced Web APIs probably will not harm their security posture, even if it might harm their users’ productivity.

Follow the Spirit of the Baseline

Admins should further take care to ensure that their use of the baselines maximizes their overall security posture. We recently encountered a customer who had disabled

Basic Authentication
ORG

over HTTP in

Edge
ORG

as a part of following the

Edge
ORG

security baseline:

However, this customer had

hundreds
CARDINAL

of legacy devices that require Basic authentication and are only accessible over HTTP. To enable them to keep working in the face of the baseline’s restriction, the customer configured

Edge
ORG

such that these devices’ IPs would load in Internet Explorer Mode. The customer treated this as a workaround for

the Security Baseline
ORG

. This only worked because they hadn’t also enabled the equivalent

WinINET
PERSON

policy that blocks Basic-over-HTTP in IE.

Thus, the customer could claim compliance with the

Edge
ORG

security baseline, but their workaround put the organization at far greater overall risk, because

IE Mode
ORG

represents a huge attack surface. Allowing that attack surface to be combined with

MiTM
GPE

-able HTTP networking means that any network-based attacker could easily exploit vulnerabilities in the legacy IE code, outside of the strong

Chromium
ORG

sandbox in which

Edge
ORG

loads content. The customer would be far more secure if they simply ignored the “No Basic over HTTP” requirement for their unique environment.

Stay safe out there!


-Eric
PERSON