The App Under Attack

The transit app that ascended to the cloud in Unit 10 now stands inspection against this unit's full threat taxonomy — every attack named, every defense answering to a named asset, and the human layer counted honestly.

Start with the estate (0611): the app, its services, its policies, and its runbooks are all cyber resources, and the security policy (0613) names the assets — riders' confidentiality, fare-data integrity, service availability, and the PII (0614) that makes the rider database worth stealing. Now walk the taxonomy against it. Malware's doors (0629): a compromised dependency in the build pipeline is the supply-chain door; a phishing message (0626) to a transit-authority employee is the judgment door — and the departed contractor's live credentials (0625) are the door nobody remembered installing. A botnet (0623) aims a distributed denial of service (0627) at launch morning — availability attacked by name — while the quieter nightmare is the advanced persistent threat (0628): a presence in the fare system for a year, no outage, no alarm, reading everything. Ransomware (0624) is the loud version: the private-side fare records encrypted against their owners, answered by the backups held apart. Against all of it, the defenses this course has been assembling since Unit 6: authentication and the protection triad at the gates, the kernel boundary under every process, HTTPS wrapping every exchange — cryptography's cast (0632) working every request, the same mechanism video 0640 ran by hand at toy scale. And over the whole estate, responsible computing (0636): the governance the builders apply before any regulator asks. The app survives inspection not because any wall is perfect but because every named threat meets a named control — which is what a security posture is.