The certificate has 9 courses:

1. Foundations of Cybersecurity
2. Play It Safe: Manage Security Risks
3. Connect and Protect: Networks and Network Security
4. Tools of the Trade: Linux and SQL
5. Assets, Threats, and Vulnerabilities
6. Sound the Alarm: Detection and Response
7. Automate Cybersecurity Tasks with Python
8. Put It to Work: Prepare for Cybersecurity Jobs
9. Accelerate Your Job Search with AI

Coursera offers a 7-day free trial. In January I used it to get through courses 1 to 4, then other exams got in the way and I let it expire rather than pay $49/month, which is steep. Courses 5 through 9 had to wait. A few days ago I came back, grabbed another trial (I am NOT paying 49$), and finished everything. The first 5 I had already done so they went fast, about 1 day, and the last 4 took another 2. All 9 done within a week.

What’s good

Videos

Short, 2 to 8 minutes each, and consistently well produced. Each concept gets its own clip, so you can move quickly through things you already know and slow down where you need to. I took a lot of notes on Course 6 (detection and response) and skimmed most of the rest.

Quizzes

4 to 10 questions per module, conceptual rather than tricky. With a CS background they are not a challenge, but they do make you check whether you actually absorbed the video or just had it on in the background while doing something else (not that I would know anything about that).

What’s bad

Repetition

The biggest issue by far. SIEM (Security Information and Event Management, basically a tool that aggregates logs from across your infrastructure and helps you detect threats) is introduced in Course 2, reappears in Course 3’s network security section, and then Course 6 dedicates an entire module to it. Brute force attacks (trying every possible password combination until one works) show up in Course 3 and again in Course 5. OWASP (Open Worldwide Application Security Project, the organisation behind the well-known Top 10 list of most critical web vulnerabilities) principles are in Course 2, and the OWASP Top 10 is back in Course 5. None of it builds on what came before, it is just the same explanation with slightly different slides. By Course 6 you notice it, and by Course 7 you start wondering if the authors have a SIEM-shaped hole in their hearts.

Course 7 (Python)

Python 101: variables, loops, functions, strings, lists, regex, file handling. If you have written any code before, skip it entirely. I took zero notes and finished it faster than it takes to make coffee.

Courses 8 and 9

Mostly career prep: how to escalate incidents, how to communicate with stakeholders, how to use AI for job hunting. Course 9 is literally called “Accelerate Your Job Search with AI.” Fine if you are entering the field from a non-technical background, but if you are doing this alongside a CS degree it feels like the course ran out of technical content and needed to fill two more modules.

More broadly, a lot of the material (Python, SQL, web vulnerabilities) is not difficult with any programming background. The course is built for people without one, which makes sense, but it does mean you will spend more time than you would like on things you already know.

How it compares to SIC

The UA course goes into depth that Google does not touch: the math behind cryptographic primitives, how PKI (Public Key Infrastructure, the system of certificates and authorities that makes encrypted communication on the web possible) works at the protocol level, SSH internals, IPSec (the protocol suite that secures traffic at the network layer, used in most VPNs), the full evolution of wireless security standards from WEP to WPA3. Google covers VPNs, firewalls, brute force, phishing, and IDS/IPS (Intrusion Detection and Prevention Systems, which monitor network traffic for suspicious activity), but at a surface level. The difficulty gap is significant.

The parts that were actually useful for the exam were network security and threat modeling, where the Google course gave me a slightly different framing of concepts I had already seen in the UA lectures. Not a large difference, but occasionally helpful.

Is it worth it?

At $49/month, probably not, unless you need the certificate for a job application. For anyone with a CS background, courses 1 to 5 are where the value is: they actually focus on cybersecurity, and the 7-day trial is enough to get through them if you commit to it. Courses 6 to 9 are where the repetition and career fluff kick in, and the returns drop off quickly.

As a broad introduction to the cybersecurity field before going deeper elsewhere, it is worth doing once. Just use the trial.

