Recently, I've been discussing a rather intriguing topic with quite a few people: Level 3 Classified Protection (MLPS 2.0 Level 3).

Initially, my attitude toward this whole thing was very simple: What kind of bizarre relic in the field of information security is this? We spend hundreds of thousands of yuan on it, once a year. Many organizations pursue Level 3 Classified Protection, yet it involves neither code auditing, nor threat modeling, nor mapping out the service tree, nor implementing zero trust, nor upgrading software that hasn't been touched in eight hundred years, nor even checking whether your permission model has completely rotted. Instead, it’s all about buying equipment.

One firewall, one bastion host, one log auditing system, one database auditing system, one internet behavior management unit, and a few more flashy metal boxes. Bam, the Level 3 Classified Protection package.

file

In the past, seeing this setup would instantly spike my blood pressure, because the concept of "security" in my mind is completely different. My servers can all run a unified, streamlined, and fully controlled Linux system; base images are compiled by myself; containers are built by myself; the software supply chain is managed by myself; Authentik handles identity authentication for the entire organization; high-privilege accounts use FIDO2/YubiKey; full-disk encryption is enabled; all links enforce TLS; wherever declarative management is possible, manual changes are strictly avoided; permissions, auditing, monitoring, alerting, and On-call processes are all embedded into the system design.

I need to know exactly where a request goes after it hits the browser: which layer of CDN it passes through, which reverse proxy it hits, which ingress it reaches, which container it lands in, what credential it uses, which database it accesses, and finally, which disk the data is written to. In other words, true security requires you to understand the entire system. It is not a piece of equipment; it is a system property.

Yet after I implemented all of this, people would come over and ask: Do you have a bastion host? No. Do you have a database auditing device? No. Do you have some specific box? No. Then you are not secure.

Me: ?

This is particularly absurd.

Later, someone told me: Anduin, you misunderstood one thing

Once, when I was venting my frustration about all this stuff, someone suddenly said something to me: “MLPS (Multi-Level Protection Scheme) was never designed for people like you.”

I paused. Then he said: “MLPS is designed for water treatment plants.”

It suddenly clicked for me.

The entities I had in mind when thinking about regulatory targets were Google, Cloudflare, Microsoft, or a software company with a full DevSecOps capability. But if I were the state, what do I actually need to regulate? It’s XX County People’s Hospital, XX City Water Utility, XX Vocational and Technical College, a third-tier subsidiary under XX State-Owned Enterprise, XX District Traffic Management Platform, a traditional manufacturing plant, a local public institution.

In the IT department of these organizations, there might be only three people in total. One fixes the printers, one installs Windows, and the last one got promoted to network administrator because they know how to use ping.

Then you walk in, slap a set of standards on them: TPM 2.0, Measured Boot, FIDO2, Workload Identity, mTLS, Immutable Infrastructure, Policy as Code, Reproducible Build, SBOM, Remote Attestation, eBPF Runtime Detection, and then you say: “Final acceptance by year-end.”

That’s not called information security development. That’s called a mass extinction event for the national IT industry. The next day, all the water plants across the country stop delivering water so everyone can collectively start studying SPIFFE.

file

So from a regulator’s perspective, the problem suddenly looks completely different. Level 3 MLPS might not be intended to lift an organization that’s already scoring 90 up to 98. Its primary job is to force the massive number of organizations across the country that are scoring 5, 10, or 20 up to 60.

Once you think about it that way, a lot of things suddenly make sense.

Some organizations, if there were no MLPS requirements, genuinely wouldn’t even bother buying a firewall. No server logs, no asset inventory, accounts not deleted even three years after employees leave, databases exposed directly on the public internet, admin / 123456, former employees still able to log in via VPN, and the data center key might just be hanging on the door frame. In such places, if you try to talk to them about zero trust, they don’t even know “who has the root password for the servers.”

So what MLPS does first, in essence, is draw a very rough passing line for the whole society: you must have a firewall, you must keep logs, you must manage accounts, you must segment your network, you must be able to investigate security incidents at least, you must have documented policies, and someone must be accountable when something goes wrong.

Are these requirements useful? Of course they are. They are extremely useful for an organization with a security maturity score of only 10.

The Real Problem Lies In: Security Must Be "Accepted"

But once you dig a bit deeper, things start to get really interesting.

Security is actually a hidden variable that is very difficult to observe directly. Suppose the true security level is denoted by S. Regulators simply cannot walk up and ask, “Hello, please prove that your S is 83.7.”

So they have to rely on proxies: devices, logs, policies, documentation, processes, configurations, personnel, and audit records. Ideally, the better these are done, the higher the security level is likely to be. In other words:

Proxy ↑ => Security ↑

This approach is perfectly reasonable.

Here’s the problem. The moment the government issues a document declaring that these proxies are the assessment criteria, the rules of the game change instantly. Because once any metric becomes a target for evaluation, it ceases to be a good metric—a classic case of Goodhart's Law.

What companies need to optimize for shifts subtly from “how to make the system truly secure” to “how to demonstrate compliance with these security metrics at the lowest possible cost.”

As a result, an extremely stable industry chain naturally forms: Regulators need replicable, quantifiable, and accountable levers; these requirements must be verifiable; the requirements get broken down into products; vendors launch “Level 3 Compliance Packages”; integrators show up with checklists to rectify issues; clients realize that building their own security capabilities is far less hassle than simply buying a package; assessment agencies have become accustomed to these standard answers; and the next client just copies the same approach.

In the end, Level 3 compliance easily degenerates into: buying a bunch of equipment + writing a pile of documentation + preparing for inspections.

The most fascinating part is that this system doesn’t even necessarily involve any bad actors.

Everyone Is Completely Rational

The regulators are entirely reasonable. They oversee tens of thousands, hundreds of thousands, or even more organizations. How could they possibly send a Linux Kernel Hacker to audit sshd_config at every single one? What they need is something replicable, trainable, verifiable, documentable, and accountable. The box is there, the green light is on, the invoice is there, the remediation report is there, the signatures and seals are there. It’s perfect.

The vendors are also entirely reasonable. The regulators need a capability, so I productize that capability. You need logs? I sell log auditing. You need boundaries? I sell firewalls. You need operational auditing? I sell bastion hosts. This is even the most normal market behavior imaginable.

The client’s leadership is also entirely reasonable. Why would I bet on a security system built by our own few engineers? I spend money to buy the most well-known equipment in the industry, pass the assessment, and get the report stamped. If something really goes wrong later, at least I can say: “I remediated as required, I purchased the equipment, I completed the assessment. The attacker was just too strong.”

In a sense, they are buying not just a firewall, but also a disclaimer.

Frontline operations are even more reasonable. You want me to change all my SSH to hardware authentication? I have two hundred Bash scripts with hardcoded passwords. Who is going to change them? Who will take the blame if they break? It’s 3 AM and there’s a live incident. Normally, it’s just one ssh root@server. Now you want me to jump through the bastion host, open a browser, install a plugin, fumble for a key, get approval, and then jump in again? If I can bypass it, I will.

For an ordinary employee, making the system more secure benefits the company; making the system more cumbersome makes the pain personal.

So, in the end, the most absurd scenario appears.

Suppose tomorrow the standard suddenly states: “All employees must use YubiKey.” I guarantee many organizations will end up like this: The procurement department rushes to buy five hundred, registers them as assets, employees sign for them, and they get stuffed into drawers. The day before the experts come for inspection, IT shouts in the group chat: “Everyone, bring that USB-drive-like thing we distributed last time tomorrow! The experts want to take photos!”

After the photos are taken, they unplug it and continue with ssh [email protected], password: 114514.

This is what they call: Buy it and it’s safe, power it on and it’s compliant.

Tools Are Not Security

This is also a viewpoint that I hold with increasing strength: security devices are not security, security features are not security, and even security technology itself is not security.

YubiKey is incredibly powerful, but "buying a YubiKey" does not equal "phishing protection." What is truly effective is that FIDO2 is enforced, password authentication is genuinely disabled, recovery processes cannot be bypassed, high-privilege systems are all integrated into a unified identity, and consistent policies are enforced across SSH, VPN, Web, and Cloud Console. Additionally, credentials can be revoked after a device is lost, and administrators do not have magical backdoors. Only when all these elements are connected does a true security property emerge.

Otherwise, a YubiKey is just a very expensive, very polished USB drive keychain.

The same applies to bastion hosts. What I find most frustrating right now is certain bastion hosts. Internal networks and VPNs still allow direct SSH access, but compliance requirements mandate the use of a bastion host. As a result, the actual responsibility of this bastion host has become "proving that we have a bastion host."

It may not even serve as a true security boundary. On the contrary, due to this broken client, browser plugin, local invocations, and proprietary protocols, it may end up adding a whole new attack surface to my infrastructure.

Every time I use certain domestic bastion hosts, I get a feeling: my system was originally healthy, but now, to prove it is healthy, I have to insert three catheters into myself first.

So who actually broke things?

Many people like a saying: "The intent above is good; it's the execution below that goes wrong."

I can probably only agree with that about 75%. For the remaining 25%, I think the situation is not that simple.

This is not a simple story of "a good policy being twisted by bad executors," because from start to finish, every layer is doing the right thing according to its own incentives. Regulators want auditability, vendors want productization, clients want liability protection, assessment agencies want scalable delivery, and frontline employees want minimal hassle.

When you put these five local optima together:

local optimum × 5

You get an incredibly grand:

global shitshow.

Together, we built a massive stage of compliance theater. On stage, the firewalls are on, the bastion hosts are on, log auditing is on, the big screens are flashing, policy documents are neatly stacked in the cabinets, experts take their photos, reports get stamped, and everyone leaves satisfied.

Then, on some server in the back:

PermitRootLogin yes

PasswordAuthentication yes

The password hasn't been changed in three years.

This is the part I think is most worth discussing.

Is Zero Trust the Answer?

Not exactly.

I used to easily swing to the other extreme: since traditional perimeter security is so dumb, let's go all-in on zero trust. The network is untrusted, identity is trusted, endpoints are standardized, hardware-based authentication, full-disk encryption, declarative infrastructure, least privilege, short-lived Credentials, and locking down every single component.

Technically, it’s exhilarating.

Then I suddenly realized that if the government were to actually mandate a national standard based on my proposal tomorrow, the IT departments across the country would likely rush over the next day and hang me from a streetlight.

Because what counts as “best practice” for a mature technical team is complete gibberish to a county-level water utility company.

And more importantly: who is doing the acceptance testing?

Imagine asking an evaluation expert to verify: “After an attacker has compromised any employee’s Credential, taken over any office endpoint, and gained a Remote Code Execution (RCE) on a standard Kubernetes Workload, they still cannot laterally move to access the core production database.”

This statement carries infinitely more security significance than “whether a bastion host is deployed,” but first, an expert might take three days to verify it. Second, the conversation would go like this: “Is it deployed?” “Where?” “Here.” “What about the invoice?” “Here.” “Okay, next item.”

And it’s over in ten minutes.

So this is actually a nearly unsolvable paradox: The closer a question gets to true security, the harder it is to standardize, quantify, and regulate; whereas the easier something is to standardize, quantify, and regulate, the more susceptible it becomes to being turned into KPIs, procurement items, or mere performance.

I Can't Even Come Up with a Truly Good Solution

This might be the most frustrating—and yet the most interesting—part of my research on this issue.

I’m particularly good at criticizing things. This architecture is garbage, that product is garbage, this standard is outdated, that process is bureaucratic. If you asked me to design a company’s security framework, I’d have ten thousand different solutions in my head.

But now, if you put me in the seat of a regulatory body and ask me to design an information security oversight system that can cover hospitals, schools, state-owned enterprises, factories, water treatment plants, and internet companies across the entire country—while keeping costs acceptable, enabling scalable audits, and avoiding becoming mere formalism—I fall silent.

Because I genuinely don’t know.

You suggest eliminating device checklists and accepting everything based on outcomes? Then the assessment costs will explode. You suggest accepting everything based on attack results? That’s equivalent to conducting a Red Team exercise for every organization in the country every year. You suggest allowing enterprises to freely prove that “we adopted more advanced equivalent measures”? Then who decides what’s equivalent? That would require highly specialized experts. You suggest raising the skill level of assessment experts? Then we hit the limits of expert availability and cost. You suggest continuing to quantify everything? Goodhart's Law will immediately resurface.

Even if you design a very advanced new metric, vendors will come out with a “Zero Trust Level 3 MLPS All-in-One Appliance” within three months.

Plug it in. Half a million. Green light. Supports Guomi. Supports AI. Supports large screens. When the expert arrives, they can generate a Word report with one click.

And then it all starts over.

Thinking this far through, I even feel a bit despairing.

Current Assessment of Level 3 Classified Protection

I still believe it is profoundly backward, rigid, and formalistic in many respects. In real-world practice, there are indeed severe issues of "boxification," "procurement-driven compliance," and "compliance prioritized over actual security." If I had to use one of those garbage bastion hosts myself, I’d still curse. When the situation calls for it, my brain still generates ten thousand impulses to find a way around it.

But I no longer simply say: “Level 3 Classified Protection is a pile of meaningless garbage.”

Because without it, China’s most elite companies might not have been affected at all—they were already doing security properly. The ones truly impacted are the vast number of organizations that originally scored only 10 or 20 out of 100.

At least now, someone is forcing them to buy a firewall, keep some logs, sort out their accounts, write an emergency response plan, know which servers they have, and avoid the situation where, when something goes wrong, they can’t even find their logs.

For an organization that originally scored only 10 points, moving from 10 to 60 is already a massive improvement.

So if you ask me now whether Level 3 Classified Protection is good or not, my answer would be: It is a very important 60-point system.

The truly absurd thing is not that the state designed a 60-point passing threshold, but that society gradually started to mistake “passing this 60-point exam” for “being secure.”

Even worse, it forces someone who has already achieved 90 points to spend hundreds of thousands of dollars buying a set of 60-point standard answers, just to display them in the server room with green lights blinking, in order to prove they are secure. That is what I really want to criticize.

But if you ask me how to solve it? I don’t know.

And the more I think about it, the more I feel that perhaps every system in the world that tries to turn complex engineering capabilities into administrative regulatory metrics will eventually grow into something like this, to varying degrees. This may not just be a “Level 3 Classified Protection problem.” It is the inevitable cost humans pay when trying to manage a fundamentally dynamic, adversarial, and directly unobservable complex system using tables, metrics, procurement, audits, and stamps.

In the end, we end up with a huge theater stage. The play is real, the actors are real, the money is really spent, and this stage does indeed block some attacks. But never mistake the fact that all the lights on the stage are on for the idea that the hackers outside the city walls have already clocked out.