Chapter 32 — Security architecture and engineering: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Series and parallel"]
N2["Lab — Series and parallel availability"]
N3["32.2 Redundancy for security services"]
N4["32.3 When security hurts reliability"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Series and parallel"]
N2["Lab — Series and parallel availability"]
N3["32.2 Redundancy for security services"]
N4["32.3 When security hurts reliability"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Series and parallel]
|
v
[Lab — Series and parallel availability]
|
v
[32.2 Redundancy for security services]
|
v
[32.3 When security hurts reliability]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) compute availability of components in series and parallel; (2) design redundancy for security services; (3) recognise when security controls reduce reliability.
32.1 Series and parallel
Reliability engineering gives simple rules. Components in series, all needed for the service, multiply their availabilities, so the whole is less available than any part. Components in parallel, any one sufficient, combine so the whole is more available than each. Sofia applies this to ingestion, which needs the load balancer, the ingestion service, the secret store and the database in series. The lab below computes overall availability with synthetic figures and shows how adding a second secret-store instance in parallel changes the result. Security services such as secret stores are often forgotten when availability is planned.
Lab — Series and parallel availability
# Series/parallel availability with synthetic component figures.
comp = {"load balancer": 0.9995, "ingestion": 0.999, "secret store": 0.998, "database": 0.9995}
def series(xs):
p = 1.0
for x in xs: p *= x
return p
def parallel(a, n): return 1 - (1 - a) ** n
base = series(comp.values())
red = series([comp["load balancer"], comp["ingestion"], parallel(comp["secret store"], 2), comp["database"]])
print(f"single secret store: {base:.4f} (~{(1-base)*8760:.0f} h/yr down)")
print(f"two secret stores: {red:.4f} (~{(1-red)*8760:.0f} h/yr down)")
Run with python3 lab_avail.py. Verified output:
single secret store: 0.9960 (~35 h/yr down)
two secret stores: 0.9980 (~18 h/yr down)
32.2 Redundancy for security services
Authentication, key management and logging are dependencies of almost everything. If the identity provider fails, staff cannot log in; if the secret store fails, services cannot start; if logging fails, attacks go unseen. Sofia proposes redundancy for each: clustered identity providers across two sites, replicated secret stores, and local log buffering when the central collector is unreachable. She also documents what happens in degraded mode, such as validators continuing with cached deny lists. Designing degraded behaviour deliberately is safer than discovering it during an outage.
32.3 When security hurts reliability
Some controls reduce availability. Strict certificate validation fails closed if the revocation service is unreachable; aggressive rate limiting can block legitimate surges; mandatory multi-factor authentication fails if the second-factor service is down. Sofia lists such cases and decides each deliberately: tap ingestion soft-fails revocation checks for a short period using cached lists, while administrative access hard-fails. The decision follows from the asset and the threat: revenue collection must continue, while administrative access can wait. Reliability and security are both properties of the same system and must be traded off explicitly.
Worked example
Sofia computes ingestion availability with and without a redundant secret store, designs redundancy for three security services and records fail-open and fail-closed decisions.
Synthetic case. Availability figures are synthetic.
Errors and limits
Independence assumptions overstate parallel benefits when replicas share a failure cause. Soft-fail windows can be abused.
Exercises
- EX094 — Series rule. How do availabilities combine in series? Rubric: 3 = multiply; the whole is less available than any part;; 2 = multiply;; 1 = add;; 0 = none.
- EX095 — Lab redundancy effect. What did the lab show when the secret store was duplicated? Rubric: 3 = availability rose from 0.9960 to 0.9980, roughly halving downtime from about 35 to 18 hours a year;; 2 = rise;; 1 = fall;; 0 = none.
- EX096 — Fail decision. Which path soft-fails revocation checks, and which hard-fails? Rubric: 3 = tap ingestion soft-fails briefly; administrative access hard-fails;; 2 = both;; 1 = reversed;; 0 = none.
Synthesis
Reliability engineering applies to security services, and fail-open or fail-closed choices must follow from assets and threats.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →