Week 13 — Security Requirements¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

# Windows (PowerShell)
.\build.ps1
cd week-13\01-uyum-matrisi
.\bin\windows\uyum.exe
cd ..\02-gereksinim-kalite
.\bin\windows\gereksinim_kalite.exe

# WSL / Linux
./build.sh
cd week-13/01-uyum-matrisi && ./bin/linux/uyum
cd ../02-gereksinim-kalite && ./bin/linux/gereksinim_kalite

0. Before we start¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full.

What we bring from earlier weeks¶

• Assets, threats, and the application protection plan — the written plan that governs a piece of software's security: scope, architecture and interfaces, assets, threats, controls, verification, residual risk; for each asset, where it lives, when it is created and destroyed, and which protection (C/I) it needs is listed in an asset table (Week 1, §6). This week, in Section 2 we link every requirement to that table and to the threat model, and in Section 7 we turn that link into a decision process.
• Independent evaluation, findings, and evidence — the evidence-based evaluation process carried out by an independent laboratory rather than the product's own developer; every gap the evaluator documents is a finding (Week 12, §2). This week, in Section 2 we use the same discipline as the "traceability chain from requirement to evidence," and in Section 9 as your term project's S17/S14 sections.

This week's concept map¶

Why are there so many terms? (rationale)¶

The certification world uses its own vocabulary because an evaluator reads your document, not your project. If what you call a "requirement" in the document is actually a "control," the evaluator conflates the two and asks the wrong question: instead of "Where is this requirement's control?" they should be asking "Why is this requirement written like a control, what does it satisfy?" If the terms are not used consistently, the traceability chain (Section 2) cannot be built; each word maps to a different box (requirement, control, or evidence), and if those boxes get mixed up the matrix becomes meaningless. That is why the discipline this course requires is, first, using the right word in the right place; the technical solution is the second step.

The difference between a 'requirement family' and a 'standard'¶

This course uses two different things coming from two different sources, and confusing them is a common mistake:

• Standard: an external document the course did not write (e.g., ETSI EN 303 645, Common Criteria, FIPS 140-3, OWASP MASVS). It has its own clause numbers and its own issuing body.
• The course's requirement family: the course's own short list, adapted from these standards, with ids of the form CEN429-<family>-<number> (Section 8). Its purpose is to gather the common denominator of different standards into a single workable list.

When writing a requirement, "which standard it is based on" (source) and "which of the course's families it belongs to" (id) are two separate questions; you state both separately, in the S1 (sources) and S17 (compliance matrix) sections. In Section 6 we'll see how these two express the same need in different words, across four standards.

The difference between 'not met' and 'not applicable'¶

These two statuses are often confused but mean very different things; using both correctly is just as important to the matrix's credibility as the requirement statuses themselves:

• Not met: the requirement applies to the product but is not yet satisfied. This is a gap; it is written into the residual risk and goes into the next release plan.
• Not applicable: the requirement does not apply to the product at all (e.g., if the product does not use network connectivity, "data in transit" requirements are not applicable). This is not a gap, but if written without a rationale, the evaluator treats it as "the requirement was skipped, not checked."

We'll see this rule's common mistake and its consequence again in Section 7, when we carry requirements into the project.

The six status/decision words we've seen in this section¶

Let's gather the status and decision words we've seen throughout this section; these are the words you'll use over and over when filling in S17 and S14 in your term project:

Keeping this table in mind will give you a reference point as you read every example in the sections ahead.

1. What is a security requirement? How do you write a good one?¶

Throughout the term we linked every control to a threat: "we protect this asset against this attacker." In the certification world, the same link extends one step further: every control is linked to a requirement. A requirement states what the product must do; it does not say how. Design and code answer the "how"; the evaluator instead asks "has the requirement been met, and where is the evidence?"

Before writing a requirement, you first need to be clear about which type you mean; requirements split into three main types:

Three types of requirement¶

Bad and good requirements¶

