The Tensions Between Pillars

The three pillars are not independent. Strengthening one almost always weakens at least one of the others.

This is the page that separates students who can recite the triad from students who can apply it. Beginners draw a triangle and treat each corner as a separate concern. Practitioners know that confidentiality, integrity, and availability are coupled, and that the interesting security questions are about where to put the slider.

The three sides of the triangle correspond to the three pairs of pillars: confidentiality versus availability, integrity versus availability, and confidentiality versus integrity. Each side has a characteristic tension that shows up in real systems. The rest of this page walks through each one with a worked example.

This is the most familiar tension because nearly every login screen embodies it. To prove you are authorized to see the data, you must complete an authentication ritual: a password, then maybe an MFA code, then maybe a hardware token. Each step strengthens confidentiality (more confidence that the right person is being admitted) at the cost of availability (more time and friction before legitimate access).

The same trade-off appears at the architectural level. Air-gapping a system maximizes confidentiality by removing every network path an attacker could use. It also makes the data unavailable to anyone not physically present in the secure room. Network segmentation, jump hosts, and zero-trust architectures sit somewhere along this spectrum.

Integrity controls add verification steps. Verification takes time. The more rigorous the verification, the slower the system responds and the more likely it is to reject a legitimate operation that fails a strict check.

A simple example: an e-commerce site that requires a manager's approval for every order above one thousand dollars has stronger integrity (lower chance of fraudulent large orders) but weaker availability (the order is pending until the manager responds). Multiply this by every transaction and you get a system that may be unusable during a manager's vacation.

At a deeper architectural level, distributed databases trade integrity and availability in the formal sense via the CAP theorem. When the network partitions, you can have a database that continues to accept writes (favoring availability) or one that refuses writes to prevent inconsistent state (favoring integrity, called consistency in the CAP framing). You cannot have both.

This tension is subtler and less often discussed, but it appears whenever you cannot inspect what you cannot read. Encrypted traffic protects confidentiality from any observer who lacks the key. It also blinds the integrity-checking systems that depend on observation, such as deep packet inspection firewalls, intrusion detection systems, and data-loss prevention tools.

The standard organizational response is a TLS inspection proxy: a device that holds a trusted certificate, terminates incoming connections, inspects the plaintext, and re-encrypts onward. This restores integrity inspection at the cost of breaking end-to-end confidentiality between the user and the destination. Many organizations consider this trade worth making for outbound corporate traffic. It is not a trade made lightly for personal banking or healthcare traffic.

Read each scenario. For each one, identify which pillar is being prioritized, which is being compromised, and whether the trade is appropriate for the context.

Scenario A · Online banking app. After three failed password attempts, the account is locked for thirty minutes. Customers complain that lockouts during traffic disrupt their day. The bank reduces the threshold to ten failed attempts before lockout.

The original policy favored confidentiality (low tolerance for brute-force attempts) over availability. The change favors availability at the cost of confidentiality, accepting roughly three times the brute-force search space per lockout. Whether this is appropriate depends on the cost of a successful breach versus the cost of an annoyed customer. For online banking, the original policy was probably correct; for a low-stakes consumer app, the change is reasonable.

Scenario B · Software supply chain. A team disables a slow integrity-checking step in their build pipeline because it adds twenty minutes to every deployment. The check verified that every dependency hash matched a known-good list.

The team prioritized deployment availability over build integrity. The disabled check was a defense against the SolarWinds-style supply-chain attack covered on the previous page. This trade is almost never appropriate; the right response to a slow integrity check is to make it faster, not to remove it.

Scenario C · Medical imaging archive. A radiology system stores images on encrypted, read-only optical media for long-term retention. Retrieving an image for review takes ninety seconds while the archive robot loads the platter. Clinicians complain about latency and ask for the images to be re-stored on fast SSDs in plaintext.

The current configuration favors confidentiality and integrity (encrypted, read-only) over availability. The proposed change would reverse all three. The correct compromise is probably a hybrid: keep the archive encrypted and read-only, but maintain a fast encrypted cache of recently accessed images on SSD. The trade is rebalanced rather than abandoned.

Every security decision you make for the rest of your career will be a position along these axes. The discipline is not to find a magical answer that satisfies all three pillars. The discipline is to:

1. Identify which pillars are in tension for this specific decision.
2. Name the business or mission context that determines which pillar should win.
3. Choose the trade explicitly, with the trade-off documented.
4. Add a compensating control that softens the corner you sacrificed.

Step four is what separates good security from bad. A team that disables MFA because the help-desk cost is too high has chosen availability over confidentiality. A team that does the same thing and adds geographic and behavioral anomaly detection in the same change has rebalanced the trade-off with a compensating control. The triangle is the same. The risk posture is very different.

From the next page on, we extend the model. The Parkerian Hexad adds three properties the triad cannot describe; the attack mapping translates real incidents to pillars; the controls matrix gives you the toolkit for compensating controls.