Google Cybersecurity Certificate, Course 6: Sound the Alarm: Detection and Response (Study Notes)

Plain-English notes on the incident response lifecycle, logs, IDS and SIEM tools, packet analysis and evidence handling. Includes practice questions with explanations.

Independent study aid. Not affiliated with or endorsed by Google or Coursera. All explanations and questions are original. Confirm current course content on the official Coursera page.

1. Course overview

Prevention never stops every attack, so teams also need to notice trouble quickly and handle it calmly. This course covers the life of an incident from first alert to lessons learned, the data sources analysts rely on (logs, network traffic), the tools that watch for threats, and the care needed when handling evidence.

Core idea

Detect early, contain fast, document everything, learn afterwards.

Builds on

Vulnerabilities and attacks from Course 5.

Study tip

Take any news story about a breach and sort what happened into the lifecycle phases.

2. Weekly breakdown (study plan)

A suggested four-part plan grouped by topic. Follow the official course order for graded work, as week titles may differ.

Part 1: Incident response and the lifecycle

An event is any observable occurrence; an incident is an event that threatens security. Most events are harmless.
An incident response team mixes roles: analysts, a lead (incident commander), communications, legal and system owners.
Documentation matters: playbooks guide actions, and a final report records what happened and why.

NIST lifecycle phase	Plain meaning	Example
1. Preparation	Get ready before anything happens	Playbooks, training, tools, contact lists
2. Detection and analysis	Notice and understand it	Alert review, scoping affected systems
3. Containment, eradication, recovery	Stop the spread, remove the cause, restore service	Isolate a host, remove malware, restore from backup
4. Post-incident activity	Learn and improve	Lessons-learned meeting, updated playbook

See NIST’s incident response resources. Related ideas: triage (rank by urgency) and escalation (hand to someone with more authority or skill).

Part 2: Logs, detection and monitoring

Logs record what happened: who, what, when, from where. Sources include operating systems, firewalls, servers, applications and cloud services.
Good logs have accurate timestamps, enough detail, and are protected from tampering.
IDS watches and alerts; IPS also blocks. Signature-based detection matches known bad patterns; anomaly-based detection flags unusual behaviour. Network-based sensors watch traffic; host-based ones watch a single device. Examples: Suricata and Snort.
EDR monitors and responds on endpoints such as laptops and servers.
Indicators: an IoC is evidence a compromise happened (a bad file hash); an IoA is evidence an attack is underway (suspicious sequence of actions).
Alert quality: a false positive is a harmless thing flagged; a false negative is a real attack missed.

Part 3: SIEM and packet analysis

A SIEM (for example Splunk, Google Chronicle or Elastic) collects logs from many sources, normalises and correlates them, and raises alerts. Analysts search and build dashboards. A SIEM is a lead generator, not a verdict.
Packet analysis inspects network traffic itself. Wireshark offers a graphical view; tcpdump works from the command line. A saved capture is a pcap file.
Look at headers (source, destination, ports, flags) and, if unencrypted, the payload. Encrypted traffic hides payloads, so metadata and timing matter.

tcpdump -nn -r capture.pcap port 53       # DNS traffic only
tcpdump -nn -r capture.pcap host 10.0.0.8 # one device's traffic

Capture or analyse only networks you own or are authorised to monitor.

Part 4: Evidence handling and reporting

Chain of custody is a written record of who held evidence, when, and what they did, so it remains trustworthy.
Order of volatility: collect the most short-lived data first (memory, running processes, network connections), then disk, then archives.
Preserve integrity: work on copies, record hashes of images, avoid changing the original, and keep notes with timestamps.
Escalation notes should say what happened, when, which systems, evidence found, actions taken and next steps.
Post-incident review: find the root cause, what worked, what did not, and update controls and playbooks.

3. 15 must-know terms

Term	Plain meaning
Event	Any observable occurrence
Incident	Event that threatens security
Triage	Ranking issues by urgency
Escalation	Passing an issue to the right person
Containment	Stopping an incident from spreading
Eradication	Removing the cause
Playbook	Documented steps for a scenario
Log	Record of system events
IDS / IPS	Detects / detects and blocks threats
SIEM	Central log collection, correlation and alerting
EDR	Endpoint monitoring and response
IoC / IoA	Sign of compromise / sign of attack in progress
Packet capture (pcap)	Saved network traffic
Chain of custody	Record of who handled evidence
Root cause analysis	Finding the underlying reason

