12. Countermeasure Catalog: What, Why, and How to Verify

This chapter is not a product-purchasing list. Each countermeasure is organized by where it takes effect — prevention, detection, limitation of impact, or recovery. Detailed implementation configuration values are not covered, as they vary by environment, product, and risk. Instead, verifiable evidence for claiming something has been implemented is presented. Why each boundary is necessary was addressed in Chapter 4. This chapter focuses on what to confirm in order to say something has been implemented — objective, actions taken, verification method, and evidence of completion.

12.1 Management of Externally Exposed Assets

Objective

Do not let a forgotten exposed service, administration console, old VPN, or cloud misconfiguration become an entry point. Even for services that need to be exposed, make clear the owner, purpose, update process, logs, and how to shut it down in an anomaly.

Actions Taken

• Collect candidate assets from DNS, certificates, cloud, IP addresses, procurement records, and network devices.
• Assign an owner and business purpose to each candidate, treating an unknown owner as an issue rather than an exception.
• Minimize externally exposed remote administration and administration consoles, and record the reason and expiration for the exposure.
• Make clear who is responsible for updating internet perimeter devices, VPNs, remote access, and web applications.
• Preserve logs for exposed assets in a location that remains accessible even after a compromise.

Verification

Cross-check the ledger against actual external reachability, and confirm there is no exposed asset absent from the ledger, that unowned assets are remediated within a deadline, and that the emergency shutdown procedure can be executed by a different staff member.

Example of Failure

A state such as “SaaS contracted directly by a cloud-using business unit is outside IT’s scope,” or “the details are unknown because it’s a VPN used by the maintenance vendor.” To an attacker, ownership boundaries are irrelevant. If a reachable surface exists, it is the organization’s attack surface.

12.2 Management of Vulnerabilities and Configuration

Objective

Reduce, in priority order, known vulnerabilities, default configurations, unnecessary services, expired certificates, weak cryptographic methods, and misconfigured exposure settings.

Actions Taken

• Link the asset ledger to vulnerability information, and set priority by external exposure, business criticality, and observed exploitation.
• Include, in change management, whether a patch can be applied, maintenance downtime, rollback, and compensating measures.
• For assets that cannot be updated, choose from taking the exposure offline, network isolation, access restriction, stronger monitoring, or a replacement plan.
• Establish configuration baselines, reducing unnecessary management surfaces, services, privileges, and sharing by default.
• For significant configuration changes, consider a four-eyes principle or independent review.

Verification

Extract overdue critical items, and confirm that each has an owner, a reason, a compensating measure, an approver, and a next-review date. Look not only at the completion rate of vulnerability scans, but at whether the exposed surface was actually updated or isolated.

12.3 Defense of Email and People

Objective

Rather than blaming people as the “last line of defense,” build an environment in which even a successful deception does not connect directly to significant privilege.

Actions Taken

• Put in place anti-impersonation measures, inspection of attachments and links, restriction of dangerous content, and labeling of external email.
• Make payment changes, account-detail changes, privilege requests, and MFA requests into business procedures that cannot be completed by email alone.
• Provide a report button and a point of contact for advice, valuing early reporting rather than blaming a mistaken action.
• Base training not on a ranking of click rates, but on reporting rate, speed of consultation, and the dangerous tasks specific to each role.
• Assume the possibility of email compromise, and monitor forwarding rules, delegation, app consent, and session anomalies.

Verification

Test where a user who receives a suspicious email can actually report it, and with what information attached. Also confirm whether the SOC or responsible staff can correlate that report with identity, mail, and endpoint logs to make a judgment.

12.4 Defense of Identity and Authentication

Objective

Even if credentials are stolen or reused, make it hard to reach critical services — especially the management plane — and detect anomalies early.

Actions Taken

For design decisions on identity classification, privilege separation/time-limited elevation, and MFA application, see Section 4.2. What is additionally confirmed as a matter of operations is the following.

• Reduce legacy authentication methods, shared accounts, indefinite tokens, and long-lived secrets.
• Audit new MFA factors, privilege additions, condition changes, app consent, and mail delegation/forwarding.
• For emergency access, periodically verify both that it is not used in normal times and that it can be used in an emergency.

Verification

Collect a list of privileged identities and confirm the owner, purpose, MFA, last-used date, whether permanent or temporary, logging, and end date. Using a sample of resignations or contract terminations, inspect whether all access has actually been removed.

12.5 Defense of Endpoints and Servers

Objective

Lower the probability of a successful initial compromise, and detect and limit post-compromise reconnaissance, lateral movement, and destruction.

Actions Taken

