RDRDS, or Five Points of Security Architecture

There’s a concept that gained some traction not too long ago, called anti-fragile. The idea is to make things that can withstand a certain level of abuse without failing. Bend, don’t break is the easy way of thinking about it.

I think the concept of anti-fragile is a good one, but it is too limiting. I prefer RDRDS – Redundancy, Diversity, Resiliency, Depth, and Simplicity – or Five Points of Security Architecture.

We security professionals talk about the CIA triangle – confidentiality, integrity, and availability. Availability is often overlooked. RDRDS addresses that. Integrity is also covered in this scheme, in that the systems that data rely upon need not just make sure the data is available but that it remains unaltered, either intentionally or otherwise. RDRDS helps assure that because it’s built into the concept and the quality of those systems is known in advance of their use.

Operationally, availability is critical. When I was a network manager I mostly lived in the operations world. When systems fail the phone starts ringing. Focusing on operational issues becomes a simple math problem in many organizations, and we should take advantage of it. Is the cost of implementing and maintaining these redundant systems worth it? How many minutes of downtime pays for these systems?

When I talk about RDRDS, what do I mean?


  • Duplication of components or circuits to provide survival of the total system in case of failure of single components.

Firewalls are the canonical examples of security tools deployed in a redundant configuration. In most organizations they are a pair of nodes in a cluster, although 3 or more nodes and multiple clusters are not uncommon.

We want critical systems to be redundant. By redundant, I mean they should keep running in the event of any specific element failing. This is typically handled via clustering, secondary paths, and load balancing among other tools.


  • The quality of being different or unlikeness.
  • A variety.
  • Diverse types or examples.

Diversity basically boils down to not relying on a single thing: vendor; technology; or philosophy. Lacking diversity limits the value of redundancy.

Diversity also means avoiding single points of failure in a system. For example, having a server with two power supplies plugged into the same power circuit is an example of having redundancy (two power supply units) but a lack of diversity (one power circuit). Purchasing two data circuits from different providers when they both come in on the same cable through the same conduit is another example.


  • the physical property of a material that can return to its original shape or position after deformation that does not exceed its elastic limit.
  • an occurrence of rebounding or springing back.

Resiliency deals with the margins, the exceptions, the extremes in a system. How well can the system handle not just peak loads but also a lack thereof and return to a normal state?

It also talks to the ability to get the system back up and running after an event, such as a fire. Resiliency can also be described as scalability, the ability to shrink and grow as needed. Also elasticity, the ability to bend and flex but not break.

The concept of anti-fragile I think mostly touches on resilience, though to an extent it encompasses all of the concepts here.

We want systems that are properly sized and can handle peak loads without falling over. We want them to load balance or calculate the relative cost between possible paths. It should be possible to isolate and route around broken components. A modular and distributed design provides resiliency, plus provides additional benefits when it comes to upgrades and maintenance and the like.


  • Strength held in reserve, especially a supply of skilled or capable replacements.
  • A team with depth at every position.
  • The degree of richness.
  • Complete detail.
  • Thoroughness.

Defense In Depth (DID) is a common mantra in the industry since the 90’s, maybe earlier. What does depth provide us? If we stack all of our assets at the perimeter then how does that help us when something gets inside anyway? Think about the internal malicious actor. Layering security throughout the infrastructure, thereby not placing all of one’s eggs into one basket, provides depth as well as diversity.

Depth can also address third party connections as well as upstream issues from suppliers, partners, vendors, and so on.

Information Sharing and Analysis Centers (ISAC) data and broad threat intelligence adds to depth. CERTs and the Internet Storm Center (ISC) and other third party threat intelligence vectors also enrich depth.

From a personnel perspective, making sure that the one professional with all the institutional knowledge documents it so that she can take an uninterrupted vacation is also part of depth.


  • The quality or state of being not complex, or of consisting of few parts.
  • A freedom from complexity or intricacy.

Modularizing systems, like deploying a log management solution that the Security Incident & Event Monitoring (SIEM), operations monitoring, and other systems tie into. In networks, separating the access, distribution, and core layers.

Gap analysis helps with simplification. Compartmentalization of systems without compartmentalizing data, thereby allowing maintenance and potential component replacement without losing fidelity of data sources is valuable.

Above all, avoid introducing artificial complexity.

What does all of this mean from a security perspective?

There are several basic questions that need answers before you can proceed with RDRDS/the Five Points:

  1. Should security systems fail open or closed? By this we mean in the electrical engineering sense – failing open means that the circuit is broken and traffic stops flowing. Failing closed means that the circuit isn’t broken and traffic continues to flow.
  2. What are the security thresholds?
    1. How long can the IDS/IDP be down?
    2. How long can notifications from the SIEM be down or delayed?
    3. What is the cost per minute of downtime?
    4. What is the sensitivity of the data?
  3. What is the comfort level with F/OSS (Free/Open Source Software) as secondary systems?
  4. What are you trying to protect?

There are other questions, and we will flesh those out as the concept is developed. Your comments and questions are welcome here, at hashtag askpvcsec, or email comments@pvcsec.com.

By the way, these Five Points can apply to any system – servers or databases or IT or applications or personnel or finance or anything.


Due to an error on my part, I lost track of what dictionaries I pulled the various definitions from. I will endeavor to cite them appropriately.