4. Three worked examples

Example 1: Triage an alert

Scenario: A SIEM shows 300 failed logins for one account in two minutes, followed by one success from a new country.

Reasoning: the pattern fits credential guessing that finally worked, so this is more than noise. Actions: check the account and source, contain (disable sessions, reset credentials), review what the account accessed, escalate per the playbook, and document times and evidence.

Example 2: Place actions in the lifecycle

Scenario: A company (a) trains staff and writes playbooks, (b) disconnects an infected laptop from the network, (c) restores files from backup, (d) holds a review meeting.

Answer: (a) Preparation; (b) Containment; (c) Recovery; (d) Post-incident activity. Detection and analysis happened between preparation and containment.

Example 3: Handle evidence correctly

Scenario: A suspect laptop is switched on and may be compromised.

Steps: record the time and who is present; capture volatile data first if procedures allow; create a forensic copy of the disk and record its hash; log each hand-off in the chain of custody; analyse the copy, not the original. Why: evidence must be reliable if it is used in HR or legal action.

5. Common mistakes

Confusing event and incident. Most events are normal; not every alert needs a full response.
Skipping documentation. Without notes and timestamps you cannot explain decisions or hand over properly.
Wiping or rebooting too soon. It can destroy volatile evidence and the cause. Follow your procedure.
Treating IDS alerts as proof. Validate before escalating, and track false positives to tune rules.
Mixing up IDS and IPS. One alerts, one blocks.
Forgetting the last phase. Without lessons learned, the same incident repeats.

6. 10 practice questions (tap to reveal)

Q1. What is the difference between an event and an incident?

An event is anything that happens on a system or network; an incident is an event that actually threatens security.

Q2. List the four phases of the NIST incident response lifecycle.

Preparation; detection and analysis; containment, eradication and recovery; post-incident activity.

Q3. Which phase is an analyst in when isolating an infected server?

Containment (phase 3), which limits spread before the cause is removed.

Q4. Why is accurate time stamping in logs important?

It lets you put events from different systems in the correct order and rebuild a timeline of the attack.

Q5. How does signature-based detection differ from anomaly-based?

Signature-based matches known bad patterns and is precise for known threats; anomaly-based flags deviations from normal and can catch new threats but may give more false positives.

Q6. What does a SIEM do that reading one server’s log cannot?

It pulls logs from many sources into one place, correlates them and alerts on patterns that only appear across systems.

Q7. What is a false negative, and why is it dangerous?

A real attack that detection missed. The attacker keeps operating unnoticed.

Q8. Which tool would you open to inspect a saved pcap graphically?

Wireshark. tcpdump can read the same file from the command line.

Q9. What is chain of custody?

A documented record of every person who handled evidence, when and why, proving it was not altered.

Q10. Which data should you collect first: a disk image or running memory contents?

Running memory, since it is more volatile and disappears on shutdown. Then collect the disk image.

7. YouTube search links

8. One-screen revision summary

Lifecycle: Preparation, Detection and analysis, Containment/eradication/recovery, Post-incident activity.
Event vs incident; triage then escalate with clear notes.
Logs: accurate time, enough detail, protected.
Detection: IDS alerts, IPS blocks; signature (known) vs anomaly (unusual); NIDS vs HIDS; EDR on endpoints.
Indicators: IoC (compromise happened), IoA (attack happening).
SIEM: collect, correlate, alert, dashboard; verify before acting.
Packets: Wireshark and tcpdump; pcap; headers vs payload.
Evidence: chain of custody, volatile first, work on copies, record hashes.
Finish: root cause, lessons learned, update playbooks.

9. What you should be able to do

Explain the four lifecycle phases and give an action for each
Tell an event from an incident and triage a simple alert
Write a clear escalation note
Describe what logs contain and why they matter
Compare IDS, IPS, signature and anomaly detection
Explain what a SIEM does and how analysts use dashboards
Filter a packet capture by host or port with tcpdump or Wireshark
Describe chain of custody and order of volatility
Run a basic post-incident review and name a root cause

← Back to hub

Educational summary for learners; not affiliated with Google or Coursera. Verify details against official course materials. Last reviewed: October 2026.

Subscribe to Updates

What's Hot