Google’s certificate is a good starting line, not a destination :)

The rough idea

The setup is basically a tree. There’s one Sink at the root and a bunch of Nodes hanging off it in layers. Each node forwards messages upward to the Sink, the Sink routes them down to wherever they need to go, and end-to-end everything is encrypted so intermediate nodes can’t actually read the payloads they’re carrying. The whole thing runs over Bluetooth Low Energy, using the Linux BlueZ stack underneath, and the nodes form the tree automatically by picking the best parent they can find.

The interesting bit for a security course is the layered protection: everything between two nodes is mutually authenticated with certificates, every hop is HMAC-protected against tampering, and end-to-end traffic gets its own AES-256-GCM layer so even intermediate nodes on the path only see routing headers, never content. Kind of like DTLS, but cobbled together over BLE GATT characteristics.

Why BLE and why a tree

BLE mostly because the spec asked for it, but also because it’s actually pretty convenient: discovery and pairing primitives are built in, you get small broadcasts for advertising, and GATT gives you a clean request/response channel once connected. Tree topology because it’s about the simplest routing structure that still lets arbitrary nodes talk through a central authority (the Sink), and because it limits how much state any one node has to carry.

Nodes pick a parent by scanning around, reading the hop count each candidate advertises, and going with the lowest one they can find. So if a node hears a neighbor that’s 2 hops from the Sink, it’ll prefer that one over a neighbor that’s 4 hops away, and its own hop count becomes 3. Enough to get a working tree without any central coordinator.

The tree forms on its own as nodes pick the lowest-hop parent they can see.

Dual-role BLE (aka “a node is both a client and a server”)

Each node has to accept connections from children below it while also maintaining its own uplink to its parent, which means it needs to be a GATT server and a GATT client at the same time. Python doesn’t really have one library that does both cleanly, so we mixed two:

• bleak for the client side (uplink towards the parent)
• dbus-python + GLib for the server side (downlink from children)

The GUI runs on top of that in Tkinter, so at runtime each node has three concurrent contexts going: GLib for D-Bus/BlueZ callbacks, asyncio for the Bleak client, and Tkinter for the UI. Keeping those three cooperating takes a bit of care, especially around anything touching shared state.

One process, three concurrent contexts, one block of shared state holding them together.

The security side

This is the part the course was actually about.

Provisioning and PKI

Before anything runs, every device gets provisioned with its own credentials:

• A P-521 ECC keypair
• An X.509 certificate signed by a shared CA
• A copy of the CA cert so it can verify others

The device identity (a 128-bit NID) is embedded into the Subject Alternative Name of its certificate, so you can’t just present any valid cert, the NID in the cert has to match the one the device is advertising over BLE.

Mutual auth on pairing

When two nodes pair, both read each other’s certificate off a known GATT characteristic, verify the signature against the CA public key, and check that the NID in the cert matches the one being advertised. If either check fails, the pairing just doesn’t happen. Pretty standard mutual auth, but wiring it into GATT read/write flows in both directions is its own little adventure.

Session keys via ephemeral ECDH

Once both sides trust each other, they do an ephemeral ECDH handshake. Each generates a fresh P-521 keypair, they exchange public halves, compute the shared secret, and run it through HKDF-SHA256 to derive a session key. Because the keypairs are ephemeral, every connection has its own session key, so past traffic stays safe even if a long-term key leaks later. That’s basically Perfect Forward Secrecy, at least for the link layer.

Certs first, then ephemeral key exchange. The session key is derived locally on both sides and never actually travels on the wire.

Hop-by-hop integrity

Every message on the wire gets prepended with a sequence counter and an HMAC-SHA256 computed with the session key, then the routing headers, then the payload. The receiver verifies the HMAC, checks the sequence counter is strictly greater than the last one it saw from that sender (that’s the replay protection), and only then processes the message. This layer is always on, including for end-to-end encrypted traffic.