• Identify managed endpoints, and grasp their patch status, protection state, encryption, and local administrators.
• Do not leave administrator privilege in everyday use; grant it only when needed.
• Track disabling, non-deployment, or loss of communication with protective functions such as EDR as an operational exception.
• Control administrative access to critical servers by target, time, endpoint, and log.
• For legacy or special-purpose endpoints, make clear the compensating measure and residual risk.

Verification

Regularly report unprotected endpoints, overdue updates, excessive grants of local administrator privilege, and loss of monitoring communication, and confirm they are assigned to an owner rather than left unaddressed.

12.6 Network and Lateral-Movement Containment

Objective

Prevent the compromise of a single endpoint or identity from reaching organization-wide data, the management plane, and backups.

Actions Taken

• Define boundaries among the business network, servers, management plane, backup, guest, and outsourcing-partner connections.
• Move gradually toward denying, by default, traffic not needed for business.
• Grasp the pathways for privileged administration, and reduce reachability from general endpoints.
• Make it possible to correlate logs from perimeter devices, DNS, VPN, proxies, and remote access.
• Decide in advance, together with business impact, which segments and connections would be stopped in the event of a compromise.

Verification

Rather than a paper network diagram, confirm using actual access rights, traffic rules, and administrative pathways that a user endpoint cannot unnecessarily reach the backup management plane or identity infrastructure.

12.7 Data Protection and External Sharing

Objective

Reduce the impact of double extortion, and make investigation, notification, and recovery possible.

Actions Taken

• Classify critical data, and record its owner, storage location, retention period, external sharing, and regulatory requirements.
• Minimize sharing privileges, and audit public links, external sharing, and large-volume downloads.
• Encryption is useful, but design it as one with key management, access rights, and administrative privilege.
• Make a decision to either delete data that is no longer needed or continue holding it safely.
• Establish a baseline for the normal state of data egress, so anomalies can be judged.

Verification

For the most critical data sets, confirm whether the organization can answer “who can read it,” “who can share it externally,” “when was access last reviewed,” and “can access history be traced in the event of a compromise.”

12.8 Backup and Recovery

Objective

Ensure that even if an attacker destroys or encrypts production, priority operations can be restored from a trustworthy state.

Actions Taken

• Combine multiple generations, multiple locations, isolation, and immutability according to criticality.
• Place the backup management plane, deletion privilege, encryption keys, and monitoring in a trust boundary separate from production.
• Include the peripheral elements needed for recovery (identity, configuration, certificates, DNS, licenses, procedures).
• Restore in an isolated environment, and confirm the absence of malware and tampering, and data integrity.
• Have the business owner perform business sign-off after restoration.

Verification

Measure not only whether the latest backup could be restored, but whether business operations can resume within the specified time from a safe recovery point chosen on the assumption of an attack. Compare the results against RTO/RPO and report the gap to management.

12.9 Monitoring, Detection, and Response

Objective

Find anomalies before encryption occurs, narrow the scope of the attack, and leave an explainable record.

Actions Taken

• Collect critical logs from identity, endpoints, network, cloud, and backup.
• Confirm time synchronization, retention period, access control, and tamper resistance.
• Prioritize detection of anomalous privilege, authentication, disabling of protection, configuration changes, sharing changes, and data movement.
• Define the owner, response time, communication, and isolation authority for high-severity alerts.
• Record investigation results in tickets and a timeline, and improve detection rules.

Verification

Using a safe simulation or past detection cases, confirm that the alert is delivered, that staff can confirm its basis, and that the necessary communication, isolation, and recording can be carried out within the required time.

12.10 Governance, Insurance, Legal, and Public Relations

Objective

Align technical response with business continuity, customer response, contracts, notification, sanctions/law, insurance, and accountability.

Actions Taken

• Define the incident command structure, decision authority, recordkeeper, and external point of contact.
• Organize, during normal operations, the notification requirements for personal information, industry regulation, contracts, and overseas locations.
• Confirm with legal counsel the insurance policy’s notification conditions, designated vendors, evidence-preservation requirements, and payment-related conditions.
• Prepare templates for the initial report, updates, customer FAQ, and business-partner notification.
• Place decisions regarding payment within an escalation process that includes technical, legal, sanctions, insurance, investigative authorities, and business impact. [S01]

Verification

In a tabletop exercise, confirm whether an initial report explicitly stating unconfirmed items can be produced, who approves it, and whether the technical team’s investigation and external communications can proceed without interfering with each other.

12.11 Prioritizing Countermeasures by Situation

Countermeasures should be chosen starting not from a fashionable threat buzzword, but from what actually exists in one’s own organization: “operations that cannot be stopped,” “privilege concentrated too much in one place,” and “data that cannot be restored.”