Cyber Security Frameworks Demystified Part 9 - ISO/IEC 15408-1

In this episode, we break down what ISO/IEC 15408-1 is, how it provides an internationally recognised framework for evaluating the security of IT products and systems and why it plays a critical role in building trust, assurance and compliance in today’s cyber security landscape. 

Duration: 0:22:34

Visit https://www.wecyberyou.com for more cyber security education, resources and awareness content like this. 

Thank you for listening. 
WeCyberYou! Team

Transcript

SPEAKER_00 0:00

Imagine you are um the federal procurement officer, right? Right. And you're tasked with buying the software that will protect the entire national power grid.

SPEAKER_01 0:09

Oh wow. No pressure at all, right?

SPEAKER_00 0:11

Yeah, exactly. No pressure. The stakes are just well, they're almost unfathomably high. And a vendor sits across from you, slides this, you know, glossy brochure across the desk and promises their new enterprise firewall is completely unhackable.

SPEAKER_01 0:26

Which is a bold claim.

SPEAKER_00 0:28

Right. So do you you just take their word for it? Do you uh sign a multimillion dollar contract based on a slick marketing pitch? Welcome everyone. I'm so glad you could join us today. You are listening to the WeCyber You Unlock podcast.

SPEAKER_01 0:40

I love that scenario because it really sets up why this stuff matters.

SPEAKER_00 0:43

It really does. Today we are wading into something that touches literally every digital interaction you have, even if you never, you know, see it operating in the background. We have a stack of excerpts from a really fascinating document titled Foundations of the Common Criteria Security Framework.

SPEAKER_01 0:58

Yeah, and specifically we're looking at a standard called ISO 154081 today.

SPEAKER_00 1:04

Yes, exactly. And our mission for this deep dive is to basically decode how governments and, well, massive enterprises actually verify that the technology we all rely on is truly secure. We want to move past the marketing hype, right?

SPEAKER_01 1:20

Well, absolutely. The hype is everywhere.

SPEAKER_00 1:22

It is. So we want to look at the actual mechanics, the rigorous, you know, laboratory testing of digital trust. Okay, let's unpack this.

SPEAKER_01 1:29

Aaron Powell The scenario you just described with the power grid, um, that is the ultimate nightmare for any infrastructure planner. I bet. And overcoming that nightmare requires a massive, globally recognized system. Because when a company sells a firewall or an operating system or, you know, a piece of encryption software, they are highly motivated to tell you it is secure.

SPEAKER_00 1:48

Aaron Powell Right, because they want to make the sale.

SPEAKER_01 1:50

Exactly. But from a global infrastructure standpoint, taking their word for it is just a recipe for disaster. We need a systematic, universally agreed upon methodology to, well, to prove those claims.

SPEAKER_00 2:02

Because before this, it was just the Wild West, right?

SPEAKER_01 2:05

It really was. Historically, before frameworks like this existed, the tech world was entirely fragmented. The United States had its own testing standards, Europe had completely different ones, and it created these massive trade barriers.

SPEAKER_00 2:19

Oh, interesting. So it was an economic issue too.

SPEAKER_01 2:21

Very much so. Yeah. A product deemed secure in Washington might be totally rejected in Berlin simply because the testing laboratories use completely different metrics.

SPEAKER_00 2:30

Aaron Powell That makes perfect sense. I mean, if I buy a physical padlock for my shed, I can hold it in my hand. I can uh feel the weight of the metal, and I can intuitively judge its strength.

SPEAKER_01 2:41

Right. You can see what you're buying.

SPEAKER_00 2:42

Exactly. But when a hospital system buys a complex software suite to protect patient data, they cannot just hold a USB drive and like gauge how heavy the security feels.

SPEAKER_01 2:52

Yeah, digital weight isn't really a thing.

SPEAKER_00 2:54

No, it's not. Yeah. They need a framework to translate that invisible code into verified trust. And according to our sources, that is exactly what the common criteria for information technology security evaluation provides.

SPEAKER_01 3:06

Spot on. And at the very bedrock of that common criteria is ISO 15408-1.

SPEAKER_00 3:13

Right. And there are three parts to this, right? Yeah.

SPEAKER_01 3:15

The standard is divided into three main parts, but part one is the absolute foundation. If you jump straight into the technical testing without a foundational rule book, you end up with chaos.

SPEAKER_00 3:25

Just a total mess of acronyms and metrics.

SPEAKER_01 3:28

Totally. You would have different laboratories using different terms, measuring different things, and essentially comparing apples to oranges.

SPEAKER_00 3:35

So part one is what gets everyone on the same page.

SPEAKER_01 3:38

Exactly. Part one establishes the general framework. It dictates the core concepts, the vocabulary, and the overarching structure for evaluating IT security.

SPEAKER_00 3:48

And just to be clear, this applies to what exactly?

SPEAKER_01 3:51

Oh, it applies to software applications, operating systems, network devices, and specialized security products like those enterprise firewalls we were talking about earlier.

SPEAKER_00 4:00

Okay, got it. So to make sure we are grounding this in reality for you, our listener, the other two parts build directly on this foundation. Part two covers security functional requirements, and part three covers security assurance requirements.

SPEAKER_01 4:15

Yeah, and we'll get into those a bit more in a minute.

SPEAKER_00 4:17

Right. But part one tells us how all these pieces fit together. I am um I'm trying to picture how this actually works in practice. Is ISA 15408-1 essentially like a building inspector's master manual?

SPEAKER_01 4:32

Oh, that's an interesting way to look at it. How so?

SPEAKER_00 4:35

Well, a building inspector's manual doesn't tell a contractor exactly how to build a house.

SPEAKER_01 4:47

Right. It doesn't care about the aesthetics or the specific materials necessarily.

SPEAKER_00 4:50

Aaron Ross Powell Exactly. Rather, it gives the overarching framework for how to evaluate if the house is safe to live in. It dictates the methodology for checking the foundation and measuring the load-bearing walls, completely regardless of the architectural style.

SPEAKER_01 5:04

That is a brilliant way to conceptualize it. The framework does not mandate a specific security architecture.

SPEAKER_00 5:10

Aaron Powell So it's not forcing everyone to build the exact same firewall.

SPEAKER_01 5:13

No, not at all. It does not dictate that a developer must use one specific encryption algorithm over another any more than your inspector demands the use of a specific brand of nails.

SPEAKER_00 5:23

That clears it up nicely.

SPEAKER_01 5:24

Instead, it creates a standardized global methodology for verifying whatever specific security claims a product is making. By establishing this rulebook, an accredited testing laboratory in Germany can evaluate a product and a procurement officer in Japan can completely trust the results.

SPEAKER_00 5:42

Aaron Powell Because they both understand and trust the evaluation framework itself.

SPEAKER_01 5:46

Exactly. They are speaking the same language.

SPEAKER_00 5:48

So instead of just looking at a list of terms, let's actually trace the journey of a product. Let's say I have just built a revolutionary new enterprise firewall, and uh I want to sell it to the government.

SPEAKER_01 6:00

Aaron Powell Okay, I'll play the role of the evaluator.

SPEAKER_00 6:02

Trevor Burrus Perfect. So I need to get it evaluated. How do the evaluators even know where to begin? Do they like test my entire company's network to see if my firewall is good?

SPEAKER_01 6:10

They absolutely do not test your whole company. That would be impossible. The very first step in the journey is defining the toe, the target of evaluation.

SPEAKER_00 6:18

The TOE, target of evaluation. Yeah.

SPEAKER_01 6:20

You have to draw a strict, unmistakable boundary around exactly what is being tested and what is excluded.

SPEAKER_00 6:25

So it's like fencing off the area of interest.

SPEAKER_01 6:27

Exactly. If you are selling firewall software that runs on a generic server, the toe might just be your specific software, not the physical server hardware it sits on.

SPEAKER_00 6:39

Oh, that makes sense. Because you didn't build the server, you built the software.

SPEAKER_01 6:42

Right. Defining the toe is crucial because if you don't know where the product ends and the rest of the world begins, you cannot accurately test it.

SPEAKER_00 6:50

Here's where it gets really interesting. Because once we have our toe, we hit the next two concepts, which are the absolute core of the testing process.

SPEAKER_01 6:59

Yep. The SFRs and the SARS.

SPEAKER_00 7:01

Right. We have SFRs, which are security functional requirements. The sources define this as what security features the product must have.

SPEAKER_01 7:08

Correct, the functional stuff.

SPEAKER_00 7:10

And then we have SARS, which are security assurance requirements. The sources define this as how well those features are tested and verified.

SPEAKER_01 7:18

Which is completely different from just having the feature.

SPEAKER_00 7:20

Exactly. And to make sure I am separating these mechanisms correctly in my head, let me throw another analogy at you. Is the SFR the heavy-duty deadbolt lock you install on the front door, while the SAR is a measure of how hard the evaluators actually tried to kick the door down to prove the lock works.

SPEAKER_01 7:37

What's fascinating here is how that perfectly captures the dynamic.

SPEAKER_00 7:40

Oh, really?

SPEAKER_01 7:41

Yeah. The functional requirement, the SFR, is simply a statement of capability. It's saying this door has a deadbolt or this firewall blocks specific IP addresses.

SPEAKER_00 7:53

This database encrypts passwords.

SPEAKER_01 7:55

Exactly. It is purely a feature list. But a feature list means absolutely nothing if the implementation is flawed.

SPEAKER_00 8:01

Right. If you build it badly, who cares what features it has on paper?

SPEAKER_01 8:04

Exactly. You could have a heavy-duty state-of-the-art deadbolt, but if it is installed on a door made of wet cardboard, the entire system fails the moment someone leans on it.

SPEAKER_00 8:14

Wow. Yeah. The lock functions perfectly in theory, but the assurance that it will protect the house is absolute zero.

SPEAKER_01 8:21

Exactly that. The SAR, the security assurance requirement, defines the depth, the rigor, and the intensity of the evaluation.

SPEAKER_00 8:29

So how hard they kick the door? Yes. Yes.

SPEAKER_01 8:31

In a laboratory setting, the SAR dictates the methodology of the attack. Did the evaluators just look at the code and nod? Did they run a basic automated scanning tool?

SPEAKER_00 8:41

Or did they get a battering RAM?

SPEAKER_01 8:43

Right. Did they bring in a team of elite penetration testers to spend three months reverse engineering the code, fuzzing the inputs, and really trying to break it? The SAR dictates the intensity of that scrutiny.

SPEAKER_00 8:55

That makes total sense.

SPEAKER_01 8:56

And to tie those locks and tests together, the framework uses two vital documents to map the journey.

SPEAKER_00 9:01

Aaron Powell Right, because the evaluators need a roadmap. This brings us to the PP and the ST. Man, so many acronyms today.

SPEAKER_01 9:09

Welcome to cybersecurity. So think of the PP, the protection profile, as a baseline standard for an entire industry category.

SPEAKER_00 9:16

Okay, so not a specific product, but a category.

SPEAKER_01 9:19

Yes. A group of cybersecurity experts, perhaps from multiple government agencies, might get together and declare any products claiming to be an enterprise firewall must meet this specific baseline list of functional and assurance requirements. They publish that list as a generic protection profile. It is completely product agnostic. It is essentially a generic job description for a firewall.

SPEAKER_00 9:43

Oh, I like that. A job description. Yeah. Then the vendor has to prove their specific product fits that generic job description. Trevor Burrus, Jr.

SPEAKER_01 9:50

That is the role of the ST, the security target. The ST is a highly detailed document written specifically for the product being evaluated. Aaron Powell Okay.

SPEAKER_00 9:58

So the vendor writes the ST.

SPEAKER_01 10:00

Yes. The vendor creates the ST and it acts as the product's resume. It says, here is our specific firewall. Here is exactly how it meets the generic requirements laid out in the industry protection profile, plus maybe a few extra custom features we built.

SPEAKER_00 10:13

Oh, so it connects the generic job description to their specific product.

SPEAKER_01 10:17

Yes. And the ST becomes the definitive binding map for the independent evaluators. They take the product into the lab and test it strictly against its own security target to ensure it delivers on every single promise.

SPEAKER_00 10:31

Aaron Powell That makes the process incredibly clear. You draw a boundary around the product, which is the TUE. You look at the industry baseline, the PP, you map your specific features in the ST.

SPEAKER_01 10:41

You've got it.

SPEAKER_00 10:41

Then the independent lab takes your feature list, the SFRs, and applies rigorous testing, the SARS, to see if the door holds up to being kicked.

SPEAKER_01 10:49

That is the whole process in a nutshell.

SPEAKER_00 10:51

But um after all that kicking, we need a way to grade the results.

SPEAKER_01 10:57

Right.

SPEAKER_00 10:57

The buyer needs to know the outcome. And that leads us to the evaluation levels, the security scorecard.

SPEAKER_01 11:02

The output of this entire journey is the evaluation assurance level or EEL. This is the certification grading system that ranges from EL1 all the way up to ELL seven.

SPEAKER_00 11:11

One to seven. Got it.

SPEAKER_01 11:12

And it is vital to understand that a higher EL does not necessarily mean the product has more security features. It means those features have been tested with exponentially more rigor.

SPEAKER_00 11:21

Our sources break down the scale clearly. EAL1 involves very basic testing. It provides a baseline level of confidence, mostly checking that the product functions as described in its basic documentation.

SPEAKER_01 11:33

Yeah, it's pretty rudimentary.

SPEAKER_00 11:34

Then we jump up to EL4, which the sources know as the commercial standard. It is the most common level for things like standard operating systems, enterprise firewalls, and mainstream corporate software.

SPEAKER_01 11:45

That's the sweet spot for most businesses.

SPEAKER_00 11:47

And then you have ELS 7, which is the absolute highest, most rigorous level of testing available under this framework. Higher levels equal greater confidence.

SPEAKER_01 11:55

Exactly.

SPEAKER_00 11:56

But looking at this scale, I have a logical pushback question. If EL7 is the most secure certification, and you know, we live in a world constantly under siege by sophisticated cyber threats, why isn't every product tested to EL7? Is it just too expensive and time-consuming for average companies?

SPEAKER_01 12:13

The short answer is yes, but the mechanics of why it is too expensive reveal a lot about how cybersecurity works in the real world.

SPEAKER_00 12:20

Okay, color me intrigued.

SPEAKER_01 12:22

It is a constant balancing act between risk, cost, and practicality. EAL7 is incredibly demanding. It requires formal mathematical verification of the product's design and source code.

SPEAKER_00 12:33

Aaron Powell Wait, hold on. How do you mathematically verify code? I thought coding was just, you know, typing commands.

SPEAKER_01 12:38

Aaron Powell Well, think about writing a geometric proof in high school. You remember those?

SPEAKER_00 12:42

Oh, yeah. Barely survived geometry. Trevor Burrus, Jr.

SPEAKER_01 12:44

Right. Well, you cannot just look at a triangle and say that looks like a right angle. You have to use formal logic to prove, step by step, that it cannot possibly be anything else.

SPEAKER_00 12:54

Oh wow. Okay.

SPEAKER_01 12:55

Normal security testing, even at high levels, is essentially bug hunting. You are searching a massive house trying to find a hidden set of keys.

SPEAKER_00 13:03

Which takes a while, but it's doable.

SPEAKER_01 13:04

Right. But mathematical verification is building a formal logic model that definitively proves the keys cannot possibly exist anywhere inside the house. There are zero gaps. Evaluators are using advanced mathematics to prove that vulnerabilities cannot exist within the defined scope of the code.

SPEAKER_00 13:21

Building a mathematical proof for millions of lines of software code sounds like it would take uh I mean that sounds like it would take years.

SPEAKER_01 13:29

It absolutely does. The time and financial resources required to achieve an EAL7 certification are just astronomical.

SPEAKER_00 13:36

So no startup is doing this.

SPEAKER_01 13:38

Definitely not. If you tried to put a standard commercial web browser or a basic corporate email server through an EAL7 evaluation, two things would immediately happen.

SPEAKER_00 13:49

What's the first one?

SPEAKER_01 13:50

First, the cost of the software would multiply by a hundred to cover the laboratory fees.

SPEAKER_00 13:55

Nobody's paying $1,000 a month for a web browser.

SPEAKER_01 13:58

Exactly. And second, the technology world moves incredibly fast. By the time a multi-year EAL7 evaluation was finally finished, the software would be completely obsolete.

SPEAKER_00 14:09

Oh man, the marketing department would be losing their minds. I can imagine the friction in a corporate boardroom over that.

SPEAKER_01 14:15

It happens all the time.

SPEAKER_00 14:16

The chief marketing officer wants to launch the new firewall today at a major tech conference, but the compliance officer says, no, we have to wait for the lab to finish.

SPEAKER_01 14:25

That exact friction is a daily reality in the tech industry. A standard EAL4 evaluation for a complex product often takes anywhere from six to twelve months in an accredited laboratory.

SPEAKER_00 14:36

And that's just for EAL4.

SPEAKER_01 14:38

Yeah. That is a massive delay for a commercial product cycle. That is why EAL4 is the recognized sweet spot for commercial standards.

SPEAKER_00 14:47

It's the balance point.

SPEAKER_01 14:48

Right. It involves methodical, independent testing of the product's design, deep source code review, and rigorous vulnerability analysis, but it stops short of demanding the painstaking multi-year mathematical proofs of EAL7.

SPEAKER_00 15:02

So EAL 4 gives a highly robust level of assurance that is appropriate for standard business environments without bankrupting the vendor or making the product obsolete before it even launches.

SPEAKER_01 15:12

Correct. EAL7 is strictly reserved for environments where the cost of a failure is absolutely catastrophic.

SPEAKER_00 15:18

Like what? What needs EL Heaven?

SPEAKER_01 15:20

We are talking about military command and control systems, top secret government communications networks, or, you know, the foundational controllers for a nuclear power plant.

SPEAKER_00 15:28

Okay, yeah. For a nuclear plant, you want the mathematical proof.

SPEAKER_01 15:31

Exactly. In those rare scenarios, time to market is totally irrelevant compared to absolute assurance.

SPEAKER_00 15:38

Okay, we have traced the journey. We understand the functional locks versus the assurance testing, and we understand how the EL scoring system grades the rigorousness of that testing.

SPEAKER_01 15:48

We've covered a lot of ground.

SPEAKER_00 15:50

We really have. Let's take all of this theory and put it into a real-world scenario because I want you, the listener, to see exactly why this framework matters to the infrastructure operating around you every single day. Let's walk through the specific example from our sources. A government buying a secure firewall.

SPEAKER_01 16:09

Perfect example. Imagine a federal agency needs to upgrade the perimeter defenses for a database housing millions of tax records.

SPEAKER_00 16:16

That's a massive target.

SPEAKER_01 16:17

Oh, it's a gold mine. They cannot just hop online, read some user reviews, and buy whatever software looks best. State-sponsored hackers are actively probing their networks 24-7.

SPEAKER_00 16:26

So the government puts out a procurement request and they mandate that any vendor bidding for the multimillion dollar contract must provide a firewall that is certified to at least ELO4 under the common criteria.

SPEAKER_01 16:38

Exactly. And when a vendor submits their firewall, the government agency does not have to spend months doing their own testing.

SPEAKER_00 16:45

Because the lab already did it.

SPEAKER_01 16:46

Right. They know that the product has already been through the ISO 15408-1 process. An independent, accredited third-party laboratory has taken the vendor's security target, examined the firewall's security functional requirements, and applied the intense security assurance requirements to test it.

SPEAKER_00 17:04

They kicked the door.

SPEAKER_01 17:05

Hard. They spent months trying their absolute hardest to break into it, and the software held strong. The firewall earned its EAL4 certification.

SPEAKER_00 17:15

So for the government procurement officer, this is no longer about trusting a salesperson's glossy brochure. It is about relying on empirical, globally recognized evidence.

SPEAKER_01 17:24

You're replacing trust with verification.

SPEAKER_00 17:26

And the global importance of this standard cannot be overstated. According to the text, it standardizes security evaluations across borders, builds trust in IT products, streamlines government and enterprise procurement, and fundamentally reduces risk.

SPEAKER_01 17:39

It really is the backbone of global tech trade.

SPEAKER_00 17:42

But I want to quickly contrast ISO 154081 with another very famous standard, because I hear this other one thrown around a lot in corporate environments. ISO 2701. Our sources make a very clear, vital distinction here.

SPEAKER_01 17:57

Yes, and it is a massive point of confusion in the industry. Many organizations proudly announce on their websites that they are ISO 2700001 certified, and buyers often assume that means the software products they are purchasing are bulletproof.

SPEAKER_00 18:10

They're not the same thing at all.

SPEAKER_01 18:11

Not even close. The two standards measure entirely different things. ISO 27001 focuses on overall security management for an organization.

SPEAKER_00 18:19

Okay, so it's about the company itself.

SPEAKER_01 18:21

Yes. It is about the people, the internal policies, and the corporate procedures. Does the company require its employees to use two-factor authentication? Do they physically lock the server room doors? Do they have an incident response plan if an employee loses a laptop?

SPEAKER_00 18:35

Aaron Powell It is entirely about organizational behavior. ISO 15481, on the other hand, is strictly about product level evaluation.

SPEAKER_01 18:43

A great way to visualize the difference is that ISO 2701 certifies the factory, while ISO 15408 certifies the actual car rolling off the assembly line.

SPEAKER_00 18:54

Oh, I love that analogy. That makes it so clear.

SPEAKER_01 18:57

You absolutely want the factory to be secure, well managed, and free of hazards. But when you are driving the car down the highway at 70 miles per hour, you really care that the brakes themselves have been rigorously tested and verified to work under pressure.

SPEAKER_00 19:10

ISO 15408 proves the brakes work.

SPEAKER_01 19:13

100%.

SPEAKER_00 19:14

So what does this all mean? Let's bring this right down to the ground. If you are listening to this and you're part of a company deciding which enterprise software to buy or which cloud service to trust with your sensitive client data, you might never actually read a dense ISO 154081 evaluation report yourself.

SPEAKER_01 19:30

Let's be honest, you probably won't. They are very dry.

SPEAKER_00 19:33

Very dry. But this framework acts like a digital passport operating in the background. It is the mechanism ensuring the vendor isn't just making empty promises. When you see that common criteria certification, you know, a completely independent group of experts took a sledgehammer to the code in a laboratory, and the code survived.

SPEAKER_01 19:53

If we connect this to the bigger picture, this framework creates something profound, a universal currency of digital trust across international borders.

SPEAKER_00 20:01

A universal currency of trust. I like the sound of that.

SPEAKER_01 20:04

Without it, global tech commerce would be paralyzed by suspicion. Every nation would have to build and test its own hardware and software from scratch, isolating themselves behind digital borders.

SPEAKER_00 20:15

Which would slow innovation to a crawl.

SPEAKER_01 20:17

It would ruin it. ISO 15408-1 makes a secure, interconnected global economy possible by providing a reliable, standardized way to verify security across entirely different cultures, languages, and legal systems.

SPEAKER_00 20:30

It is moving us from a state of blind trust to a state of verified confidence. We started this deep dive looking for the foundation of global IT security, and we found it. It really is the bedrock. It gives us the shared language of targets of evaluation, functional requirements, and assurance requirements, and distills months of laboratory testing into clear evaluation levels.

SPEAKER_01 21:00

This raises an important question, though.

SPEAKER_00 21:02

How's that?

SPEAKER_01 21:02

Everything we have discussed today is based on one fundamental assumption that technology is static.

SPEAKER_00 21:08

Static. Meaning it doesn't change once it's built.

SPEAKER_01 21:10

Exactly. You evaluate a firewall, you certify its specific code in a lab for six months, and then the code stays the same when it is deployed. But we are rapidly entering the age of artificial intelligence.

SPEAKER_00 21:22

Oh boy. AI ruins everything, doesn't it?

SPEAKER_01 21:24

It certainly complicates things. We're seeing the emergence of neural networks and machine learning systems that can autonomously adapt, rewrite their own code, and change their behaviors based on new data streams.

SPEAKER_00 21:36

Wow. Yeah, that's true.

SPEAKER_01 21:37

If ISO 15408 relies on testing static products against fixed criteria, how will this framework survive in a world where a system's security features might literally evolve and change overnight? How on earth do you certify a moving target?

SPEAKER_00 21:54

Wow. That is a massive paradigm shift to think about. A lock that dynamically changes its own internal. Mechanism while you were in the middle of trying to test it. That is something for you to mull over as you navigate the rapidly evolving tech world this week. How do we build standardized trust in machines that are constantly rewriting their own rules?

SPEAKER_01 22:12

It's the next great frontier for security.

SPEAKER_00 22:14

It really is. Well, thank you so much for joining us for this deep dive. Before we wrap up, we want to ask you to please follow the channel so you never miss out on these explorations.

SPEAKER_01 22:22

Yes, please do.

SPEAKER_00 22:23

And be sure to visit weSiberi.com for more content like that, expanding on everything we talk about here. Until next time, stay curious and keep questioning the systems working behind the scenes. Goodbye.