End-to-end, DTLS-style

Routing headers have to be readable by intermediate nodes (otherwise the Sink can’t route anything), but the payload shouldn’t be. So we added a second layer: the Node and Sink do their own mini-handshake (ClientHello / ServerHello with nonces), derive a separate end-to-end key via HKDF, and encrypt the payload with AES-256-GCM before handing it off. Intermediate hops see the headers, forward the encrypted blob, and that’s the extent of what they can read.

Outer layer is re-HMACed at every hop; the inner AES-GCM payload is only readable by the Node and the Sink.

Heartbeats and recovery

The Sink signs a heartbeat every 5 seconds with an incrementing counter. Nodes verify the signature, update their state, and forward it down to their children. If a node misses 3 heartbeats in a row, it assumes its uplink is dead, sets its own hop count to -1, broadcasts that to its children, who then recursively disconnect their own subtrees and go back into scanning mode to find a new parent. That cascading disconnect was fiddly to get right but is probably the most satisfying piece to watch in the GUI.

A single broken uplink takes the whole subtree back to scanning mode, layer by layer.

What I took from it

A few things. Writing crypto glue code (as opposed to crypto primitives, which the cryptography library handles for you) is where the subtle bugs hide: off-by-one on the sequence counter, forgetting to HKDF the shared secret, passing the wrong nonce into GCM, stuff like that. Second, designing a protocol that works across unreliable wireless links forces you to take state recovery seriously in a way purely wired setups don’t.

And third, honestly the single biggest challenge of the whole project was just working with the Bluetooth stack on Linux, because BLE and BlueZ have their fair share of quirks that you only really find out about by running into them. The D-Bus API surface changes subtly between BlueZ versions, GATT MTU negotiation doesn’t always give you the size you asked for (so big writes get silently fragmented or rejected, don’t even ask about the headache this was), pairing state sometimes lingers across reboots in ways that make you question reality, and switching roles between central and peripheral on the same adapter can leave hci0 in weird states that only hciconfig reset fixes. The error messages are also pretty cryptic, so you end up spending a lot of time reading dbus-monitor output and cross-referencing source comments in BlueZ itself to figure out what’s actually going on

If you want to poke at the code, it’s on GitHub at tfdmendes/SIC-final-project. Happy to answer questions if anyone else is running into the same BLE-on-Linux potholes 😵‍💫

Anyway, turns out teaching a bunch of BLE nodes to trust each other is mostly an exercise in not getting state wrong :)

Ok but what actually broke

Falcon ships with a kernel-mode driver, which is a fancy way of saying a piece of code that runs right next to the Windows kernel with full access to memory and hardware. EDRs need to live there because attackers often operate at that level too. That driver pulls in small configuration files called “channel files” constantly, little rule updates about new threats, and that morning one of them (C-00000291) shipped with malformed data inside. The driver tried to read a memory address it shouldn’t have (an out-of-bounds read, in the jargon), and because kernel code runs in ring 0 (the most privileged level the CPU offers) there’s no graceful “oh well, that thread crashed” fallback. When a ring-0 driver faults, the whole OS faults with it. Blue screen, reboot, load the same broken file, blue screen again.

Now picture that happening on thousands of machines at once inside an airport. The “fix” was that someone physically had to walk up to every single one, boot into safe mode, delete the file by hand, and reboot, because the driver loaded before Windows could even reach the network for a remote patch. You saw the consequences of that for days on the news: Delta staff scribbling flight info on whiteboards, gate screens stuck on blue, passengers camping out on terminal floors in Atlanta with handwritten boarding passes, radiology departments turning people away because the scanners wouldn’t come back up.

LaGuardia Airport, July 19th 2024. Photo: Smishra1, CC BY-SA 4.0 via Wikimedia Commons.

The awkward bit

