Among security professionals and industry leaders, it’s a widespread truism that an organization’s data, assets, and workloads have to be ring-fenced. Making sure that teams only have access to data they immediately need is one of the best ways to ensure a business is safe from accidents, internal sabotage, or ransomware.
Limiting access is critical, as it reduces the range of data and processes available to any one user - the “attack surface.” This means that a single breach has minimal risk of undermining the rest of a business’s data, whether it be through a ransomware package sent in an email or a compromised software supply chain.
Taken to its logical conclusion, this trend has given birth to the “zero-trust” paradigm of organizational security. But what does zero-trust mean? And, looking beyond the technical requirements of zero-trust architecture, what does it mean for your organization's backup and archiving processes?
Designing a zero-trust environment
Zero-trust sees security teams automatically segment their organization’s networks to prevent breaches. To do this, a zero-trust architecture builds a security environment predicated on hyper-granular access privileges that are automatically assigned and reassigned in real time to users.
This degree of automation means that zero-trust delivers enhanced security, while freeing up security teams from having to manually assign or reassign access privileges across an organization’s network. It also reduces the friction and frustration of security procedures for employees, as permission changes can be guaranteed in a matter of minutes.
That’s the technical checklist for zero-trust, but there’s also a major prerequisite all teams should consider before they can even consider moving to automate access privileges. That prerequisite is the question of who should have access to what information in the first place, and why.
It’s a basic question, but it belies a major need that security teams must address before going all-in on automation. An organization needs to take serious time to audit and segment their organization’s various stakeholders, and to review and break down all the categories of data and processes that should be recognized by a zero-trust architecture.
In doing such a review, an extra category of data will also need to be considered: your backups and archived data.
Subjecting backups to zero-trust
Security teams often have to give more generous access to in-progress workflows than they do to backups and archives. This is because live data often requires immediate and uninterrupted access to allow business operations to go ahead, whereas access to backup and archive data is far less time-sensitive.
However, it’s not only more viable to be stricter with backup and archive data - I take the view that organizations should always try to maximally limit access to such data. This isn’t just because of the sensitivity of many backup and archival records - think financial information, client details, or past projects - but also because preserving this data is essential for business continuity.
Ultimately, all systems are fallible. There will always be a non-zero risk that your zero-trust architecture will succumb to security risks, or you’ll suffer some accident or incident that will destroy your live environment and data. In that case, you’ll need to use backup and archival data to minimize operational downtime and get your team back to doing productive work.
Treating storage as zero-trust’s final contingency
Because of this, the solution you choose for backup and archival storage should not be an afterthought but treated as a pivotal part of your contingency planning. If everything else in your security and operational ecosystem fails, you need confidence that your backup solution is air-gapped and insulated so you can use it to bring your teams back from the brink.
In practice, what does that mean? Alongside subjecting your backups to the most rigorous and exclusive level of restrictions possible in your zero-trust architecture, you should also ensure that you keep multiple backups, with some of those not even be accessible by any of your operational teams. In practice, you should put this in place via the “3-2-1” rule: keeping at least three backups across at least two different mediums, with at least one kept off-site.
However, even this approach can be vulnerable to sabotage, disruption, or accidents. That’s why you should also ensure that your backup solution is immutable: that is, nobody is able to alter or delete it within an assigned timeframe. Immutability prevents anyone from being able to delete or encrypt data, thereby allowing immutable backups to serve as a final contingency to restore your data if all else fails.
In short: zero-trust architecture is an excellent way to maximize the security of existing workloads, and to ensure backups are also kept confidential and safe. But for the ultimate purpose of business continuity, a zero-trust architecture needs data storage that’s air-gapped from a business's day-to-day activities and immutable. Only with this final defensive line can you guarantee operational continuity and security, zero-trust or not.