Cyber Security

Incident Response: Identification, Containment, and Mitigation of Cyber Attacks

Published: 2026-08-16

Level: postgraduate

Audience: Postgraduate students in Cyber Security

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

The CIA triad — confidentiality, integrity, and availability — covered in Lecture 2
Risk analysis and risk management — covered in Lecture 3
Cost-benefit analysis of controls — covered in Lecture 1
Defense in depth — covered in Lecture 1
EDR and XDR — the proposed answer to zero-day defense — covered in Lecture 2
Malware families: virus, worm, and trojan — covered in Lecture 2
Denial of service and distributed denial of service — covered in Lecture 2
Man-in-the-middle attacks — covered in Lecture 2
ISO 27001 versus ISO 27002 — covered in Lecture 1

Incident Response: Identification, Containment, and Mitigation of Cyber Attacks

9.1 Why Identification, Containment, and Mitigation Matter

9.1.1 The Roadmap of This Chapter

Hook: Your server starts misbehaving tonight. What is the first thing you should do, the second thing, and the third? If you cannot answer that instantly, you already know why this chapter exists — the difference between a small cleanup and a company-wide disaster is a prepared sequence of actions.

This chapter is all about understanding different cyber attacks and the strategies we need to implement for their identification, containment, and mitigation. The chapter works through roughly six to seven attacks in detail, and for each one the discussion centers on these three strategies. Before jumping into the attacks themselves, the key question is why the syllabus groups them under the labels "identification, containment, and mitigation" and how those labels connect to real incident handling.

Think of the three words as one continuous story rather than three separate ideas. Identification answers "what happened?" — you find out that something is wrong and what kind of wrong it is. Containment answers "how do we stop it from spreading?" — you put a fence around the problem while it is still small. Mitigation answers "how do we reduce the damage and get back to normal?" — you remove the cause, restore services, and patch the hole so it cannot happen again. Every attack in this chapter is examined through the same three lenses, which is why mastering this frame once saves you from memorizing six or seven separate playbooks.

The weightage reasoning is stated openly: chapter five (this one) and chapter seven are the most important from the exam perspective, and everything else is mostly theoretical — chapter seven covers different cyber crimes and offenses, and chapter eight is all about case studies. The same reasoning applies beyond the exam: when you move into the cyber domain or sit for security interviews, these are the most common areas where you can jump in. So the depth on this material is deliberate.

Exam note: Chapter five and chapter seven carry the most weightage in the course, both for the exam and for quiz two. If you remember only two chapters by the end of the term, make them these.

9.1.2 From Logs to a Security Incident: The Event Chain

Every device in an organization — routers, servers, firewalls, whatever the system is — keeps generating events, and different logs are generated all the time. We set threshold values in our monitoring so that when those thresholds are crossed, alerts get triggered. So the foundational question is: what is the order of the chain? When does a log turn into an event, when does an event turn into an alert, when does an alert turn into an incident, and when does an incident turn into a security incident?

Q: What is the order — alerts, events, logs, incidents? When does each stage turn into the next? A: Events turn into logs, logs turn into alerts, alerts turn into incidents, and incidents can turn into security incidents. There are many system-generated events, and out of those you define what needs to be logged. Based on the threshold values you set, those logged items can be triggered as alerts in your monitoring systems — for example in Netcool or whatever monitoring tool you use at the front-end UI. Those alerts can further turn into different kinds of incidents: one can be an operational incident, another can be a performance-related issue.

An everyday picture helps fix the chain in your mind. A building's smoke detector is like a threshold: the air is always full of tiny particles (events), only the detector's samples get recorded (logs), and when the particle count crosses the set sensitivity the alarm sounds (alert). The alarm alone does not tell you there is a fire — that is the incident. And only when lives or property are actually threatened does it become a security incident. The chain is a filter: at every link you throw away noise and keep only the signals that matter for the next link.

Worked example — the server-support case: A server generates logs related to four things: CPU performance, memory utilization, the number of connections established, and the number of connections trying to establish. You decide which of those matter to your business, you set thresholds — say, alert me when CPU stays above 90 percent for five consecutive minutes, or when the count of connections trying to establish exceeds 1,000 in a minute — and the monitoring tool turns those crossed thresholds into alerts on the dashboard. Notice what the example teaches: the device produces far more raw events than you can ever watch by hand; your job is to pick the few that predict trouble and let the tool watch the rest. The same alert, once confirmed, becomes an incident ticket: one ticket may be an operational incident (a server needs a restart), another a performance-related incident (a query is slow).

The final step in the chain is the security incident. An incident is promoted to a security incident when it starts impacting the CIA triad — confidentiality, integrity, and availability. (The spoken term sounded like "CAA", but the three properties described are the CIA triad.) The mapping: if the alert points to unauthorized access, confidentiality is impacted; if data consistency has not been met, integrity is impacted; if the system is unavailable, availability is impacted. When any of these three is hit, you escalate: this is a security incident.

Why does this last promotion matter so much? Because an operational incident and a security incident are handled by completely different people with different goals. A performance incident goes to the infrastructure team, whose goal is a faster system. A security incident goes to the IRT — the incident response team — whose goal is protecting the data. The CIA test is the trigger that decides which team gets the ticket, so getting the mapping right at this step decides the whole response.

Pitfalls to avoid:

Mixing up the chain order. The correct order is always: events → logs → alerts → incidents → security incidents. Saying "logs turn into events" reverses the filter and will cost you marks in a scenario question.
Treating every alert as an incident. An alert is only a signal; it becomes an incident only after someone confirms it, and a security incident only when the CIA triad is impacted.
Forgetting the CIA trigger. If you cannot name which of confidentiality, integrity, or availability is at risk, you have not justified calling something a security incident.

Once you finalize that an incident really is a security incident, a dedicated IRT — the incident response team — jumps in. The IRT has its own process for tackling security incidents, and that process is what the rest of this lecture is about.

9.1.3 Why a Documented Process: The Fire Accident Analogy

The motivating question is: when a security incident happens, why do we need these stages, phases, or strategies in place at all? A student's first thought: after an attack has happened.

Q: Where exactly do the identification, containment, and mitigation stages come into the picture? Why do we need them in place? A: Once an attack or incident has happened. Think of a fire accident — that is also an incident. Everybody is in a panic zone and nobody knows what needs to be done. In those scenarios, a well-documented, drafted process makes it easy for the incident response person from a security perspective to see exactly what needs to be done. Every organization so drafts a policy and procedure document that helps the security incident person respond when an incident has happened. The identification, containment, and mitigation phases you see in the syllabus are part of that documentation.

The fire analogy is worth extending, because it explains why documentation beats bravery. In a burning building, nobody stops to think "what is the optimal evacuation plan?" — panic narrows your thinking and you reach for the first action that comes to mind, which is often the wrong one. A drafted process works because it moves the thinking to a calm moment: the plan was written months earlier, when people had time to compare options, so at the moment of panic the responder's only job is to follow the plan in order. The evacuation plans, disaster management steps, and so on are all valid points, but the core idea is a drafted process that tells people what to do, in order, under panic.

Scope of the analogy: The fire analogy is about process — having a written sequence of actions. It is not about the physical world, and it breaks if you push it: a fire spreads continuously and must be contained within minutes, while a security incident may lie hidden for months before it is even detected. That difference is exactly why the detection phase (section 9.2) gets so much emphasis later.

Recap + bridge: Identification, containment, and mitigation are not abstract syllabus labels — they are the three chapters of the written playbook every organization keeps for the panic moment. With the "why" settled, the next question is the order of play: the incident response lifecycle, which turns these three ideas into a full loop with preparation, detection, analysis, containment, and recovery.

Real-world connection: This is the same reasoning behind documented incident response policies in every regulated industry. Banks, hospitals, and cloud providers are required by standards like NIST SP 800-61 and ISO 27001 to keep written incident handling procedures — not because the procedures are perfect, but because an organization that has never decided who calls whom, and in what order, will improvise under pressure and make the damage worse. When you join a security team, one of your first tasks is usually reading that document and knowing exactly where your role sits in it.

9.2 The Incident Response Lifecycle

9.2.1 The Stages at a Glance

Hook: You are the security analyst on duty and your monitoring dashboard lights up. You have minutes to decide whether this is noise or a breach — and the decision tree you follow in that moment is the incident response lifecycle. The whole rest of this chapter is one diagram, drawn in stages.

Picture yourself as a security analyst. On your monitoring dashboard, an alert has been triggered. You troubleshoot it and identify that there is a ping of death attack — continuously, pings are getting hit. Or, in another case, you identify that unauthorized access has happened to one of your databases. Either way, that event has triggered to a security incident. This is the moment the lifecycle below takes over.

Worked example — the analyst's moment: A monitoring alert fires on your dashboard. Your first move is to troubleshoot: you pull the last hour of traffic and see a flood of oversized ICMP echo packets — hundreds per second, all aimed at one web server. That pattern is a ping of death attack (an unavailability problem). In the other scenario, your database logs show a login from an account that has never logged in before, at 3 a.m., and rows are being exported. Both cases are now confirmed security incidents, and the lifecycle begins: detect, analyze, contain, eradicate, recover, learn.

The incident response lifecycle typically has four stages (the discussion counts four main stages, then adds the closing stages): first the preparation phase, next the detection phase, then the analysis after detection, then containment or eradication, and finally you recover from the incident. Once that is done, there is also post-incident activity, which you can also call lessons learned — like the lessons-learned meeting at the end of a project, where you ask what went well, what did not go well, and where the areas of improvement are.

Two structural points matter about the lifecycle diagram. First, there are circles between detection → analysis → containment: after you detect and analyze, you contain, and after containment you must recheck and confirm that the threat is no longer present in your system. Second, the post-incident activity feeds back into the preparation phase as input — the whole cycle is a loop, not a straight line.

A picture of the loop: draw a circle. At the top is preparation; moving clockwise you pass detection, analysis, containment/eradication, and recovery; then post-incident activity sits just before the top, and an arrow from it points straight back into preparation. Two extra curved arrows leave containment and return to detection/analysis — those are the recheck loops. The takeaway from the shape: you are never "done" after recovery; every incident returns to preparation with new knowledge.

Q: In general, when an incident happens, what should be your immediate job as the incident responder? A: Containment — minimize the impact. If a fire accident has happened, the immediate action is to contain it and minimize impact. That instinct carries over directly to security incidents.

