Registered Information Security Specialist Exam — Autumn 2023 (Reiwa 5) Afternoon Question 2 Explained — Files Walking Out Over the Guest Wi-Fi

USB drives were banned. Saving files to the local disk was banned. Traffic to webmail and cloud storage the company had not approved was blocked. Attaching files to email was banned. The in-house file server was decommissioned.

Business files can still be taken out.

The afternoon session of the Autumn 2023 (Reiwa 5) Registered Information Security Specialist exam, Question 2, is set at apparel company M, which has already implemented all of the above, and asks candidates to find the holes that remain¹. This article is the second in a series that follows the explanation of Question 1 (stored XSS), and the ground it covers shifts from the web application to the internal network and device authentication.

Where Question 1 asked “where did the controls lined up in front of the web app get slipped past,” Question 2 asks “what scope did the design of the controls actually intend to protect.” None of M’s controls are wrong. But check the boundary each one was meant to cover, one at a time, and the space just outside it is left open.

What you get from this article, beyond model answers and their reasoning for each sub-question, is a set of practical review checkpoints — usable as-is in real work — covering three areas: wireless LAN, server certificates, and source-IP-address restrictions. It is written so that readers studying for the exam can read the sections by sub-question, while readers who only want the practical perspective can start directly from Sections 11 and 12.

1. The Bottom Line First

• The hole was the meeting room. Company M banned bringing personally-owned PCs onto the premises, but that ban only covered the office area — the meeting room was excluded. Both an employee wireless LAN and a guest wireless LAN reach the meeting room.
• Employees have two exfiltration routes: spoofing a MAC address to join the employee wireless LAN, and simply connecting to the guest wireless LAN. The latter is far easier — all it needs is the pre-shared key handed out to guests.
• Cloud storage (Service B) was restricted to “login only from Company M’s global IP address”. But traffic from the guest wireless LAN is translated to the same global IP address by the same NAT, so this restriction is bypassed outright. A restriction based on source IP address is a setting that permits, not a device, but everyone sharing an exit point.
• A fake AP plus fake site run by an outside attacker is stopped by server certificate validation. What actually does the work is two checks: “was it issued by a trusted certificate authority” and “does the certificate’s server name match the one being connected to.” According to IPA’s grading commentary, the correct-answer rate for the sub-question asking about these two points was low.
• Even a mistyped http:// still results in a certificate error, because HSTS rewrites it to HTTPS before connecting. And on a host where HSTS is active, the user must never be offered a way to click past the warning and continue.
• The legitimate file-sharing feature is also an exfiltration route: just enter your own personal email address as the external recipient. Manager approval existed, but some managers were not checking the recipient.
• The countermeasures rest on three pillars: switch the employee wireless LAN to EAP-TLS authenticated with a per-device client certificate, with the private key held in the TPM so it can never leave the business PC; separate the guest wireless LAN from Company M’s network (or split off its outbound global IP address); and delete the VLANs, filtering rules, and SSIDs that are no longer used.

2. About the Source Material — Attribution and How It Is Used Here

The question covered here is:

Source: Autumn 2023 (Reiwa 5) Registered Information Security Specialist Exam, Afternoon Session, Question 2

IPA states that, except where specifically provided for by law, no permission or licence fee is required to use its previously published exam questions. That does not mean it has waived copyright, however: it requires that the source be cited in the form “fiscal year, session, exam category, time slot, question number, etc.,” and that any modification to the question be noted as such².

This article does not reproduce the figures and tables from the question booklet verbatim. Where a diagram is needed to explain a mechanism, it has been replaced with a simplified diagram and summary written by us. The wording of the sub-questions and the model answers is likewise summarised. The original question booklet, model answers, and grading commentary can all be downloaded free of charge from IPA’s site, and we recommend keeping them open alongside this article^{1 3 4}.

Mapping of Sub-Questions to This Article

Feel free to start reading from whichever sub-question you want to work through.

How the Question Booklet’s Content Is Handled Here

So you can cross-reference against the original, here is a summary of what was done with each part.

3. The Setting — What Company M Had “Already Done”

Company M is a 100-employee apparel firm and a subsidiary of Company L. Its office building faces a busy street in central Tokyo. That one sentence matters later.

The previous year, an employee of Company M copied a confidential product-design file stored on the in-house file server onto a USB drive and carried it to a competitor. Under guidance from parent company L, a security review has been under way ever since. Three changes have already been made:

• Data-leak-prevention software has been installed on the laptops issued to employees (hereafter “business PCs”), configured to: block connection of external storage media such as USB drives; block saving files to the local disk except for software installation; block traffic to webmail and cloud storage that the company has not approved; block installation of unapproved software; and block attaching files to outgoing email.
• Business files are now all kept in a single cloud storage service already in use (hereafter “Service B”), whose settings have been reviewed.
• The in-house file server has been decommissioned.

The previous incident followed the route “in-house file server → USB drive,” so both ends of that route have been sealed off. The logic holds together.

Network Configuration

The office building has an office area and a meeting room. The employee wireless LAN is available in the office area; both the employee and guest wireless LANs are available in the meeting room. The meeting room’s projector is used by connecting either a device brought in by a guest (PC, tablet, or smartphone) or a business PC to the guest wireless LAN.

