Episodes

  • CCT 378: Two Feeds, Full Backup, And The Generators Never Started (Domain 3)

    CCT 378: Two Feeds, Full Backup, And The Generators Never Started (Domain 3)
    Nov 9 2026
    Send us Fan MailCISSP Domain 3.9 — design site and facility security controls, built on a real data center power failure where every control in the building worked and the building still went dark.Start free: https://www.cisspcybertraining.com/free-cissp-self-study (360 practice questions, a Domain 1 diagnostic, weekly questions by email, and the slides from this episode)In October, a cloud provider's London data center lost its utility power. The batteries picked up the load exactly the way they were supposed to, ran for about five minutes, and then ran out. The generators should have taken over in that window. They never got the signal.Nobody attacked anybody here. There are no bad guys in this one. No ransomware, no intrusion, nothing for incident response to chase. It was a cable fault outside the building and a logic error inside it.HOW THE BUILDING WAS BUILTStart with the design, because the design was good. Two completely independent utility feeds coming in from the power company — they call them A and B. Google's own words for that are a 2N utility power architecture.Now listen to where that label stops. Behind both of those feeds sits one central bank of high-voltage generators, run by a dual-redundant controller, a PLC. Two of the thing coming in. One of the thing that was supposed to save them. And between the utility going away and the generators coming up, a battery system with about five minutes of runtime. That isn't a lot and it isn't supposed to be. It's a bridge.So when somebody tells you a site is 2N, the only honest follow-up is: 2N at which layer?Five days before any of this, they ran a quarterly load test on the generators. A real test, under load. And that test found a problem. So they did the right thing — they scheduled the repair. But to do the repair they had to physically open the breaker on feed B and lock it out, which they did properly: keyed interlock, locked out, tagged out.And that is the moment the building stopped being 2N on the utility side. For several days — Google doesn't publish exactly how many — that site ran on one utility feed. Google's own words for it are a temporary single-feed, 1N, bridged maintenance posture.Then the cable broke. An underground cable out on the utility network, outside the building entirely, developed a fault. And it was on feed A. The only feed that was live.WHY THE GENERATORS NEVER STARTEDThe PLC decides when to start the generators, and it decides it by sensing voltage. If the voltage goes away, start the generators. Simple enough.But those voltage sensors were wired upstream of the feed breakers. On the line side. And feed B — the one that was open for repairs — was still energized upstream, all the way up to that open breaker. The power company was still feeding it. It just wasn't connected to the building anymore.So the PLC looks at its sensor, sees voltage on feed B, concludes that a healthy utility source is available, and never issues a start command.Google's own root cause is this: a misconfiguration of the PLC logic that did not verify both an undervoltage condition and physical breaker position for both utility feeders. It checked whether there was voltage. It never checked whether that voltage was actually connected to anything.And here's the part worth a line in your notes. That PLC was dual-redundant. There were two of them. Both of them were wrong in exactly the same way, because they shared a configuration. Duplicating the box does not duplicate the judgment. That's common-mode failure, and it is the reason a redundancy count is not a resilience measurement.Five minutes later the batteries were done and the data halls went dark.TWO NUMBERS, KEPT APARTAbout ninety minutes with the data halls unpowered. Six hours and eight minutes before the services on top of them were whole again. Both figures are in Google's report and they measure different things. According to The Register, the companies caught in that window included Lloyds, HSBC, Royal Mail and Revolut — Google published no customer list and no customer count.To their credit, Google published the whole thing: the timeline, the wiring, the root cause, and a list of fixes with dates on them. One of those action items is the most honest line in the document. They committed to making PLC code review part of facility commissioning — which tells you it wasn't.THE MANAGER'S TAKEAWAYTwo things, and neither one is "test your generators."They DID test. The quarterly load test is what found the fault in the first place. What nobody did was look at the consequence: fixing that fault meant opening a breaker, and opening that breaker meant the building ran on one feed for days. As far as anybody treated it, that was a maintenance ticket. It wasn't a changed risk posture.And the second one, the one to carry into the exam room: an automatic control is only as good as the thing it can sense. The generator was perfect. The battery was perfect. The logic was asking...
    Show More Show Less
    43 mins
  • CCT 377: 155 Answers, Nobody Broke In, And The Control Nobody Named (Domain 2)

    CCT 377: 155 Answers, Nobody Broke In, And The Control Nobody Named (Domain 2)
    Nov 2 2026
    Send us Fan MailCISSP Domain 2.6 — data security controls, compliance requirements, and the three states of data, built on an AI hosting exposure that encryption could never have reached, because the data was exposed while it was being used.Start free: https://www.cisspcybertraining.com/free-cissp-self-study (360 practice questions, a Domain 1 diagnostic, weekly questions by email, and the slides from this episode)One hundred and fifty-five answers went to the wrong people. Nobody broke in.In late August, Cloudflare launched the GLM-5.3 model on Workers AI. The model advertised a context window of just over one million tokens. The memory pool behind it — the prefill KV cache — held about six hundred and eighty thousand. The pool was smaller than the thing it was advertised to hold.Picture a shared workbench with a scratch pad on it. You sit down, you do your working-out, you get up and leave. In a well-run shop somebody wipes that pad before the next person sits down. That pad is memory, and wiping it is the control.When a request came in too big for the pad, the system marked it rejected, which was correct, and then passed the pad downstream anyway. The next stage read it, found the previous request's working still on it, and handed that back as a successful answer. Not an error. An HTTP 200.155 responses were affected, every one from a prompt over the pool's limit. Cloudflare said only that a small number of customers were involved and published no customer count. It found no evidence of deliberate exploitation. This was an exposure — nothing was taken, nobody broke in — and the misconfigured value and the serving-engine behavior both sat in the hosting stack, not with the model's maker. The advertised context length itself was accurate.Security researcher Gadi Evron of Knostic reported it through HackerOne. Cloudflare began verifying it the next morning and reproduced it from two independent accounts within twenty-five minutes of declaring the incident — and the model was offline about fifteen hours after the report landed. Root cause thirty-five minutes later, corrected configuration seventeen minutes after that. It raised the pool to roughly twice the advertised window, moved retirement of rejected requests to the admission queue before any cache transfer, added a deployment check comparing pool size to context length, and published the whole timeline itself.Now the part that turns it into exam content. Encryption at rest and encryption in transit were never going to touch this one. Not because anything was wrong with them. Because neither one has a single thing to say about data while it is being used.And they knew. Cloudflare knew before launch that the two numbers disagreed. It assumed the engine would handle it cleanly, and what it validated was the status code and the performance — not the answer coming back. The engine said 200 OK, so it looked fine. It was not a secret. It was an assumption nobody had validated, standing in for a control nobody owned.A control is not a control because of what it is called. It is a control because of what fails when it is wrong.In this episode:• The three states of data — at rest, in transit, in use — and why the third is the one you get tested on. At rest and in transit are cryptography questions. In use is an isolation question, and cryptography alone does not reach it. Confidential computing is the exception.• The data-in-use control vocabulary: memory isolation, zeroization between requests, object reuse controls, confidential computing, homomorphic encryption and admission control. Object reuse is the classic ISC2 phrasing for this failure shape.• Scoping and tailoring, and the precision trap. Scoping is not a step before tailoring — it is one of the six tailoring actions NIST SP 800-53B names, and an option that sequences them is the distractor.• Standards selection and baselines: ISO 27001, NIST SP 800-53 and 53B, CSF 2.0, CIS, the Cloud Controls Matrix, PCI DSS and SOC 2, taught by differentiator rather than contents. A baseline is a floor, not a fit.• Data protection methods — DRM, DLP, CASB, tokenization and masking — and why not one of them would have caught this. Every one reads a content flow.• Multi-tenancy and shared responsibility, and the control each side assumed the other already owned.• The crossover, named out loud: "should we accept this?" is Domain 1. "How is it enforced?" is Domain 3. "What does this data require?" is 2.6, and that is this episode.• Four CISSP practice questions and the trap inside each one. Question two is the one that gets people.The line to carry into the exam room: Domain 2.6 does not ask you to list encryption types. It asks which controls this data, in this state, in this environment actually requires — and then whether anybody owns them as requirements.LINKSFree CISSP Essentials:https://www.cisspcybertraining.com/free-cissp-self-studyAll episodes and the written ...
    Show More Show Less
    43 mins
  • CCT 376: Investigation Types and the Device Behind the Television (Domain 1)

    CCT 376: Investigation Types and the Device Behind the Television (Domain 1)
    Oct 26 2026

    Send us Fan Mail

    A company found a concealed recording device in the room where its executives meet. They pulled it, imaged it, reviewed the camera footage, went through the employee's internal tool usage, found a second device in a bag he had left in another room, terminated him and referred the matter to the FBI.

    Every one of those steps was reasonable. And somewhere in the middle of that list, the investigation stopped being theirs.

    This episode is CISSP Domain 1.6 — requirements for investigation types. It is five types on one line of the exam outline with no tools in them, and the exam asks about it anyway.

    At the start the company was running an administrative investigation: their building, their equipment, their employee, their policies, and a standard of proof that was their own. By the end a federal case was running alongside it, with a standard they do not control and evidence rules they are not a party to. Nobody announces that switch — and four things change the moment it happens: the standard of proof you must meet, what you have authority to collect, whether what you gathered can be used, and who you are permitted to tell. All four change retroactively, across everything you already collected.

    In this episode:

    · All five investigation types — administrative, criminal, civil, regulatory, industry standards — and what each one can actually do to you


    · Why the type follows whose AUTHORITY the inquiry runs under, not the conduct and not the severity


    · Burden of proof by type, and why administrative is the one standard the organization sets for itself


    · Chain of custody worked step by step from the real case, including the bag that cannot be un-opened


    · Why a forensic image that produced no readable data is still a finding, and why process produces admissible evidence while content produces a conclusion


    · The five characteristics of evidence, and why only four of them are properties of the evidence


    · Civil preservation: the duty attaches when litigation is reasonably anticipated, not when a complaint is served


    · Regulatory: the regulator sets the scope and can compel production, so your own investigation discharges nothing


    · Industry standards: a contractual obligation, where the contract names who is permitted to do the work


    · What a manager decides before any of it — naming the type out loud, setting the referral trigger in advance, and collecting as though the type will change


    It closes with four scenario questions, spread deliberately across all five types. Two are set inside the real case and two are explicitly transposed to a different organization. Question three is the one that catches well-prepared candidates: its trap is the answer the most level-headed person in the room usually gives.


    A note on the case: a former engineer has been arrested and charged by criminal complaint. He has not been convicted, and everything about his conduct is an allegation. The company has said it has no indications that model weights, source code or customer data were accessed.


    Source: U.S. Department of Justice, Office of Public Affairs press release, October 2026.


    Newsroom: https://www.justice.gov/news


    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox.


    Go to CISSPCyberTraining.com for the full question bank, the domain walkthroughs, and the CISSP Sprint Cohort.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    42 mins
  • CCT 375: The Malicious Workflow Was Already There (CISSP Domain 8.2)

    CCT 375: The Malicious Workflow Was Already There (CISSP Domain 8.2)
    Oct 19 2026

    Send us Fan Mail

    A “boring” GitHub Actions workflow file should never be able to empty your secrets vault, yet that is exactly what the Ghost Action campaign shows. We walk through GitGuardian’s research and the real mechanics of how attackers use stolen but valid developer tokens to add or modify workflow YAML, scrape secret names from your own repo, and exfiltrate CI/CD secrets to an external endpoint. The scary part is not exotic malware, it is normal automation doing what it was designed to do.

    From a CISSP Domain 8.2 perspective, this becomes a lesson in securing the development ecosystem: repositories, pipelines, toolchains, and the endpoints that build software. We unpack the trap many teams fall into during incident response rotating secrets but failing to revoke the credential that injected the workflow, or failing to remove the malicious workflow entirely. If the attacker keeps write access, you may have automated their next theft. We also dig into the governance question that changes budgets and outcomes: who owns the pipeline, not who operates it.

    We then connect the dots to modern development realities, including AI coding tools. We cover risks like insecure generated snippets, hallucinated vulnerabilities, dependency confusion, and why an AI assisted editor should be treated as a privileged endpoint based on what it can reach. You will also get a clean mental model for SAST, DAST, IAST, and SCA, plus concrete controls like least privilege build identities, short lived scoped credentials, signed or pinned build steps, separation of duties, and logging that someone actually reads.

    If you are studying for the CISSP or leading a secure SDLC program, listen through, take notes, and then share this with the person who “owns” your CI/CD pipeline. Subscribe, leave a review, and tell me what control you would implement first.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    49 mins
  • CCT 374: They Had Backups, They Could Not Reach Them. (CISSP Domain 7.10)

    CCT 374: They Had Backups, They Could Not Reach Them. (CISSP Domain 7.10)
    Oct 12 2026

    Send us Fan Mail

    495 organizations woke up and could not get to their servers. Railways. A prefectural police force. A food logistics company that could not receive or ship goods. All on the same cloud provider, all locked out at once.

    Then the provider said this, in writing: "At this time, our view is that data restoration will only be possible from backup data held by the customer themselves."

    Read that again. You are getting your data back from your own backups — and for some of those customers, the backups were sitting in the same cloud that had just gone dark.

    This episode is CISSP Domain 7.10 — implement recovery strategies — and it is the subdomain people assume they already know, because everybody has backups. Almost nobody has asked the second question, which is what else has to be working for them to reach those backups.

    You keep a spare key to your house. Smart. The only question that matters is where you keep it, and inside the house is a backup you cannot get to on the one day you need it.

    We cover RTO versus RPO versus MTD — which number means what, and which control actually satisfies each one, because candidates swap the first two constantly. Backup storage strategies across onsite, offsite, cloud, air-gapped and immutable, and why "offsite" is not a distance. Recovery site tiers from cold through hot, sized by RTO, plus the two nobody revises. Reciprocal agreements and the three ways they fail. Resource capacity agreements, and why a hot site contract can still leave you in a queue. Why high availability is not a recovery strategy, and why synchronous replication copies corruption as faithfully as it copies good data. Shared fate, including the version everybody misses — shared credentials. And the untested restore, where your real recovery time actually comes from.

    Then four practice questions set inside the same scenario. Question three is the one that catches well-prepared candidates, and I say so before I ask it.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox. Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!

    Source: Cybernews, "Japanese cyberattack hits 495 organizations, railways and police" — https://cybernews.com/security/japanese-cloud-cyberattack-railways-police-495-organizations-idcf/

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    38 mins
  • CCT 373: An AI Agent Was Told No and Got In Anyway (CISSP Domain 6.2)

    CCT 373: An AI Agent Was Told No and Got In Anyway (CISSP Domain 6.2)
    Oct 5 2026

    Send us Fan Mail

    An AI agent gets blocked by access controls, then calmly finds another way in anyway and that is the wake-up call. I use a recent Hacker News story about an automated agent bypassing an Australian government health portal to dig into what CISSP Domain 6.2 is really testing: not your ability to recite a list of techniques, but your ability to manage authorization, scope, and rules of engagement so a “test” does not turn into an intrusion.

    We break down why the portal controls could still be “working as configured” while the outcome is still unacceptable, especially when the client is autonomous and treats refusal as an obstacle instead of an answer. I map the scenario to a simple locksmith model: the same tools and actions can be legitimate with a signed work order, or criminal without one. From there, we get concrete about what must be written down, including in-bounds systems, forbidden actions like writing or persistence, stop conditions, evidence handling, time windows, and a named human point of contact on both sides.

    Then we translate the messy reality into clear exam thinking: vulnerability assessment versus penetration testing, black box versus white box versus gray box, and the commonly missed tools like misuse case testing, synthetic transactions, coverage analysis, and interface testing. I also clarify the difference between a penetration test, a red team engagement, and breach and attack simulation, so you can match the method to the question. We close with CISSP-style practice questions that reinforce triage priorities, engagement selection, and how to extend policy and accountability to AI agents acting on your organisation’s behalf.

    If you want more Domain 6.2 clarity and fewer distractor traps, subscribe, share this with a study partner, and leave a review so more CISSP candidates can find the show.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    37 mins
  • CCT 372: Stolen Sessions and Why MFA Never Saw Them (CISSP Domain 5.6)

    CCT 372: Stolen Sessions and Why MFA Never Saw Them (CISSP Domain 5.6)
    Sep 28 2026

    Send us Fan Mail

    A stolen password is annoying. A stolen session token can be invisible, valid, and instantly profitable. Today we dig into a real warning sign from Okta threat intelligence: infostealer malware lifted live session tokens from browsers, and thousands of Google sessions were still working weeks later. No MFA prompt. No brute force. Just a legitimate session replayed by the wrong person, with real dollar damage through unauthorized usage and credits.

    We use that story to sharpen the CISSP Domain 5.6 mindset around implementing authentication systems and, more importantly, validating tokens after sign-in. I walk through why authentication and token validation are different security functions with different “owners,” why forcing password resets does not invalidate an attacker’s existing session, and what a token signature does and does not prove. Then we get practical: audience claim checks, expiration and token lifetime ceilings, scope validation, and why “skipping the audience check breaks nothing in testing” is exactly how breaches scale.

    We also cover the controls that shrink risk when you cannot reliably detect theft: short access token lifetimes, narrow scoping to limit blast radius, hardware-backed signing key storage, and automated key rotation with defined crypto periods. To lock it in, we run through four CISSP-style questions and explain the traps so you can answer like a risk-focused manager, not a spec reciter.

    Subscribe for more CISSP exam training, share this with a teammate who owns IAM, and leave a review so more candidates can find the show.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    33 mins
  • CCT 371: Secure Communication Channels and Who Is Really On Your Call (Domain 4.3)

    CCT 371: Secure Communication Channels and Who Is Really On Your Call (Domain 4.3)
    Sep 21 2026

    Send us Fan Mail

    One video hotline feels like a single, simple conversation until you trace the call path and realise there may be seven companies involved in making it work. That’s the spark for this training-focused breakdown of CISSP Domain 4.3 secure communication channels, using the viral AI “actress hotline” story to show how modern voice and video collaboration really behaves behind the curtain.

    We start with a practical analogy: you think you’re transacting with the waiter, but your meal passes through a hidden chain of people you never met. The same thing happens with telephony, video conferencing, contact centres, telehealth platforms, transcription tools, AI response generation, and cloud infrastructure. Even when every vendor is legitimate, contracted, and disclosed, your security model can fail if it only accounts for the one company you can see.

    From there, we get concrete about what CISSP candidates are tested on: who can join a call, what services are attached (recording, transcription, analytics), what survives after the call, and where trust boundaries actually sit. We also tackle a classic trap: encryption in transit can stop interception, but it does not prevent authorised intermediaries like transcription providers or model services from decrypting and processing content. Finally, we connect the dots to retention “clocks” and transborder data flows, including how Domain 4 channel design intersects with Domain 1 legal transfer mechanisms and accountability.

    If you’re studying for the CISSP exam or building a real-world secure communications programme, you’ll leave with a clearer mental model and a set of exam-style questions you can use right away. Subscribe, share this with a fellow CISSP candidate, and leave a review so more security pros can find the show.

    Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

    Join now and start your journey toward CISSP mastery today!
    Show More Show Less
    30 mins