Opt-in Security

So many of computer security implementations today depend on what I call "opt-in" security. It could be called "trusted clients". Most IT implementations consist of a large scale of distributed computers which are getting more and more mobile all of the time. Controlling those distributed systems is a very tough challenge because IT's arms can only reach so far and those corporate employees (let alone consumers) are soooo far away. So enters the idea of centralized control...

The notion is simple: administrators need a central place-- a choke hold, perhaps-- to grasp (in futility, as it happens). Practically every enterprise management tool these days tries to do the same thing: make a computer that I cannot physically touch or see do something I want it to do.

The problem with centralized control of distributed systems today is that it is an illusion at best. When new applications are loaded onto systems, administrators aren't actually touching the systems. Instead, they are sending out code and data to be assimilated into each system. Likewise when "endpoint security" (marketing term du jour) systems are validating that a client computer is compliant with a policy set, it is attempting to reconfigure local settings. But under the microscope, all that really happens is that a computer program processes input, checks some properties' states, and (optionally) sends output back to a "central" server. That is, in a nutshell, all that centralized control is today.

Breaking down the steps ...

Step 1:
Maybe the remote computer's state was trustworthy at one time, back when it was first created, but before it was ever handed to a user. However, its current state is not known. After all, if we knew it was still in a known good state, why would we bother to run our policy status checking program on it?


Step 2:
The policy program runs, takes its actions (if any) and generates its output regarding a newly calculated system trustworthiness "state" of the system. Yet, if we cannot fully trust the host OS, then we cannot fully trust anything it outputs. What if our policy program asks the OS for the status of a resource (e.g. a configuration file/setting)? If the OS is untrustworthy (or if a malicious program has already subverted it), then the output is also not trustworthy; the actual value could be replaced with the value the policy program is expecting to see, so it shuts up and goes away.


Step 3:
After the pseudo-policy-science is complete, the output is sent back to the central server, which (depending upon the application) could do anything from logging and reporting the status to granting access to attempting to further remedy the remote computer.


Now for some examples ...

Mark Russinovich of SysInternals (now Microsoft) fame created a tool called "gpdisable" to demonstrate how Active Directory Group Policy is really just an opt-in tool. As it turns out, his tool could even appease Step 2 above without requiring administrator rights. You cannot download gpdisable from Microsoft today (I think they removed it when SysInternals was purchased), but thanks to the WayBack machine you can download gpdisable here.

PGP Whole Disk Encryption is entirely an implementation of opt-in security. The installer code executes, claiming that the drive in its entirety is encrypted, claiming that the keys it uploads to the central server (like Step #3 above) are the real keys it uses, and of course claiming that the bootguard bypass is reset after the very next boot.

Anti-Virus works the same way. It's not too hard for malware to disable AV. Yet, if the policy polling process (alliteration) sees the process running ("brain dead" or not), it's not necessarily trustworthy.

Network Access/Admission Control/Protection (NAC or NAP depending on your vendor preference) is the worst case of opt-in security. NAC Implementations have been beaten straight up, in the vein of "these aren't the droids you're looking for" and NAC implementations have been hijacked by students.



Ok, so where do we go from here? There are really only two options: 1) bolster trustworthiness in distributed computing, or 2) ditch distributed computing in favor of something simpler, like thin clients and centralized computing.

Option 2 is beyond what can be crammed into this post, but don't think that means vendors are ignoring the possibilities of thin clients. Dell clearly is. Now they just have to figure out how to add mobility into the equation.

Probably the single greatest contributor to the possibility of achieving option 1 is the ubiquitous adoption of TPMs. TPMs could enable Remote Attestation, but they won't be able to do it without also coupling trust at the foundational levels like memory allocation. Regardless, increasing the trustworthiness of distributed computers from "opt-in" to high assurance will require a Trusted Path from the centralized server all the way to the remote computers' hardware, which does not exist today.