Zero Trust isn’t as new concept in the enterprise space. It was conceptualized in the mid-2000’s, tried by Google (which experience code theft at the time) in the “BeyondCorp” architecture, and subsequently codified by Forrester’s John Kindervag in 2010 (see: http://www.virtualstarmedia.com/downloads/Forrester_zero_trust_DNA.pdf).nIt basically describes a future architecture in which the older model of devices protected by a moat and castle (e.g. DMZs and firewalls) – ceases to work and an assumption must be made that intruders are assumed to be in – and that the future security architectures will have to limit the damage they can do, limit their ability to move inside the network (lateral movement), detect their presence and monitor to assess the damage they have done.
Lots of fancy language (and worthwhile reading) – but the 10,000 foot summary is that in a Zero Trust architecture, the network is structured in such a way as that each component (data, users, devices, servers, etc.) gets the minimum access and connectivity that they need – depending on the roles they play.nThe center of the layered approach is data. After all – while exploits are either technological (exploited vulnerabilities) or user related (exploited employee with access) – the data that is exposed is what causes the damage to the organization. We routinely hear of companies that lost millions of records and yet never hear of companies that got breached but had no (or limited) data exposure. And the fines are always a function of the amount of data suspected to have been compromised.
MSPs can and should learn from the Zero Trust mindset:
- Don’t assume there are your customers networks are not being compromised. Some of them probably are.
- If you are still using a moat and castle approach to security, consider switching to a minimal access strategy. So a hacker that compromises the secretary’s laptop can’t use the local credentials to download sensitive data from the server.
- Understand the data your customer has:na. Ask: what data that the customer collects can get them in trouble. Sometimes it is evident (e.g. ePHI for healthcare) – sometimes not so much.nb. When you know what is sensitive – ask (or audit) where that data is and how much of it is there. Map them to the devices: A single or a few dozen PII records here or there – may be meaningless – but 100’s or thousands – are no longer meaningless.nc. Based on the map of data – work with the customer to try to limit the spread of data (so as to reduce the attack surface for the data). Move data to safer devices (like servers) – or better yet – delete unnecessary data. If the customer must keep data – try to have as much of it encrypted as practical for safe harbor.
- Understand who must have access to data stores – and limit access to databases and folders to those with a need. For example, perhaps many employees will need access to a data processing system – but only a few will need to be able to export all the data and even fewer will need access to the server that stores the underlying system files. Even better, explain to them the value of separating their accounts: the daily accounts more likely to be compromised than administrative accounts used infrequently. A password manager may be helpful for this.
- EDRs and AVs are great and essential to protecting the network and its devices. But periodically reviewing logs, running vulnerability and best practice assessments, reviewing data usage and storage logs, are key to finding gaps and trying to find a stealthy breach.
- Last point: Annotate the strategy. If the worst happens, having logs of how data and the risks to it were audited, and how the network was secured to reduce the attack surface can go a long way to help your customer reduce the implications of a breach. Penalties can change by [i]multiple orders of magnitudes[/i] based on the customer being perceived as responsible vs. careless. As an example, HIPAA fines can be assessed from $50 to $50,000 per incident. Also – make some extra money using this data to help customers address their compliance reporting requirements!
While it is easier to built a moat and castle architecture (and give everyone administrative privileges) – practicing the rules above will (over time) allow the MSP to address the evolving compliance and cybersecurity landscape.
You may also be interested in: