Module 5/5 · Weeks 13–15 · 27 h

Incident response and frameworks

UAT 367 Cybersecurity, Command and Control Links and Unmanned Aircraft Systems Traffic Management

About 90 minDraft, awaiting reviewLast updated 27 September 2026

By the end of this module you will be able to

Explain cyber incident response under NIST SP 800-61r3, organised by the CSF 2.0 Functions
Write detection rules for UAS logs and arrange the alerts into a timeline
Compute mean times to detect, contain and recover
Identify related frameworks and laws such as DO-326A, the Thai Cybersecurity Act and the PDPA

Prerequisites: UAT 367 Modules 1–4

Why this matters

No system prevents every incident. An equally important question is how quickly the team notices once something happens, and how quickly service returns. For the medical delivery network, every minute the system is down is medicine or blood that does not reach a patient. This module brings the whole course together into an incident response plan that works in practice.

The incident response cycle

NIST SP 800-61 Revision 3 (April 2025) places incident response within the six Functions of NIST CSF 2.0 instead of the older four-phase cycle:

Preparation falls under Govern, Identify and Protect: policies, owners, asset inventories, threat models and the controls from Modules 1–3.
Incident response falls under Detect, Respond and Recover.
Lessons learned feed back to improve every Function.

A purple bar at the top reads Govern. Below are five boxes in a row joined by arrows: Identify and Protect in blue, Detect, Respond and Recover in pink. A line from Recover back to Identify reads lessons learned to improvement. Under the blue boxes is the word Preparation and under the pink boxes Incident response — Figure 1 Incident response with NIST SP 800-61r3 and CSF 2.0

Detection from logs

Good detection starts with knowing what normal looks like, then writing rules that alert when behaviour deviates. Signals tied to earlier modules include bursts of bad-signature frames (Module 3), GNSS position jumps beyond the aircraft’s performance (Module 2) and senders not on the list of known systems.

Example 1 Detection rules on a log

A hypothetical log of one flight; the drone normally flies at about 15 m/s.

import math

log = [
    (95.0, "SIG_BAD", 1), (97.5, "SIG_BAD", 1), (99.0, "SIG_BAD", 1),
    (180.0, "GNSS", (1200, 5)), (181.0, "GNSS", (1215, 5)), (182.0, "GNSS", (1290, 40)),
    (240.0, "HEARTBEAT", 42), (241.0, "HEARTBEAT", 1),
]
KNOWN_SYSIDS = {1, 255}
SIG_WINDOW, SIG_COUNT, JUMP_M = 10.0, 3, 50.0

alerts, bad, last_fix = [], [], None
for t, kind, data in log:
    if kind == "SIG_BAD":
        bad = [x for x in bad if t - x <= SIG_WINDOW] + [t]
        if len(bad) == SIG_COUNT:
            alerts.append((t, "C2 injection attempt", f"{SIG_COUNT} bad signatures in {t - bad[0]:.1f} s"))
    elif kind == "GNSS":
        if last_fix:
            jump, dt = math.dist(last_fix[1], data), t - last_fix[0]
            if jump > JUMP_M:
                alerts.append((t, "GNSS anomaly", f"jump {jump:.0f} m in {dt:.0f} s"))
        last_fix = (t, data)
    elif kind == "HEARTBEAT" and data not in KNOWN_SYSIDS:
        alerts.append((t, "unknown sender", f"system ID {data}"))

for t, name, why in alerts:
    print(f"t = {t:6.1f} s  {name:<22} {why}")

t =   99.0 s  C2 injection attempt   3 bad signatures in 4.0 s
t =  182.0 s  GNSS anomaly           jump 83 m in 1 s
t =  240.0 s  unknown sender         system ID 42

All three rules need thresholds tuned from normal data on the real system, and every alert needs a playbook saying who does what next, such as switching to the backup C2 path, commanding a hover or landing at a safe point, and preserving logs as evidence.

Measuring incident response

A time bar from 0 to 60 minutes. A pink segment from 0 to 6 minutes reads unseen, a gold segment from 6 to 14 minutes reads contain and a green segment from 14 to 52 minutes reads recover. Dashed vertical lines at 6, 14 and 52 minutes read detected, contained and recovered — Figure 2 Timeline of incident 1

Example 2 Times to detect, contain and recover

Records of four hypothetical incidents from drills (minutes from incident start).

from statistics import mean, median

incidents = {                         # start, detected, contained, recovered
    "C2 injection drill": (0, 6, 14, 52),
    "GNSS anomaly on route 2": (0, 2, 5, 20),
    "server credential leak": (0, 15, 31, 95),
    "LTE outage at clinic 3": (0, 4, 9, 33),
}
detect = [d - s for s, d, c, r in incidents.values()]
contain = [c - d for s, d, c, r in incidents.values()]
recover = [r - d for s, d, c, r in incidents.values()]
for name, xs in (("time to detect", detect), ("detect to contain", contain), ("detect to recover", recover)):
    print(f"{name:<18} mean {mean(xs):6.2f} min  median {median(xs):5.1f} min  worst {max(xs)} min")

time to detect     mean   6.75 min  median   5.0 min  worst 15 min
detect to contain  mean   8.00 min  median   6.5 min  worst 16 min
detect to recover  mean  43.25 min  median  37.5 min  worst 80 min

The mean is pulled up by the server credential leak, which took longest, so median and worst case should be reported alongside it. The incident detected most slowly had no dedicated detection rule, a lesson to feed back into better detection.

Frameworks and law

NIST CSF 2.0 and SP 800-61r3 provide the structure for policy and the incident response plan.
RTCA DO-326A / EUROCAE ED-202A, the airworthiness security process, applies to the design of aircraft that need type certification; RTCA has since issued a revision, DO-326B.
Thailand’s Cybersecurity Act B.E. 2562 (2019) sets duties for critical information infrastructure organisations, with the National Cyber Security Agency (NCSA) as the lead agency. Hospitals using this system must check which duties apply to them.
Thailand’s Personal Data Protection Act B.E. 2562 (2019) applies to patient data tied to parcels and to images of people captured by the camera.

Module lab

Lab: a tabletop incident response exercise

Write a one-page incident response plan for the medical delivery network, naming owners and contact channels.
Choose one incident from Module 1’s threat model; the instructor feeds in the scenario step by step during the exercise.
Apply the code from Example 1 to a SITL log with injected anomalies and check that the rules catch them.
Record the time of each step and compute the results with the code from Example 2.
Summarise the lessons learned as a list of improvements with owners and due dates.

Common mistakes

Watch out

No one owns the alerts.
Deleting or overwriting logs during recovery, leaving no evidence.
Reporting only averages, hiding the worst incident.
Running one drill and never updating the plan.
Forgetting personal data rules when sending logs outside the organisation.

Summary

SP 800-61r3 organises incident response by the six CSF 2.0 Functions, split into preparation and incident response.
Detection rules link to analysed threats and need playbooks for what happens next.
Measure times to detect, contain and recover, reporting mean, median and worst case.
Real operations must align with DO-326A, the Cybersecurity Act 2019 and the PDPA as they apply to the organisation.

Check your understanding

Which CSF 2.0 Functions fall under incident response in SP 800-61r3?
An incident starts at 10:00, is detected at 10:12 and recovered at 10:47. What are the time to detect and the time to recover (from detection)?
Detection times are 2, 3, 4 and 31 minutes. What are the mean and median?
What does a position jump of 90 m in 1 s mean when the drone flies at 15 m/s?
Which agency leads under Thailand’s Cybersecurity Act B.E. 2562?

Answers

Detect, Respond and Recover.
12 minutes and 35 minutes.
Mean 10 minutes, median 3.5 minutes.
It is far beyond the drone’s performance, so GNSS should be suspected of an anomaly or spoofing.
The National Cyber Security Agency (NCSA).

Key formulas

Mean time to detect	$MTTD = \frac{1}{n} \sum_{i} (t_{detect, i} - t_{start, i})$
Mean time to recover (from detection)	$MTTR = \frac{1}{n} \sum_{i} (t_{recover, i} - t_{detect, i})$

Key references

Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST SP 800-61r3). National Institute of Standards and Technology. link
National Institute of Standards and Technology. (2024). The NIST cybersecurity framework (CSF) 2.0. link
RTCA. (2014). Airworthiness security process specification (DO-326A; EUROCAE ED-202A). link
พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562. (2562). ราชกิจจานุเบกษา, 136(69 ก). link
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562. ราชกิจจานุเบกษา, 136(69 ก), 52–95. link

In class / field

Intensive lab and field practice recorded in a lab notebook

Learning evidence: Lab notebook signed by the instructor

Module quiz

This is a formative self-check, not a graded exam

Knowledge domain: Law, safety and risk · Communications, networks and IoT

Incident response and frameworks

By the end of this module you will be able to

Why this matters

The incident response cycle

Detection from logs

Measuring incident response

Frameworks and law

Module lab

Common mistakes

Summary

Check your understanding

Key formulas

Key references

Further reading

Safety management systems (SMS)

C2 and abnormal events in simulation

In class / field

Module quiz

Incident response and frameworks

Lesson

By the end of this module you will be able to

Why this matters

The incident response cycle

Detection from logs

Measuring incident response

Frameworks and law

Module lab

Common mistakes

Summary

Check your understanding

Key formulas

Key references

Further reading

Safety management systems (SMS)

C2 and abnormal events in simulation

In class / field

Module quiz