The properties of a good requirement: singular (one sentence, one requirement), verifiable (it can be shown to be met with a test or review), traceable (it has an id and is linked to a threat or a standard), feasible (technically possible), and what, not how (it doesn't dictate a solution, but does give criteria such as a security level).

Worked example: improving a bad requirement step by step¶

You saw the finished results in the table above; now let's see the process. Think of the starting sentence as if it were taken from a real guide draft:

"The application must protect user data."

Step 1 — Flag the vague words. "User data" (which data?) and "must protect" (against what, at what level?) cannot be measured. When an evaluator reads this sentence, they find nothing to test; they don't know what evidence to ask for to call it "protected." This is the same ailment as the first row of the "good vs. bad requirement" table ("the application must be secure"): the sentence says everything and nothing.

Interim step: "The application must protect user data." → it isn't clear which data, against which threat.

Step 2 — Link it to the asset table (Week 1). "User data" is not a single thing; it is separate rows in the asset table: session token, profile information, payment token, log records... Each has a different confidentiality/integrity class (C/I/I+/N) and requires a different requirement. In this step, we narrow the single sentence down to "sensitive fields in the local database" marked class C in the asset table.

Interim step: "Class-C fields in the local database must be protected." → "must be protected" still isn't measurable.

Step 3 — Clarify the protection goal (confidentiality, integrity, or both). In the threat model (Week 1), the threat to this data is "an attacker who compromises the device reads the database file" — that is, a confidentiality threat. But we also ask whether the attacker could modify the file to fool the application — yes, so integrity is needed too. Recognising that both goals are needed at the same time determines the next step.

Interim step: "The confidentiality and integrity of class-C fields in the local database must be protected." → there's still no "how," no measurable criterion.

Step 4 — Add a measurable technical criterion (linking to Week 9's protection rules). The rule we saw in Week 9: if you want confidentiality and integrity at the same time, the right tool class is AEAD (see Week 3). This adds a concrete, technology-independent criterion to the requirement; we still aren't naming a specific library.

Interim step: "Class-C fields in the local database must be protected with authenticated encryption (AEAD)." → what strength, and when it will be verified, are still not written.

Step 5 — Add the state (at rest/in use/in transit) and the keyword. The data here is at rest (it sits on disk, it isn't being transferred). We choose "must" (MUST) as the keyword because this is an indispensable condition against the threat; if it were "may" (MAY), the evaluator would treat it as optional and would not write a finding even if it wasn't met.

Interim step: "Sensitive class-C data at rest must be protected with authenticated encryption (AEAD)." → the verification method is still not written; this is stated in the traceability matrix (Section 2), not in the requirement text itself.

Step 6 — Give it an id and link it to the threat. Finally we give the requirement an id from the course's family scheme (Section 8) and note which threat it corresponds to; a requirement with no id never enters the traceability chain.

Final form: CEN429-DR-01 — "Sensitive class-C data at rest must be protected with authenticated encryption (AEAD)." (Threat: T-03, "an attacker who compromises the device reads/modifies the database file," Week 1's threat model.)

Each of the six steps eliminated one kind of ambiguity: which data (asset table), against which threat (threat model), which goal (confidentiality/integrity), which tool class (AEAD — the class, not the solution itself), which state (at rest), and which obligation (MUST). If any one of these six is missing, the requirement remains open to debate and the evaluator sends it back.

Second example: a speed test of the process¶

To apply the process faster, let's go through the same six steps again in a much shorter example; this time as a table:

Final form: CEN429-ID-04 — "Every login attempt must be validated server-side; client-side checking alone must not be considered sufficient."

The word "fast" is handled as a separate performance requirement (outside this course's scope) — this is another face of the singularity rule: mixing security and performance requirements in the same sentence blurs which one is met and which isn't; the two can progress at different paces.

Reinforcing requirement keywords with an example¶

The concrete consequence of confusing these three words: if you write a SHOULD requirement as if it were MUST and fail to meet it, you unnecessarily put yourself in a "not met / residual risk" situation when a rationale would have sufficed. The reverse also happens: if you soften a MUST into a SHOULD and don't meet it, the evaluator treats it as a serious gap.

Third example: improving a process requirement¶

Alongside functional requirements, process requirements demand the same discipline. The bad version:

"Code review must be performed."

• Which change? (Every change, or only big ones?)
• Who reviews it? (Does the author themselves count?)
• When? (Before merging, or after?)

The good version: "Every change must be reviewed by at least one person other than the developer who wrote it, before being merged into the main branch (main/master), and the review approval must be recorded in the version control system." This sentence is now verifiable: you check the version control history to see whether every pull request has at least one approval record — it can even be audited automatically.

Writing a requirement isn't enough: the next question is "how do I verify it?"¶

In this section we learned to write a requirement well; but even a well-written requirement proves nothing on its own. The next question is always: "By what concrete step do I show that this requirement has been met?" This question takes us to the traceability chain in Section 2.

2. From requirement to evidence: traceability¶

A requirement is only considered met together with its evidence. This discipline is called traceability: linking each requirement to a control, a test, and evidence; it means being able to answer "where was this requirement met, how was it verified?" at all times. In certification, the following chain is built for every requirement:

The tabular form of this chain is called the compliance matrix:

The matrix has two directions: forward traceability (does every requirement lead to a control and a test?) and backward traceability (does every control rest on a requirement or a threat, or is it unnecessary?). The evaluator reads the forward direction first: a row claimed to be met but with no evidence is the first finding.

Worked example: from an asset to evidence, end to end¶

Let's fill in how the chain is built, from start to finish, through a single asset.

1. Asset (from Week 1's asset table).

2. Threat (from Week 1's threat model). An attacker positioned on the network (e.g., on the same public Wi-Fi) can listen on an unencrypted connection, capture the token, and use it in their own requests to act as the user (STRIDE: Spoofing + Information Disclosure, Week 1 terminology).

3. Requirement (this week's subject). We write what the system must do against the threat; we briefly reapply the six steps from Section 1: asset (session token) → threat (network eavesdropping) → goal (confidentiality + identity) → tool class (encrypted channel + server authentication) → state (in transit) → obligation (MUST).

CEN429-DT-01 — "The session token must be carried over a channel using TLS 1.2 or higher, with the server certificate validated."

4. Control (which section of the guide, what is done). In the guide's S10.3 "Transport security" section: "The client performs a TLS 1.2+ handshake on every connection to the server; the certificate chain and hostname are validated (see Week 10). No request is sent before the channel is established."

5. Verification (how it was tested). The security testing team tries to intercept the connection with a MITM (man-in-the-middle) tool: it verifies that (a) presenting an invalid/self-signed certificate gets the connection rejected, and (b) attempting a plaintext (non-TLS) connection gets rejected.

6. Evidence (where, produced by whom). The test tool's log output (mitm_test_2026-11-03.log), the CI run record (#617), and the TLS handshake packet capture taken during the connection (handshake.pcapng) are stored in the project repository's evidence/week13/ folder, and are referenced by these file names in the compliance matrix.

Once these six steps are complete, the row in the compliance matrix fills in like this:

What would happen if one of the chain's six links were missing?

• If the asset were undefined → the requirement would have no answer to "which data."
• If it weren't linked to a threat → the requirement would look arbitrary; there'd be no answer to "why does this requirement exist?"
• If no control were written → the "met" claim would be unsupported.
• If no verification were defined → there would be no answer to "how was it tested?"
• If there were no evidence → the row would be the evaluator's first finding (see the rule below).

Let's also see the "deferred" status with the same requirement: if the product were a library and the host application opened the TLS connection, CEN429-DT-01 would be deferred to the host application, and S14 would say "to whom: the host application; why: the library opens no network connection; how: the host application must connect with TLS 1.2+ and certificate validation". The rules for deferring are in §3.

Backward traceability: finding a superfluous control¶

We saw forward traceability above. Backward traceability asks the opposite: does every control written in the guide rest on a requirement? Say the guide has this sentence: "The application applies a random delay at startup." Which requirement does this control link to? If the team cannot show that it rests on CEN429-AP-05 ("a defined response must be given when a debugger or hook is detected"), then either (a) the threat model is missing a threat (why was the delay needed, which attack does it slow down?), or (b) the control is unnecessary and should be removed from the guide. Backward traceability is the way to clean out "seemed like a good idea" controls that pad the guide but meet nothing; every page is a page the evaluator must read, and an unnecessary control lengthens the evaluation time.

The link between traceability and Week 12's assessment¶

The assessment process you saw last week (Week 12) is, in fact, the way this matrix is read: when an evaluator examines your project, they don't read random lines of code; they open the compliance matrix first, select the "met" rows, request evidence for each, and independently verify that evidence (Week 12's "independent verification" principle). The better your matrix is built, the faster and with fewer question marks the assessment proceeds; a poorly built matrix makes the evaluator stop at every row and ask "how do we know this?", lengthening the process.

Worked example: the full chain of the 'not met' status¶

The chain is built not only for "met" rows but for "not met" rows too — the difference is in the last two links.

This is the expanded version of the CEN429-DT-04 row we saw in the compliance-matrix table at the start of the section. In the "not met" state, the control and verification columns can stay blank, but the evidence column cannot — there, instead of real evidence, you write where the residual risk is documented. Leaving it blank gives the impression that the risk was forgotten.

Why 'matrix,' not 'list'?¶

A checklist only says "done/not done." The compliance matrix is called a "matrix" because it holds six dimensions together (id, requirement, status, control, verification, evidence): every row is a requirement, every column is a link in the traceability chain. If a cell is missing, it means that row is unverifiable in that dimension — a list can't show this, a matrix can.

The five finding types an evaluator writes most often¶

An evaluator reading a compliance matrix usually writes one of these five finding types; check these five before submitting your own matrix:

1. A "met" with no evidence. The most common finding; this section's main rule.
2. Inconsistent ids. The same requirement is given different ids in different places in the guide (e.g., CEN429-DR-01 in one place, DR01 in another) — traceability can no longer be checked automatically with software tools.
3. An unlinked control (backward traceability). The guide has a control but doesn't state which requirement it meets.
4. A "not applicable" with no rationale. The mistake covered in this week's Sections 0 and 7.
5. Generic/copy-pasted evidence. The mistake seen in the worked example in Section 8.

The demo tool 01-uyum-matrisi automatically scans only for the first type (a "met" with no evidence); the other four are, for now, found manually, by reading like an evaluator.

Carrying traceability into the code level too¶

The compliance matrix is usually kept as a separate document (a table), but it is also possible — and common in large projects — to carry traceability into the source code itself: adding a comment line like "this function meets CEN429-DR-01" above a critical function lets the next developer reading the code (or yourself, a year later) instantly answer "why is this line here?" This is a small, code-side reflection of the requirement block from Section 3:

/* CEN429-DR-01: the vault file at rest is encrypted with AEAD. */
int kasa_dosyasi_sifrele(const unsigned char *anahtar, ...) {
    ...
}

A comment like this does not replace the evidence column (the evidence must still be a test/record); but it visually links the requirement to the code. Someone doing a code review can scan for these comments when looking for the code that meets a requirement.

3. The requirement-block pattern and deferred requirements¶

The requirement block in the guide¶

In security guides that pass certification, every section opens with the requirements that fall under it. Every requirement is written in this pattern:

[Standard/scheme] Requirement id — STATUS
The requirement's text (from the standard).
A description of how the product meets this requirement; reference to the relevant control cards and sections.

In the field, in a mobile payment library's guide, every section — "data at rest," "data in use," "data in transit," "reporting," "crypto methods and keys" — opens with the two card schemes' requirements on that topic, and each one is marked met or deferred to the parent application. The strength of this pattern is that the evaluator can go from requirement to evidence in a single glance.

Deferred requirements: the boundary of responsibility¶

A software component (e.g., a library embedded inside other applications) cannot meet every requirement on its own. Installing the application, updating it, showing a notification to the user, or protecting its own source code is the job of the application that uses the component, not the component itself. These requirements are deferred and written explicitly in the guide's "security expected from external components" section.

For your project: S14 "Assumptions and deferred requirements"¶

Even if your project is a standalone application, it has assumptions: the supported operating systems, that the user is not an administrator, that the build environment is trustworthy, that the server is protected by a separate team. Writing these down explicitly helps the evaluator correctly understand the scope, and answers the question "why is this threat out of scope?" in advance.

Worked example: filling in the requirement block from start to finish¶

Let's fill in the pattern with a real example; this is the written-up-in-the-guide form of the CEN429-DR-01 chain from Section 2:

[CEN429-DR] CEN429-DR-01 — Met
Requirement: Class-C sensitive data at rest must be protected with authenticated encryption (AEAD).
Compliance: The local vault file is encrypted with AES-256-GCM (see S7.2 "Vault file encryption").
The encryption key is derived from the device's secure storage unit (Android Keystore / iOS
Keychain) and is never stored as plaintext outside memory. Verification: a unit test
(test_butunluk.c) checks that changing a single byte of the encrypted file and then decrypting it is
rejected. Evidence: CI run record #482, test output evidence/week13/test_butunluk_ci482.log.

Every line in the block serves a purpose: the header line ([Family] Id — Status) tells the evaluator's eye quickly where to go; the Requirement line repeats the "what" coming from the standard or the threat model (copy-paste, not reinterpreted); the Compliance paragraph describes the "how," with concrete file and section names; the Verification and Evidence sentences complete the last two links of the chain from Section 2.

Now let's fill in the same pattern for a deferred requirement — this time the parent application meets it, not the product itself:

[CEN429-AP] CEN429-AP-07 — Deferred (to the parent application)
Requirement: The application must be installed and updated securely.
Compliance: The library does not have its own distribution/update mechanism; this is the
responsibility of the parent application that packages the library. The recommended method for the
parent application's developer: (1) use the official app store's signature verification, (2) if a
custom update channel is used, sign update packages with the signing scheme described in Week 6.
To whom: the parent application's developer. Why: the library does not access installation at the
network/file-system level, it is only called as an API. How: one of the two methods above, detailed in the guide's "Security expected from external components" section.

Notice that the "deferred" block also has a Compliance field — but this field answers "how must the other party do it, and why aren't we doing it ourselves" rather than "how did we do it." Deferring does not mean leaving that field blank; on the contrary, it demands more explanation, because you have to prove where the boundary of responsibility lies.

Three assumptions commonly overlooked when filling in S14¶

Projects usually forget these three assumptions; check for them when adding to S14:

1. Is the build environment trustworthy? The assumption "an attacker cannot access the build server" is usually not written down, but it is a foundation every project rests on (Week 6, supply-chain security).
2. Is the user's device not rooted/jailbroken? If it is, which controls become invalid (e.g., secure storage may no longer be secure) must be stated explicitly.
3. Is the server side protected by a separate team? If so, it must be stated clearly which requirements (e.g., server-side access control) are out of scope for this project; otherwise the evaluator will expect them from this project too.

Why deferring is not a bad thing (rationale)¶

New developers perceive the word "deferring" as a weakness and try to meet everything in their own component — this usually leads to the component trying to take on tasks it cannot do (installation, OS-level isolation, UI warnings), or worse, silently skipping them without handling them at all. In the certification world, drawing boundaries explicitly always scores better than leaving boundaries vague: an evaluator trusts a guide that knows who was deferred what; they do not trust a guide that says "we handle everything ourselves" but cannot produce evidence.

Worked example: the requirement block in the 'not met' state¶

Some requirements are neither met nor deferred yet — the project has consciously decided to carry this risk. The block's form in this state:

[CEN429-DT] CEN429-DT-04 — Not met
Requirement: The server certificate must be pinned (certificate pinning).
Status: Not currently implemented; only standard TLS certificate chain validation is performed
(CEN429-DT-01 is met, but pinning is absent). Residual risk: if an attacker manages to obtain a
fraudulent certificate from a trusted root certificate authority, MITM may become possible (see
S16.4). Planned fix: pinning will be added in v1.1 (see project plan, task #217).

The "not met" block fills in the Status and Residual risk fields instead of Compliance; this honestly states that the requirement will be met in the future but is not met right now. Not writing it at all (removing the row from the matrix) is worse: the evaluator finds the requirement themselves and asks "why did you skip this?"

A hard deferral decision: when does hardware take on a requirement, and when doesn't it?¶

"If there is no hardware secure element (secure element/TEE), a requirement cannot be deferred to hardware" — this simple rule is sometimes applied incorrectly. Take, for example, the requirement "the key must be protected against physical attack":

• If the device has a secure element: the requirement can be deferred to hardware; the guide states "key generation and storage are deferred to the device's secure element, the application only calls the API."
• If the device does not have a secure element: the requirement cannot be deferred, because there is no party to defer it to. In this case the product itself must implement a software-based control (e.g., white-box cryptography, code obfuscation), or mark the requirement "not met" and write the residual risk.

A common mistake is to write "deferred to hardware" in the second case too — since there is no concrete party to defer to, this is an invalid deferral and is rejected by the evaluator.

4. Common Criteria (ISO/IEC 15408)¶

Common Criteria (CC) is the international standard for the security evaluation of IT products. The evaluation methodology is defined in a separate document (CEM, ISO/IEC 18045). Thanks to the Common Criteria Recognition Arrangement (CCRA), a certificate issued in one country is also recognised in the other countries that are party to the arrangement.

Basic concepts¶

EAL levels¶

A higher EAL does not mean the product is "more secure"; it means the evaluation was carried out more deeply. An EAL4 product can be less secure than an EAL2 product; what matters is the scope of the security objectives and threats in the ST. The "+" mark (EAL4+) shows that additional assurance components were added to the package; the most commonly added one increases the depth of the vulnerability assessment.

Vulnerability assessment and attack potential¶

CC's vulnerability-assessment component (AVA_VAN) determines what attack potential the product must withstand from an attacker: Basic, Enhanced-Basic, Moderate, and High. Attack potential is scored in the CEM with five factors: elapsed time, expertise, knowledge of the product, window of opportunity, and equipment. The sum of the scores shows which potential level a successful attack requires; the product must withstand attackers below the level it claims in the ST. Adapted versions of the same idea are used in the evaluation of payment products as well.

Worked example: filling in an ST skeleton for your project¶

Writing a security target (ST) from scratch can look intimidating; it is actually a reorganization of the documents you've gathered throughout the term. Below, we fill one in for a sample mobile-payment component in three steps.

Step 1 — Define the TOE (what we are evaluating, what we are not).

TOE: the "CEN429-Pay" library, version 1.0, Android ARM64 build only. Out of scope: the parent application's user interface, server-side components, the operating system kernel.

When defining the TOE, writing what's out of scope is just as important as writing what's in scope — it connects directly to the "deferred requirements" idea from Section 3: everything left out of scope reappears in the ST as an "assumption."

Step 2 — List the threats and assumptions (from Week 1's threat model).

Step 3 — Map the security objectives to the corresponding SFR families.

This table is the heart of the ST: every row is a bridge between "why this requirement exists" (threat) and "what evidence is requested" (the SFR family, later tested against a SAR). Choosing the target EAL is the last step: for this project the team can choose, as a target, an assurance depth resembling EAL4, "the most common upper level for commercial products" (without actually undergoing a real CC evaluation, just to build their own internal discipline to that level).

The origin of CC: why do several countries use the same standard?¶

Before Common Criteria, the US, Europe, and Canada each had their own separate evaluation criteria (the Orange Book/TCSEC in the US, ITSEC in Europe, CTCPEC in Canada). Because each country certified against its own criteria, a product certified in one country had to be re-evaluated in another. Common Criteria merged these three approaches into a single international standard (ISO/IEC 15408); thanks to the CCRA (Common Criteria Recognition Arrangement), a certificate from one country is recognised in the other party countries without needing re-evaluation. This is much like different countries switching from different electrical-outlet standards to a single common one: the cost of compliance drops, and comparison becomes easier.

Why SFRs are not invented, but chosen from a catalogue¶

The relevant part of Common Criteria has a predefined SFR catalogue (families such as FCS, FDP, FIA, FAU, FMT, FPT, FTP, and their subcomponents). When writing an ST, you choose from this catalogue instead of inventing a new SFR; if a need has no exact counterpart in the catalogue, it is separately defined and justified as an "extended component." The reason for this is consistency: if two different products' STs use the same catalogue, an evaluator can compare them; if every product invented its own terminology, comparison would be impossible.

Choosing an EAL: a practical decision guide¶

Students often ask "which EAL should we write for our project?" Even if you're not going to undergo an actual CC certification (and you won't, for the term project), it's useful to use the EAL concept as an internal discipline target:

This table does not promise a CC certificate; it only offers a rough comparison for the question "how rigorous a documentation and testing process do we need."

Reusing a PP for an ST¶

If a PP already exists for a product class (e.g., the "mobile device" or "firewall" PPs), a team developing a new product does not write its ST from scratch; it takes the PP's requirements, adapts them to its own TOE, and says "we claim conformance to this PP." This is the same logic as the course's requirement families in Section 8: a PP is a template, an ST is that template applied to a specific product. For your own project, the course's requirement families can be thought of as an informal "mini PP."

Comparing the CC process with Week 12's assessment process¶

The independent-assessment steps you saw last week (Week 12) — document review, code review, repeating tests, vulnerability analysis — are, in fact, the evaluation activities CC defines in the CEM, scaled down to this course's level: in CC, ADV (development) documentation is reviewed, ATE (testing) results are independently repeated, and AVA (vulnerability assessment) analyses attack potential. Your one-session assessment last week imitates, on a small scale, a process an accredited lab spends months on — the same discipline, a different scale.

5. FIPS 140-3: validating cryptographic modules¶

FIPS 140-3 is the US NIST's security standard for cryptographic modules; its content is based on the international ISO/IEC 19790 standard. Validation is performed by accredited laboratories under the Cryptographic Module Validation Program (CMVP), jointly run by NIST and Canada. It replaces FIPS 140-1/140-2, mentioned in the textbook's Recipe 11.18; as of 2026, FIPS 140-2 certificates are being moved to the historical list.

Security levels¶

What a module must do under FIPS 140-3 (summary)¶

• Use only approved algorithms (AES, SHA-⅔, HMAC, RSA, ECDSA, approved random generators; post-quantum algorithms from 2024 onward) in approved mode; each algorithm must also have a certificate from the algorithm validation program (CAVP).
• Perform self-tests on power-up and conditionally (known-answer tests, integrity checks); on failure, enter an error state and provide no cryptographic service.
• Define roles and services (user, operator); document which critical security parameter (key) each service accesses.
• Generate, input/output, and zeroize critical security parameters securely once their job is done.
• Publish a security policy document.

Worked example: auditing a module against FIPS 140-3 Level 1¶

Let's apply the "summary" list above to a real (but simplified) project. Say your project's crypto layer works like this: it uses OpenSSL's standard EVP interface, encrypts with AES-256-GCM, generates keys from getrandom() (Week 3), and silently falls back to a default key on error. Let's check off the Level 1 expectations one by one:

This table shows the project is far even from FIPS 140-3 Level 1, and that the most critical gap is "silently falling back to a default key on error" — this is the exact opposite of the zeroization principle, and a violation of the "if the random generator fails, stop, don't continue" rule we saw in Week 3.

The steps of FIPS validation (roughly)¶

Getting a cryptographic module validated under FIPS 140-3 is not a one-time approval, it is a step-by-step process:

1. The developer prepares the module with approved algorithms, together with a security policy document.
2. CAVP (Cryptographic Algorithm Validation Program) tests that each algorithm (AES, SHA-2, HMAC, RSA...) is correctly implemented, separately, and issues an algorithm certificate.
3. An accredited laboratory tests the module against FIPS 140-3's physical, logical, and process requirements.
4. CMVP reviews the laboratory's report and publishes the module certificate; the certificate states the module's exact version and the platform it runs on.
5. If the module or platform changes (e.g., a new operating system version), the certificate may require revalidation.

This sequence shows why the sentence "we use AES" is insufficient as a FIPS claim: Step 2 covers only the algorithm, while Steps 3–4 cover the whole module (algorithm + self-tests + roles + zeroization). The certificate is not issued until Step 4 is complete.

What does a CMVP certificate state?¶

A real CMVP certificate generally states: the module's name and version, which operating system/hardware it was tested on, which security level it was validated at, and the CAVP certificate numbers of the validated algorithms. When a project says "we use the FIPS-validated library X," it must actually check that the exact version and platform match in that certificate is identical to how it's used in their own product; if the certificate was issued for Linux x86-64, an Android ARM build of the same library does not automatically inherit that certificate.

Don't confuse FIPS levels with CC EAL¶

Because both are expressed with small numbers (1 to 4, or 1 to 7), students confuse these two scales:

A product can claim both "FIPS 140-3 Level 2" and "CC EAL4" at the same time — these are not mutually exclusive, they measure different dimensions. Neither substitutes for the other.

Three questions to ask before claiming FIPS compliance¶

Before writing a FIPS claim in your project, ask these three questions in order:

1. Which module has the certificate — the operating system's crypto library, or a separate library embedded by the application?
2. Does this certificate cover the exact version and platform you use (the "platform/version mismatch" mistake above)?
3. Does every algorithm call you use run in the module's "approved mode," or are you using one of the module's non-approved helper functions?

If you cannot answer "yes" to all three questions, narrow your claim down to a smaller, more honest sentence such as "we use FIPS-approved algorithms" (as seen in the tip box at the start of this section).

The connection to this week's demo¶

This week's 01-uyum-matrisi demo automatically finds "met" rows with no evidence; writing a FIPS claim without evidence is a mistake of the same class. If you write a sentence like "we comply with FIPS 140-3" in your own project, treat it as a separate row in your compliance matrix, and write the certificate number in the evidence column (or the honest "no certificate, we only use approved algorithms").

6. ETSI, GSMA, EMVCo, PCI, and OWASP: sector-specific requirement sets¶

ETSI EN 303 645: the consumer internet of things¶

This standard from the European Telecommunications Standards Institute (ETSI) defines a baseline security line for internet-connected consumer devices, and has become the basis for regulations in Europe. Its thirteen provisions read like a brief summary of the topics we've covered throughout the term:

GSMA¶

GSMA, the association of mobile operators, runs the IoT Security Guidelines for IoT devices and services, the Security Accreditation Scheme (SAS) for SIM/eSIM manufacturing and subscription-management facilities, and an assessment scheme for network equipment (NESAS). SAS is an example of auditing the manufacturing and management facility, not the product: physical security, personnel, processes, key management.

EMVCo and PCI: payments¶

Notice the EMVCo family list above: throughout the term, every week's topic corresponded to one of these families. The course's requirement families (Section 8) are adapted from this structure.

OWASP MASVS: a practical checklist¶

Although it doesn't issue a formal certificate, OWASP's Mobile Application Security Verification Standard (MASVS) is the most widely used open checklist for mobile applications. Its control groups: storage (MASVS-STORAGE), crypto (MASVS-CRYPTO), authentication (MASVS-AUTH), network (MASVS-NETWORK), platform (MASVS-PLATFORM), code (MASVS-CODE), resilience (MASVS-RESILIENCE), and privacy (MASVS-PRIVACY). Testing methods are given in a separate guide (MASTG). The resilience group covers the topics of Weeks 4, 5, 6, and 9.

Worked example: the same requirement's counterpart across four standards¶

Although the standards were written independently of one another, they generally express the same security need in different words. Let's trace two requirements across four standards.

Example 1 — Encryption of sensitive data at rest

Example 2 — Preventing default/weak authentication

What these two tables show is this: if a product has already prepared the evidence to meet the "data at rest encryption" requirement for an EMVCo/PCI document, most of that same evidence can be reused in a MASVS-STORAGE audit too — because both ask for the same underlying need (encrypted, zeroizable, non-leaking storage). But "reusable" doesn't mean "automatically met"; each standard's own criteria (e.g., MASVS also requires the key to be protected via the operating system's secure-storage API) must be verified separately.

How do you choose and prioritise among standards?¶

A project does not try to comply with all five of these sources (CC, FIPS, ETSI, GSMA/EMVCo/PCI, MASVS) at once; which standard applies depends on the product's type and market:

• If you're selling a consumer IoT device → ETSI EN 303 645 (a legal requirement in some markets).
• If you're developing a mobile application → OWASP MASVS (the de facto industry standard, even without a certificate requirement).
• If you're a payment-processing application/library → EMVCo and/or PCI documents (the card schemes' requirement).
• If you're selling to a government/defence buyer → a Common Criteria certificate (often a tender requirement).
• If you're selling a cryptographic module/library → FIPS 140-3 (mandatory for US federal buyers).

The course's requirement families (Section 8) extract the common denominator of these five; you're expected to determine which sector your own project falls into and state explicitly, in the S1 (sources) section, which standards you're basing it on.

Worked example: applying ETSI EN 303 645 provision 5.13 to your project¶

Provision 5.13 says "validate input data"; let's map this one-to-one to the input validation/sanitization topic we saw in Weeks 4 and 5:

1. Provision: "Device software must prevent the corruption of data or the crashing of the device by validating data coming from user interfaces or the network."
2. The course's requirement: This provision can be adapted to the course's CEN429-AP family or to a new input-validation family: "Every input coming from the network or the user must pass a length, type, and range check before being processed (see Weeks 4–5)."
3. Control: The guide lists which parsing functions perform boundary checking.
4. Verification: Fuzzing or boundary-value testing shows that invalid input is safely rejected (links to Week 4's fuzzing demo).
5. Evidence: The fuzz-test run report, a summary showing the crash count is zero.

This example shows how the ETSI provision's abstract sentence turns into a concrete requirement, control, and test for the course — just like the traceability chain in Section 2.

A short note on GSMA NESAS and PCI DSS levels¶

• GSMA NESAS (Network Equipment Security Assurance Scheme) evaluates mobile network equipment manufacturers' secure development processes and their products' security tests; unlike SAS (which is facility-focused), it is both process- and product-focused.
• PCI DSS divides organisations that process card data into levels based on transaction volume (the highest-volume organisations are subject to the strictest audits); we don't go into level details within this course, but the idea that "audit frequency/depth changes with size" is similar to CC's EAL logic: the bigger the risk, the deeper the assurance must be.

A comparative summary table of the sector sets¶

This table is this week's answer to the question we asked at the very start of the course — "who certifies what, and how?" — and serves as a summary closing out Section 6.

Can a product belong to more than one set at once?¶

Yes, and in fact most real products are. For example, a mobile payment application can simultaneously target: the card scheme's EMVCo requirements (because it works with card data), OWASP MASVS (because it's a mobile application), and, indirectly through the crypto library it uses, FIPS 140-3 (because that library may be FIPS-validated). A Common Criteria certificate is generally not needed for this product, because CC is requested mostly by government/defence buyers and is rarely required for consumer payment applications. The same analysis applies to your own project: the answer to "which market are we selling into, and which standard does that market ask for?" determines which standards you write into S1 — you don't have to write all of them, only the relevant ones.

7. Carrying requirements into the software plan and asset management¶

Reading a requirement set is the easy part. The real work is turning it into the product's plan. The steps:

1. Applicability: for every requirement in the set, ask "does this apply to this product?" Those that don't apply are marked with their rationale (e.g., "the product doesn't use network connectivity, data-in-transit requirements don't apply").
2. Responsibility: applicable requirements are split into "we meet it" and "we defer it" (Section 3).
3. Linking to assets: every requirement is linked to the relevant assets in the asset table. The requirement "crypto keys must be erased once their job is done" requires the "creation → erasure" column to be filled in for every key in the asset table.
4. Linking to threats: every requirement must correspond to at least one threat; if it doesn't, either the threat model is missing something, or the requirement is unnecessary for this product.
5. Control and verification: a control card and a verification method (test, review, analysis) are planned for every requirement.
6. Release plan: which requirement will be met in which release is written into the project plan; those that cannot be met are written into residual risk.

Worked example: applying the six steps to a single requirement¶

Let's apply the six steps from the start of this section (applicability → responsibility → linking to assets → linking to threats → control and verification → release plan) end to end, through the CEN429-CR-03 requirement ("keys must be erased once their job is done").

1. Applicability. Does the project use a crypto key? Yes — there's a session key and a vault-file key. The requirement applies.

2. Responsibility. The code that generates and uses the key is the project's own code; there's no reason to defer. The team decides we meet it ourselves.

3. Linking to assets. The asset table (S5) has two key rows: "session key" and "vault-file key." Both need their "creation → use → erasure" column filled in; right now the "vault-file key" row has an empty erasure time. This gap is noticed right here.

4. Linking to threats. Which threat requires this requirement? Week 1's threat model has the threat "an attacker with physical access to the device takes a memory dump"; if the key stays in memory after its job is done, this threat can be realized. The requirement links to this threat; if it couldn't be linked, either the threat model was missing something or the requirement was unnecessary for this product (item 4 above).

5. Control and verification. Control: sifreleme_bellek_sil() is called immediately after the key is used (overwriting with zeros; it's made sure the compiler doesn't optimise this call away — linking to Week 9's protection rules). Verification: a memory-analysis tool (e.g., taking a memory dump and searching for the key's bytes) verifies that the key is not present in memory once its job is done.

6. Release plan. For the session key, this control already exists in v0.9 (met). For the vault-file key it's missing; the team adds it to the v1.0 release plan and, until that day, writes the status in the compliance matrix as not met, with the residual risk "the vault-file key may remain in memory after its job is done; fix in v1.0."

At the end of the six steps, both a compliance-matrix row and a task in the project plan (zeroizing the vault-file key in v1.0) come out of it — this is the difference between "reading a requirement" and "turning a requirement into the project."

Second example: applying the same six steps to a process requirement¶

The steps work the same way not only for technical requirements but for process requirements too. Let's go quickly through CEN429-DV-02 ("every change must be reviewed"):

1. Applicability: Does the project use a version control system? Yes → applies.
2. Responsibility: The team meets it through its own process (there's no party to defer to).
3. Linking to assets: It's not linked to an "asset" directly, but to the development process; it's documented not in S5, but in the guide's "development lifecycle" section.
4. Linking to threats: Threat: "a malicious or faulty change entering the main branch unnoticed" (Week 6, supply-chain security).
5. Control and verification: Control: a pull-request rule, at least one approval mandatory. Verification: it's checked that the last 20 merges in the version-control history have at least one approval record.
6. Release plan: This process is already in effect; it's marked "met," noted as a rule requiring continuous monitoring (not a one-time thing, it applies to every merge).

This second example shows that the six steps work the same way not just for "crypto requirements," but for every type of requirement (functional, assurance, process).

Writing it into the release plan: a small example¶

The sixth step ("which requirement will be met in which release") turned into a concrete project-plan row:

This table is the project-management-side counterpart of the "not met" rows in S17 (the compliance matrix); whoever updates S17 should update this table in the same session — otherwise the two documents drift apart and one contradicts the other.

Why skipping these six steps is tempting but wrong¶

Reading a requirements list and directly saying "everything's met" is the fastest way to skip the six steps — and exactly for this reason it's the most common mistake. Teams under time pressure skip Step 3 (linking to assets) and Step 4 (linking to threats), because these look like "paperwork." But once these two steps are skipped, the remaining "met" claim rests on nothing; this is why Section 9's project checklist asks you to review S5 (the asset table) and S17 (the compliance matrix) together.

8. The course's requirement families¶

For your term project, we use a requirement set adapted from open standards (ETSI EN 303 645, OWASP MASVS, NIST SSDF, Common Criteria catalogues) and the structure of sector documents. Ids take the form CEN429-<family>-<number>.

Worked example: filling in a compliance-matrix row from start to finish, mistakes and all¶

Let's follow how a team filled in its matrix row for CEN429-AP-04 ("the application must check its own integrity at runtime"), from the first draft to the corrected version; this is Section 1's "bad to good" idea applied to a compliance-matrix row.

First draft (inadequate):

This row has three problems: (1) "There's an integrity check" is not a description of a control, it's a restatement of the requirement; which mechanism (a checksum? a signature check? debugger detection?) is not stated. (2) "Tested" is not a verification method, it's a claim that verification exists. (3) The evidence column is empty.

The fix, step by step:

1. The team makes the control concrete: the application computes a hash of its own code section at startup and compares it with the expected hash embedded at build time; if they don't match, it stops running. This is described in the guide's S12.3 section.
2. The verification method is clarified: a test tool changes one byte of the binary and verifies that the application refuses to start.
3. Evidence is added: the CI job where this test runs automatically (ci-integrity-check), its latest run record, and the output log.

The corrected row:

The difference isn't in the row's length, it's in the concreteness of every cell. The first draft also looked "filled in"; but none of its cells could be independently verified.

The logic behind the families: why nine families?¶

The eight families (AP, ID, AS, DR, DU, DT, RP, CR) plus the process family (DV) correspond to nine questions that recur in real guides across the industry: "How does the application protect itself (AP)? Who does it trust (ID)? What does it protect (AS)? Where does that protected thing sit — on disk (DR), in memory (DU), or on the network (DT)? What does it say/not say if something goes wrong (RP)? Which cryptographic tools does it do all this with (CR)? And how does the team that produced it work (DV)?" These nine questions overlap almost one-to-one with the section headings in EMVCo's software-based mobile payment document (as seen in Section 6), because nearly every security guide in the industry asks the same nine questions in a different order.

A common mistake when choosing a family: writing to the wrong one¶

Putting a requirement in the wrong family (e.g., writing "the key must be erased once its job is done" under DU instead of CR) isn't a big mistake, but it breaks consistency: when looking for the same kind of requirements, an evaluator checks a specific family; if the requirement sits in the wrong family, it can be missed.

The difference between the AS family and the DR/DU/DT families¶

Beginners often ask "isn't AS (asset protection) the same thing as DR (data at rest)?" The difference is this: AS is about the asset itself (which asset exists, how it's classified, what happens if a copy is compromised); DR/DU/DT is about which state (at rest/in use/in transit) that same asset is in. The same asset (e.g., a crypto key) can be the subject of both an AS requirement (e.g., "the location and lifecycle of every key must be defined") and a DU requirement (e.g., "session data must be erased from memory immediately after use") — one asks for the asset's inventory, the other for the asset's state at a given moment.

Remembering the nine families at a glance¶

The order AP-ID-AS-DR-DU-DT-RP-CR-DV can be hard to remember; remembering this chain of questions can help: "Does it protect itself (AP)? Who does it trust (ID)? What does it protect (AS)? Where is that thing — at rest (DR), in use (DU), in transit (DT)? What does it say if something goes wrong (RP)? With which tool (CR)? Who produced it, and how (DV)?" This is the "asset → threat → control" chain we've followed since Week 1, split into nine pieces.

9. Term project: this week¶

• S17 — Compliance matrix: all requirements from the course's families that apply to your project; every row has status, section, verification, and evidence.
• S14 — Assumptions and deferred requirements: supported platforms, out-of-scope components, user and environment assumptions; for every deferred requirement, to whom, why, and how.
• S1 — Sources: state which standards you're basing it on (ETSI EN 303 645, OWASP MASVS, NIST SSDF, CERT).
• Review your asset table (S5) against the requirements: is every asset's lifecycle and protection class filled in?

How to prepare this week's deliverable in 45 minutes¶

S17 and S14 are the documents an evaluator opens first (as stated in the info box at the start of this week too); leaving them messy creates a bad first impression even if the rest of the project is good. The suggested order:

1. Mark the requirements that apply to your project from the family table in Section 8 (copy-paste, then instead of deleting the ones that don't apply, leave them as "not applicable, rationale: ..." — the rule from Section 7).
2. Fill in the six columns from Section 2 (id, requirement, status, control, verification, evidence) for each one; don't write "met" without filling in the evidence column.
3. Move every row you marked "deferred" into S14; write the to-whom/why/how triple in full sentences, like the example in Section 3.
4. Open your asset table (S5); find the row of the asset each requirement links to. If it can't be linked, either the asset is missing or the requirement doesn't apply to this product.
5. Write which standards you're basing it on into S1 (sources) — see the "how do you choose standards" guide in Section 6.

How you should organise your evidence folder¶

A simple folder layout is recommended so every evidence reference in the compliance matrix is actually findable:

evidence/
  week13/
    test_butunluk_ci482.log
    mitm_test_2026-11-03.log
    handshake.pcapng
    integrity_test.log
  README.md   <- lists, in one line each, which requirement every file is evidence for

The README.md file is the mirror of the evidence column in the compliance matrix: every row in the matrix that says "evidence: file X" must actually be findable in this folder. If the folder is empty or the file is missing, the matrix is considered to have no evidence — just as described in the rule in Section 2.

If you're short on time: the priority order¶

There's a lot to deliver this week; if time is limited, proceed in this order (the order that earns the most points for the least time):

1. First, produce an S17 skeleton with at least 15 requirements (id + requirement + status columns filled in, control/verification/evidence can be blank) — this is far better than an empty S17.
2. Then, complete the rows you called "met" for which you actually have the evidence; honestly turn the ones without evidence into "not met."
3. Then, move the deferred rows to S14.
4. Finally, fill in the control/verification columns of the remaining rows.

This order rests on the principle that a "small but honest" matrix always scores better than a "large but evidence-free" one (see the evidence rules in Sections 2 and 8).

Why you shouldn't rush this week¶

S17 and S14 should become a document that grows a little every week, not just in the last week of the term project. If you note, throughout the term, which requirement each new control you add (in the "this week's project step" sections) satisfies, then by the time you reach this week S17 will already be half full. This week's real work then becomes only completing the missing rows and checking consistency.

10. Work on your own¶

Why you should solve these exercises on your own¶

The worked examples you saw in the sections above (bad→good requirement, the end-to-end traceability chain, the ST skeleton, the FIPS audit, the cross-standard mapping, the compliance-matrix row) were all explained through other requirements and other assets. The goal was to show the method; now you need to apply the same method to your own project's assets and requirements. You learn a method not only by watching it, but by applying it yourself once — especially in Exercises 1 and 3, you must notice which word is vague; this skill only comes with practice.

A mini checklist for evaluating your own answer¶

After finishing each exercise, check this list of five (it's the inverted form of the "five finding types an evaluator writes most often" list from Section 2):

• Does my answer have a "met" with no evidence?
• Are the ids consistent (the same id for the same requirement everywhere)?
• Is every control I wrote linked to a requirement?
• Is there a rationale everywhere I said "not applicable"?
• Did I write a generic sentence as evidence, or a concrete reference?

If you can answer "no" (i.e., no problem) to all five items, your answer is close to evaluator standard.

A starting template for Exercise 1¶

If you still don't know where to start, use this fill-in-the-blank template (the compressed form of the six steps from Section 1):

"[Which asset], [against which threat], [with which goal: confidentiality/integrity/availability], [with which tool class], [in which state: at rest/in use/in transit], [MUST/SHOULD] be protected."

Once you fill in every bracket, you'll have a requirement resembling the examples in Section 1. If one of the blanks can't be filled in (e.g., you can't answer "against which threat"), this is a sign the requirement isn't mature yet — go back to your threat model (Week 1).

11. Self-check¶

12. Resources and further reading¶

Textbook — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003: Recipe 11.18 (statistical randomness tests and the FIPS 140 context; today, FIPS 140-3 and NIST SP 800-90B/22).

Open standards and sources

• ISO/IEC 15408 (Common Criteria) and ISO/IEC 18045 (CEM); the protection profiles at commoncriteriaportal.org.
• FIPS 140-3, ISO/IEC 19790 and 24759; the NIST SP 800-140 series; CMVP and CAVP.
• ETSI EN 303 645 and ETSI TS 103 701 (conformity assessment).
• GSMA IoT Security Guidelines; GSMA SAS.
• EMVCo software-based mobile payment documents (general structure); PCI MPoC, PCI DSS v4.0, PCI Secure Software Framework.
• OWASP MASVS and MASTG; NIST SP 800-218 (SSDF).
• RFC 2119 / RFC 8174 (requirement keywords).

Why we chose these sources this way¶

This week's source list is deliberately made up of open and freely accessible standards (except for the card schemes' own texts, since those are shared under a non-disclosure agreement — see the info box at the top of the page). The goal is to offer sources you can still access after this course, and can reference directly in your project; when you say "standard X says this" on an exam or in the project, we want to make sure that standard is genuinely accessible.

How you format sources in S1 (example)¶

S1 — Sources (example format)
[1] ETSI EN 303 645 V2.1.1, "Cyber Security for Consumer Internet of Things: Baseline Requirements."
[2] ISO/IEC 15408-1:2022, Common Criteria for Information Technology Security Evaluation.
[3] OWASP Mobile Application Security Verification Standard (MASVS) v2.0.
[4] NIST FIPS 140-3 (2019), Security Requirements for Cryptographic Modules.

Listing every source with its version/date information is a direct application of the rule at the start of this section; the same format can also be used when referencing a standard in the requirement blocks (Section 3) of your guide.

This week's short summary¶

This week we saw how to write a good requirement from scratch (Section 1), how to trace it all the way to evidence (Section 2), how to write it correctly into the guide (Section 3), and how the major standard families (Common Criteria, FIPS 140-3, ETSI/GSMA/EMVCo/PCI/MASVS) express the same needs in different words (Sections 4–6). In Sections 7–8 we covered how to carry these into your project, and in Section 9, how to prepare this week's concrete deliverable step by step. The asset table you've gathered since the start of the term (Week 1), the protection rules (Week 9), and the assessment process (last week) all come together this week in a single document (the compliance matrix) — in the coming weeks, this document will be the first and most important page you present to the evaluator for your project.