AP Cybersecurity Incident Report Guide

This guide helps you turn raw scenario evidence into a clear, organized cybersecurity report. You will learn how to take logs, permissions, firewall rules, and policy documents and structure them into findings, evidence, risk, impact, recommended mitigation, and follow-up. This skill shows up directly in the Device Security Analysis free-response question and in the workplace-style scenarios across Units 3, 4, and 5.

Where This Shows Up on the Exam

The AP Cybersecurity Exam has one free-response question called Device Security Analysis, worth 30% of your score with a suggested 50 minutes. It gives you several simulated sources from a single device, which may include security policies, firewall configurations, file-system permissions, and log files.

The question asks you to identify security issues, detect evidence of attacks, describe how configuration or permission changes affect the device and users, and evaluate how controls like firewalls or automated systems influence traffic and behavior. Skill Categories 2 (Mitigate Risk) and 3 (Detect Attacks) are assessed here.

The key expectation is this: you must cite evidence from the provided sources and explain your reasoning. A finding without source evidence does not earn what a fully supported finding does.

The Report Structure That Maps to the Rubric

A strong incident report repeats the same building blocks for each issue you find. Use this six-part structure as your mental template, even when the prompt only asks for part of it.

Not every prompt asks for all six. Read the task verbs carefully. If it says Identify, give the finding and evidence. If it says Explain, you owe reasoning that connects evidence to outcome. If it says Write, produce an actual command.

Connecting Findings to Source Evidence

The sample FRQ supplies sources like device firewall settings, system application logs at /var/log/app/network_app.log, authentication logs at /var/log/auth.log, and nginx access logs at /var/log/nginx/access_log. Each source type points you toward specific evidence.

For authentication logs, scan for repeated failed logins from one source, which signals a possible brute-force or password attack. Quote the actual line and the count.

For file-system permissions, read the permission string carefully. A string like rwxrwxrwx (777) on a sensitive directory means everyone can read, write, and execute, which is a weak access control finding. Tie it to the policy that says only certain users should have access.

For firewall configurations, check the access control list rules. A rule that allows broad inbound traffic where the policy only needs one service is your evidence of an overly permissive rule. For access logs, look for unusual request patterns, repeated requests to sensitive paths, or status codes that suggest probing.

A Worked Mini-Example

Imagine the sources include an /var/log/auth.log excerpt and a policy stating accounts should lock after five failed attempts. The log shows this:

</>Code
Feb 12 02:14:09 host sshd[2201]: Failed password for admin from 203.0.113.45 port 51022
Feb 12 02:14:11 host sshd[2203]: Failed password for admin from 203.0.113.45 port 51040
Feb 12 02:14:12 host sshd[2205]: Failed password for admin from 203.0.113.45 port 51058
Feb 12 02:14:14 host sshd[2207]: Failed password for admin from 203.0.113.45 port 51071
Feb 12 02:14:15 host sshd[2209]: Accepted password for admin from 203.0.113.45 port 51090

Here is how you would write that finding.

Finding: The device shows a likely brute-force password attack against the admin account.

Evidence: /var/log/auth.log records four consecutive Failed password for admin from 203.0.113.45 entries within six seconds, followed immediately by an Accepted password from the same IP.

Risk: Rapid, repeated failed logins from a single source indicate an automated password-guessing attack. The successful login afterward suggests the attempt succeeded.

Impact: An adversary may now have authenticated access to a privileged account, which could lead to data theft or further compromise.

Recommended mitigation: Configure an account-lockout policy so the account locks after a set number of failed attempts, consistent with the stated policy. The current behavior shows the lockout was not enforced.

Follow-up: Continue monitoring auth.log for renewed attempts from 203.0.113.45 and review whether the account performed unexpected actions after the successful login.

Notice how every claim points back to a specific source. That is what separates a high-scoring response from a vague one.

A Reusable Workflow

Use this order under exam time pressure so you do not miss anything.

1. Read the prompt and underline each task verb and what it asks for.
2. Skim every source once and jot a one-word label for each, such as auth log, firewall, permissions, policy.
3. Cross-reference: compare what each policy requires against what the logs, rules, or permissions actually show.
4. For each mismatch, draft a finding with its evidence quoted directly.
5. Add risk, impact, mitigation, and follow-up only as the task verbs require.
6. If asked to Write a command, make sure it has the exact indicated effect, such as restricting a permission or denying a firewall rule.

Common Mistakes to Avoid

Do not describe a generic attack without citing the source. Saying brute-force attacks are dangerous earns little; quoting the four failed logins and the IP earns the point.

Do not confuse mitigation with detection. A firewall rule change and an account-lockout policy are mitigations (Skill Category 2). Reviewing logs and setting up alerts are detection methods (Skill Category 3). The prompt may want one, the other, or both, so match your answer to what is asked.

Do not recommend something the evidence does not support. If permissions look correct but the firewall is open, your fix belongs on the firewall, not on the file permissions.

Do not misread permission strings. Practice translating rwxr-xr-- and octal values like 754 quickly, because a wrong reading turns a correct finding into an incorrect one.

Do not propose offensive actions. Keep every recommendation defensive: restricting access, enforcing policy, tightening rules, and monitoring. The course expects you to secure and protect systems using your access responsibly.

Finally, do not leave reasoning implicit when a verb says Explain. Spell out the chain from evidence to outcome so a reader sees exactly why the issue creates risk.

Quick Reference Checklist

Before you move on from any finding, confirm you have done these:

• Stated the finding in one clear sentence
• Quoted the exact log line, permission, or rule
• Named the policy or specification it violates, when one is provided
• Explained the risk and impact in plain cause-and-effect terms
• Recommended a specific, defensive mitigation
• Noted follow-up monitoring or verification when relevant

If you can check every box for each issue, your report reads like the work of a real analyst, which is exactly what the Device Security Analysis question rewards.