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

USB drives banned, saving to the local disk banned, email attachments banned, the internal file server retired. Even then, a route for taking business files out was still there.

What Afternoon Question 2 of the Autumn 2023 (Reiwa 5) Registered Information Security Specialist Examination asks about is not the number of countermeasures but who can reach the files, from which device, over which route. Countermeasures that work on a business PC and countermeasures that stop access from a personally owned PC have to be considered separately.¹

This article is the second in a series that follows the explanation of Question 1 (stored XSS). Each sub-question is followed in the order “model answer, then the evidence in the question text, then the mechanism,” and the practical cautions that go beyond the exam’s premises are collected in Chapter 10. The figures and tables of the question booklet are not reproduced as they are; simplified diagrams and summaries of our own are used instead. The sources and the scope of quotation and summary are given at the end.¹²

1. The Big Picture First — Separate the Outside Attacker from the Employee

This question falls into place if you read it in the following three stages.

An outside attacker has to steal credentials, whereas an employee can log in with their own legitimate ID. The data-leak-prevention software on the business PC has no effect on the personally owned PC the latter uses. On top of that, what Service B’s source IP address restriction looks at is not the device but the NAT exit point. This difference is what ties the whole question together.

Go from a Sub-Question to the Chapter You Need

If you are preparing for the exam, get the premises straight in Chapter 2 first, then move on to the sub-question you want to solve. If your goal is a design review in practice, start from the countermeasure comparison in Chapter 11 and the checklist in Chapter 12, and check the conditions and exceptions in Chapter 10.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (24 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. The Premises of the Question — What Company M Protected and What It Permitted

2.1. The Previous Year’s Incident and the Countermeasures Already Taken

Company M is a subsidiary of Company L, an apparel business with 100 employees. Its office building faces a busy main street in central Tokyo. In the previous year, an employee saved product design files from the internal file server onto a USB drive and took them to a competitor. Following guidance from its parent company, Company M has already completed the following review.¹

These are coherent countermeasures that block both ends of the previous year’s “internal file server to USB drive” route. But the restrictions on the PC reach only as far as the business PCs that have that software installed.

2.2. The Rules Cover the Meeting Room and the Office Area Differently

There are three security rules.

The employee wireless LAN is available in the office area, and both the employee and the guest wireless LANs are available in the meeting room. The projector in the meeting room was set up so that visitor-brought devices (PCs, tablets, smartphones) and business PCs connect to the guest wireless LAN in order to use it.

2.3. The Networks Are Separate, but the Exit to the Internet Is the Same

Transcribing only the parts needed for the explanation, the configuration is as follows.

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 the source<br/>to a single global<br/>IP address"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Service B<br/>(cloud storage)"]
    FW --> I["Internet"]

Figure 1: A simplified diagram of Company M’s configuration. The guest, employee and server networks are separate, but internet-bound traffic passes through the NAT on the same firewall.

2.4. Service B’s “Login” and “External Sharing” Are Separate Doors

There are two ways to use Service B.

The sharing link is disclosed neither to the requester nor to the manager. It contains a random string that is hard to guess, and it expires after one day. On the other hand, the external recipient can download without logging in. Do not let the login restriction on employee IDs stand in for an explanation of how the sharing link is used.

Taking this configuration as given, Mr. Y of the information systems department and Mr. S, a Registered Information Security Specialist at parent company L, work through the outside attacker, then the employee, then the additional countermeasures, in that order.

3. Questions 1(1) and 1(2) — Even After Connecting to a Fake AP, Logging In to a Fake Site Is Stopped

3.1. Question 1(1): Connecting to the Wireless LAN Still Requires an ID and a Password

Model answer: blanks a and b are “user ID” and “password” (in either order).²

The first scenario Mr. Y considers is a visitor who has used the guest wireless LAN before connecting again on a later day from near Company M and reaching Service B. Because the building faces a main street, the possibility that the radio signal reaches outside the premises has to be taken into account.

WPA2-PSK is a scheme in which everyone holds the same pre-shared key. There is no way to return just one party you have already told to a state of not knowing it; revoking it means changing the key for everyone. But connecting to the wireless LAN and logging in to Service B are two different things. An outside attacker does not have an employee’s user ID and password.

3.2. Question 1(2): A Fake Site’s Certificate Fails on Its Issuer and Its Server Name

The next scenario is an attack that prepares a fake AP configured identically to the guest wireless LAN and a fake site at the same URL as Service B, then tampers with DNS settings to steal login credentials. The aim is for an employee’s business PC to connect to the fake AP by mistake.

A fake AP that uses the same SSID and the same pre-shared key is called an evil twin. What WPA2-PSK confirms is that the other side knows the same key. Without the key the connection procedure cannot be completed, but an attacker who knows the key handed out to visitors can set up an AP that is hard to tell apart from the genuine one.

Even so, connecting to Service B’s URL over HTTPS brings server certificate validation into play. Filling in the blanks, the error detail given in Figure 2 of the question booklet comes to the following four items.

• This server certificate is not a server certificate issued by a trusted certificate authority (blank c)
• The server name written 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

What Question 1(2) asks you to write is the first two items above (c and d, 40 characters or fewer each, in either order). The revocation and expiry items are given in the question text from the start.²

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

    Note over F: Sets up an AP with the same SSID and<br/>the same pre-shared key as the guest wireless LAN
    U->>F: Connects to the fake AP by mistake
    Note over F: Tampers with DNS to point Service B's<br/>domain name at the fake site
    U->>F: Connects to Service B's URL over HTTPS
    F-->>U: Server certificate of the fake site
    Note over U: Validation fails<br/>- Not issued by a trusted certificate authority<br/>- The certificate's server name differs from the destination
    Note over U: Shows an error saying the connection is not secure<br/>The login screen is never displayed
    Note over U,B: There is no communication with the<br/>genuine Service B in the first place

Figure 2: Even after a connection to the fake AP, HTTPS server certificate validation remains. Authenticating to the wireless LAN and confirming the site you reached are separate stages.

3.3. Do Not Stop at “Certificate Error” — Say What Was Validated

With a self-signed certificate the chain cannot be traced up to a trusted root. Even if the attacker legitimately obtains a certificate for their own domain (b-service.example.net, say), it will not match Service B’s domain name. Under the question’s premises the attacker does not control Service B’s domain and therefore cannot obtain a legitimate certificate for that name, and that is the basis of the answer.

Certification path validation is described in RFC 5280 and name matching in RFC 6125.³⁴

IPA’s grading commentary says the following about Question 1(2).⁵

The correct-answer rate for Question 1(2) was low. Even if an attacker prepares a fake site, server certificate validation fails as long as the access is over HTTPS. Validating a server certificate is basic knowledge for securing communication, so we would like candidates to understand it well, down to exactly what items are validated.

What is being asked is not only the outcome that “an error appears” but whether you can name the issuer and the name specifically. In practice, though, the revocation checking implementation and the device’s trust store also need to be checked. The point that the four items do not always take effect with the same certainty is covered in Sections 10.1 and 10.2.

4. Question 1(3) — HSTS Rewrites HTTP to HTTPS Before It Is Sent

4.1. The Answer Runs from “Rewrite” to “Receive the Certificate”

The sub-question asks, in 60 characters or fewer, how the browser behaves up to just before the error is displayed when an employee connected to the fake AP mistakenly types Service B’s URL as http://.

Model answer: “It replaces the HTTP access with HTTPS access and connects. It then receives a server certificate from the fake site.”²

HSTS (HTTP Strict Transport Security) is a mechanism by which the browser remembers a Strict-Transport-Security header received over HTTPS and from then on connects to that host over HTTPS. It is specified in RFC 6797.⁶

Access to a known HSTS host proceeds in the following order.

1. Inside the browser, the URL’s scheme is replaced from http with https. If port 80 was stated explicitly, it is converted to 443.
2. It connects over HTTPS. In this question, however, DNS has been tampered with, so the destination is the fake site.
3. It receives a server certificate from the fake site.
4. Certificate validation fails, producing the error from Chapter 3.

This is not a matter of sending a plaintext HTTP request and then switching. The replacement is complete before anything goes out onto the network. Because the sub-question asks only for what happens up to just before the error, the model answer describes only as far as step 3.

4.2. HSTS Also Has the Job of Not Letting Users Ignore the Warning and Continue

Section 8.4 of RFC 6797 requires that if an error occurs while establishing a secure transport with a known HSTS host, the connection be terminated regardless of whether the error is a warning or fatal. Section 12.1 describes this as “No User Recourse.”⁶

For an ordinary certificate error, most browsers offer a path through “Advanced” and “Proceed.” For a host where HSTS is active, that escape route must not be offered to the user. Shutting down the reflex of clicking straight through a certificate error is what matters as a defense against fake sites.

4.3. The Premise Is That the Browser Holds a Valid HSTS Record

HSTS being configured on the site does not by itself protect the first access from every device. Normally the browser must have reached the genuine site over HTTPS and received the header.

The record is unavailable for the first access from a new business PC, when it was wiped along with a rebuilt browser profile or cleared browsing data, or when the record’s max-age has expired. What fills the first-access gap is the browser’s HSTS preload list. The registration requirements and how hard removal is are explained in Section 10.3.

5. Question 2(1) — Even the Legitimate Sharing Feature Becomes an Exfiltration Route If Nobody Checks the Recipient

5.1. The Basis of the Answer Is That Managers Are Not Checking the Recipient

From here on the subject is an employee who holds a legitimate user ID. Question 2(1) asks, in 40 characters or fewer, how the sharing feature can be abused so that a file becomes downloadable from outside Company M.

Model answer: “Specify the employee’s own private email address as the external recipient’s email address.”²

Service B has manager approval, and the sharing link is disclosed neither to the requester nor to the manager. There is a hard-to-guess string and a one-day expiry as well. Even so, making the recipient your own private address means you receive the link yourself as the external recipient. There is no need to guess the link or to attach a file to email from the business PC.

In the question text, Mr. Y answers that there are managers who are not checking the recipient’s email address and the file. What is missing is not the approval mechanism itself but the operational premise that the approver checks the recipient.

5.2. Whether Approval Exists and Whether Its Content Is Checked Are Separate Questions

An approval workflow presupposes that the approver looks at what is being approved. If nobody looks, it stops being a mechanism for blocking inappropriate sharing and becomes a delivery route for the link.

In practice the number of approvals, the material the approver judges with, business deadlines, and after-the-fact review of approval outcomes are designed together. A concrete review table is given in Section 10.4.

6. Question 2(2) — A Personally Owned PC Reaches Service B from the Meeting Room

6.1. What Both Share Is That They Do Not Use the Business PC

Bringing a personally owned PC in was prohibited only in the office area; it can be brought into the meeting room. Method 1 and Method 2 in the question text are both routes that download the files onto a personally owned PC and carry the PC itself out.

The download destination lies outside the data-leak-prevention software’s control. Prohibiting USB drives and local saving on the business PC has no effect on this route.

6.2. Question 2(2): What Is Changed Is the MAC Address

Model answer: blank e is “MAC address.”²

In Method 1 the MAC address of the personally owned PC’s wireless LAN interface is changed to that of a business PC. Because the employee is a user of a business PC, they are in a position to know the shared pre-shared key. A MAC address can likewise be changed in the device’s settings or the driver’s properties, and because it is not encrypted in wireless LAN frames, receiving them nearby is enough to learn a registered address.

Hiding the SSID is no countermeasure either against learning the SSID from the exchange that takes place when a device connects. MAC address filtering and a hidden SSID can serve as housekeeping that reduces mis-connections, but they are not a mechanism for authenticating someone who connects on purpose.

6.3. Method 2 Is Simply Connecting to the Guest Wireless LAN

Using the pre-shared key handed out to visitors, an employee too can connect a personally owned PC to the guest wireless LAN. All that is left is to log in to Service B with their own user ID and download.

Why does the restriction to “only from Company M’s global IP address” let this through? The answer lies in the firewall’s NAT configuration.

The source IP address Service B sees is the same in every case. This configuration on its own cannot tell a business PC on the employee wireless LAN apart from a personally owned PC on the guest wireless LAN.

A source IP address restriction permits not a device but everything that shares that exit point. This is not to say the restriction is unnecessary; you need to know what it actually permits and layer it with device authentication and user authentication. Practical examples are given in Section 10.5, and the countermeasures within the question in Chapters 8 and 9.

7. Questions 3(1) to 3(4) — EAP-TLS and the TPM Limit Which Devices Can Connect

7.1. Question 3(1): Between the AP and the Authentication Server It Is RADIUS

As a countermeasure against Method 1, the employee wireless LAN moves to EAP-TLS and an authentication server is set up. Question 3(1) asks for the protocol over UDP that the authentication server uses with EAP, and the model answer is “RADIUS.”²

Between the business PC and the AP it is IEEE 802.1X (EAP over LAN); between the AP and the authentication server it is RADIUS. RADIUS is specified in RFC 2865 and the EAP-TLS procedure in RFC 5216. When the authentication server is built on Windows Server, Network Policy Server (NPS) takes that role.⁷⁸⁹

In the last row of the table, what the client validates a certificate against is the authentication server, not the AP. Configuring on the client side which certificate authority and which server name to trust is part of the premise; choosing EAP-TLS is not enough on its own. Section 10.6 goes into the detail.

7.2. Question 3(2): What Is Protected Is the Private Key, Not the Public Key

A CA server is newly installed to issue client certificates, and they are placed on business PCs through the directory server’s function rather than by hand by the employees. Blank f is what corresponds to that certificate and is protected by the TPM, and the model answer is “private key.”²

The public key is contained in the certificate and is information you may hand to the other side. What authentication proves is possession of the corresponding private key. Possession is shown by signing with that key, so if the private key is duplicated, another device can use the same credential.

IPA’s grading commentary also points out how important it is to distinguish the private key from the other elements.⁵

The correct-answer rate for Question 3(2) was somewhat high, but some answers such as “public key” and “server certificate” were seen. PKI is an important technology that underpins a wide range of security technologies, so we would like candidates to understand well where and how it is used.

7.3. Question 3(3): Store It in the TPM So It Cannot Be Taken Off the Business PC

Blank g asks, in 20 characters or fewer, the purpose of storing it in the TPM. The model answer is “so that it cannot be taken off the business PC.”²

If the private key is left on the device as a file, it is data that can be copied. Copy it to a personally owned PC and that PC passes authentication as a business PC. You think you have closed off Method 1 (MAC address spoofing), but it is simply replaced by “certificate spoofing.”

The TPM can generate a key inside itself and hold it in a state where it cannot be taken out. Operations such as signing are performed inside the TPM, and the key itself is handed neither to the OS, nor to applications, nor to malware. The result is that the private key is pinned to a single physical component in a single machine.

To implement this on Windows, specify Microsoft Platform Crypto Provider as the key storage provider (KSP) in the certificate template. This provider protects keys using the TPM, and it cannot be selected while “Allow private key to be exported” is checked in the certificate template¹⁰. It is the obvious constraint: there is no point protecting a key that can be exported anyway.

The role of the TPM as a component is covered from the drive-encryption angle in the BitLocker Practical Guide. The idea of never letting a private key leave the device is the same thinking behind the authenticator design explained in Why Are Passkeys Secure?.

7.4. Question 3(4): Explain the Distribution Target and the Key Protection Together

This sub-question asks, in 40 characters or fewer, why Mr. S answered that there was no problem if that storage method was used.

Model answer: “Because the credentials EAP-TLS requires can only be stored on a business PC.”²

The reasoning runs as follows.

1. Client certificates are distributed from the directory server to business PCs and never pass through employees’ hands.
2. The corresponding private key is protected by the TPM so that it cannot be taken off the business PC.
3. Because the credentials cannot be moved to a personally owned PC, spoofing a MAC address will not get past EAP-TLS authentication.

What matters is the condition “if that storage method is used.” Hand over the private key as a file that can be copied and the same conclusion no longer follows. On the other hand, what the TPM stops is duplication of the key; carrying the device itself out, impersonation of the user, and malware on the device are separate problems. Section 10.7 sets out the limits.

8. Question 3(5) — Change the NAT Exit for the Guest Wireless LAN Only

Two proposals address Method 2: changing the NAT configuration, and separating the guest network onto a different wireless LAN service (Service D).

Question 3(5) asks, in 70 characters or fewer, what to change in the NAT configuration. The gist of the model answer is to “make the source IP address used when accessing the internet from the guest wireless LAN an IP address other than the global IP address currently in use.” The question text denotes the current address as a1.b1.c1.d1.²

This is not a change to the IP address restriction on Service B’s side. Only the guest wireless LAN is translated to a different global IP address, taking it out of the existing permitted range.

What makes this proposal possible is that the subnet mask on the WAN side of the firewall in the question is 255.255.255.248 (/29), so more than one global IP address is available. Whether the same proposal is available in practice depends on the line contract; if only one global IP address is available, this proposal is off the table. In that case, consider the isolation proposal in the next chapter.

9. Questions 3(6) and 3(7) — Isolate the Guest Network and Delete the Old Configuration Too

9.1. What Was Adopted Was Service D, Going Straight to the Internet over a SIM

What Company M finally chose was Service D. A leased Router D is placed in the meeting room, with its DHCP server and DNS cache server functions enabled. Visitor-brought devices connect to the internet through Router D’s SIM without passing through Company M’s network. The projector is also changed to connect over an HDMI cable rather than the guest wireless LAN.