The preparation phase is also described with a readiness metaphor: it is where you are ready with all your required "weapons" so that incidents should not happen — the controls from the IT perspective. But even with all controls in place, there is still a chance a security incident gets triggered. No incident happened yet? Then the first important step is detection — how quickly you can detect. Once you detect and confirm the incident is a true positive, not a false positive, you immediately contain: put the affected system in an isolated zone, perform the required steps, and make sure the system recovers. Then you do one more analysis pass — rescan for malware or whatever the incident was — to confirm it is no longer in the organization. Only then do you perform post-incident activity: the root cause analysis document, what went wrong (all the five whys), what went best, and the areas for improvement. All of that becomes input to preparation so that any delta missing in the preparation stage gets added.

9.2.2 Detection Time: The Rootkit Warning

The most emphasized point in the whole lifecycle discussion is that the quicker you detect a security breach, the less impact it has on the organization. Preparation happens before the incident; detection is the immediate priority the moment the incident has occurred.

Worked example — the rootkit that ran for six months: A rootkit is a stealthy set of programs that gives an attacker covert, continuing access to a system while hiding its own presence — often by modifying operating-system internals so the malware does not show up in normal file and process listings. In this scenario a rootkit has been installed on your servers and people are doing exfiltration — pulling out all the data — but you only identify it after six months. Even though you have a strong process and every control in place, almost everything would already have gone out of your organization: six months of customer records, credentials, and source code, with nothing to recover. No containment step can undo a leak that finished months ago.

The lesson is quantitative, not just emotional. The damage an incident can do grows with every hour the attacker stays inside: each week of hidden access adds more stolen data, more compromised accounts, and more lateral movement. Containment and recovery can only shrink the remaining damage; they cannot restore what already left. That is why, based on the severity of the incident, you contain and try to recover — but the speed of detection is the factor that decides how much damage control is even possible.

Warning (explicitly emphasized in the lecture): "Detection is the most important phase" was repeated several times for emphasis. Do not let the glamour of the containment step make you downgrade detection — an attacker who is detected late has already won most of the battle. Organizations track detection time as a metric (you will see a worked detection-time audit in section 9.10).

9.2.3 The COVID Containment Analogy: The Whole Lifecycle in One Story

The entire lifecycle is walked through the COVID pandemic, and it maps one-to-one onto security incidents:

Preparation: masks were mandated, people were told to maintain distance, not to travel unnecessarily, and not to gather in groups. These are the controls.
Incident happens: even though you prepared and implemented measures, COVID still spread. Incidents happen despite preparation.
Detection: the moment symptoms appeared — cold, cough, whatever the symptoms were per the guidance — that was the trigger. Then a test was performed.
Containment: once the test confirmed positive, the person was put in a containment zone so the virus would not spread to the people around them.
Recovery: the infected person was given the necessary medication and recovered.
Lessons learned: what went wrong, what was the reason for a control failure, how can we ensure it will not repeat, and how long did it take to detect — if detection took 30 minutes or one hour, what was the reason it could not be detected earlier?

The value of this analogy is that everyone already knows the story, so the stage names become concrete: symptoms are the precursor indicator, the test is the confirmation, the isolation room is containment, and the after-action review is lessons learned. Whether the government actually followed the lessons-learned step is another question, but the cycle shows the intent: after the incident, you examine where the control failed and why. Notice also that the detection question appears inside lessons learned — "how long did it take to detect, and why not earlier?" — which is the same detection-time obsession from section 9.2.2, now formalized as a post-incident question.

9.2.4 A Malware Walkthrough: Scan, Isolate, Re-scan

From the IT perspective, here is the same lifecycle applied to malware on hosts. You want to know the number of hosts infected by malware. So you run a scan, and you find one system that has been infected. The first important step is to isolate that system from the network immediately — that is what stops it from spreading to the rest of the systems on the LAN. Once the isolation is done and the system is removed from the records, you do a re-scan to ensure no further systems have been impacted. Once that is confirmed, the incident has been successfully handled, and you issue a detailed report covering what the cause was, what the cost of the incident was, and what steps you will take to prevent that incident from happening again.

Worked example — the full walkthrough: Suppose your LAN has 40 hosts. You run an antivirus scan across all of them and exactly one desktop (host 14) returns a positive for malware. Your immediate step is to isolate host 14 — pull its network cable, disable its LAN port, or quarantine it in your endpoint tool — so the malware cannot use host 14 to reach the other 39 machines. Only after isolation do you re-scan the remaining 39 hosts; the re-scan comes back clean, confirming the malware never spread. The incident is now closed, and the detailed report names the cause (a malicious email attachment), the cost (host 14 offline for six hours, plus cleanup), and the prevention steps (block that attachment type at the mail gateway, update signatures, retrain the user).

This example also shows the circular nature of the lifecycle: after containment, the loop passes back to detection/analysis to make sure there are no further impacted systems. The re-scan is not a formality — it is the mechanism that proves containment worked, and without it you would be assuming the attack stayed on one host instead of verifying it.

Recap + bridge: The lifecycle is a loop: preparation → detection → analysis → containment/eradication → recovery → post-incident activity, with recheck loops from containment back to detection, and with lessons learned feeding the next preparation. Detection speed sets the ceiling on damage control. Next, the lecture zooms into each phase one at a time, starting with preparation and its risk-based planning.

Real-world connection: Every security operations center (SOC) runs exactly this loop daily, using the alert queue as the detection feed, incident tickets as the analysis state, and quarantine actions as containment. The COVID mapping is not just a story — pandemic response and incident response share the same modeling vocabulary (precursor signals, confirmed positives, containment zones, recovery and review), which is why public-health lessons transfer so directly to security teams.

9.3 Preparation Phase

9.3.1 Limit, Never Nullify: Risk Assessment and Controls

Hook: Can an organization ever become 100 percent secure? The honest answer is no — and the preparation phase is built on that admission. Its real goal is not to stop every incident, but to decide which incidents are worth stopping and what the leftover risk is worth paying for.

The preparation phase has one main objective: limit the number of incidents — never nullify them. The point is made outright: "We are never saying nullify." Even after implementing 110-plus controls in a defense-in-depth mechanism, there is always risk left over. No organization will say it is 100 percent secure. In the same way, the preparation phase attempts to limit incidents by implementing suitable controls, and the input for choosing those controls is the risk assessment result.

How the risk assessment works: you list out all of your infrastructure — systems, servers, routers, firewalls — and the people, process, and technology. A risk assessment is all about the adverse events that may happen to your system, and what the impact to your organization would be if they did. The calculation is stated explicitly: the combined calculation of the probability of that event and its impact leads to the risk value.

Formalize — the risk equation. The risk value, written $R$ , is the product of two quantities: $P$ , the probability of the adverse event (a number from 0 = impossible to 1 = certain), and $I$ , the impact of that event (what it costs the organization if it happens — lost data, lost revenue, lost reputation):

$R = P \times I$

Every symbol is named: $R$ (risk value), $P$ (probability of the adverse event, in [0, 1]), $I$ (impact of the event, in whatever unit matters — dollars, hours of downtime, records leaked). A probability of 1 means the event is certain; a probability of 0 means it cannot happen. Because both factors are on the right side, risk can be lowered by reducing either one: make the event less likely (preventive controls) or make its consequences smaller (recovery and backup controls).

Worked example — putting numbers on risk: Suppose your organization's risk assessment decides that the probability of a virus attack in a given year is $P = 0.3$ , and the estimated impact — cleaning infected files, downtime, and lost work — is $I = 10, 000$ dollars. Then the risk value is

$R = 0.3 \times 10, 000 = 3, 000 dollars$

The same math drives the cost-benefit analysis of controls: if a virus checker costs 100 dollars per year, it is worth buying, because 100 dollars is far below the 3,000 dollars of expected loss it prevents. Sense-check: even if the checker blocks only half the attacks, it still avoids 1,500 dollars of expected loss against a 100 dollar price, so the purchase is justified.

So you perform the risk assessment, find where the high, medium, and low risks are, design controls for them, and do a cost-benefit analysis of those controls. Then you recommend to management: which controls you are suggesting, why you are suggesting them, what happens if the control is not there, whether it is a legal or regulated requirement, and how the lack of this control would impact the business continuing its operations.

A useful contrast is asked and answered in the room:

Q: After implementing the controls, the leftover risk is called residual risk. What is the risk that was there before implementing the controls? A: That risk is called the inherent risk — the risk that has been there before implementing the controls. The risk left over after implementing the controls is the residual risk.

The objective then becomes: implement controls so that the generated risk value is within a value the organization accepts — that accepted level is the risk appetite. Every organization has some appetite that it can accept. The whole agenda of the preparation phase can be stated as: identify the risks, assess them, prioritize them as high, medium, and low, implement the necessary controls based on that prioritization, and make sure the residual risk stays within the organization's risk appetite:

$Residual Risk \leq Risk Appetite$

Assumptions and scope of the risk equation:

The formula assumes you can estimate $P$ and $I$ at all. In practice both are estimates — frequency counts from past events, or expert opinion — so the risk value is a planning number, not a precise prediction. Treat the relative size of risks as more important than the exact digits.
It also assumes the risk can be measured before and after controls. The residual-risk inequality only makes sense when controls reduce either $P$ , $I$ , or both; a control that is never deployed or never enforced changes nothing.
No organization reaches $R = 0$ : even with 110-plus controls, some risk always remains, which is exactly why the inequality uses "less than or equal to" rather than "equals zero".

There is also a governance angle. For the CISO — the Chief Information Security Officer — one of the key performance indicators (KPIs) is the number of security incidents that happen in a year. If the number of incidents is increasing month over month or quarter over quarter, that signals that no effective security controls have been implemented, and the responsibility falls on the CISO. That is why the number of security incidents is one of the key parameters on the CISO's dashboard that the management and board of directors will consider.

Exam note: Expect the inherent-risk-versus-residual-risk contrast and the risk-appetite idea — this is a vocabulary point that commonly appears in questions about the preparation phase. Learn the pair as a single story: inherent risk is the starting point, controls are the treatment, residual risk is what remains, and the risk appetite is the acceptable upper limit that the residual risk must stay under.

9.3.2 The IRT Team, Contacts, and the War Room

The very first step of the incident response process is to establish and train an incident response team. "Well-trained" means the right skills, capabilities, and the necessary tools and resources. Like a fire emergency team that must arrive with the right equipment and training to stop a fire, the security IRT must have everything in place before the incident.

A parallel is drawn from the ITIL lifecycle: when an incident turns into a crisis, you declare it a crisis and call your on-call managers, establish a bridge call, and have a predefined list of contacts who should join the call. There is a protocol already defined.

Worked example — the ITIL crisis declaration: Every company has its own criteria for what counts as a crisis. Suppose this company's rule is: if a network link goes down and it impacts more than three customers — some companies set the bar at ten — the organization declares it a crisis. The moment the crisis is declared, a predefined procedure takes over: the on-call managers are called, a bridge call is opened, and the procedure document lists exactly which persons and account managers join, what the agenda is, the bridge details, and where the war room is located. The point of drafting all of this in advance is that nobody has to search for a phone number while the clients are already affected.

In the same way, the training for the security incident response team should be well documented — including the tools: how they join the call, what numbers to use, where the Zoom details live, and so on.

So the preparation checklist includes: who all needs to be contacted, what are their on-call information details, how should you report the incident, how do you track incidents, do you have a work area recovery site, and is there a war room.

9.3.3 Secure Storage and the Chain of Custody

A requirement that is highlighted is the secure storage facility, and the reason is legal. If an incident ends up in court, the evidence you submit needs to be admissible. Evidence is admissible only when the chain of custody has been maintained — wherever the artifacts are moved from one team to another, the security and integrity of the evidence must not be hampered. As long as the chain of custody is maintained — confidentiality and integrity intact — the court will admit the evidence you submit. That is why a secure storage facility is one of the important preparatory requirements for handling incidents.

Pitfall: The most common way organizations lose a case is not a lack of evidence — it is broken provenance. If an analyst copies a disk image onto a personal drive, or a team hands evidence to another team without a signed record of who held it and when, the court can reject the evidence as tampered, even when it is genuine. The chain of custody exists precisely so that nobody has to trust anybody's word about the evidence's journey.

9.3.4 Hardware, Software, and Information Requirements

The IRT also needs hardware and software, because analysis requires tools. If you want to do a forensic investigation, you need to create an image of the laptop, preserve the log files, and preserve the relevant incident data. Modern reality: most of this now happens in software, and there is very little need for dedicated hardware, because SaaS providers offer forensic capabilities — they remotely log in, use secure FTP, or install their own proprietary software on the device, then capture all the information present in the system, whether it is a router or whatever device.

The full requirements list from the preparation phase:

Data for analysis: analyzing data, sniffing packets, and report templates.
System-level resources: separate more workstations, servers, networking, and already-virtualized equipment that can be used for the main purpose — for example, restoring a backup. When you restore a laptop or desktop that held confidential data, you restore to a secondary machine, keeping the primary mission machine intact.
Network-level resources: packet sniffers or protocol analyzers to capture the traffic coming in.
Digital forensic software for analyzing disk images when an incident happens.
Evidence-gathering kit: digital cameras and other context-based methods, plus evidence storage bags and tags required for legal actions.
Configuration documentation: which OS, which OS version, which applications, which protocols, which IDS, which IPS, which antivirus products you use, your infrastructure diagram, your critical assets, where the database servers are, which database you use and what version, and the baselines you set for operating systems and networks. All of this is configuration management information that must be in place.
Hashes of critical files: the moment you hash a file, any change in the file will change the hash value. That is how you detect whether your system files have been changed. Maintaining hashes of critical files is so important.

Worked example — hashing a critical file: A cryptographic hash is a fixed-length fingerprint computed from a file's contents, such as the SHA-256 digest. Before an incident, you record the hash of every critical system file, say $H_{0} = 9 f 2 c ...$ for the web server binary. During an investigation you recompute the hash on the suspect machine and get $H_{1} = 4 b 7 a ...$ — a different value. Because even a one-byte change produces a completely different digest, the mismatch proves the file was modified. A matching hash, on the other hand, gives you confidence that the file is the original, unaltered version. This is why file hashes are stored in advance, in a trusted place, as part of preparation.

9.3.5 The Fire Drill Analogy and Ready-to-Use Tools

The fire drill analogy ties preparation together: we do fire drills so that when a real fire happens, the process is already in people's heads — they know how to exit the room, how to exit the floor, and where the emergency exit diagram is. The drill makes you prepared so that when something goes wrong you know how to respond. Security incidents work the same way: before the incident happens, you prepare for it — the people who support the systems, the people who can respond, the technology that gathers incident information, the necessary tools, and the third-party vendors who should be involved. All of that information is gathered in the preparatory phase.

The time-critical argument for having tools in advance: if you need to do a port scan, use a packet analyzer, or a network analyzer, you cannot run around purchasing tools at that moment — Nmap, Acunetix, or Qualys scanners cannot be bought during the incident. At that time, time is very precious: the more quickly you respond, the less impact to your organization. So you always have all of these tools in place.

Assumption of the fire-drill model: Drills work only when they are repeated and honest. A fire drill that is announced, skipped, or run once in five years does not put the exit route in people's heads. The same applies to incident response: a preparation document that is written and never tested, or tools that are licensed but never exercised, gives the same false comfort as a locked door that was never opened by the person who is supposed to use it.

Real-world connection: Nmap is the standard port scanner, Acunetix is a web application vulnerability scanner, and Qualys provides cloud-based security scanning — all named as tools you should have ready before an incident. In real security operations these tools are licensed, installed, and tested during normal operations, so that when an incident hits, the analyst reaches for a tool that is already calibrated to the organization's own environment instead of learning it under pressure.

Recap + bridge: Preparation is the phase where risk is measured ( $R = P \times I$ ), prioritized, and treated with controls until the residual risk fits inside the risk appetite; meanwhile the IRT, its contacts, secure storage, forensic tools, and ready-to-use scanners are all put in place before the incident. With the groundwork done, the next phase is the moment the incident actually happens: detection.

9.4 Detection Phase

9.4.1 Attack Vectors: Where the Attack Came From

Hook: When the alarm sounds, the first question is not "what do we fix?" — it is "where did this come from?" Every incident enters through some door, and the detection phase starts by looking in all directions for that door: the attack vector.

In the detection phase you look 360 degrees around and try to identify quickly where the incident came from — that is the attack vector. The examples of attack vectors, some of which were "validated" in the discussion:

External or remote media
Employees who left the organization
Browsing activities that resulted in the incident
A virus passed by email attachment
Impersonation
Not adhering to organization policies — for example, downloading third-party software without a security sign-off; the downloaded executable (.exe file) had a trojan embedded, and the trojan spread across the network
Improper usage of equipment
The laptop being stolen
A default password left in place, which resulted in all the data getting leaked

Worked example — two validated attack vectors:

The trojan in the downloaded executable. An employee downloads a free third-party utility without the security team's sign-off, breaking the organization's download policy. The .exe file carries an embedded trojan — malicious code hidden inside a program that looks legitimate. When the employee runs it, the trojan executes and begins spreading across the network. Detection question asked in 360 degrees: browsing activity (policy violation), the download (external source), the executable (malware vector).
The stolen laptop with a default password. An employee's laptop is stolen, and the machine was still protected by the factory-default password — never changed when it was provisioned. The thief logs in with the default credentials and all the data on the laptop is leaked. Detection question: physical loss (equipment), plus a configuration failure (default password left in place) that turned a stolen device into a data breach.

The pattern across all nine vectors: detection is not one sensor but a sweep. Some vectors are technical (email attachment, browsing), some are physical (stolen laptop, external media), and some are human (impersonation, departing employees). A detection strategy that watches only the network will miss the laptop in the parking lot — which is why the lecture frames the sweep as 360 degrees.

9.4.2 Indicators of Attack vs Indicators of Compromise

Two terminologies help decide whether an event has turned into a security incident — and crucially, whether you detect that before or after the incident. The discussion returns to these two terms from an earlier session.

Q: What are the two terminologies that help us identify whether an event has turned into a security incident — one before the happening of the incident and one after? A: Indicators of compromise (IOCs) and indicators of attack (IOAs). The distinction: indicators that show up before the happening of the attack are indicators of attack; indications that show up after the attack has happened are indicators of compromise.

So IOA is the "something is about to happen / is happening" signal, and IOC is the "evidence left behind after the compromise" signal. A concrete split makes the pair stick: a sudden burst of port scans against your perimeter, an unusual number of failed logins, or a phishing email wave matching a known campaign are indicators of attack — they precede or accompany the intrusion. A file you never created appearing in a temp folder, an unknown account with administrator rights, or data flowing out of the network at 3 a.m. are indicators of compromise — they exist only because the attack already succeeded. The same event can even be read both ways depending on timing: a log entry is an IOA while it is being written and an IOC when you analyze it later.

Relatedly, the discussion touched on precursor indicators — early signs that an attack is brewing — which connect back to the attack-vector discussion as the input side of detection. Precursors are the earliest of the early warnings: the reconnaissance traces an attacker leaves before the actual exploit, such as the probe of a specific port that the attack will later use.

This is also framed as the "science of incidents": for many organizations, the most challenging part of incident response is accurately detecting and positively assessing whether an incident occurred at all, and if so, what is the type, extent, and magnitude of the problem.

Pitfalls to avoid:

Using the two terms interchangeably. In a question, "before the attack" must always map to indicators of attack, and "after the attack" to indicators of compromise — the timing is the whole distinction.
Waiting for IOCs before acting. A mature team also reacts to IOAs (the brewing attack) because acting early is what the detection-speed lesson from section 9.2 is built on.
Treating a single sign as proof. An indicator is a signal, not a verdict — confirming the type, extent, and magnitude of the incident is the analysis phase's job (section 9.5).

9.4.3 Correlating Alerts: SIEM, EDR, and XDR

A single alert firing in a monitoring tool cannot confirm an incident. In an infrastructure with a lack of properly configured servers, you will have a large number of alerts "gaping" (going off), and one alert alone is not confirmation. You need correlation — you correlate between different alerts across the infrastructure. That is where you deploy SIEM (Security Information and Event Management), EDR (Endpoint Detection and Response), and XDR (Extended Detection and Response) systems: once you configure them across all of your infrastructure, they correlate among systems, applications, and networks, and help confirm whether an event can be turned into an incident.

Worked example — why one alert is not enough: Imagine your SIEM shows a single alert: one workstation tried to reach a known-bad domain. On its own, that could be a user clicking a stale bookmark, a false-positive signature, or a real infection. Now correlate: the same workstation shows a new scheduled task at the same minute, its antivirus process was disabled an hour earlier, and three neighboring hosts show the same new task created two minutes later. The picture changes — four hosts, one coordinated change, and an evasive action pattern. That correlation is what turns a lone alert into a confirmed incident.

The three platforms cover different surfaces, and the comparison helps decide which one an organization is looking at:

Platform	Full name	Surface it watches	Typical answer it gives
SIEM	Security Information and Event Management	Logs and events collected from many devices (firewalls, servers, applications)	"Do these events across the network tell one story?"
EDR	Endpoint Detection and Response	Individual endpoints (laptops, desktops, servers)	"Is this host compromised, and what did it do?"
XDR	Extended Detection and Response	Endpoints plus network, email, cloud, and identity data in one platform	"Can I see the attack across every surface at once?"

The rule of thumb: if the question is about a single machine, EDR; if it is about event streams from everywhere, SIEM; if you want one correlated view across all surfaces, XDR. Organizations typically build up: SIEM first for visibility, EDR for endpoint action, then XDR to fuse the two.

Recap + bridge: Detection sweeps 360 degrees for attack vectors, classifies what it sees as indicators of attack (before) or indicators of compromise (after), and uses SIEM, EDR, and XDR correlation to confirm whether an event is really an incident. But confirmation is not the end — the next phase asks how much of what the tools report is actually true, which is where analysis comes in.

Real-world connection: SIEM, EDR, and XDR are the standard commercial detection platforms — Splunk, Sentinel, CrowdStrike-class endpoint tools, and the newer XDR platforms all do this correlation work. In a modern SOC, the detection feed is these platforms' dashboards, and the correlation rules inside them encode exactly the reasoning of the worked example above: no single alert closes a case; a case closes when independent signals agree.

9.5 Analysis Phase

9.5.1 False Positives: The KPI of Your Detection Tools

Hook: A detection tool that screams at you 500 times a day is worse than one that whispers once — because the screaming tool teaches you to ignore it. That is why the analysis phase's first question is not "how many alerts do we have?" but "how many of them are true?"

Incident detection analysis should ideally be accurate — a true positive. But in most cases you will deal with false positives. The two terms need precise definitions. A true positive is an alert that points at a real security event — the tool is right. A false positive is an alert that fires when nothing is actually wrong — the tool flagged a benign condition as an attack. (Its mirror, the false negative, is the worse failure in the opposite direction: a real attack that the tool never flags.)

So the question becomes: how do you measure whether a SIEM or XDR is working effectively? The key performance indicator is the number of false positives — the fewer false positives a tool generates, the more effectively it is working. If a tool frequently generates false positives, it is not really able to identify the true security event turning into an incident.

Worked example — user-provided indicators can lie too: A user calls the help desk: "The server is unavailable." That complaint is an indicator — but it is not automatically a true positive. It could be a real attack (a denial of service or a crashed service), or it could be a false positive (the user's own network cable is unplugged, or a VPN session dropped). Similarly, an IDS (intrusion detection system) with an incorrect configuration can flag ordinary traffic as an attack all day long — an often-incorrect IDS is a factory for false positives. Incorrect indicators like these make incident analysis and validation a genuinely tough challenge: every indicator must be checked against other evidence before it is trusted.

Pitfall — alert fatigue: The real cost of false positives is not the alert itself; it is the habit it builds. When a tool is wrong often enough, analysts stop responding to its alerts, and the one true positive among the noise gets ignored — which is how the rootkit from section 9.2.2 stays hidden for six months. Fewer false positives means each alert is worth attention, which is exactly why the count is the tool's KPI.

9.5.2 Best Practices for More Effective Analysis

The best recommendations to make analysis easier and more effective, as listed:

Create a profile of your networks and systems. A profile means the standard or normal behavior: the default configuration of the systems, the default configuration of the network, which processes access your system files and which access your data files, what the expected normal behavior is, when huge traffic will be hitting, and when the traffic will be nominal.
Create a log retention policy. Logs should be kept for 30 days, 90 days, or whatever the client requirements are. If there are no logs, there is no chance to do analysis — if logs are wiped out every week, you cannot analyze anything.
Correlate events across your infrastructure. Correlate events at the system level, network level, load balancer level, and VPC level, and merge them as input to your XDR.
Synchronize time. All host clocks must be synchronized so you can cross-correlate the happening of an incident between different systems. If the timing of events is different across systems, cross-correlation would be impossible.

Q: Which protocol do we use to ensure that all host clocks are synchronized? A: NTP — Network Time Protocol. It is the most important protocol for making sure all host clocks are synchronized, precisely because you want to cross-correlate events across systems.

Visual intuition — the synchronized timeline: Draw a horizontal time axis shared by three hosts. On the unsynchronized version, each host draws its own axis shifted by minutes, so the same attack looks like three different moments and no pattern links them. On the synchronized version, all three hosts mark the same wall-clock time: host A shows an outgoing connection at 10:02:11, host B shows the inbound connection at 10:02:12, and the firewall log shows the same flow at 10:02:12 — one story, three witnesses agreeing on the time. The takeaway: correlation across systems is impossible unless every log tells the time the same way, which is what NTP exists for.

Keep a knowledge base (KB). The KB is the knowledge base of all the information about the organization's systems and incidents.
Use external resources. Internet search engines for research and packet sniffers to collect extra information.

The six practices work as a set: the profile tells you what normal looks like, the retention policy guarantees you have the logs to compare, correlation merges evidence, NTP makes the merge trustworthy, the KB stops you from re-solving yesterday's problem, and external resources fill the gaps in your own visibility.

9.5.3 AI and ML-Based XDR

The current generation of AI- and ML-based XDR takes correlation a step further: based on the way alerts hit its dashboard, the system itself tries to understand the behavior of your organization, and when something abnormal happens, it immediately triggers an alert. That self-learning behavior model is exactly why AI/ML-based XDR platforms have become so popular. Real-world: this is the anomaly-detection approach used by modern commercial XDR and SIEM products.

Scope and limits of the AI model: The learned "normal" is only as good as the training window. If the system learns during a period when a slow breach is already running, it can file the attacker's behavior under "normal" and never alert. And because the model learns the organization's own rhythm, a brand-new environment or a sudden legitimate change (a new application launch) can look abnormal and flood the dashboard with false positives — the same KPI problem from section 9.5.1, now coming from the learning curve rather than the signatures.

Recap + bridge: Analysis judges the detection feed: true positives are the goal, false positives are the KPI to minimize, and profiles, retention, correlation, NTP, knowledge bases, and external research are the six practices that make the judgment reliable. With a confirmed true incident in hand, the response stops being reactive and becomes deliberate — which is where documentation and handling come in.

Real-world connection: AI/ML-based XDR is the current industry direction for the exact reason the lecture gives: rules describe known attacks, but behavior models catch what the rules never anticipated — including the zero-day behaviors that make detection speed the decisive factor. Modern commercial XDR and SIEM products ship these self-learning anomaly models as a standard layer on top of signature matching.

9.6 Incident Documentation and Handling

9.6.1 Record Everything, With Timestamps

Hook: Two teams handle the same incident identically. Six months later, one team can reconstruct every minute of what happened; the other remembers "something about a laptop." The first team wins — and the difference was not skill, it was documentation.

When an incident response team suspects that an incident has occurred, the immediate job is to start recording all the artifacts and facts about that incident — system events, conversations, observed changes in files, all of it. Every step, from the time the incident was detected all the way to the final resolution documentation, must be documented, including the timestamp. Documentation is stressed as one of the most important criteria for effective incident response — and it is immediately connected to the exam.

Exam note: The exam may contain a scenario where every phase is walked through and then the statement is made that "there is one thing which is missing here" — you have to identify the missing step by remembering all the phases. The missing step is usually the documentation.

Worked example — the exam template scenario: An incident happened; the IRT confirmed it was a security incident; they came into the picture; they found out exactly where the incident happened; they contained the laptop; they recovered the laptop; they found the cause — an end user inserted a pen drive, so the incident happened because USB was not disabled; and then they closed the incident. Every phase was executed: detection, containment, recovery, root cause. What was missing in the entire discussion? The documentation — nobody recorded the timeline, the actions, or the findings. That one scenario is the template for a whole class of exam questions: read the phases, spot that documentation never happened, name it as the missing step.

Why does documentation deserve this status? Four reasons. First, the record is the evidence base: if the incident goes to court or to an audit, the timeline is the only thing that can be examined. Second, the record is the memory: analysts rotate shifts, and the person who detected the incident at 2 a.m. may be asleep when the next action is needed. Third, the record feeds lessons learned — post-incident activity (section 9.10) is impossible without a written account of what actually happened. Fourth, timestamps make the record credible: an entry without a time cannot be ordered against other entries, and ordering is what reconstruction is made of.

The same framing works when you audit an incident response procedure document: was there any planning done? Were they able to identify and was the risk assessment done with the critical assets identified? Did they identify the attack vectors from internal and external resources, and did they identify the necessary controls for those attack vectors? How do they limit false positives, and what mechanisms are incorporated for detection and analysis? What is the generic amount of time taken for every incident's detection?

9.6.2 The Issue Tracking System

Incidents must be tracked in an issue tracking system — an issue tracker — with a status for the current incident: new, in progress, resolved, waiting for confirmation from the stakeholder — the stages can differ per organization, and can include resolved, finally closed, waiting for feedback from stakeholders, and so on.

The important fields of an issue tracker entry, as listed: a summary of the incident; what the indicators were; what other incidents can happen related to this one; what actions you took; the chain of custody if applicable; the impact assessment — was the impact at the organization level, location level, a specific department level, or a specific client level; the contacts for who needs to be contacted; the comments from the persons who handled it; and the next steps you suggest — for example, rebuild your operating system or upgrade the application.

Worked example — one ticket, full lifecycle: An analyst opens a ticket for the pen-drive incident from section 9.6.1: status "new". The ticket body carries the summary ("malware detected after pen drive insertion"), the indicators (the antivirus signature that fired), related incidents (a similar event last quarter on a different floor), the actions taken (host isolated, scanned, cleaned), the impact assessment (department level — one team lost two workdays), the contacts (the account manager, the IT support lead), and the next steps (disable USB on managed desktops, upgrade the antivirus definitions). As work proceeds, the status moves: "in progress", then "waiting for confirmation from the stakeholder", then "resolved", then "finally closed". Without the tracker, each of those states — and the person responsible at each state — exists only in someone's head.

9.6.3 Prioritizing Incidents

When two or three similar incidents happen, you need to prioritize: is it a high-impact incident, medium, or low? Companies define their own strategy.

Worked example — client crisis vs routine traffic: Suppose the core network link goes down. If the link carries production traffic for more than five clients, some companies will declare a client crisis — high priority, immediate bridge call. But the same core link, if it is down while only non-production traffic or SNMP management traffic passes through it, is a medium- or low-impact incident — because the production traffic that clients depend on is not affected. The identical technical failure (one link down) maps to different priorities depending on what the link carries; prioritization is about business impact, not about the hardware.

The parameters organizations consider when prioritizing: the context of the organization, the risk posture of the organization, the commitment given by the organization to its clients, and the SLAs signed by the organization with its clients. All of these are decided by the people who draft the policy.

9.6.4 Notification

Notification is critical and should be pre-decided: who should be notified? Clients — and how many clients? Does it need to be notified to external regulatory authorities? Does senior management need to be notified — and is that at the client-specific level or the organization level? All of this is defined in the incident notification process document before any incident happens.

Pitfall — notifying in the wrong order or not at all: Two failure modes are common. First, notifying nobody because the team is busy fixing — but regulatory obligations (for example, breach notification to authorities) are time-boxed, and missing the window turns a technical incident into a legal one. Second, notifying too many people with inconsistent details — different statements to different clients erode trust and can even tip off an attacker still present in the network. The notification document exists precisely to pre-decide the list and the message.

Recap + bridge: Documentation with timestamps is the most important criterion for effective incident response; every incident lives in an issue tracking system with status and fields, is prioritized by business impact, and follows a pre-decided notification plan. With the paper trail in place, the next phase is the most urgent one — stopping the damage, which is containment.

Real-world connection: Incident ticketing and notification are where the process becomes auditable: regulators and clients ask for the ticket, the timeline, and the notification record, and an organization that cannot produce them is treated as if the incident never happened or was hidden. The pen-drive scenario is not exam-only — it is the standard shape of real breach post-mortems, where "the response was fine but nobody wrote it down" is a recurring finding.

9.7 Containment Strategy

9.7.1 Why Containment Comes First

Hook: A fire doubles in size with every minute it is left alone, and so does a breach. Containment exists for that reason: before you can clean anything, you must make the fire stop growing — the same instinct a fire responder has when the first move is not investigation but isolation.

Containment is important because it comes before the incident escalates, hurts more resources, or increases the damage. The goal of containment is to limit the impact — isolate and restrict the impact so it happens to only one system. Most incidents require containment, which is why it is an important consideration in the handling of every incident.

Containment also buys time: it provides time for developing a tailored remediation strategy. When you want to remediate, your containment strategy acts as input to your remediation — because the containment approach you chose tells you what remediation will work, and you add further recommendations on top of it. The logic is a chain: containment limits the damage now, and the way you contained it determines what eradication and recovery can look like later. If you isolated a host, remediation means cleaning that host; if you redirected traffic, remediation means fixing the primary system while the secondary serves clients.

Scope of containment: Containment is a damage-limiting action, not a cure. It does not remove the attacker or restore the data — those belong to eradication and recovery (section 9.9). The trap to avoid is treating "contained" as "finished": the loop back to detection/analysis (section 9.2.1) exists precisely because containment must be followed by a recheck before anything is considered handled.

9.7.2 Decision Making: Who Shuts the System Down?

The essential part of containment is decision making: who decides what needs to be done — shutting down a system, disconnecting it from the network, or disabling certain functions? The faster you can take the decision, the less the impact and the less the spread. This decision cannot be taken by an end analyst or a support guy. It is the shift boss, shift leader, shift manager, or account head who decides, after analyzing the business impact: if I shut down the server, how will the traffic be directed? How will clients get the required data? Is there an alternate path? What is the committed SLA? All of that feeds the decision.

Why is this decision kept away from the front-line analyst? Because shutting down a system is a business decision, not a technical one. The analyst knows the system is compromised; the shift manager knows what the system is for — which clients it serves, what SLA is committed to those clients, and what the alternate path costs. Shutting down a server that serves a hospital's patient portal has a very different price than shutting down a server that serves internal testing, and only the person with the business context can weigh that trade-off in the minutes available.

Those decisions are much easier to take when there are predetermined strategies and procedures for containing incidents. If you already defined that, for a well-known or most-common incident, the immediate step is fixed — for example, the moment a desktop is infected with malware, the IT support guy knows the immediate step is to make sure the laptop is removed from the network.

Worked example — the predefined immediate step: The organization's containment playbook states: "On confirmed malware infection of a desktop, the immediate step is to remove the laptop from the network." An infection is confirmed on host 14. The IT support guy does not need to call a meeting or weigh options — the playbook already decided the first move, so the machine's LAN is disabled within minutes and the malware cannot reach the other 39 hosts. The decision was made calmly, before the incident, by people who had time to think; the operator just executes it.

Predefined strategies make the life of an operator or IT admin very easy. You cannot list out every possible incident, so you highlight the most common ones based on the context of your organization. And the organization should define the acceptable risks in dealing with these incidents — because ultimately, everything in the incident lifecycle is about keeping the risk of the organization within the acceptable level. When you remove a malware-infected laptop from the network by disabling its LAN, you are reducing the risk of it spreading to more machines — you are pushing risk back inside the risk appetite.

9.7.3 Containment Approaches

The concrete containment strategies named: isolating the system from the network, shutting down the system, or — in a primary/secondary setup — redirecting all traffic to the secondary systems the moment an issue with the primary is identified. The right approach depends on the organization.

Worked example — primary and secondary redirect: An organization runs its customer portal on a primary system with a live secondary system ready to take over. An alert shows anomalous activity on the primary. The predefined strategy fires immediately: all traffic is redirected to the secondary system, and the primary is taken offline for investigation. The incident is contained before it damages anything — clients never see an outage because the secondary absorbed the traffic from the first redirected request, and the responders now own the damaged primary in isolation, where it can be analyzed without touching production.

The three approaches trade off differently: isolation keeps the service alive on the infected host's neighbors but leaves the compromised host available to its attacker locally; shutdown is the most complete containment but kills the service; redirect preserves service continuity but requires a redundant system that must be kept ready at all times. The choice is a risk decision (section 9.3): how much availability am I willing to trade for how much containment, and does the outcome keep the residual risk inside the risk appetite?

Recap + bridge: Containment comes first because it limits the spread and buys time for a tailored remediation; the shutdown decision belongs to the shift boss or account head, not the analyst, and predefined strategies make the common cases instant. With the damage fenced in, the response now has to preserve the proof of what happened — evidence gathering and handling.

Real-world connection: The primary/secondary redirect is the architecture behind every "failover" story in production IT: cloud providers and banks run live standby systems so that an incident on the primary is invisible to customers. The containment decision at that scale is made by on-call incident commanders working from exactly the same playbook idea — pre-decided steps for the most common incidents, executed fast, with business impact reviewed afterward.

9.8 Evidence Gathering and Handling

9.8.1 Evidence for Resolution and for the Court

Hook: Evidence serves two very different masters. The first master is your own response — you need to know what happened to fix it. The second master is the court — if the incident ever goes to trial, the same evidence must survive a much harder test: being admissible.

The primary reason for gathering evidence is to resolve the incident — but sometimes it is needed for legal proceedings, for example if the incident must be addressed in court, or if the company wants to sue the person who accessed the system illicitly. All evidence, including compromised systems, must be preserved so that there is no tampering of the data — that is what makes it admissible in court.

Not all evidence you submit is admissible. The law defines which evidence is primary and which is secondary.

Worked example — hearsay is not admissible: Suppose person A killed person B. A witness comes forward and says: "I heard from person D that person B killed person A." The court will not accept that — it is hearsay: the witness is repeating what someone else said, so the source cannot be cross-examined and the statement cannot be verified. The admissible version is the witness's own direct observation. The digital parallel: a security analyst testifying "the logs show the attacker's IP" is primary evidence only if the logs were collected and preserved by a verifiable process; a claim of "a colleague told me the logs show it" is hearsay and will be excluded.

Primary evidence requires maintaining the chain of custody and ensuring the data has not been tampered with — the same chain of custody introduced as a preparatory requirement in section 9.3.3. In India, the Indian Evidence Act 1872 defines which evidence can be admitted into a court of law and which cannot. So the message is: evidence should be collected according to procedures that meet all applicable laws and regulations, procedures developed with your legal staff and appropriate law enforcement agencies, so the evidence can be admitted as an artifact in court.

Pitfall — destroying evidence while fixing the problem: The most natural response to a suspected incident is to start fixing: reboot the machine, reinstall the software, change the configuration. Every one of those actions can destroy or distort the evidence on the device. The discipline that keeps evidence admissible is to do as little as possible before the scene is secured and the data is captured — the same reason a fire responder does not start picking through debris while the zone is still burning.

9.8.2 Bug Bounty Programs

The evidence discussion leads to bug bounty, because a bug-bounty report is all about proving a vulnerability with evidence: you cannot just say "as per the OWASP Top 10 vulnerability list, a CSRF attack can happen here" — you have to prove exactly how a cross-site request forgery could happen.

Q: Have you heard of the term "bug bounty"? A: Most of you would have heard of it. Companies know they are never 100 percent secure, so beyond internal vulnerability assessment, penetration testing, and outsourced external pen tests, they run bug bounty programs: a bounty is given for identifying a bug — a security loophole.

Worked example — the Facebook bug bounty walkthrough: Take facebook.com. Facebook has implemented all necessary controls, but still, a white-hat hacker — a person who does not intend to damage Facebook — sends an email saying: "In your UI (user interface) there is a security bug in a few lines of code that will let an actual attacker deface the website — for example, deface the profile of a person." The researcher shows a video of how to do it and sends all the details. Facebook's security testing team analyzes the report and confirms whether it is valid. Once they confirm the bug is accurate, they award money to the person who reported it. That is a bug bounty.

The walkthrough contains the whole economics of the model: the company buys evidence, not claims. The report had to show the exploit working (the video) before any money moved — the same standard as the CSRF rule above. The security team's confirmation step is the validation gate: reports that cannot be reproduced are rejected, and only proven findings get paid.

Payouts scale with severity: the example figures cited are about 5,000 dollars for a critical bug, 2,000 dollars for a medium bug, and 1,000 dollars for a low bug (amounts vary by vendor). Most companies enroll in bug bounty programs, and if you google "bug bounty program" you will find the vendors who provide them. You can self-enroll for free, and just browsing what security researchers are listing each month genuinely improves your knowledge — you see the thought process of how researchers exploit a very small loophole, sometimes as simple as a data-input-validation mistake in the code.

Pitfall — citing the list instead of proving the exploit: A report that says "this endpoint is vulnerable to CSRF because CSRF is in the OWASP Top 10" shows nothing. The vulnerability list is a catalog of categories, not a proof about any specific endpoint. A valid report must walk the reader through the actual request, the missing token, and the consequence — evidence, not citations.

Career value is called out directly: this is one of the areas to concentrate on if you want to enter the cyber security domain. AppSec people mostly focus on bug bounty programs. There are ratings — top-rated performer, medium-rated performer — and putting "bug bounty" with a rating on your resume raises its weightage considerably. Real-world: bug bounty programs exist for Apple products, Oracle products, Salesforce, and many government sites; you can report to medium- or low-tier companies that have enrolled and earn rewards.

9.8.3 Identifying the Attacking Host: Priorities

During incident handling, system owners and others sometimes want to identify where the attack came from — which IP addresses or MAC addresses. That matters, but the IRT should first focus on containment, eradication, and recovery.

The fire analogy again: As a fire responder, your main job is not to investigate where the fire started — your main job is to save the lives of the people and to contain the zone. Alarms, eradication, and finally recovery come before origin investigation. An origin that is found while the fire is still spreading is just a fact you cannot use; a contained fire can be investigated safely afterward.

The priority order is fixed: containment, eradication, and recovery come first; identifying the attacking host (by IP or MAC addresses) comes after the environment is safe. The IP or MAC address is collected during the response — you record what you see in the logs and tickets — but hunting the attacker's identity must not delay or compete with stopping the damage. The attacker's identity is a case for law enforcement and post-incident investigation, not for the containment phase.

Recap + bridge: Evidence is gathered for both resolution and the court, with admissibility guarded by the chain of custody and primary-versus-secondary rules; bug bounty programs are the market version of the same idea — rewards for proven vulnerabilities; and the IRT's priority order keeps containment, eradication, and recovery ahead of identifying the attacking host. Next: actually removing the attacker and restoring the environment — eradication and recovery.

Real-world connection: The hearsay and admissibility rules are not classroom formalities — the Indian Evidence Act 1872 and equivalent evidence statutes in other countries are exactly what digital forensics teams prepare for when they preserve systems, document the chain of custody, and write their reports as court-ready artifacts. And bug bounty platforms (the same ones the lecture names for Apple, Oracle, and Salesforce) are now a standard hiring and resume channel for application security roles, exactly as the lecture describes.

9.9 Eradication and Recovery

9.9.1 Eradication: Remove the Presence

Hook: Containment stops the attacker from doing more damage. But the attacker is still inside the building. Eradication is the phase where you go room by room and remove them — every copy of the malware, every compromised account, every hidden persistence mechanism.

Eradication means removing the presence of the attacker from your environment. Examples: deleting the malware, disabling breached accounts, deleting breach accounts — whatever the presence is. During eradication it is important to identify all the hosts within the organization that need remediation: is it only one system, or multiple systems? You should list out the systems that have been impacted.

Why does the host list matter so much? Because eradication is only complete when the last copy is gone. If the attacker installed the malware on one server but moved sideways to three others, cleaning only the first server leaves three live presences that can re-infect everything you just cleaned. The list of impacted hosts is the eradication work order: every host on the list must be remediated before the environment can be called clean. For some incidents, eradication is either not necessary or is performed during your recovery — that depends on the incident that has happened.

Worked example — eradication across hosts: The rootkit scenario from section 9.2.2, detected after six months: the investigation lists impacted hosts — two web servers, one database server, and a developer workstation. Eradication removes the rootkit binaries and the attacker's backdoor from each of the four hosts, one by one, and disables the three breached accounts the attacker created. Each host is verified after cleanup before the next host is started, so a clean host is never re-exposed to a still-infected neighbor.

Eradication also ties into the account side: eradicate those accounts and update your security posture by mitigating all the vulnerabilities that were exploited. The phrase "update your security posture" matters: eradication closes this incident's presence, and mitigating the exploited vulnerabilities closes the door so the same attack cannot walk back in — which is the preparation-phase loop (section 9.10) in miniature.

9.9.2 Recovery: Back to Normal

After eradication you recover from the incident: restore the data, bring systems back, and confirm the environment is clean. The recheck loop matters here too — after containment and eradication, you go back through detection/analysis to make sure no further systems have been impacted by the virus or malware. Then, and only then, is the incident handled and everything back to normal.

Pitfall — restoring the infection with the backup: Recovery has a classic failure mode: you restore data from backups without realizing that the backups themselves were taken after the infection began, so the "clean" restore brings the malware back with the data. Recovery must verify that the restore source is trustworthy (backup timestamps before the infection window, or verified-clean images) and confirm the environment is clean after restore — the recheck loop is what catches this failure.

Recap + bridge: Eradication removes the attacker's presence (malware, breached accounts) from every impacted host, and recovery restores data and confirms the environment is clean, with the recheck loop verifying no further systems were impacted. With the environment back to normal, the response enters its final phase — post-incident activity, where the incident pays its lessons forward.

Real-world connection: This two-step rhythm — clean everything, then restore from trusted sources — is why real recovery runbooks demand verified-clean backups and staged bring-up (restore the least critical systems first, confirm, then restore the rest). It is also why patch-and-remediate steps are tracked in the same ticket: an environment that is clean but unpatched is an environment that will host the same incident again next quarter.

9.10 Post-Incident Activity

9.10.1 Lessons Learned and Root Cause Analysis

Hook: The incident is over, the systems are back, and everyone wants to forget it. That is exactly the wrong moment to forget — because the only guaranteed payoff of an expensive incident is what you learn from it, and post-incident activity is where that learning is banked.

Post-incident activity is the stage after everything is back to normal: the lessons learned. You prepare the root cause analysis document — every organization has its own method; some call it the root cause analysis document covering what went wrong, using the five whys technique. You also record what went best and where the areas of improvement are.

Worked example — the five whys in action: The root cause analysis technique asks "why?" five times, each answer feeding the next question, to dig from the symptom to the underlying cause. Suppose the symptom is "the pen-drive incident occurred."

Why did the malware get in? Because an end user inserted a pen drive.
Why could the pen drive be used? Because USB ports were not disabled on managed desktops.
Why were USB ports not disabled? Because the desktop baseline policy did not include a USB control.
Why did the baseline miss it? Because the baseline was never reviewed after the last policy update.
Why was the review missed? Because there is no scheduled baseline-review calendar.

The root cause is not "a careless user" — it is the missing review process, which is exactly the kind of finding that becomes a control recommendation. The five whys also asks what went best (what should be kept) alongside what went wrong, and the areas of improvement get their own list.

The collected incident data has a purpose: from it you dig into where the attack happened, and based on whether the incident impacted a large or small footprint, you define the retention schedule for that incident data. A wide-impact incident earns a longer retention schedule than a single-host one, because the investigation and any legal proceedings will need the data longer. Finally, you produce recommendations, and those recommendations are passed as input into the preparation phase — they go to the security engineering folks, who implement the necessary controls so this incident does not occur again. That is the loop closing: the output of post-incident activity is the input to preparation.

The loop, stated as a law of the lifecycle: The output of post-incident activity is the input to preparation. If that transfer never happens, the cycle is broken — the organization spends on the same incident twice. The March detection-time improvement in section 9.10.3 is the lecture's proof that the loop works when it is followed.

9.10.2 Frameworks: ISO and NIST

Organizations follow some of the best frameworks for their incident response lifecycle — either ISO standards or NIST SP 800-61 (the Computer Security Incident Handling Guide), and some can be client-specific standards. Whatever framework the organization adheres to, that is how the security incident response lifecycle typically flows.

Why follow a published framework instead of writing a private one? Three reasons. First, completeness: the frameworks were written by people who studied many incidents, so they cover phases and roles a home-grown process tends to forget. Second, auditability: auditors and clients recognize ISO and NIST structures, so a response that follows the framework is easier to verify than a custom one. Third, the loop: both frameworks make lessons learned an explicit stage feeding preparation, which is the same feedback cycle the lecture draws between post-incident activity and preparation.

9.10.3 Auditing Incident Response: Detection-Time Scenario Practice

The audit of an incident response procedure document is walked through, and it doubles as exam practice. The audit questions: was any planning done? Was the risk assessment done with the critical assets identified? Were the attack vectors identified from internal and external resources? Were necessary controls identified for those attack vectors? How do they limit false positives, and what mechanisms are incorporated for detection and analysis? What is the generic amount of time taken for every incident's detection?

Then the detection-time trend analysis.

Worked example — the detection-time trend: In January there was a security incident whose detection took about 90 minutes or two hours. As a lesson learned, in March, when an incident happened, the detection time was reduced from 90 minutes to 45 minutes — that proves the lessons learned were fed back into the planning phase. The counter-example: if an incident takes 150 minutes to detect, it has crossed the acceptable detection time — so what do you propose as a cyber security analyst? The reasoning pattern is always the same: compare against the accepted limit, name the gap, and trace the gap to a preparation-phase input. For the 150-minute case the proposal would be a stronger detection feed: new correlation rules, an added sensor, faster alert triage — and the recommendation goes back into preparation, exactly as the loop demands.

Exam note: Multiple scenario-based questions of this exact shape can be asked on the incident lifecycle, and you should practice reasoning through them. Learn the audit checklist as a fixed list — planning, risk assessment with critical assets, attack vectors from internal and external resources, controls, false-positive limiting, and generic detection time — and the detection-time reasoning as a fixed pattern: is the time within the accepted limit, and if not, what preparation input closes the gap?

Recap + bridge: Post-incident activity produces the lessons-learned and root cause analysis documents, sets a retention schedule for incident data, and — critically — passes recommendations back into preparation, closing the lifecycle loop; ISO standards and NIST SP 800-61 frame the process, and audit scenarios train the reasoning. With the full lifecycle mastered, the final section applies it attack by attack.

Real-world connection: The detection-time audit is not a classroom invention — it is the core metric of modern SOCs (mean time to detect, mean time to respond), and quarterly detection-time reviews are exactly how security leadership justifies new tooling to the board. Frameworks matter at this scale too: NIST SP 800-61 is the reference most incident response policies in industry are written against.

9.11 Applying the Lifecycle to Specific Attacks

9.11.1 Malware, Denial of Service, Session Hijacking, and Man-in-the-Middle

Hook: The lifecycle is a frame, not a formula — every attack walks through the same phases, but each attack type walks them differently. This final section takes the four named attacks and runs each one through the same three questions: how do we identify it, how do we contain it, and how do we mitigate it?

The chapter then maps the lifecycle onto specific attacks. For each attack, the target questions are the same: what are the strategies for identifying it, how do we do the containment of it, and what are the mitigations for it? The attacks named: a malware incident; a denial of service (DoS) attack, where an unavailability issue has happened; a session hijack, where a session has been hijacked by a third party; and a man-in-the-middle (MITM) attack. These are the exploits the chapter considers, and each one is aligned to the incident lifecycle: identification, containment, and mitigation are applied per attack type.

Attack	What it targets	Identification focus	Containment focus	Mitigation focus
Malware	Host integrity and confidentiality	Antivirus scans, file-hash changes, suspicious processes	Isolate the infected host from the network	Remove the malware, patch the exploited weakness, restore from clean backups
Denial of service (DoS)	Availability	Traffic volume anomalies, link saturation, service unavailability	Block the attack traffic at the perimeter, redirect to secondary capacity	Rate limiting, filtering rules, capacity planning, attack attribution
Session hijacking	Authentication (the established session)	Unexpected session activity, session ID reuse, replayed requests	Terminate the session, force re-authentication, revoke the session token	Session timeouts, token binding, re-authentication on risk changes
Man-in-the-middle (MITM)	Integrity and confidentiality of communication	Certificate anomalies, unexpected intermediaries, mismatched traffic paths	Cut the tampered path, re-route traffic through verified channels	Cryptographic verification — certificates, strong key exchange, mutual authentication

The comparison row by row shows what is really happening: each attack targets a different leg of the CIA triad, so each identification strategy watches a different signal, each containment stops a different mechanism, and each mitigation fixes a different root cause. The lifecycle frame stays the same — identify, contain, mitigate — but the content of every phase is attack-specific.

For a malware incident the identification signal is the host-level compromise (scan finding, changed file, odd process); containment is isolating the host from the LAN exactly as in the section 9.2.4 walkthrough. For a denial of service the identification signal is availability itself — the ping of death pattern from section 9.2.1 — and containment means stopping the flood at the perimeter before the service collapses. For a session hijack the identification signal is the hijacked session's behavior (requests that do not match the legitimate user's pattern); containment is killing that session and forcing a fresh authentication. For a man-in-the-middle the identification signal is the communication path itself (an unexpected certificate, an extra hop); containment is removing the tampered path from service.

Pitfall — applying the wrong containment: Each attack's containment is tied to its mechanism, and mixing them up wastes the response window. Blocking traffic at the perimeter does nothing against a session hijack (the attacker is already inside a legitimate session), and terminating a session does nothing against a flood (there are thousands of connections, not one). Containment choice must match the mechanism the attack actually uses.

Recap + bridge: The four attacks — malware, denial of service, session hijacking, and man-in-the-middle — each get the same three questions (identify, contain, mitigate), answered differently per attack: host isolation for malware, perimeter blocking for DoS, session termination for hijacking, and cryptographic verification for MITM. This closes the chapter: the lifecycle from preparation to post-incident activity, applied to real attacks, is the whole story of identification, containment, and mitigation.

Real-world connection: These four attacks are the daily workload of security operations: phishing-delivered malware is the most common incident opened in a SOC, DoS remains a standard extortion and disruption tool, session hijacking is the classic web-application failure after login, and MITM is why browsers now treat certificate warnings as hard stops. Recognizing which leg of the CIA triad each attack targets is the first skill an analyst uses when a new alert arrives.

Exam Guidance Summary

Quiz two will cover chapter five and chapter seven only. The pattern is the same as quiz one: 25 MCQs.
Quiz two will be triggered only after the makeup examination is done — around mid-Friday or the end of this month — so you get 10 to 15 days of preparation time.
Weightage: chapter five and chapter seven carry the most weightage in the exam. Chapter seven is theoretical cybercrime; chapter eight is case studies; chapters one to four are already covered for the mid and the quiz.
Scenario-based questions on the incident response lifecycle are likely: you will get a scenario where every phase was done correctly but one thing was missing — the documentation. Be ready to name the missing phase.
Audit-style questions: given a past incident timeline (e.g., January incident detected in 90 minutes; March incident detected in 45 minutes because lessons learned were applied), reason about whether the detection time is acceptable, and propose what you would do as a security analyst if an incident took 150 minutes.
Be ready to contrast inherent risk (before controls) with residual risk (after controls), and to state the role of risk appetite.
Grading pattern: 5 percent quiz one (done), 5 percent quiz two (pending, to be triggered after the makeup exam), mid-semester done. Assignments: 10 is the minimum count required; expect one or two more assignments over the next two to three chapters to complete the count.
The makeup examination is next week; the same syllabus, nothing will be changed.

Key Industry Applications

Monitoring and alerting: Netcool and similar front-end monitoring tools turn threshold-crossing logs into alerts.
Detection platforms: SIEM, EDR, and XDR products, including the newer AI/ML-based XDR platforms that learn an organization's normal behavior and alert on anomalies.
Time synchronization: NTP to keep host clocks aligned for cross-system event correlation.
Readiness tools: Nmap (port scanning), Acunetix (web application scanning), and Qualys (cloud security scanning) should be licensed and ready before an incident, not purchased during one.
Forensics: SaaS-based forensic services that remotely image and capture system data; disk-image analysis tools; packet sniffers and protocol analyzers.
Legal evidence handling: chain of custody, primary versus secondary evidence, and the Indian Evidence Act 1872 for court admissibility.
Bug bounty programs: Facebook, Apple, Oracle, Salesforce, and government sites; vendor platforms where you can self-enroll, study researchers' findings, and earn rewards (roughly 5,000 dollars for critical, 2,000 dollars for medium, 1,000 dollars for low, depending on vendor); a recognized resume credential (top-rated performer ratings) and the primary focus area for AppSec careers.
Vulnerability knowledge: OWASP Top 10 and CSRF — with the requirement to prove an exploit with evidence rather than just cite the list.
Crisis and incident management: ITIL-style crisis declaration, bridge calls, on-call managers, war rooms, and incident notification processes (clients, regulators, senior management).
Service levels: Amazon and GCP SLAs that never promise 100 percent uptime — the residual-risk idea applied to availability (99.9 percent up to 99.99999 percent).
Frameworks: ISO standards and NIST SP 800-61 for structuring the incident response lifecycle, plus client-specific standards.

CS Lecture 9 notes · Incident Response: Identification, Containment, and Mitigation of Cyber Attacks

Cyber Security· postgraduate· 2026-08-16

Sections Breakdown

1Why Identification, Containment, and Mitigation Matter

The event chain from logs to security incidents, the CIA trigger that promotes an incident, and the documented process that guides the incident response team under panic.

2The Incident Response Lifecycle

The full lifecycle loop: preparation, detection, analysis, containment or eradication, recovery, and post-incident activity feeding back into preparation, with detection speed as the decisive factor.

3Preparation Phase

Risk assessment and the risk equation, inherent versus residual risk and risk appetite, the trained IRT and war room, secure storage, forensic hardware and software, and ready-to-use tools.

4Detection Phase

Attack vectors scanned in 360 degrees, indicators of attack versus indicators of compromise, and SIEM, EDR, and XDR correlation to confirm whether an event is an incident.

5Analysis Phase

False positives as the KPI of detection tools, the six best practices for analysis (profiles, log retention, correlation, NTP, knowledge base, external resources), and AI/ML-based XDR.

6Incident Documentation and Handling

Timestamped documentation as the most important criterion, issue tracking systems and their fields, prioritization by business impact, and pre-decided notification.

7Containment Strategy

Why containment comes first, who decides to shut a system down, and the three approaches: isolating from the network, shutting down, and redirecting traffic to secondary systems.

8Evidence Gathering and Handling

Evidence for resolution and for the court, primary versus secondary evidence, the chain of custody, bug bounty programs, and why containment precedes identifying the attacking host.

9Eradication and Recovery

Removing the attacker's presence from every impacted host and restoring from trusted sources, with the recheck loop confirming the environment is clean.

10Post-Incident Activity

Lessons learned and root cause analysis with the five whys, retention schedules, ISO and NIST SP 800-61 frameworks, and detection-time scenario practice.

11Applying the Lifecycle to Specific Attacks

Identification, containment, and mitigation applied to malware, denial of service, session hijacking, and man-in-the-middle attacks.

12Exam Guidance Summary

Exam strategy for quiz two: scenario questions with the missing documentation step, detection-time trend reasoning, and the inherent-risk versus residual-risk contrast.

13Key Industry Applications

Industry tools and standards: Netcool, SIEM/EDR/XDR, NTP, Nmap/Acunetix/Qualys, SaaS forensics, the Indian Evidence Act 1872, bug bounty platforms, and ISO/NIST frameworks.

Postgraduate students in Cyber Security

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

9.1 Why Identification, Containment, and Mitigation Matter

Must-know: The event chain order is events -> logs -> alerts -> incidents -> security incidents, with an incident promoted to a security incident only when the CIA triad (confidentiality, integrity, availability) is impacted; the IRT handles security incidents using a documented process.

⚠️ Top pitfall: Mixing up the chain order (e.g., saying logs turn into events) or treating every alert as an incident without confirming it or checking the CIA impact.

Self-check: A monitoring dashboard shows CPU above 90 percent for ten minutes. Is this already a security incident? Why?

Connects to: 9.2

9.2 The Incident Response Lifecycle

Must-know: The lifecycle order: preparation, detection, analysis, containment/eradication, recovery, post-incident activity feeding back into preparation, with recheck loops from containment back to detection/analysis. Detection is the most important phase; quicker detection means less impact.

⚠️ Top pitfall: Treating the lifecycle as a straight line instead of a loop — forgetting the recheck after containment and the post-incident feedback into preparation; also underestimating detection speed in favor of containment.

Self-check: In the malware walkthrough, why is the re-scan after isolation essential rather than optional?

Connects to: 9.1, 9.3, 9.10

9.3 Preparation Phase

Must-know: Risk = Probability of the adverse event x Impact; inherent risk exists before controls, residual risk remains after controls, and residual risk must satisfy Residual Risk <= Risk Appetite. Preparation limits incidents, never nullifies them.

$R = P \times I$

⚠️ Top pitfall: Confusing inherent risk (before controls) with residual risk (after controls), or believing controls can make an organization 100 percent secure; SLAs never promise 100 percent uptime.

Self-check: An event has probability 0.3 and impact 10,000 dollars. What is the risk value, and is a 100-dollar control worth buying?

Connects to: 9.2, 9.10

9.4 Detection Phase

Must-know: Indicators of attack (IOA) show up before the attack happens; indicators of compromise (IOC) show up after. Detection looks 360 degrees for attack vectors, and correlation via SIEM, EDR, and XDR confirms whether an event is an incident.

⚠️ Top pitfall: Using IOA and IOC interchangeably: 'before the attack' maps to indicators of attack, 'after the attack' maps to indicators of compromise. Treating a single alert as confirmation of an incident.

Self-check: A port-scan burst hits your perimeter an hour before a database breach. Which is the IOA and which is the IOC in this story?

Connects to: 9.2, 9.5

9.5 Analysis Phase

Must-know: The number of false positives is the KPI of detection tools: fewer false positives means more effective detection. NTP (Network Time Protocol) keeps all host clocks synchronized so events can be cross-correlated across systems.

⚠️ Top pitfall: Letting false positives accumulate into alert fatigue, which hides true positives; failing to synchronize clocks so cross-correlation becomes impossible; keeping no logs means no analysis is possible.

Self-check: Why would the analysis phase fail if each host recorded events with its own unsynchronized clock?

Connects to: 9.2, 9.4

9.6 Incident Documentation and Handling

Must-know: Documentation is the most likely missing phase in scenario questions: an end user inserted a pen drive, USB was not disabled, the incident was contained and recovered but closed without documentation — name documentation as the missing step.

⚠️ Top pitfall: Closing an incident without documentation; treating prioritization as technical instead of business-impact based (a core link down is a client crisis only if production clients are affected); notifying the wrong people or in the wrong order.

Self-check: A core network link goes down carrying only SNMP management traffic. Is this a client crisis? Why?

Connects to: 9.7, 9.10

9.7 Containment Strategy

Must-know: Containment comes first to limit impact and buy time for tailored remediation. The containment decision belongs to the shift manager or account head (analyzing business impact, traffic redirection, SLA), not the end analyst, and predetermined strategies make common incidents instant (remove laptop from network, redirect traffic to secondary).

⚠️ Top pitfall: Letting an end analyst make the shutdown decision without business-impact analysis; treating containment as the end of the response (the recheck loop back to detection/analysis is required); listing every possible incident instead of predefining the most common ones.

Self-check: Why is the decision to shut down a server taken by the shift manager rather than the front-line analyst?

Connects to: 9.3, 9.9

9.8 Evidence Gathering and Handling

Must-know: Evidence must be preserved without tampering to be admissible (primary vs secondary; hearsay like 'I heard from person D' is not admissible; Indian Evidence Act 1872). Bug bounty reports must prove the exploit with evidence, not just cite OWASP Top 10. IRT priority: containment, eradication, recovery before identifying the attacking host.

⚠️ Top pitfall: Citing the OWASP Top 10 list instead of proving the exploit; destroying evidence while fixing the problem (rebooting, reinstalling); chasing the attacker's IP/MAC address before containing the damage.

Self-check: Why would a court reject a witness statement that begins 'I heard from person D that...'?

Connects to: 9.3, 9.7, 9.9

9.9 Eradication and Recovery

Must-know: Eradication removes the presence of the attacker (malware, breached accounts) and lists all impacted hosts for remediation; recovery restores data and confirms the environment is clean, with the recheck loop back through detection/analysis before the incident is handled.

⚠️ Top pitfall: Cleaning only one host when several are impacted (leftover presence re-infects); restoring from backups taken after the infection began, which brings the malware back with the data.

Self-check: Why must eradication identify ALL impacted hosts before the environment can be called clean?

Connects to: 9.2, 9.7, 9.10

9.10 Post-Incident Activity

Must-know: The output of post-incident activity is the input to preparation (the loop closes): lessons learned, root cause analysis with the five whys, retention schedule, and recommendations for security engineering. Frameworks: ISO standards and NIST SP 800-61.

⚠️ Top pitfall: Skipping lessons learned so the loop breaks and the same incident recurs; forgetting the retention schedule for wide-footprint incidents; treating detection time as acceptable without comparing to the agreed limit (150 minutes crossed it).

Self-check: January's incident took 90 minutes to detect; March's took 45 minutes. What does the improvement prove about the lifecycle?

Connects to: 9.2, 9.3

9.11 Applying the Lifecycle to Specific Attacks

Must-know: For each attack (malware, DoS, session hijack, MITM) apply identify/contain/mitigate: malware targets host integrity and is contained by isolation; DoS targets availability and is contained by perimeter blocking; session hijacking targets authentication and is contained by terminating sessions and forcing re-authentication; MITM targets integrity/confidentiality and is mitigated by cryptographic verification.

⚠️ Top pitfall: Applying the wrong containment to the wrong attack (perimeter blocking against a session hijack, or session termination against a flood) wastes the response window.

Self-check: Which leg of the CIA triad does a denial of service attack target, and what is its containment focus?

Connects to: 9.2, 9.7

Exam Guidance Summary

Must-know: Quiz two: 25 MCQs on chapters five and seven only. Most likely question shapes: missing-phase scenario (documentation), detection-time trend reasoning (January 90 minutes, March 45 minutes, 150 minutes crossed the limit), and inherent risk vs residual risk with risk appetite.

⚠️ Top pitfall: Preparing for the wrong chapters (chapters one to four are already covered for the mid and quiz one), or forgetting the documentation phase in scenario questions.

Self-check: Which two chapters does quiz two cover, and how many MCQs does it have?

Connects to: 9.1, 9.6, 9.10

Key Industry Applications

Must-know: Named industry tools and standards: Netcool, SIEM, EDR, XDR, NTP, Nmap, Acunetix, Qualys, OWASP Top 10, CSRF, Indian Evidence Act 1872, ISO, NIST SP 800-61, and bug bounty platforms (Facebook, Apple, Oracle, Salesforce).

⚠️ Top pitfall: Confusing tool purposes (Nmap for port scanning, Acunetix for web application scanning, Qualys for cloud scanning) or forgetting that tools must be ready before the incident, not purchased during it.

Self-check: Which tool is the standard port scanner, and why must it be licensed before an incident?

Connects to: 9.3, 9.4, 9.5, 9.8

Previous LectureLecture 08 · Cyber Threat Landscape and Cyber Attacks

Next LectureLecture 11 · Cyber Attacks

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.

Prerequisite Knowledge

Previously Covered in This Subject

9.1 Why Identification, Containment, and Mitigation Matter

9.1.1 The Roadmap of This Chapter

9.1.2 From Logs to a Security Incident: The Event Chain

9.1.3 Why a Documented Process: The Fire Accident Analogy

9.2 The Incident Response Lifecycle

9.2.1 The Stages at a Glance

9.2.2 Detection Time: The Rootkit Warning

9.2.3 The COVID Containment Analogy: The Whole Lifecycle in One Story

9.2.4 A Malware Walkthrough: Scan, Isolate, Re-scan

9.3 Preparation Phase

9.3.1 Limit, Never Nullify: Risk Assessment and Controls

9.3.2 The IRT Team, Contacts, and the War Room

9.3.3 Secure Storage and the Chain of Custody

9.3.4 Hardware, Software, and Information Requirements

9.3.5 The Fire Drill Analogy and Ready-to-Use Tools

9.4 Detection Phase

9.4.1 Attack Vectors: Where the Attack Came From

9.4.2 Indicators of Attack vs Indicators of Compromise

9.4.3 Correlating Alerts: SIEM, EDR, and XDR

9.5 Analysis Phase

9.5.1 False Positives: The KPI of Your Detection Tools

9.5.2 Best Practices for More Effective Analysis

9.5.3 AI and ML-Based XDR

9.6 Incident Documentation and Handling

9.6.1 Record Everything, With Timestamps

9.6.2 The Issue Tracking System

9.6.3 Prioritizing Incidents

9.6.4 Notification

9.7 Containment Strategy

9.7.1 Why Containment Comes First

9.7.2 Decision Making: Who Shuts the System Down?

9.7.3 Containment Approaches

9.8 Evidence Gathering and Handling

9.8.1 Evidence for Resolution and for the Court

9.8.2 Bug Bounty Programs

9.8.3 Identifying the Attacking Host: Priorities

9.9 Eradication and Recovery

9.9.1 Eradication: Remove the Presence

9.9.2 Recovery: Back to Normal

9.10 Post-Incident Activity

9.10.1 Lessons Learned and Root Cause Analysis

9.10.2 Frameworks: ISO and NIST

9.10.3 Auditing Incident Response: Detection-Time Scenario Practice

9.11 Applying the Lifecycle to Specific Attacks

9.11.1 Malware, Denial of Service, Session Hijacking, and Man-in-the-Middle

Exam Guidance Summary

Key Industry Applications

CS Lecture 9 notes · Incident Response: Identification, Containment, and Mitigation of Cyber Attacks

Sections Breakdown

Exam Revision Notes

9.1 Why Identification, Containment, and Mitigation Matter

9.2 The Incident Response Lifecycle

9.3 Preparation Phase

9.4 Detection Phase

9.5 Analysis Phase

9.6 Incident Documentation and Handling

9.7 Containment Strategy

9.8 Evidence Gathering and Handling

9.9 Eradication and Recovery

9.10 Post-Incident Activity

9.11 Applying the Lifecycle to Specific Attacks

Exam Guidance Summary

Key Industry Applications

Was this lecture useful?

BitsNotes AI Assistant

Configure AI Chat

Sign in to use AI Chat