None of this was exotic. CrowdStrike isn’t some sketchy vendor, they’re one of the biggest names in the business, and Falcon is everywhere because it actually works well. The update pipeline did exactly what it was designed to do, which was take a signed, vendor-approved file and ship it to every sensor on the planet in a few minutes. Everything worked as intended, and that’s kind of the uncomfortable part.

The thing that makes modern EDR useful (push fast, push everywhere, run in ring 0 because that’s where the interesting stuff happens) is the same thing that turned one bad file into a worldwide outage. No attacker, no zero-day, nothing clever going on, just a signed update shipped at scale with nothing meaningful in the way of a circuit breaker.

What I actually took from it

Your security tool is a supply chain too

We spend a lot of time worrying about supply chain attacks, meaning malicious code slipped in through some dependency like a compromised npm package. We spend way less time worrying about supply chain accidents, where the code is fine, signed correctly, and just behaves badly anyway. From the customer’s seat, the outcome is pretty much identical: the kernel still panics and the plane still doesn’t move.

Any vendor that can auto-push code into ring 0 on every machine in your fleet is, by definition, a single point of failure for that fleet, and it’s worth being honest about that rather than filing it under “boring dependency.”

“Defense in depth” is doing more lifting than it can

Everyone says “defense in depth” like it’s a magic phrase, but in practice most places run one EDR on every endpoint, from laptops to servers to point-of-sale machines. When that EDR breaks, there’s no second layer underneath, the whole defensive stack goes with it. Real depth implies heterogeneity (different vendors for different tiers, or different OSes), and heterogeneity costs money and complexity that nobody volunteers for.

The outage didn’t really punish companies for having bad security, it punished them for having the same security everywhere, which is a genuinely different problem.

Staged rollouts, even for “just config”

The detail from the post-mortem that really stuck with me was that the file went out to everyone at once. No ring deployment (shipping to 1% of machines first, then 10%, then the rest), no canary fleet, nothing. The reasoning was basically “this is threat intelligence content, not code, content is low risk, threats move fast, we gotta ship fast.” Which is also the exact reasoning that lets a broken file land on 8.5 million machines before anything can stop it.

The content-vs-code distinction is convenient for the vendor but doesn’t give the customer any real safety. If a file can crash your kernel, it’s code in every sense that matters, and it deserves the same care: canary deployments, ring rollouts, a rollback mechanism, a pause button customers can reach.

The recovery plan is kinda the real product

Every vendor has an incident response plan. Almost nobody has one for the scenario where the vendor is the incident, and that’s what separated the people who handled July 19th okay from the ones who didn’t. The ones who did okay had thought about it ahead of time: Bitlocker recovery keys (which you need just to get into an encrypted Windows machine) stored somewhere reachable and not only on the servers that were also down; out-of-band management like IPMI or iLO to get into machines without the OS; runbooks written from the assumption that the security tool itself could be the thing breaking everything.

If your recovery plan quietly assumes your security vendor is healthy, it’s less of a plan and more of an aspiration.

What I keep thinking about

Security software earns its place by being trusted, privileged, and basically everywhere. You can’t really design it any other way, an EDR that can’t see inside the kernel can’t catch an attacker who’s operating in the kernel. But the flip side of “trusted, privileged, everywhere” is that one bad push from the vendor can become everybody’s problem at the same moment.

CrowdStrike didn’t teach me Falcon is bad, it isn’t. What it reminded me of is that thinking about security software purely as a protector is only half the picture. It’s also a dependency in the hard operational sense, sitting in the kernel with update access to thousands of machines, and a dependency that powerful needs to be treated as one, with some redundancy where you can afford it, some staged trust in the update pipeline, and an actual plan for the day something about it goes sideways.

One vendor shouldn’t really be able to take down an airline, or a hospital, or someone’s emergency line, and when it happens, honestly it’s less about blaming CrowdStrike specifically and more about how we keep architecting systems in a way that lets one vendor have that kind of reach.

Anyway, maybe keep a Bitlocker key on paper somewhere :)