Bromium implements a security model as old as society itself, with two powerful new twists: CPU enforced least-privilege and relative trust. Recently I’ve been thinking about parallels between what we implement in technology and our own human nature. It turns out there are many similarities.
The Bromium architecture feels familiar because it is: In society we protect ourselves by relying on our own instincts and the collected learning of others. Relative trust is the loom that weaves together the threads of our relationships. As children we trust our families to care for us. Later we develop friendships, play on teams and become colleagues and parents. We trust those we depend on and collaborate with, and distrust others.
But trust is not binary. It is a sophisticated, personal and continually evaluated assessment of relative confidence: “Untrusted” does not mean “bad” – it just means “unknown”, and trust is highly context specific. When we entrust someone with important information, we lose control of it. Greater trust brings the benefits of a deeper relationship but leaves us more vulnerable. So we instinctively apply the principle of least privilege: We limit what we share based on context and what is needed. Relative trust helps us to manage least privilege to reduce risk.
Our desire for privacy is also framed by trust: We seek to retain control over information that could be used against us. We also know that our trustworthiness is continually evaluated by others, based at least in part on their observation of our respect for “the duty of trust” – confidentiality – which is so important that it is formalized in our legal system. As Einstein put it: “Whoever is careless with the truth in small matters cannot be trusted with important matters.”
Trust is life’s most important navigation aid. As we make our way through the world, our relationships and their trust dynamics inevitably change. But if we faithfully respect least privilege, we maximize our privacy and security as well as the security of those who trust us. It’s not perfect, but as the famous American novelist E.L. Doctorow put it: “It’s like driving a car at night. You never see further than your headlights, but you can make the whole trip that way.”
Least privilege and relative trust are instinctive foundations of human operational security. We dynamically evaluate trustworthiness to control our risk, and thereby maximize our security.
Bromium maps these concepts into technology to help each endpoint to defend itself, monitor its own health, and quickly share threat information with other endpoints in its “society” so that they too can better protect themselves.
Before I continue, it may be helpful to compare Bromium to today’s endpoint security tools: Black-listing the “known-bad” (like today’s AV) is the equivalent of a background check for a new employee – useful for weeding out convicted criminals. But it can’t help in your inescapable daily interactions with hundreds of people you don’t know and can’t check up on – the vast majority of whom will be benign. The list will always be out of date, but perhaps more importantly, a sophisticated criminal will disguise himself as someone you trust – perhaps a policeman – exposing you to a social engineering attack. What about white-listing the “known good”? (The term itself ought to ring alarm bells). Can you imagine a starker showcase of its failure than the current US problem of police overreach? There is no such thing as “known good” – only “known privileged – and vulnerable to attack”.
Hardware-enforced least-privilege: Bromium enforces least privilege isolation on a per-task basis using endpoint CPU virtualization to ensure that there is no way for malware to access information, credentials, devices, networks or sites that it shouldn’t. This gives us the most rigorous enforcement mechanism possible. Users can safely access untrusted networks, sites and edit untrusted files. If one of them turns out to be nasty, it’s a “don’t care” – there’s nothing to steal, no user identity, credentials, or files are available, and the attacker cannot pivot to attack high value networks or sites. More importantly, the endpoint is protected from breach by the CPU enforced isolation of a micro-VM.
This may appear to cast trust in a binary light. What about relative trust – the tax form that I download, save, repeatedly edit and then submit? Relative trust requires that I disclose only the specific required/relevant information in a particular context, but not that I trust the document just to edit it. Bromium allows you to repeatedly edit and save an untrusted document – each time in a new micro-VM – without ever having to trust it (elevating its privileges and enabling an attacker to steal information). Forcing the user to trust, just to be productive, is bad design. Micro-virtualization solves this problem elegantly.
What about the over-trusting (or even malicious) user, who tries to place high-value information in an untrusted context – for example attaching a corporate file to a gmail? Data Loss Prevention policies state what information a user can paste/attach/upload/enter into an untrusted context and are enforced by the Microvisor.
And what of evaluating trustworthiness? Recall that a fundamental requirement in any system based on least privilege is an ability to evaluate and react to any “breach of trust”. Once again micro-virtualization offers an elegant solution: Unlike our human experience, and unlike today’s computer systems in which a successful breach gives the attacker full access to privileged information, the hardware confines of a micro-VM are perhaps 100,000 times more difficult to compromise than software based isolation. So instead of trying to detect an attack before it occurs, we can simply let the user get on with her task, and if an attack occurs, it will be obviously malicious. Because the isolated environment executes copy-on-write, we have full forensics and can provide detailed information about the attack.