Availability

Availability ensures networks, applications, and data remain reliably accessible to authorized users within agreed expectations. "The disks still spin" is not availability if staff cannot open the files. "The website resolves" is not availability if checkout fails under load. Measure from the user's job: can they complete the authorized action? If not, availability is the first language even when encryption or hashes are involved as side effects of the incident.

Security that people cannot use often collapses into sticky notes and shared passwords — which then breaks confidentiality. Balancing the triad is part of availability thinking: controls must match risk. Five gates for every email open sounds "secure" and destroys work. Strong MFA for admin and finance with simpler step-up for low-risk reads is usually the durable design. Availability is not "turn security off." It is "design controls humans can operate under real deadlines."

Denial-of-service (DoS) and distributed denial-of-service (DDoS) flood a service with junk or expensive requests so legitimate users cannot connect. Defenders care about capacity, filtering, and failover — not about how to point a stress tool at a school site. Resource exhaustion can also be local: a full disk, a runaway log, a certificate nobody renewed. Physical and operational failures — cut cables, fire, failed disks, accidental "delete production" — stop service without any glamorous "hack." Patch windows done carelessly create avoidable downtime; patch windows skipped create avoidable breaches. Both are availability stories.

Ransomware's immediate operational punch is often availability: files exist as ciphertext on disk, but authorized staff cannot use them. Later lessons show how the same campaign also hits confidentiality (stolen copies, leak threats) and integrity (trust in records and backups). For this pillar, remember: lockout of authorized work is an availability failure even before money moves. Tested restores — especially offline or immutable copies — are the control that turns "encrypted forever" into "restore and continue."

Personal availability failures are quieter but common: a phone that will not update because storage is full, a single USB backup that was never restored, a cloud account you locked yourself out of because MFA recovery codes lived only inside the same phone. Defenders rehearse recovery before panic. Restore one photo. Write down where backup codes live offline. Keep enough free space for updates. Those habits do not require attacking anyone's uptime — they require treating your own continuity as part of security, not as an afterthought once the triad poster is memorized.

Redundancy means spare servers, links, power, and regions so one failure is not a total outage. Load balancers and traffic filters absorb or shed floods before the core app collapses. Capacity planning asks whether holiday peaks or a viral campaign will look like a DDoS to your users. Monitoring turns "it feels slow" into a measured event before customers tweet the outage for you.

Backups are not complete until restore is proven. A cloud sync that mirrors ransomware encryption into the only copy is not a recovery plan. Prefer at least one copy that is not always connected — an unplugged drive, an immutable snapshot, a version history you have actually used. On personal devices, free disk space is a humble availability control: full volumes break updates, logs, and saves. Check space; delete junk you own; do not fill someone else's disk "as a test."

Organizations also treat maintenance as an availability risk. Patching improves Confidentiality and Integrity by closing bugs attackers abuse, but a botched change window can take payment systems offline on a peak day. The defensive craft is planning: staged rollouts, rollback plans, communication. Your personal analogue is simpler: update on your schedule before the OS forces a reboot mid-exam; keep chargers and offline copies for work you cannot afford to lose. Availability is the pillar that asks whether security still lets authorized life continue.

Prove you can reach a service you rely on, prove you have a backup path, and prove disk space is not a silent landmine — all on gear and accounts you own. This is readiness, not attack practice.

# 1) Can you reach a service you rely on?
# Browser: open your email / cloud drive — does it load?

# 2) Backup reality check (personal)
# - Where is your last backup? (cloud? external drive?)
# - Is at least one copy offline / not always plugged in?
# - Have you restored ONE small file as a test?

# 3) Disk free space (full disks break availability)
# Windows PowerShell:
Get-PSDrive -PSProvider FileSystem

# macOS / Linux:
df -h

# Optional notes:
# mkdir -p "$HOME/cyberlium-lab"
# Write where your separated backup lives (no account passwords in the file)

# NEVER: flood, stress-test, or "DDoS practice" any site you do not own
# NEVER: delete other people's data to "simulate outage"

You can now name threats and defenses for uptime — capacity, redundancy, backups, balanced controls — without practicing denial-of-service. Next — Real-world Applications — ransomware shows how one incident can hammer Confidentiality, Integrity, and Availability together.