Behold, the fool saith, “Put not all thine eggs in the one basket” – which is but a matter of saying, “Scatter your money and your attention”; but the wise man saith, “Pull all your eggs in the one basket and – WATCH THAT BASKET. – Mark Twain
Mark Twain’s logic has been the staple food of data protection for many years. However, in the wake of the recent mega data breaches like the JP Morgan Chase,Sony Studios and Anthem, it’s apparent that the old common sense doesn’t work anymore.
Putting all the eggs in one basket: The pitfall of nowadays IT systems
Security is associated with control. The common sense of control is ‘Centralize & Secure’; Limit the number of sensitive/confidential/high-value data repositories, and watch them well.
But what does it mean ’watch them well‘? Mostly encrypt some of them, limit the access to them via policy, isolate them (as far as possible) from the network, etc. Looking at a typical IT system, we will find the following:
- Data is stored in central repositories. If distributed, it’s spread across very few locations.
- Security credentials (passwords, encryption keys, certificates, etc.) are stored in a single repository, either secure one (e.g. HSM) or most often insecure.
- Privileged users (administrators): A very small number of users have unrestricted access to the limited-access resources.
Results? Well, not so good, given the increasing number of massive security breaches and data thefts we’re witnessing almost on a daily basis.
The conundrum of the principle of least privilege
Most security controls are based on the principle of least privilege, however, unless enterprise’s entire IT is designed from the ground-up according to the principle of least privilege (and none is..), efforts to enforce security controls following this principle are bound to fail.
Truth be told, even if IT systems were designed according to the principle of least privilege, still, the implementation, policy setting and enforcement would be all but impossible. Today’s IT systems are just too big and too complex.
Attackers: Attack the weakest link
The security of the IT system is as strong as its weakest link. Most of the recent attacks had to do with stealing credentials of privileged users who enjoyed excess access rights. An individual or a small number of individuals, with excess access rights has beyond doubt proved to be one of the weakest links of IT systems. Couple this with unencrypted heavily-centralized data stores and you’ve got the recipe for disaster.
“Divided We Stand, United We Fall”…
Clearly, a new approach is needed, where data, credentials and access rights are NOT centralized nor controlled by any single individual at any given time. If data, credentials and access rights are distributed (rather than centralized) and properly audited, the risks for massive data breaches or undetected compromised users/credentials are greatly mitigated. The mitigation is not so much due to another layer of security control, but by the way the very nature the data and credentials are stored, deployed and managed.
Let’s take a closer look at some of the key principles of this approach:
- Separate & Distribute: The more distributed the data is, the less likely a data breach will affect the entire data. Today’s technologies allow distribution of data without tampering with productivity or performance. This principle relates both to the IT infrastructure, and to the policies and security controls.
- Isolate: This old principle, applied primarily in virtualized environment, has to present itself to the data/identity protection as well. Isolate data and identities from applications and policies.
- Peer-Power: This, perhaps, is the most elusive principle. Experience has it that monolithic, top-down, static security policies are hackable. It’s time to introduce a more dynamic framework — that of a peer-security/peer-audit. If peers are actively auditing critical activities, anomalies and breaches undetectable by security controls can be rather easily detected.
Implication on IT infrastructure:
- Data SHOULD NOT be centralized.
- Security credentials SHOULD NOT be stored in one repository. Credentials should be divided in a way which will necessitate usage of all repositories in order to be able to use them (e.g. attacker will have to break into all credentials repositories in order to use even one set of credentials).
Implication on Policies, Security Controls & the Human Factor:
- No single individual should have full access rights to the entire data.
- In case of required access to data repositories, immediate and automatic alert should be sent to the owner of the used administrative account — in more than one channel (e.g. mail and text message). The alert should be sent to at least one peer as well (e.g. mitigate the risk of identity/credentials theft).
- ‘Peer Audit should be implemented. In case of required access to data repositories, at least one more peer should be notified and approve (similar to the 2-keys/people activation of nuclear weapons, if you will..).
- In case of needed access to data repositories, beyond the above peer audit — immediate automatic policy should take effect, monitoring the requested access for all possible scenarios of data exfiltration (exfiltration directly from the data source, copying data to another location in the network which is not part of the data repository, etc.)
So where are we now?
Although still in small doses, we’ve already began seeing green-shoots following these core principles.
Distributed encryption: Where credentials and keys are randomly split over different servers (and never reconstructed even during usage), assuring they are never exposed to theft.
Virtualization & security: Detach detection from attack surface, such as Lynx‘ approach.
Multi Factor Authentication: Security credentials at the endpoint are divided and distributed across several domains (“what you know; what you have; what you are”). While this approach is definitely not new, it’s slowly becoming a mainstream these days.
Most importantly to note is that many of the required technologies already exist. It’s only a matter of decision, investment and execution. Security breaches and data thefts are not Force Majeure.
* First published at LinkedIn.