Drawn to include only what’s needed for the explanation, it looks like this:

flowchart LR
    subgraph M["Company M internal network"]
        direction TB
        G["Guest wireless LAN<br/>192.168.10.0/24<br/>meeting room AP only"]
        E["Employee wireless LAN<br/>192.168.20.0/24<br/>office area and meeting room"]
        S["Server network<br/>192.168.30.0/24<br/>DHCP, DNS, directory"]
        FW["FW<br/>NAT translates<br/>source to one<br/>global IP address"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Service B<br/>cloud storage"]
    FW --> I["Internet"]

The specifications that matter for the sub-questions are these:

And there are three security rules: business PCs may not be taken off-site; bringing personally-owned PCs, tablets, or smartphones into the office area is prohibited; business files may not be taken off-site by any method other than Service B’s file-sharing feature.

Did you notice the second rule says “into the office area”? The meeting room is not mentioned.

How the Question Proceeds

Ms. Y of the IT department, supported by Mr. S — a Registered Information Security Specialist at parent company L — checks whether the controls around exfiltration from Service B are sufficient. The two of them consider exfiltration by an outside attacker and exfiltration by an employee separately. Question 1 covers the former, Question 2 the latter, and Question 3 is about designing countermeasures.

4. The Fake Wi-Fi and the Fake Site — Sub-Questions 1(1) and 1(2)

Ms. Y first raises the scenario of a guest who has used the guest wireless LAN before acting as an attacker, connecting to the guest wireless LAN from near Company M, and accessing Service B.

This scenario works because the wireless LAN’s authentication method is WPA2-PSK. PSK (Pre-Shared Key) means, as the name says, that everyone shares the same key. The guest wireless LAN’s pre-shared key exists specifically to be given to guests. Once it’s been given out, there is no way to revoke that one person’s knowledge of it going forward (short of changing it for everyone). And because the office building faces a busy street, the signal reaches well outside the building.

Mr. S’s answer is straightforward: logging in to Service B requires [a] a user ID and [b] a password. That is the model answer for Sub-question 1(1) (order not significant). Merely being able to join the wireless LAN does not amount to logging in to Service B.

The Fake AP and the Fake Site

Ms. Y then pushes the scenario one step further: what about setting up a fake AP configured identically to the guest wireless LAN’s AP, plus a fake site at the same URL as Service B, with tampered DNS, to steal user IDs and passwords? Place a fake AP near Company M, and an employee’s business PC might mistakenly connect to it, then try to reach Service B, land on the fake site, and log in without realising.

This is the so-called evil twin. Standing up an AP with the same SSID and same pre-shared key as the guest wireless LAN makes it indistinguishable from the genuine AP as far as the device is concerned. Under WPA2-PSK, all a device can confirm about an AP is “it knows the same pre-shared key.” An AP that doesn’t know the key can’t complete the connection procedure — but conversely, anyone who does know the key can become “the genuine AP.” Since this is a key that’s handed out to guests, it should be assumed the attacker has it too.

Mr. S’s answer is again straightforward. When an employee tries to reach the fake site over HTTPS, the browser shows an error stating the connection is not secure, and — depending on the server certificate the fake site used — displays one or more of the following four items:

• This server certificate was not issued by a trusted certificate authority (blank c)
• The server name on this server certificate differs from the server name being connected to (blank d)
• This server certificate has been revoked
• This server certificate has expired

The bottom two of these were already given in the question booklet; Sub-question 1(2) asks for the top two (blanks c and d, each ≤40 characters, order not significant).

sequenceDiagram
    autonumber
    participant U as Employee business PC
    participant F as Fake AP / fake site<br/>attacker
    participant B as Service B - genuine

    Note over F: Stands up an AP with the same SSID and<br/>same pre-shared key as the guest wireless LAN
    U->>F: Mistakenly connects to the fake AP
    Note over F: Tampers with DNS so Service B's<br/>domain name resolves to the fake site
    U->>F: Connects to Service B's URL over HTTPS
    F-->>U: Fake site's server certificate
    Note over U: Validation fails<br/>- not issued by a trusted authority<br/>- certificate server name differs from the destination
    Note over U: Shows an error that the connection is not secure<br/>login screen is never shown
    Note over U,B: Never actually communicates<br/>with the genuine Service B

What Is Certificate Validation Actually Checking?

On this sub-question, the grading commentary says:

The correct-answer rate for Sub-question 1(2) was low. Even if an attacker prepares a fake site, accessing it over HTTPS causes server certificate validation to fail. Server certificate validation is fundamental knowledge for securing communications, and candidates should thoroughly understand exactly what is being checked.

In other words, plenty of people knew “you get a certificate error” without being able to break that down into the four specific items being checked. Organised by what each of the four items in Figure 2 is actually checking:

From the attacker’s perspective, the top two rows are the wall they cannot get over. A self-signed certificate fails on the first; even a legitimately obtained free certificate for the attacker’s own domain (say, b-service.example.net) fails on the second, because the destination is Service B’s domain. A certificate for Service B’s domain name can only be obtained by someone who controls that domain. This pair of checks can fairly be called the actual substance of the certificate mechanism.

RFC 5280 specifies certificate path validation⁵, and RFC 6125 specifies the procedure for matching the name on a certificate against the destination name⁶.

The Four Items Are Not Equally Strong

Here it’s worth separating what the exam expects as an answer from how browsers actually behave. The four items above are what the question’s Figure 2 lists as “the detail that may be displayed” — they should not be read as meaning every browser checks all four with equal rigour.

Issuer, server name, and expiry can all be determined from information already on hand at the moment the certificate is received, so they are always checked. These three are also what stops the attack in this question.

Revocation checking alone is a different matter. Whether a certificate has been revoked is not written in the certificate itself; it requires fetching separate information, so it depends on implementation and configuration.

• Chrome does not normally perform online OCSP or CRL checks. Instead it distributes a limited list called CRLSet, whose primary purpose is quickly blocking certificates in an emergency; only some entries drawn from CA revocation lists get folded into it⁷
• Even implementations that do query OCSP widely use a “soft-fail” configuration that lets the connection through when no response is received

So do not make “if the private key leaks, just revoke the certificate” the centrepiece of your countermeasures. Revocation is something you should do, but it is not a mechanism guaranteed to take effect in every user’s browser. The industry trend toward shorter certificate validity periods is itself partly an answer to the fact that revocation cannot be relied upon. If you suspect a key of your own has leaked, alongside filing for revocation you also need to swap the certificate and invalidate whatever the key was protecting — sessions, API keys, and so on.

A Practical Pitfall — Who Decides What Counts as a “Trusted Certificate Authority”

From here we’re beyond the text of the question. The first row of the table above depends on what that particular device trusts. The list of trusted authorities is held by the browser or OS; on Windows it’s the “Trusted Root Certification Authorities” certificate store.

Which means the first check passes in situations like these:

• A private certificate authority’s root certificate has been distributed to business PCs, and an attacker has gained control of that authority’s private key or its issuance process
• A proxy or security product that inspects traffic terminates TLS using its own root certificate installed on the device, and that product or its operation has been compromised by an attacker
• Someone in the past registered an exception, or added a self-signed certificate to the trusted roots, simply “because it kept throwing a certificate error”

The third of these is something we genuinely see all the time in the field: something added by hand to make an internal system’s certificate error go away, which then lives on inside a disk image inherited by machine after machine, long after whoever added it has left. What’s inside the Trusted Root Certification Authorities store is a literal declaration of who that device trusts, so make it a target of your inventories. Which stores should hold which certificates is worked through in the Windows certificate store practical guide.

There’s a separate practical concern around the second check (matching the server name). Certificates offer no protection against a user misreading the domain name. If an attacker registers a confusingly similar domain like b-serv1ce.example.com and legitimately obtains a certificate for it, the browser raises no error at all. What a certificate guarantees is “the destination server name matches the server name on the certificate” — not “that server name is who the user actually intended to reach.” A design that doesn’t leave that last step to the user’s own eyes is exactly what passkeys (WebAuthn) provide, by having the authenticator itself verify the origin. This is covered in more depth in Why Are Passkeys Secure?.

5. Why It Still Fails Even After Typing http:// — Sub-Question 1(3)

Ms. Y presses further. Suppose an employee, still connected to the fake AP, types the URL for Service B into the browser but mistakenly enters http:// — wouldn’t the error message not appear in that case?

A fair question. Connecting over plain HTTP means no server certificate ever enters the picture. It seems like the fake site could show a login screen with no error at all.

Mr. S’s answer: “That’s fine — because HSTS is enabled, the same error message appears even then.” Sub-question 1(3) asks, in ≤60 characters, what the browser does up to the point that error message is shown.

The model answer is: “It replaces the HTTP access with an HTTPS access before connecting. It then receives a server certificate from the fake site.”

What’s Actually Happening Inside the Browser

HSTS (HTTP Strict Transport Security) is a mechanism whereby a site declares, via a Strict-Transport-Security header, “from now on, always reach this host over HTTPS,” and the browser remembers that. It’s specified by RFC 6797⁸.

When the browser tries to access a remembered host over http://, it does the following:

1. Rewrites the URL’s scheme from http to https, converting port 80 to 443 if it was explicit (RFC 6797, Section 8.3)
2. Connects over HTTPS as a result. Because DNS has been tampered with, the actual destination is the fake site
3. Receives a server certificate from the fake site
4. Validation fails, producing the same error as in Section 4

The crucial part is that step 1’s rewrite happens before anything reaches the network. The plaintext HTTP request is never sent at all. So it never becomes a situation where “the connection was HTTP, so no certificate was involved.”

The User Can’t Click “Continue Anyway”

There’s another property of HSTS with major practical weight. Section 8.4 of RFC 6797 requires that if an error occurs while establishing a secure channel with an HSTS-active host, the connection be terminated regardless of whether the error is a warning or fatal. Section 12.1 describes this behaviour as “No User Recourse” and states that the user must not be offered a choice such as “this connection is not secure, continue anyway?”

For an ordinary certificate error, most browsers put a path through the warning screen — “advanced,” “proceed anyway.” In practice, it’s a common sight for a user who’s grown used to internal-system certificate errors to click through reflexively. HSTS blocks that reflex. Against a fake site, this “you simply can’t click through” property may matter even more than the certificate validation itself.

The Assumption Behind HSTS — It Can’t Protect the Very First Visit

HSTS does have a precondition, though. As Section 8.1 of RFC 6797 requires, a host only becomes a “known HSTS host” once the user agent has received a Strict-Transport-Security header over a secure channel. In other words, that browser needs to have reached the genuine site over HTTPS at least once already.

So it offers no protection in cases like:

• A newly issued business PC whose very first access happens to occur under a fake AP
• A rebuilt browser profile, or browsing data cleared so the HSTS record is gone too
• The recorded entry’s max-age having expired

The HSTS preload list exists to fill this first-time gap. If a domain is included in the list built into the browser in advance, it is forced onto HTTPS even on the very first access, with no prior visit required.

If you’re considering registering your own site, though, check the requirements first. The registration criteria are⁹:

• Serve a valid certificate
• If listening on port 80, redirect from HTTP to HTTPS on the same host
• Serve HTTPS on every subdomain (including www if there is a DNS record for it)
• Return a Strict-Transport-Security header on the base domain with max-age of 31536000 seconds (1 year) or more, plus includeSubDomains and preload

The third requirement, combined with includeSubDomains, is where things bite. If an old internal subdomain is HTTP-only, or has no certificate configured, it becomes unreachable the instant you register. Inventory every subdomain before registering.

And removal is not easy. Deletion requests are generally accepted, but it can take several months for the change to reach users’ browsers, and there is no guarantee for browsers other than Chrome⁹. Treat preloading as a setting that is not “just undo it if you got it wrong.”

Conversely, from the consuming side, whether a cloud service you’re using in your business supports HSTS is a reasonable thing to add to your vendor-selection checklist.

6. The Moment Approval Becomes a Formality, the Sharing Feature Becomes an Exfiltration Route — Sub-Question 2(1)

From here the discussion moves to exfiltration by an employee.

Mr. S starts by checking how the file-sharing feature is actually operated: does the approving manager properly check the recipient’s address and the file before approving? Ms. Y’s answer: “it seems some managers aren’t checking.”

That’s what leads Mr. S to Sub-question 2(1): describe concretely, in ≤40 characters, how the file-sharing feature could be abused to make a file downloadable from outside Company M.

The model answer is: “Enter your own personal email address as the external recipient’s address.”

The Design Is Sound; the Operation Has a Gap

Service B’s file-sharing feature is well thought out.

• Sharing requires manager approval
• The external share link is told to neither the sender nor the manager. The sender cannot forward the link out themselves
• The link contains a hard-to-guess random string and expires after one day

The second point in particular is a design built with insider exfiltration specifically in mind. And yet it still fails, because setting the recipient to yourself delivers a link “not told to the sender” straight into the sender’s own hands.

And the condition that opens this gap is exactly one thing: “the manager isn’t checking the recipient.” The approval workflow is designed on the assumption the approver actually looks at what’s in front of them. If they don’t, it’s just an automated delivery route.

The Conditions Under Which Approval Becomes a Formality Are Predictable

In practice, when approval becomes a formality, the cause is usually one of these:

What Company M lacks here is mainly the last two. Once you put in a mechanism to approve requests, you also need a mechanism to look back at what was approved. Simply being able to see a monthly list of external shares sent to free-email domains makes this kind of trick much easier to catch.

The bigger picture of where small and mid-sized companies should start is covered in Navigating IPA’s “Information Security Guidelines for SMEs” Version 4.0.

7. The Meeting-Room Loophole — Sub-Question 2(2)

Mr. S’s next question: “Can personally-owned PCs be brought into the meeting room?” Ms. Y’s answer: “Bringing them into the meeting room isn’t prohibited, so yes.”

This is where Methods 1 and 2 come in. Both follow the same plot: download files from Service B using a personally-owned PC, and walk out carrying that personal PC itself. The data-leak-prevention software configured on the business PC has zero effect on a personally-owned PC.

Method 1 — Spoofing the MAC Address

Method 1 is to change a personally-owned PC’s wireless interface’s [e] MAC address to match the MAC address of a business PC’s wireless interface, then connect that personal PC to the employee wireless LAN. Answering blank e is Sub-question 2(2).

Two things guarded the door to the employee wireless LAN: the WPA2-PSK pre-shared key, and MAC address filtering. An employee can get past both.

• The pre-shared key is configured on the business PC, and the employee is the one using that PC. Given that everyone shares one key, “the user is in a position to know it” has to be the starting assumption
• A MAC address can be rewritten on the device side — typically through OS settings or driver properties, no special tools required. On top of that, because wireless LAN frame MAC addresses are unencrypted, an attacker within radio range can also learn a registered business PC’s MAC address

MAC address filtering and hiding the SSID do have value as housekeeping to reduce accidental mis-connections. But they are not an authentication mechanism against someone trying to get in deliberately. It’s worth checking whether your own configuration counts these two among its actual defences.

Method 2 — Simply Connecting to the Guest Wireless LAN

Method 2 is simpler still. Connect a personally-owned PC to the guest wireless LAN, download files from Service B, and walk out with the personal PC. That’s it.

No MAC address spoofing is needed. All it requires is the guest wireless LAN’s pre-shared key — which is handed out to guests. There’s no way an employee wouldn’t know it.

The obvious question follows: wasn’t Service B restricted so that “the user IDs assigned to Company M’s employees can only log in from Company M’s global IP address”?

What a Source-IP-Address Restriction Actually Permits

Reading the firewall configuration in the question gives the answer. Traffic leaving both the guest wireless LAN and the employee wireless LAN for the internet is translated by the same NAT to the same single global IP address.

From Service B’s point of view, these three are indistinguishable. The IP-address restriction is simply bypassed.

This exact shape shows up again and again outside of exam questions too. A restriction based on source IP address does not mean “only this device.” It means “everyone who goes out via this global IP address.” Here are some common cases where the range you meant to permit and the range actually permitted come apart:

None of this means a source-IP-address restriction is worthless. It means don’t rely on it as a single layer. Only once you layer it with a mechanism that identifies the device itself (a client or device certificate) and a mechanism that identifies the user (multi-factor authentication) can you actually express “this specific person, on this specific device.” The countermeasures in this question head in exactly that direction.

8. Locking Down the Device With a Certificate — Sub-Questions 3(1)–(4)

As a countermeasure against Method 1, Company M decided to switch the employee wireless LAN’s authentication method to EAP-TLS and stand up an authentication server.

Sub-Question 3(1) — RADIUS

Sub-question 3(1) asks which UDP-based protocol the authentication server uses for EAP. The model answer is RADIUS.

Laid out, there are three parties involved:

Between the business PC and the AP it’s IEEE 802.1X (EAP over LAN); between the AP and the authentication server it’s RADIUS. RADIUS runs over UDP¹⁰. The EAP-TLS procedure itself is specified in RFC 5216¹¹. On Windows Server, the role of authentication server is played by Network Policy Server (NPS)¹².

Let’s pin down what actually changes going from WPA2-PSK to EAP-TLS.

The last row needs a caveat. In EAP-TLS, the party whose certificate the client validates is the authentication server, not the AP. The AP is just an authenticator relaying the EAP exchange; the client is not confirming the AP’s own identity.

Even so, this does defend against the evil twin from Section 4, because the key material generated only once authentication succeeds is delivered only to a genuine AP that holds the RADIUS shared secret. An AP an attacker sets up on its own can never complete this procedure unless it has a genuine authentication server behind it. What the client directly validates is the authentication server; the AP’s legitimacy is derived from that indirectly.

There is a condition attached, though: unless the client is configured with which certificate authority’s, and which named, server certificate to trust, it cannot tell the difference if an attacker sets up their own authentication server. Configurations do exist in the real world where EAP-TLS has been deployed, but server certificate validation has been left disabled in the client profile. If you deploy this, verify that this piece is actually configured too.

Sub-Question 3(2) — The Wrong Answer the Grading Commentary Called Out

Ms. Y’s explanation continues: client certificates are issued from a newly built CA server and, rather than employees installing them on their own business PCs, they are distributed to business PCs through the directory server’s functionality. And whatever corresponds to a client certificate — [f] — is stored in the business PC’s TPM in order to be [g] and protected there.

Sub-question 3(2) asks for blank f. The model answer is private key.

The grading commentary says:

The correct-answer rate for Sub-question 3(2) was somewhat high, but some candidates answered “public key” or “server certificate.” PKI is foundational to a wide range of security technologies, so candidates should have a solid grasp of how and in what contexts it is actually used.

A public key is what ends up inside the certificate and is handed out to the world. It is not something that needs protecting. What must be protected is the private key, which only the certificate’s rightful owner should hold. To be more precise, “authenticating with a client certificate” means “proving you hold the private key that corresponds to the public key in the certificate, by using that key to produce a signature.” So the moment the private key can be copied, authentication by certificate loses its meaning.

What Actually Changes When You Put It in the TPM — Sub-Question 3(3)

Sub-question 3(3) asks for blank g in ≤20 characters. The model answer is “so it cannot be taken off the business PC.”

If the private key sits on the device as a file, it’s data that can be copied. Copy it to a personally-owned PC, and that PC passes authentication as if it were the business PC. Closing off Method 1 (MAC spoofing) would just get replaced by “certificate spoofing.”

A TPM can generate a key inside itself and hold it in a state where it can never be taken out. Operations like signing happen inside the TPM; the key itself never reaches the OS, any application, or any malware. The result is that the private key is pinned to that one physical component.

On Windows, this is implemented by specifying Microsoft Platform Crypto Provider as the certificate template’s key storage provider (KSP). This provider protects keys using the TPM, and cannot be selected if the certificate template has “Allow private key to be exported” checked¹³ — a natural constraint, since protection is meaningless if the key can be exported anyway.

The role of the TPM component itself is covered from the drive-encryption angle in the BitLocker practical guide. The idea of “never letting the private key leave the device” is the same design philosophy behind authenticators, which we explain in Why Are Passkeys Secure?.

Why Can We Say It’s “Acceptable”? — Sub-Question 3(4)

Having heard Ms. Y’s explanation, Mr. S responds, “with that storage method, I think it’s fine.” Sub-question 3(4) asks for the reason, in ≤40 characters.

The model answer is: “Because the authentication data EAP-TLS needs can only be stored on a business PC.”

Following the chain of logic:

1. The client certificate isn’t installed by the employee themselves — the directory server delivers it to the business PC. The employee is never in the loop
2. The private key lives inside the TPM and can’t be taken off the business PC
3. So the only devices that can authenticate to the employee wireless LAN via EAP-TLS are business PCs the company issued
4. A personally-owned PC cannot pass authentication even by spoofing its MAC address — Method 1 is shut down

Notice the conditional phrasing “with that storage method.” Had the private key been stored as a plain file on the business PC, Mr. S would not have said it was fine. The same phrase “authentication by client certificate” can protect very different ranges depending on how the private key is stored.

What the TPM Does Not Protect Against

That said, putting the key in the TPM is not a blanket guarantee of safety. What the TPM guarantees is only “that key cannot be copied to another device.” It does not protect against:

• The device itself being taken off-site. Walk out with the business PC, and you’ve walked out with the TPM inside it. Company M’s rules ban taking business PCs off-site, but a rule and a technical enforcement of that rule are two different things. Drive encryption (including pre-boot authentication) and a procedure for revoking the certificate on loss need to exist separately
• Impersonation of the user. The TPM identifies the device, not who is operating it. User authentication is still needed on top
• Malware running on the device. The private key can’t be read out, but code running on that device can still ask the TPM to produce a signature. Key duplication is prevented, but abuse during the window while the device is compromised is not

9. Splitting Off the Exit IP Address — Sub-Question 3(5)

As a countermeasure against Method 2 (simply connecting to the guest wireless LAN), Company M considers two options: changing the firewall’s NAT configuration, or using an outside wireless service (Service D).

Sub-question 3(5) asks for the content of the former change, in ≤70 characters. The model answer, in substance, is: “make the source IP address used when accessing the internet from the guest wireless LAN a different IP address from the one currently used” (the question booklet denotes that global IP address as a1.b1.c1.d1).

As seen in Section 7, Method 2 works because guest wireless LAN traffic exits via the same global IP address as employee traffic. So it follows that if only the guest wireless LAN is translated to a different global IP address, Service B’s IP restriction stays as it is, and only access from the guest wireless LAN falls outside it.

This works because Company M’s WAN side has more than one global IP address allocated. Reading the firewall interface configuration in the question, the WAN-side subnet mask is 255.255.255.248 — a /29 — showing more than one usable address is available. A subtle but deliberate detail planted in the question’s tables, meant to be read closely.

Whether your own organisation can do the same depends on whether your line contract lets you use multiple global IP addresses. If you only have one, this option is off the table, and you’d need the separation approach in the next section instead.

10. Deleting Unused Configuration Is Part of the Fix — Sub-Questions 3(6) and 3(7)

After weighing the options, Company M decided to use Service D.

• A wireless router leased from Service D (the “D router”) is installed in the meeting room
• On the D router, the DHCP server function and DNS cache server function are enabled
• Guest-brought devices connect to the internet without going through Company M’s network at all, via a SIM built into the D router
• The projector stops using the guest wireless LAN and switches to an HDMI cable instead

flowchart LR
    subgraph M["Company M internal network - after countermeasures"]
        direction TB
        E["Employee wireless LAN<br/>EAP-TLS + RADIUS<br/>private key inside the TPM"]
        S["Server network"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Meeting room"]
        T["Guest-brought device"]
        D["D router<br/>SIM straight to the internet"]
        T --> D
    end
    FW --> B["Service B"]
    D --> I["Internet"]

The guest network is now separated from Company M’s network both physically and logically. It no longer even exits via the same global IP address.

Sub-Question 3(6) — Traffic That’s No Longer Needed

Once guest-brought devices no longer use Company M’s network, the DHCP server and [h] server traffic that used to be needed becomes unnecessary. The model answer for blank h is DNS.

Because the D router itself has DHCP server and DNS cache server functions, guest-brought devices no longer need the DHCP or DNS servers on Company M’s server network. Re-reading the question’s own description gives you this answer directly.

Sub-Question 3(7) — Listing Every Setting to Delete

Sub-question 3(7) asks candidates to list every row number that should be deleted from the firewall’s VLAN interface settings and filtering settings as a result of this change.

The answer: from the VLAN interface settings, the guest wireless LAN’s VLAN (row 1); from the filtering settings, the rule permitting HTTP/HTTPS from the guest wireless LAN to the internet (row 1) and the rule permitting access from the guest wireless LAN to the server network’s DNS (row 4) — two entries. In addition, the guest SSID configuration should be removed from the AP settings.

The grading commentary says:

The correct-answer rate for Sub-question 3(7) was high. Candidates needed to understand the implications of the wireless LAN review across all of the firewall’s filtering settings, and this was well understood.

Despite the high correct-answer rate on the exam, plenty of organisations don’t actually follow through on this in real operation. Adding a new mechanism comes with a budget and a deadline attached; deleting old configuration does not. And forgetting to delete it tends to surface like this:

The firewall in this question evaluates rules in order from the lowest row number and applies the first match (the question booklet states this explicitly). Under this evaluation model, leaving an unused permit rule sitting near the top has the same effect as leaving a hole open that never lets traffic reach the deny rule at the bottom.

Do not generalise this evaluation model to every firewall, though. Different products decide differently.

Whichever model applies, leaving an unused permit rule in place is dangerous regardless. What changes is why it’s dangerous and how you fix it. Confirm which model your own equipment uses, and add “does the source and destination even still exist” to the checklist for your periodic inventories.

The host-side firewall question — how to manage the inbound rules a business application actually needs — is covered in Windows Firewall and Business Applications.

11. Controls That Didn’t Work, and Controls That Did

Summarised into a single table: the controls Company M had, and where each one was actually bypassed.

Only that last row is a “worked.” And here’s how the proposed countermeasures line up:

Line these two tables up and the difference in character is obvious. The controls that got bypassed are mostly bans on a “means.” The controls that worked, and the ones proposed, change the “route” or the nature of the “credential.” Blocking USB drives means nothing if a route to the files remains; lengthening a pre-shared key doesn’t change the fact that it’s still a shared secret.

12. Practical Review Checkpoints

Here are the checkpoints for mapping this question onto your own environment.

1. Can you write your exfiltration controls in terms of routes, not means? Rather than a list of means (USB drives, email attachments, webmail), build “a list of every device and network that can reach business files.” If even one route reaches the files from an unmanaged device, banning means is just being routed around
2. Do your bring-in/take-out rules quietly leave a location unrestricted? “Bringing devices into the office area is banned” implicitly permits the meeting room, reception, and shared spaces. Check whether your physical zoning matches your network zoning
3. Can you state exactly what your source-IP-address restriction actually permits? Count everything that exits via that global IP address: guest Wi-Fi, guest networks, site-to-site VPNs, remote-work aggregation gateways, staging environments
4. Is your wireless LAN credential per-device? A pre-shared key is a secret everyone holds identically — one leak leaks it for everyone, and it can’t be used to block a single device
5. Are you counting MAC address filtering and a hidden SSID among your defences? Both are housekeeping to reduce accidental mis-connections, not authentication
6. Can a client certificate’s private key be removed from the device it’s on? A key stored as a file can be copied. Specify a TPM-backed key storage provider, and disallow export
7. Does your EAP-TLS client actually validate the authentication server’s certificate? Disable this, and you lose all resilience against a fake authentication server
8. Can a user click “continue” past a server certificate error? Enable HSTS on your own sites. Don’t let a neglected internal-system certificate error teach users that “an error is something you click past”
9. Do you inventory what’s inside the Trusted Root Certification Authorities store? Whatever is in there is a literal declaration of who that device treats as genuine, based on which certificate authority issued it
10. Do approvers in your approval workflows actually have enough information to judge? And is anyone reviewing approvals afterwards? Periodically review external-domain and free-email-domain shares
11. Have you actually deleted configuration for retired routes? VLAN interfaces, filtering rules, SSIDs, allowlist entries. Give the “delete” work a deadline, the same way you’d give the “add” work one

Closing — A Control With No Stated Scope Doesn’t Protect Anything

If Question 1 asked “which stage of which attack does this control actually stop,” Question 2 asks “what scope does this control actually protect.”

Every control Company M had came with an implicit scope. The data-leak-prevention software’s scope stopped at the business PC. The bring-in ban’s scope stopped at the office area. MAC address filtering’s scope stopped at “whoever doesn’t spoof it.” The source-IP restriction’s scope stopped at “everyone exiting via that one global IP address.” Each of these worked correctly within its own scope — it’s just that the seam next to it was left open.

What makes this question feel true to practice is that Company M is portrayed as a company that took security seriously. Following the previous year’s incident, they sealed off both ends of that route and even deployed dedicated software. And still a hole remained — not because anyone was careless, but because adding controls one at a time doesn’t reveal the gaps between their boundaries.

Finding those gaps requires writing out a list of routes, not a list of controls. That is exactly what Ms. Y and Mr. S were doing throughout this question: splitting the problem into “an outside attacker” and “an employee,” and, for each, sealing off the reachable routes one by one. What IPA’s stated exam intent calls “the ability to anticipate threats in a wireless-LAN-based environment from a variety of angles” is, in the end, this exact exercise.

Related Consulting Areas

KomuraSoft LLC works on design reviews premised on an existing network and device configuration, and on implementing certificate distribution and key protection within Windows environments.

• Technical Consulting / Design Review
• Windows App Development
• Bug Investigation & Root-Cause Analysis
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

We banned USB drives and banned saving to the local disk. Why can files still be taken out?

Because what was banned was a function of the business laptop the company issued, not the route to where the files live. In this question, the employee uses their own personally-owned PC. Without touching the business PC at all, they connect their personal PC to the wireless LAN in the meeting room, log in to the cloud storage (Service B) with their own user ID, download the files, and walk out with the personal PC itself. The data-leak-prevention software configured on the business PC has no effect whatsoever on a personally-owned PC. Company M did ban bringing personally-owned PCs onto the premises — but only into the office area; the meeting room was excluded. Even if you block the means one by one (USB drives, email attachments, webmail), the exfiltration still succeeds as long as some route to the files remains.

Service B was restricted to "login only from Company M's global IP address". Why does that not stop access from the guest wireless LAN?

Because traffic from the guest wireless LAN also passes through the same firewall's NAT and is translated to the same global IP address before it reaches the internet. From Service B's point of view, access from a business PC inside the office and access from a personally-owned PC connected to the guest wireless LAN in the meeting room both look like the same source IP address. They cannot be told apart. A restriction based on source IP address needs to be understood as permitting not "only this device" but "everyone sharing this exit point". Guest Wi-Fi, site-to-site VPNs, and aggregation gateways for remote work — anything that goes out via the same global IP address — all fall inside the permitted range.

The employee wireless LAN had MAC address filtering in place. Doesn't that count as a countermeasure?

No. A MAC address can be freely rewritten on the device side. Method 1 in this question was to change the MAC address of a personally-owned PC's wireless adapter to match the MAC address of a registered business PC, then connect. Because MAC addresses in wireless LAN frames travel unencrypted, an attacker who receives the signal nearby can also learn a registered MAC address. The same is true of hiding the SSID. Even with SSID broadcast disabled, the SSID becomes apparent from the exchange that happens when a device connects. MAC address filtering and a hidden SSID reduce accidental mis-connections, but they are not an authentication mechanism that stops someone connecting on purpose.

Even with a fake access point and a fake site set up, why can we say the employee won't be fooled?

Because as long as the connection is over HTTPS, a fake site cannot pass server certificate validation. Figure 2 in the question lists four items that can appear as the detail of the resulting error: not issued by a trusted certificate authority; the server name on the certificate differs from the server name being connected to; revoked; and expired. An attacker cannot obtain a legitimate certificate for Service B's domain name, so a self-signed certificate fails on the first point, and a certificate legitimately obtained for the attacker's own domain fails on the second. According to IPA's grading commentary, the correct-answer rate for the question asking about this validation content was low. Note that these four items do not carry equal weight. What actually stops the attack is the first two (issuer and name) plus the expiry date — browsers always check these. Revocation checking, by contrast, depends on implementation and configuration. Chrome, for instance, does not normally perform online OCSP or CRL checks; instead it uses a limited list called CRLSet, whose primary purpose is emergency blocking. Do not assume that revoking a certificate is guaranteed to block it. And if a business PC has a corporate certificate authority's root certificate distributed to it, and that authority's private key or issuance process has been compromised by an attacker, the first check passes too.

What happens if someone mistypes the URL as "http://"? What is HSTS actually doing?

The browser rewrites HTTP to HTTPS before connecting, so the result is again a server certificate error. HSTS is a mechanism by which the browser remembers the contents of a header it received the last time it connected to that site over HTTPS. RFC 6797 requires that when a URL for the target host contains the http scheme, the user agent replace it with https, converting port 80 to 443 if it was stated explicitly. In other words, the plaintext HTTP request never leaves the machine. Even more important: if certificate validation fails during communication with a host for which HSTS is active, the specification requires the connection to be terminated regardless of whether the error is a warning or fatal. It states explicitly that the user must not be offered a choice such as "this connection is not secure, continue anyway?" That said, HSTS assumes the browser has already reached the genuine site once over HTTPS and received the header. It offers no protection if the very first access from a brand-new device happens to hit a fake site. The browser's built-in preload list is what fills that first-time gap.

What changes when a client certificate's private key is stored in the TPM?

The private key can no longer be taken off that business PC. A private key kept as a file on the device can simply be copied to a personally-owned PC, letting that PC pass authentication as if it were the business PC. If the key is generated inside the TPM and set never to be exported, operations such as signing happen entirely inside the TPM, and the key itself never reaches the OS or any malware. The result is that only the business PCs the company issued can complete EAP-TLS authentication. This is why Mr. S could say "that storage method is fine." Implementing this on Windows means specifying Microsoft Platform Crypto Provider as the certificate template's key storage provider, with private key export not permitted. Note that the TPM only protects against the key being copied to another device — it does nothing to stop someone who physically has that device from using it. Loss or theft of the device itself still needs to be covered separately, with drive encryption and certificate revocation.

What should we take back to our own practice from this question?

Four things. First, think about exfiltration countermeasures in terms of routes, not means. Blocking USB drives, email attachments, and webmail one at a time means nothing if a device that can still reach the files remains. Second, write out what a source-IP-address restriction actually permits. If guest Wi-Fi or a VPN shares the same exit point, that is inside the permitted range too. Third, make wireless LAN authentication a per-device credential. A pre-shared key is a shared secret everyone holds identically, so if one person leaks it, everyone's credential is leaked. Moving to EAP-TLS with client certificates, and keeping the private key from ever leaving the TPM, ties the credential to the device. Fourth, delete configuration you no longer use. The final sub-question in this problem asks the candidate to list every VLAN interface setting and firewall filtering rule left over after the guest wireless LAN is retired — and according to IPA's grading commentary the correct-answer rate was high, yet not many organisations actually follow through on this in practice.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.