flowchart LR
    subgraph M["Company M internal network (after the 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["Visitor-brought devices"]
        D["Router D<br/>straight to the internet over a SIM"]
        T --> D
    end
    FW --> B["Service B"]
    D --> I["Internet"]

Figure 3: A simplified diagram of the configuration after the countermeasures. The employee side strengthens device authentication, and the guest side is separated onto a route that does not use the same exit as Company M.

9.2. Question 3(6): The Destination No Longer Needed Is the DNS Server

The sub-question asks which of Company M’s servers visitor-brought devices stop using: the DHCP server, and the server in blank h. The model answer is “DNS.”²

Because Router D itself provides both functions, visitor devices no longer need to talk to the DHCP and DNS servers on Company M’s server network.

9.3. Question 3(7): Item 1 in Table 3, and Items 1 and 4 in Table 4

The sub-question asks you to list all the item numbers to delete from each of the firewall’s VLAN interface settings and its filtering settings.²

The guest SSID configuration is deleted from the AP as well. Note, though, that the item numbers you write for Question 3(7) are those of Table 3 and Table 4 above. Do not confuse them with the SSID deletion on the AP.

IPA’s grading commentary says the following about Question 3(7).⁵

The correct-answer rate for Question 3(7) was high. Answering required understanding all of the firewall’s filtering settings and the impact of the review of the wireless LAN environment, and that was understood appropriately.

The firewall in this question evaluates rules from the lowest item number upward and applies the first one that matches. This is not, however, a specification common to every product. The danger of missed deletions and the differences between evaluation schemes are covered in Section 10.8.

10. Practical Notes — Do Not Generalize the Exam Answers As They Stand

From here on are points to confirm separately from the answers to the sub-questions themselves. This chapter sets out the conditions under which certificates, HSTS and device authentication take effect, and the routes that remain in day-to-day operation.

10.1. Certificate Revocation Checking Varies in Reliability from Browser to Browser

At this point it is worth separating the exam answer from how browsers actually behave. The four items in Section 3.3 are what Figure 2 of the question text lists as “the detail of the error that may be displayed”; they must not be read as meaning that every browser checks all four with the same reliability.

Issuer, server name and expiry date can all be decided from information already at hand the moment the certificate arrives, so they are always validated. These three are also what stop the attack in this question.

Revocation checking alone is different in kind. Whether a certificate has been revoked is not written inside the certificate, so other information has to be fetched, which makes it dependent on implementation and configuration.

• Chrome does not normally perform online OCSP or CRL checks. Instead it distributes a limited list called CRLSet, whose main purpose is to block certificates quickly in an emergency, and only part of what is in a CA’s revocation list is taken into it¹¹
• Even in implementations that do query OCSP, a configuration that lets the connection through when no response is obtained (soft-fail) is widely used

So do not make “if the private key leaks, just revoke it” the pillar 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 shortening of certificate validity periods in recent years is in part the industry’s answer to revocation being unreliable. When you suspect a key leak of your own, you need to move on replacing the certificate and invalidating whatever that key protected (sessions, API keys and so on) in parallel with filing the revocation request.

10.2. Check the Contents of the Trust Store, and the Domain the User Intended

What follows is outside the question text. The first row of the table in Section 3.3 depends on what that device trusts. The list of trusted issuers is held by the browser or the OS; on Windows it is the Trusted Root Certification Authorities certificate store.

In other words, the first check passes in situations like these.

• The root certificate of an internal certificate authority (a private CA) is distributed to business PCs, and that CA’s private key or its certificate issuance process has been taken over by an attacker
• A proxy or security product that inspects traffic has installed its own root certificate on the device in order to terminate TLS, and that product or its operation has been taken over by an attacker
• Someone in the past registered an exception, or put a self-signed certificate into the trusted roots, because “a certificate error kept appearing”

The third is something you really do see in the field: something added by hand once to make an internal system’s certificate error go away, which then lives on in an image inherited from a departed employee’s PC. The contents of the Trusted Root Certification Authorities store are a literal declaration of who that device believes, so make them a target of your inventories. Deciding what belongs in which store is worked through in The Windows Certificate Store in Practice.

There is a separate practical caveat about the second check (matching the server name). A certificate is powerless against an attack in which the user misreads the domain name. If an attacker registers a confusingly similar domain such as b-serv1ce.example.com and legitimately obtains a certificate for it, the browser raises no error. What a certificate guarantees is that “the destination server name and the certificate’s server name match,” not that “that server name is the party the user intended.” The mechanism that keeps this last step off the user’s own eyes is one that verifies the origin in the authenticator, as passkeys (WebAuthn) do. This is covered in Why Are Passkeys Secure?.

10.3. Before Using HSTS Preload, Check the Impact on Subdomains and on Removal

What fills this first-access gap is the HSTS preload list. If your domain is on the list built into the browser in advance, HTTPS is enforced even for a host that has never been visited.

If you are considering registering your own site, however, check the conditions first. The registration requirements are as follows¹².

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

The one that bites is the third, combined with includeSubDomains. If an old internal-facing subdomain is HTTP-only, or has no certificate prepared for it, it becomes unreachable the moment you register. Take inventory of every subdomain before registering.

And removal is not easy. Removal requests are generally accepted, but it takes months for the change to reach users’ browsers, and there is no guarantee for browsers other than Chrome¹². It is safer to approach preloading as a setting you cannot simply roll back if you get it wrong.

Looking at it from the consuming side, whether a cloud service you use for work supports HSTS is a reasonable item to add to your selection checklist.

10.4. Design What the Approver Judges With, and the Review That Follows Approval

When approval becomes a formality in practice, the cause is usually one of the following.

What Company M is mainly missing in this question is the last two. Once you put in a mechanism for granting approval, you need a mechanism for looking at what was approved afterwards. Just being able to list how many external shares went to free email domains in a month makes this technique far easier to spot.

The bigger picture of where a small or mid-sized company should start is covered in Where Should SMEs Start on Security?.

10.5. Work Out What a Source IP Address Restriction Permits, Starting from the Exit Point

This pattern shows up again and again outside the exam too. A restriction by source IP address does not mean “only from this device.” It means “from everyone who goes out via this global IP address.” Here are typical cases where the range you think you permitted and the range actually permitted diverge.

None of this says a restriction by source IP address is meaningless. It says do not use the restriction on its own as a single layer. Only when you narrow by IP address and then layer on a mechanism that identifies the device itself (a client certificate or a device certificate) and a mechanism that identifies the user (multi-factor authentication) can you express “this person, on this device.” The countermeasures in Chapters 7 through 9 follow the same thinking.

10.6. In EAP-TLS, What You Validate Is the Authentication Server

The last row of the comparison table in Section 7.1 needs a note. In EAP-TLS, what the client validates a certificate against is the authentication server, not the AP. The AP is only an authenticator relaying the EAP exchange; the client is not confirming the identity of the AP itself.

It still guards against the evil twin from Chapter 3 because the key material that is generated only once authentication succeeds is handed only to a legitimate AP that holds the RADIUS shared secret. An AP an attacker has stood up on their own cannot carry the procedure through to the end unless it has a legitimate authentication server behind it. The structure is that what the client validates directly is the authentication server, and the AP’s legitimacy follows indirectly from that.

This comes with a condition, though. Unless the client is configured with which certificate authority’s issuance and which server name it will trust in a server certificate, it cannot tell the difference when an attacker brings up an authentication server of their own. Configurations where EAP-TLS has been deployed but server certificate validation is disabled in the client profile really do exist. Once you deploy it, check that far.

10.7. The TPM Does Not Solve Abuse of the Device Itself or Authentication of the User

On the other hand, putting the key in the TPM does not make everything safe. All the TPM guarantees is that “the key is not duplicated onto another device.” It does not protect against the following.

• The device itself being carried out. Carrying out the business PC means carrying out the TPM with it. Company M’s rules prohibit taking a business PC off the premises, but a rule and technical enforcement are different things. Drive encryption (including pre-boot authentication) and an operational process for revoking the certificate when a device is lost are needed separately
• Impersonation of the user. The TPM identifies the device, but it guarantees nothing about who is operating that device. User authentication is needed separately
• Malware running on the device. The private key cannot be read out, but code running on that device can still ask the TPM to sign. Duplication of the key is prevented, but abuse while that device is under someone else’s control is not

10.8. Delete Old Permissions. Check Each Product’s Firewall Evaluation Scheme

The correct-answer rate for this sub-question was high, but not many organizations follow through this far in practice. Work to put a new mechanism in comes with a budget and a deadline; work to delete old configuration comes with neither. And the things you forget to delete surface in ways like these.

The firewall in this question uses the scheme of evaluating rules from the lowest item number upward and applying the first one that matches (the question text states this explicitly). Under that scheme, leaving a disused permit rule near the top is the same as leaving open a hole that keeps traffic from ever reaching the deny rule at the end.

Do not, however, generalize this evaluation scheme to every firewall. How the decision is made differs by product.

Whatever the scheme, the fact that leaving unused permits in place is dangerous does not change. What changes is why it is dangerous and how to fix it. Confirm which scheme your own equipment uses, then add the question of whether the source and destination still exist to what your periodic inventory looks at.

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

11. Match Countermeasures to Routes and Review the Whole

11.1. How Far Did the Existing Countermeasures Reach?

HTTPS and HSTS stop the route to the fake site that the question posits. Adding more operational restrictions to the business PC, on the other hand, leaves the routes that use an unmanaged device or the legitimate sharing feature in place.

11.2. Which Routes Do the Additional Countermeasures Close?

Many of the countermeasures that were got past prohibit a means, such as USB drives or email attachments. The countermeasure that worked and the additional countermeasures change the route or the nature of the credential. Blocking USB drives still leaves the exfiltration standing as long as a route to the files remains, and lengthening a pre-shared key does not stop it being a shared secret.

12. A Checklist to Apply to Your Own Configuration

1. Can you write out your exfiltration countermeasures as routes rather than means? Instead of a list of means such as USB drives, email attachments and webmail, build a list of the devices and networks that can reach business files. If even one route lets an unmanaged device reach them, a ban on the means will be bypassed
2. Do your rules on bringing devices in and out limit themselves to a place? “No bringing devices into the office area” permits the meeting room, the reception area and shared spaces. Check whether the physical zoning and the network zoning line up
3. Can you state what your source IP address restriction actually permits? Count everything that goes out via that global IP address: guest Wi-Fi, the visitor network, site-to-site VPNs, aggregation gateways for remote work, test environments
4. Are your wireless LAN credentials per-device? A pre-shared key is a shared secret everyone holds identically, so one person leaking it leaks everyone’s, and you cannot block just one machine either
5. Are you counting MAC address filtering and a hidden SSID among your countermeasures? Both are housekeeping that reduces mis-connections, not authentication
6. Is the client certificate’s private key in a state where it cannot be taken off the device? A private key left as a file can be duplicated. Specify a key storage provider that uses the TPM, and do not permit export
7. Do the clients you moved to EAP-TLS validate the authentication server’s certificate? Disable this and resistance to a fake authentication server is lost
8. Can users get past a server certificate error by clicking “Proceed”? Configure HSTS on your own sites. Do not leave certificate errors on internal systems unfixed and teach users that an error is something you click through
9. Do you take inventory of the contents of the Trusted Root Certification Authorities store? What is in there is precisely the set of parties about which the device declares “a certificate issued by this authority counts as genuine”
10. Does the approver in your approval workflow get material to judge with? And is anyone looking at the approval results afterwards? Review a periodic list of shares sent to external domains and free email addresses
11. Are you deleting the configuration of retired routes? VLAN interfaces, filtering rules, SSIDs, allowlist entries. Treat deletion the same way as work to put something new in, and give it a deadline too

Conclusion — Write a List of Routes, Not a List of Countermeasures

If Question 1 asked which stage of which attack you stop, Question 2 asks what range a given countermeasure protects.

Data-leak-prevention software reaches as far as the business PC, the ban on bringing devices in reaches as far as the office area, MAC address filtering reaches as far as someone who does not spoof. What a source IP address restriction permits is everyone who goes out via the same global IP address. Check the range of each individual countermeasure and the gaps at the seams come into view.

Company M is a company that had been working through countermeasures after the previous year’s incident. Holes remain not because the people responsible did not try hard enough, but because adding countermeasures one at a time makes the gaps between their ranges hard to find. The way of reading to take back to your own work is what Mr. Y and Mr. S do: separate the outside attacker from the employee, and check the routes to the files one at a time.

Sources and the Scope of Quotation and Summary

The question covered here is the following.

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

IPA states that, except where laws provide otherwise, no permission or usage fee is required for the past examination questions it publishes. It has not, however, waived copyright: it requires the source to be stated in the form “fiscal year, session, examination category, time slot, question number and so on,” and requires any partial modification of a question to be stated as such¹³.

This article does not reproduce the figures and tables printed in the question booklet as they are. To the extent needed to explain the mechanisms, they are replaced with simplified diagrams and summaries that we produced ourselves. The sub-question texts and the model answers are also handled in summary form. The original question booklet, model answers and grading commentary can be downloaded free of charge from IPA’s pages, so reading with them open alongside is recommended^{1 2 5}.

A Table for Cross-Checking the Question Booklet Against This Article

Related Consultation Areas

KomuraSoft LLC handles design reviews premised on an existing network and device configuration, and the implementation of certificate distribution and key protection in Windows environments.

• Technical Consulting and Design Review
• Windows Development
• Bug Investigation and Root Cause Analysis
• Contact

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 connecting USB drives and banned saving to the local disk. Why can files still be taken out?

Because what was banned was a capability of the business PC the company issued, not the route to where the files live. The employee in this question uses their own personally owned PC. Without touching the business PC at all, they connect that 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 settings of the data-leak-prevention software installed on the business PC have no effect whatsoever on a personally owned PC. Company M did prohibit bringing personally owned PCs in, but the prohibition covered only the office area; the meeting room was out of scope. Blocking the means one at a time (USB drives, email attachments, webmail) still leaves the exfiltration standing as long as a route to the files remains.

Service B was restricted so that login was possible only from Company M's global IP address. Why does the guest wireless LAN get past that?

Because traffic from the guest wireless LAN also passes through the NAT on the same firewall and is translated to the same global IP address before it goes out to the internet. From Service B's point of view, access from a business PC inside the company 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 by source IP address has to be understood as a setting that permits not "only this device" but "everyone sharing this exit point." Guest Wi-Fi, site-to-site VPNs, aggregation gateways for remote work: anything that goes out via the same global IP address falls inside the permitted range.

The employee wireless LAN had MAC address filtering on it. Is that not 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 the personally owned PC's wireless LAN interface to that of a registered business PC and then connect. Because MAC addresses in wireless LAN frames travel unencrypted, receiving the signal nearby is also enough to learn a registered MAC address. The same applies to hiding the SSID. Even with SSID broadcast disabled, the SSID becomes apparent from the exchange that takes place when a device connects. MAC address filtering and a hidden SSID may reduce mis-connections, but they are not an authentication mechanism that stops someone connecting on purpose.

Even if a fake access point and a fake site are set up, why can we say the employee will not be fooled?

Because as long as the connection is over HTTPS, the fake site cannot pass server certificate validation. Figure 2 of the question text lists four items as the detail of the error that may be displayed: not issued by a trusted certificate authority; the server name written on the certificate differs from the server name being connected to; revoked; and expired. The attacker cannot obtain a legitimate certificate for Service B's domain name, so a self-signed certificate fails on the first item, 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 sub-question asking about this validation content was low. Note that the four items do not take effect with equal force. What stops the attack is the first two (issuer and name) plus the expiry date, which browsers always validate. Revocation checking, by contrast, depends on implementation and configuration. Chrome, for example, is designed not to perform online OCSP or CRL checks under normal circumstances, using instead a limited list called CRLSet whose main purpose is emergency blocking. Do not assume that revoking a certificate is guaranteed to block it. And if a corporate certificate authority's root certificate has been distributed to the business PCs, and that authority's private key or issuance process has been taken over by an attacker, the first check passes as well.

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

The browser replaces HTTP with 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, and convert port 80 to 443 if it was stated explicitly. In other words, the plaintext HTTP request disappears before it reaches the network. More important still, if certificate validation fails while communicating 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 along the lines of "this connection is not secure, continue anyway?" That said, HSTS presumes that the browser reached the genuine site over HTTPS at least once and received the header. It has no effect if the very first access from a brand-new device goes straight to a fake site. What fills that first-access gap is the preload list built into the browser.

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 left on the device as a file can be copied to a personally owned PC, and that PC then passes authentication as a business PC. If the key is generated inside the TPM and left in a state where it cannot be exported, operations such as signing are performed entirely inside the TPM, and the key itself is handed neither to the OS nor to malware. The result is that only the business PCs the company issued can pass EAP-TLS authentication. This is why Mr. S could say that there was no problem if that storage method was used. To implement it on Windows, specify Microsoft Platform Crypto Provider as the certificate template's key storage provider and configure the template not to permit export of the private key. Note, however, that all the TPM protects is that the key is not duplicated onto another device; it does not change the fact that whoever holds the device can use it. Loss or theft of the device needs drive encryption and certificate revocation prepared separately.

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 reach the files remains. Second, write out what a restriction by source IP address actually permits. If guest Wi-Fi or a VPN uses 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 is leaked. EAP-TLS with client certificates, in a configuration that never lets the private key out of the TPM, ties the credential to the device. Fourth, delete configuration you no longer use. The final sub-question in this problem has you 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 organizations follow through this far 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.