Secure by Design

Protecting the control plane and protecting the repositories that hold backup data - the two pillars this guide is scoped to, as established in System Resilience - starts with how you design around them. The same core Zero Trust principles apply to both: never assume a component is trustworthy by default, verify explicitly, and design for the assumption that any single layer can fail or be compromised.

A system that was not designed with security in mind cannot be made truly secure by adding controls on top of it afterwards. Retrofitted security is always a compromise - you are compensating for structural decisions that were made without considering the threat model, and some of those decisions may be impossible to undo without rebuilding the system entirely. If you are in this position, start retrofitting today - but design the next iteration correctly from the start.

When designing a secure Veeam architecture, the following principles can help in guiding an architect towards a secure design.

Simplicity

Overly complex designs become harder for the IT team to manage and overlook, making it easier for an attacker to exploit and stay in the shadows. Simpler designs that can be easily overviewed are inherently more secure. Use the K.I.S.S. principle for your designs.

KISS - “Keep it simple, stupid” - is a design principle noted by the U.S. Navy in 1960. It states that most systems work best if they are kept simple rather than made complicated. A simple design is easier to overview and to secure as a whole.

Least Functionality

Only install and enable what is strictly required. Every unnecessary service, port, protocol, or feature is potential attack surface - and attack surface that you may not be actively monitoring. When in doubt, disable it. Enabling a feature later is always cheaper than recovering from a breach caused by one you forgot about.

Separation of Failure Domains

A well-designed backup infrastructure is organized into isolated silos, each representing a failure domain: control plane, primary backup, secondary backup, offsite or immutable copy. A compromise or failure in one domain should not cascade into the others. This is the architectural expression of the 3-2-1 backup rule - and the structural foundation of Zero Trust Data Resilience resilience zones.

Explicit Trust Boundaries

Every point in your architecture where trust changes - between networks, between components, between users and systems - should be a conscious design decision, documented and enforced. Trust boundaries that emerge by accident, or that are assumed rather than defined, are where attackers find their paths. Design your trust boundaries first, then build around them.

Avoid Security by Obscurity

Do not rely on the complexity or secrecy of your design as a security control. Assume that a determined attacker will eventually map your architecture. Design so that this knowledge alone does not give them access - every layer should be secure on its own merits, not because it is hidden.

Residual Risk

Intellectual honesty leads every architect to accept the fact that no design will ever be perfect. There will be - hopefully small - gaps that attackers may be able to exploit. Accepting risk is not accepting failure or stating our own incompetency; quite the opposite. It helps us mentally to remember that no solution is perfect, whatever marketing says. It hence drives us to leverage defence in depth (using multiple solutions in conjunction that help each other), and ultimately prepares us for the bad times, so that the damage will be minimal and recovery will be quick and painless.

References

• KISS Principle - Wikipedia
• NIST SP 800-160 - Systems Security Engineering
• NIST SP 800-53 - Security and Privacy Controls (see control CM-7: Least Functionality)
• NIST SP 800-207 - Zero Trust Architecture
• CIS Controls - Center for Internet Security
• Veeam Zero Trust Data Resilience - Veeam ZTDR whitepaper