5.4Incident Response in Practice

Modern security management prepares on the premise that the question is not "whether" an incident will occur but "when." When an incident actually happens, whether you know the procedure makes an entirely different difference to how fast the damage spreads and how well accountability is met afterward. Exam B centers on questions that ask "what should be done right now, at this point" within the flow from detection through post-incident activity.

5.4.1The flow from detection to recovery

• Detection is the stage of grasping an anomaly through log monitoring, IDS/IPS alerts, or reports from employees. Initial response is the stage, immediately after detection, of provisionally grasping the scope of damage and immediately reporting to the person in charge. A misjudgment here puts the later containment step behind the curve. Containment is the stage of taking action to stop the damage from spreading further than it already has, such as isolating an infected endpoint from the network or temporarily suspending the affected account.
• Eradication is the stage, after containment, of removing the root of the problem--for example, removing the malware that caused the incident or fixing the vulnerability that was exploited. Recovery is the stage of restoring from backup and resuming service, once eradication has been confirmed. If recovery is rushed and the system is returned to its original state before eradication is thorough, the risk of re-entry through the same route remains. Not skipping the order of these six stages--detection, initial response, containment, eradication, recovery, post-incident activity--is the basic discipline of the practice.

5.4.2Reporting/public communication and evidence preservation

• Reporting and public communication involve, internally, staged reporting to management and relevant departments (prioritizing speed for the initial report, with details following), and externally, individual notification to affected customers and business partners, and, where necessary, public disclosure such as a press release. Making a definitive announcement before the facts are settled can require a later correction and damage trust, so it matters to clearly distinguish confirmed facts from matters still under investigation when communicating.
• Evidence preservation is the activity, from the earliest stage of incident response, of preserving potential evidence--logs, memory dumps, disk images, and the like--so it is not altered or overwritten. To prepare for the cause investigation and, in some cases, consultation with investigative authorities or legal action, the procedure for evidence preservation must be built in alongside the containment and eradication stages, so that logs that would serve as evidence are not erased in the rush to complete recovery work.

5.4.3Recurrence prevention and notification to relevant authorities

• Post-incident activity (a postmortem) is the stage, after the incident has been resolved, of organizing the root cause, a timeline of the response, and what went well versus what needs improvement, and recording it as a report. Rather than dwelling on assigning blame to individuals, the purpose is to surface weaknesses in the process or mechanism and translate them into concrete recurrence-prevention actions (strengthened monitoring, a rule revision, additional training, and so on).
• Notification to relevant authorities: depending on the nature of the incident, this may involve providing information to JPCERT/CC (a computer emergency response team), reporting to the Personal Information Protection Commission if personal data was leaked, or consulting the police if criminal activity is suspected--engaging outside specialist bodies rather than keeping everything in-house. Coordinating with outside parties early, rather than shouldering it alone, helps grasp the full picture of the damage and prevent similar harm elsewhere.

Take the response to a ransomware infection at a mid-sized company as an example of the flow. Late at night, the monitoring system detected unusual encryption activity on a specific server, and an alert reached the on-duty staff member. As the initial response, the on-duty staff member immediately reported to the security lead per the CSIRT emergency contact chain, and provisionally surveyed the likely scope of impact. The lead then made a containment decision, physically isolating the suspected server from the network immediately while keeping other servers--which showed no sign of encryption yet--running to sustain business operations, a response that discerned the scope of damage. At this point, the staff resisted the urge to rush recovery and copied the memory dump and logs from the time of infection to separate media for evidence preservation before proceeding further. The next morning, forensic investigation revealed the entry route was "a known vulnerability on a VPN device that had gone unpatched for six months." As the eradication stage, the patch for this vulnerability was applied, and the absence of any remaining suspicious malware was confirmed. Only after confirming eradication did the team begin restoring data from backup and recovering service, avoiding the risk of re-entry from a hasty recovery. In parallel, the public relations department contacted only the customers confirmed to be affected individually, and sent an interim report--internally and externally--that explicitly labeled matters still under investigation as "currently under investigation," avoiding definitive statements. Because this incident involved some customers' personal data, the legal department checked whether reporting to the Personal Information Protection Commission was required, and, since the attack exploited a known vulnerability, also provided information to JPCERT/CC, helping to prevent similar harm from spreading to other organizations. Two weeks after the incident was resolved, the CSIRT conducted a post-incident review (postmortem), surfacing the process weakness of why the VPN device's patch had gone unapplied for six months, and introduced the recurrence-prevention measure of "conducting a monthly inventory of patch status for critical devices," with a named owner and deadline. As this sequence of events shows, following the order of each stage, prioritizing evidence preservation over recovery, reporting transparently while avoiding premature certainty, and focusing recurrence prevention on process weaknesses rather than assigning individual blame are the consistent principles of incident response in practice.

5.4.4Section summary

• Incident response does not skip the order detection -> initial response -> containment -> eradication -> recovery -> post-incident activity. Recovering before eradication is confirmed leaves a re-entry risk
• Evidence preservation runs from the early stage, alongside containment/eradication. Reporting and communication distinguish confirmed facts from matters under investigation
• Post-incident activity (postmortem) focuses on process weaknesses, not assigning individual blame. Notify relevant authorities such as JPCERT/CC as needed