CISSP Data Security Controls: The Third State of Data Nobody Tests You On

One hundred and fifty-five answers went to the wrong people. Nobody broke in. No attacker, nothing taken.

For about two weeks, if your question to a hosted AI model was too big, the system handed you back pieces of somebody else's.

And here is the part that should stop you. Encryption at rest and encryption in transit were never going to touch this one. Not because anything was wrong with them. Because neither has a single thing to say about data while it is being used.

Three states of data. At rest, in transit, in use. You have seen that list a hundred times. So when was the last time anybody tested you on the third one?

What actually happened

In late August, Cloudflare launched the GLM-5.3 model on its Workers AI service. Last week it published its own writeup, which is where every number below comes from.

The model was advertised as accepting a context window of just over one million tokens. The memory pool built behind it — the prefill KV cache — held about six hundred and eighty thousand, smaller than the thing it was advertised to hold.

Think of that pool as a scratch pad on a shared workbench: in a well-run shop somebody wipes it before the next person sits down. The pad is memory, and wiping it is the control.

When a request came in too big, the system did the right thing and marked it rejected. But it did not stop there. It swapped the request for a one-token placeholder and sent the cache downstream anyway. The next stage read GPU memory pages that still held an earlier request's data, and returned the result with an HTTP 200. Not an error. A success.

One hundred and fifty-five responses were affected, every one from a prompt over the pool's limit. Cloudflare published no count of affected customers, only that a small number were involved — so that figure counts responses, not people. It found no evidence of deliberate exploitation, and the misconfigured value and the engine behavior both sat in the hosting stack rather than with the model's makers.

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, added a deployment check on pool size against context length, and published the whole thing itself.

The reframe: two controls out of three

At rest and in transit are cryptography questions. In use is an isolation question.

Data in use is data loaded into memory and being operated on, normally readable so the work can happen. The controls that answer it differ in kind: memory isolation so each request gets its own pages, zeroization of the buffer between requests, object reuse controls so a new subject never receives a prior subject's residue, and confidential computing, where an enclave keeps memory encrypted in use. That last one is the exception that keeps "cryptography alone does not reach data in use" honest.

So an organization can encrypt everything it stores and everything it sends and still hand one tenant's data to another. Not a gap in the encryption — a gap in the question somebody asked.

They knew

The easy version of this episode is that somebody missed a number. That is not what happened. Cloudflare says, in its own postmortem, that it was aware of the mismatch before launch, that it assumed the engine could gracefully handle the difference, and that it validated — this is the sentence — HTTP response codes and engine performance at long contexts.

So they tested. They checked that an over-length request came back with the right status code and that the system stayed fast. Both passed.

What nobody tested was the answer coming back.

Not a secret, and not an oversight. An assumption standing where a control should have been — and the test that would have caught it looked at the envelope instead of the letter.

A control is not a control because of what it is called. It is a control because of what fails when it is wrong.

Now do what a manager would do. Go find whoever owns a value like that in your own shop — a cache size, a queue depth, a retention period — and ask whether it is a security setting. Not one of the answers will say the word security. It is a capacity parameter in a performance document, reviewed as capacity: load, latency, cost. What it governs is whether one tenant's data stays separate from another's, in use.

Read the subdomain again — determine data security controls and compliance requirements. It asks which controls this data, in this state, requires, and then whether anybody owns them as requirements. The second question is where organizations lose.

Nobody owned this one. That is the whole episode.

Name the boundaries too. "Should we accept this?" is Domain 1 governance. "How is it enforced?" is Domain 3 architecture. "What does this data require?" is Domain 2.6 — the decision, and the record of it.

The one line to carry into the exam room

When a stem describes a failure, do not ask which security tool was missing. Ask which state the data was in — that narrows your control set before you read an option.

Try one of the questions

This is question four from the episode, verbatim. Question two catches more people, and I am keeping that for the video. Four catches the ones who understood everything above and then answer too narrowly.

The incident is closed. The cache pool has been raised to roughly twice the advertised context length, the serving engine now retires rejected requests at the admission queue before any cache transfer, and the postmortem has been published.

The board asks which SINGLE change will most reduce the likelihood of a similar exposure in a future deployment. What do you recommend?

A. Require every deployment to check the memory pool is never smaller than the advertised limit

B. Raise the cache pool further so the margin above the advertised context length is larger

C. Run a penetration test against every new model before it is released to production

D. Require the model provider to contractually warrant the advertised context window

The answer is A.

Why A. The board asked about recurrence, not this instance. Raising one number fixes one model; writing that check into the deployment process fixes every model that ships after it. In NIST's vocabulary that is supplementing the baseline — one of the six tailoring actions in SP 800-53B, for when no baseline contemplated your environment. It gives the value an owner, a review gate and evidence — which is what turns a performance setting into a control.

Why B is the trap. B is the correct ENGINEERING fix. It is already deployed. It is what actually stopped this, and an engineer picks it in two seconds without being wrong about the engineering. Then it turns: one value, one model, no owner, no review gate, no evidence. The next model ships next quarter and nothing in the process prevents the same mistake. The exam loves an option that is a true statement and an insufficient answer.

Why C and D are wrong. Do not eliminate C by saying a penetration test is not a control — NIST SP 800-53 CA-8 is literally a control by that name. It loses on being point-in-time rather than a process gate, and because a test only finds what somebody thought to list. And D moves the problem outside the building: the advertised context length was accurate, so no vendor warranty reaches a value in your own stack.

Where to go next

Start with free CISSP Essentials: 360 practice questions, a Domain 1 diagnostic, and the slides from this episode. It is where you start, not everything you need.

Accelerator and Pro add the full question bank and the domain walkthroughs, and Pro adds live office hours. Pro and Cohort members also get the CPE Insider sheet every week.

If you have an exam date and self-study is not getting you there, the CISSP Sprint Cohort is 8 weeks, live, paced to your exam date, with an accountability partner. Cohort 3 starts November 17.

The full episode is on the podcast page. Last week: CISSP Domain 1.6 — Investigation Types.

Source: Cloudflare's incident writeup, late October 2026 — https://blog.cloudflare.com/kv-cache-exposure-remediation. Reported by Gadi Evron of Knostic via HackerOne.

Shon Gerber, CISSP — former Commander, 177th IAS. Former CISO, fractional CISO, adjunct professor at WSU, founder of CISSP Cyber Training.