CISA Security Event Management: Awareness, Attacks, Testing, Monitoring, Incident Response and Forensics
Security event management is the part of information security that prepares people for attacks, tests and monitors defences, and responds to incidents and preserves their evidence, and in CISA Domain 5, section 5B, the IS auditor evaluates whether each of these works in practice. This lesson covers the six subtopics of 5B: security awareness training and programs, information system attack methods and techniques, security testing tools and techniques, security monitoring tools and techniques, security incident response management, and evidence collection and forensics. You will learn how to judge an awareness program by behaviour, how social engineering, web, malware and denial-of-service attacks work and which control reaches each, how vulnerability scans and the different kinds of penetration test differ and what must be authorized first, how SIEM and intrusion detection are made trustworthy, how incident response runs from preparation to lessons learned, including the auditor's own role, and how chain of custody, order of volatility and write-blocked imaging keep evidence admissible. Frameworks, access, network security and DLP are in the lesson on access control, physical and network security; encryption, PKI and cloud in the sibling lesson on those topics.
On this page10 sections
- Security awareness programs: who, when and how to measure them
- Social engineering attacks and out-of-band verification
- Web application attacks: SQL injection, XSS and CSRF
- Malware and network attacks
- Vulnerability scanning versus penetration testing
- Penetration tests: authorization, rules of engagement and test types
- Security monitoring with a SIEM: coverage, time and tuning
- Intrusion detection and prevention, and honeypots
- Security incident response: phases, escalation, notification and improvement
- Evidence collection and forensics
- Evaluate a security awareness program by behavioural outcomes, coverage of all users and training before access, and recommend role-based content
- Recognise social engineering, web application, malware and DDoS attack methods and recommend the control that addresses each root cause
- Distinguish vulnerability scanning from penetration testing, judge scan evidence (credentials, false positives) and choose the right type of penetration test
- Confirm the authorization, scope and rules of engagement a penetration test needs, including third-party hosting rules and stop criteria
- Assess SIEM coverage, time synchronization and alert tuning, and the choice and deployment of signature or anomaly-based IDS/IPS
- Evaluate incident response phases, escalation, notification timing and metrics, and know what an IS auditor does on discovering an incident
- Apply chain of custody, order of volatility, write-blocked imaging, hash verification and legal holds to judge whether evidence is admissible
Security awareness programs: who, when and how to measure them
A security awareness program is effective when it changes how people behave, so an IS auditor judges it by behavioural outcomes over time, checks that it covers everyone who has access, and checks that people are trained before they receive that access. The CISA task is to evaluate the organization's security awareness training program, and most weak programs fail on one of three points: what they measure, who they reach, or when they reach them.
Measuring effectiveness: activity versus outcome
| Measure | What it shows | Weight as evidence of changed behaviour |
|---|---|---|
| Course completion rate | That people sat the training | Weak: an activity measure |
| Quiz score | That people can recall content shortly afterwards | Weak: recall, not behaviour |
| Volume of material, posters, newsletters | Effort spent by the security team | Weakest: an input |
| Simulated phishing click rate and report rate, trended | What people actually do when a realistic lure arrives | Strong, if the simulations are realistic and varied |
| Real incidents caused by user error, and staff reports of real suspicious messages | Behaviour under real attack | Strong |
When completion and quiz scores are high but click rates stay flat, the program is not achieving its objective, and the auditor should report that its content, targeting and delivery need reassessment rather than accept the activity figures. Report rates add context to click rates, but no second metric can rescue a flawed simulation: when the test itself is recognisable, every number it produces improves because staff spot the test, not because they would spot a real attack.
Simulation evidence is only as good as the simulations. When campaigns are predictable in content or schedule, staff learn to recognise the exercise rather than the threat, and the trend overstates resistance to real attacks. Sound programs vary the scenario, sender, timing and difficulty so that the measurement resembles the threat.
Targeting content by role and risk
A single generic module for everyone is the weakest design. Good programs are risk-based and role-based: the baseline content goes to all users, and groups facing particular threats get specific modules, such as payment-fraud and supplier-verification procedures for finance and accounts payable, credential-phishing and privileged-access behaviour for administrators, and pretexting for help desk staff. When incidents show which groups attackers are succeeding against, that evidence should drive where a fixed training budget goes.
Coverage and timing
- Before access, not after. New users should complete awareness training and acknowledge the security and acceptable use policies before any account is activated. Any window in which an account is live before training is complete is a window in which untrained people handle information assets, and measures that only watch what they do during it are detective, not a substitute.
- Everyone with access. Contractors, temporary and third-party staff need the same training and policy acceptance as employees. Who employs them does not change the exposure their accounts create.
- Refreshed regularly, and updated when the threat changes or incidents reveal a weakness.
Web application attacks: SQL injection, XSS and CSRF
The three web application attacks CISA expects you to distinguish are SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF); each exploits a different trust, so each has a different root-cause control. Defence-in-depth measures such as a web application firewall are worth having, but the auditor's best recommendation for a described flaw is the one that removes it from the code.
| Attack | What is abused | Typical evidence | Root-cause control |
|---|---|---|---|
| SQL injection | The application builds SQL by concatenating user input, so input is executed as code | Database error text in responses to unusual input; data returned or changed that the user should not reach | Parameterized queries (prepared statements), backed by input validation and a least-privilege database account |
| Cross-site scripting | The application sends user-supplied content to other users' browsers without encoding, so attacker script runs with the site's privileges | Script in a stored comment runs for every visitor and sends session cookies elsewhere (stored XSS); script reflected from a crafted link (reflected XSS) | Context-appropriate output encoding, supported by input validation (and cookie flags such as HttpOnly and a content security policy as additional layers) |
| Cross-site request forgery | The application trusts any request that arrives with a valid session cookie | Transactions made from users' own valid sessions after they visited an external page, with no credentials stolen | A unique, unpredictable anti-forgery token bound to the session and required on every state-changing request (SameSite cookies and re-authentication for sensitive actions as extra layers) |
Telling XSS and CSRF apart is the common trap. In XSS the attacker's code runs inside the trusted site in the victim's browser. In CSRF the attacker's page simply makes the browser send a request to the trusted site; no script runs on the site and nothing is stolen, yet the action succeeds because the session cookie travels with it. Strengthening how users sign in does not help against CSRF, because the forged request rides on a session that is already authenticated; encrypting the connection does not stop either attack, because it protects transport, not content.
The general rule for injection flaws: measures that hide symptoms, filter traffic in front of the application or limit what a successful attack can reach are damage limitation. Only changing how the query is built removes the flaw.
Malware and network attacks
Malware is malicious code classified by how it is triggered, spreads or hides, and network attacks such as distributed denial of service target availability; the auditor matches each to the control that actually reaches it.
| Method | Defining feature |
|---|---|
| Logic bomb | Code planted in a system that executes its payload when a condition is met, such as a date or the removal of a particular record. Insider programmers are the classic source, which is why code review, segregation of duties and change control matter. |
| Trojan horse | Malicious function hidden inside an apparently legitimate program. |
| Virus | Attaches to a host file or program and spreads when that host runs. |
| Worm | Self-propagates across networks without a host file or user action. |
| Salami technique | Skims very small amounts (for example rounding fractions) from many transactions. |
| Ransomware | Encrypts data and demands payment; modern groups usually steal a copy first and threaten to publish it (double extortion). |
| Distributed denial of service (DDoS) | Traffic from many sources overwhelms a service or saturates its connection. |
Ransomware is availability and confidentiality
Restoring from clean, pre-intrusion backups and closing the entry point solves the availability problem. If the attackers copied data before encrypting it, the incident is also a data breach: exfiltration must be investigated, and legal and privacy functions must assess breach-notification obligations, whose deadlines usually run from when the organization became aware. An incident should not be closed while that question is open.
Volumetric DDoS needs upstream mitigation
In a volumetric attack the bottleneck is the organization's internet connection itself: once it is saturated, legitimate traffic is lost before it arrives, so nothing on the organization's side of that link, however well configured or scaled, can restore service. The effective control is mitigation upstream: the ISP's filtering or a specialist scrubbing/DDoS protection service that absorbs and filters attack traffic before it reaches the link, ideally contracted and tested before an attack.
Vulnerability scanning versus penetration testing
A vulnerability scan is an automated, broad and repeatable search for known weaknesses that does not try to exploit them; a penetration test attempts exploitation, so it shows which weaknesses an attacker can actually use and what they could reach. CISA's task "utilize technical security testing to identify potential vulnerabilities" covers both, and the auditor must know what each kind of result can and cannot prove.
| Vulnerability scan | Penetration test | |
|---|---|---|
| Method | Automated checks against known vulnerabilities and missing patches | Manual and tool-assisted attempts to exploit weaknesses and chain them |
| Coverage | Broad: many hosts, frequently | Narrow: defined targets, periodically |
| Output | A list of potential weaknesses, including false positives | Demonstrated impact: what was reached and how |
| Risk to operations | Low | Higher; needs authorization and rules of engagement |
| Limits | No proof of exploitability or impact | Never proves the absence of vulnerabilities; reflects testers' skill and time |
Credentialed scans
An uncredentialed scan sees only what a host exposes to the network. A credentialed (authenticated) scan logs in and reads installed software versions, patch levels and local configuration. A low count of missing patches from uncredentialed scans is therefore weak evidence that patching works: the results probably understate missing patches and local weaknesses.
False positives: verify, don't accept or dismiss
Scanners do report false positives, for example when they infer a vulnerability from a version banner on software that the vendor has back-patched. When management says findings are false positives and wants them excluded, the auditor treats the claim as an assertion to be tested, not a conclusion: they check a sample of the disputed findings against patch and configuration records and report what the evidence supports.
Security monitoring with a SIEM: coverage, time and tuning
A security information and event management (SIEM) system collects logs from many sources, correlates them and raises alerts, and it is only as good as three things the auditor tests: which sources feed it, whether their clocks agree, and whether the alerts it raises are the ones analysts can and do act on. (Operational log management, retention and integrity are covered in the IT service operations lesson; this section is about security monitoring.)
Coverage: reconcile sources to critical assets
A SIEM can only alert on events it receives. Metrics about alert handling, such as response times and closure rates, describe how quickly received alerts are processed, not what is being watched, so they can look excellent while an important system feeds nothing in. The audit step that exposes the gap is comparing the systems that actually send events with the organization's inventory of critical systems. A missing source is a blind spot that good handling statistics cannot reveal.
Time synchronization
Correlation and investigation depend on putting events from firewalls, directories, servers and databases on one timeline. If devices keep their own clocks, records of the same action are minutes apart and the sequence cannot be trusted. The fix is to synchronize every device to an authoritative time source (for example via NTP). Improvements to how logs are stored, transported or formatted cannot repair a clock that was wrong when the event was recorded.
Tuning and risk-based prioritization
When alert volume far exceeds analysts' capacity, real attacks are missed among false positives. The recommendation is to tune correlation rules to remove known false positives and to rank alerts by risk, for example by the criticality of the asset and the confidence of the detection, so high-risk alerts are always reviewed. The fix removes noise at its source and puts risk in charge of what is reviewed; responses that only add capacity, help after the fact or cut detection without regard to risk leave the problem in place.
Intrusion detection and prevention, and honeypots
An intrusion detection system (IDS) watches traffic or host activity and alerts on suspected attacks, an intrusion prevention system (IPS) sits inline and can block them, and the main design choice for either is between signature-based and anomaly-based detection.
| Signature (knowledge) based | Statistical / anomaly (behaviour) based | |
|---|---|---|
| How it detects | Matches activity against patterns of known attacks | Learns a baseline of normal activity and alerts on deviations |
| Strength | Accurate for known attacks; few false positives | Can detect new, previously unseen attacks |
| Weakness | Blind to attacks with no signature; signatures must be kept current | More false positives; needs a sound baseline and tuning, and a baseline learned during an attack treats it as normal |
A false positive is an alert on legitimate activity; a false negative is a real attack that raises no alert. False negatives are the more dangerous because they leave no trace in the alert queue, but too many false positives cause real alerts to be ignored.
Deploying an IPS without breaking the business
Because an IPS is inline, every false positive becomes a dropped legitimate transaction. The standard practice is to run it in detect-only (monitoring) mode against real traffic first, tune or disable signatures that misfire, and then enable blocking. Detect-only mode is a stage, not a destination: the plan should define when tuning is complete and blocking begins.
Placement matters too: sensors are placed where they can see the traffic of interest, for example behind the perimeter firewall, on segments in front of critical servers, or on hosts (host-based IDS) where encrypted traffic is decrypted.
Honeypots
A honeypot is a decoy system with no business function, made to look attractive to intruders. Because no one should legitimately use it, any interaction is a strong sign of hostile activity, and recording it shows defenders the attacker's tools and methods. A network of them is a honeynet. A honeypot must be isolated so it cannot become a foothold into production.
Security incident response: phases, escalation, notification and improvement
Security incident response management is the prepared, staged process for limiting the damage of a security incident: preparation, detection and analysis, containment, eradication, recovery, and post-incident review, with defined escalation and notification along the way. (General IT incident and problem management for service disruptions is covered in the IT service operations lesson.)
The phases in order
- Preparation: the plan, roles, contact lists, tools, training and testing. A tabletop exercise, a discussion-based walk-through of a realistic scenario, confirms that team members understand their roles without touching production.
- Detection and analysis: confirm the incident, classify its severity and scope.
- Containment: once an incident is confirmed, stop it spreading, for example by isolating affected hosts. Where legal action is possible, contain without destroying evidence: isolate, then capture a forensic image before anything is wiped or rebuilt.
- Eradication: remove the cause (malware, attacker accounts, the exploited weakness).
- Recovery: restore systems from trusted sources and monitor for recurrence.
- Post-incident review (lessons learned): what happened, what worked, what must change.
Sequence is the test: any step that changes a system before it has been isolated and imaged trades evidence for speed, and a system an intruder has controlled cannot be trusted until it is rebuilt from known-good sources.
The IS auditor who discovers an incident
An auditor who finds signs of an ongoing intrusion escalates immediately to the appropriate level of management so the incident response process can act. Timing matters because damage continues for as long as the information sits with the auditor. The auditor's job is to inform, not to operate: containment decisions belong to management and the response team, and an auditor who takes them compromises independence and may destroy evidence or disrupt operations.
Classification, escalation and notification
The severity scheme decides who gets involved and how fast. A scheme that measures only operational disruption under-rates incidents whose harm is legal or reputational, such as customer records exposed without any outage, and so never routes them to the people who must decide on notification. Severity criteria should include data sensitivity, regulatory and reputational impact, with defined escalation paths to legal, privacy, communications and senior management.
Breach-notification laws usually run from the moment the organization becomes aware of a reportable breach, not from the end of the investigation; the GDPR, for example, requires notifying the supervisory authority within 72 hours of becoming aware, where feasible. The plan should therefore define criteria, legal counsel's involvement and a timeline for the notification decision during the investigation.
Metrics and lessons learned
Response capability is best shown by outcome trends: mean time to detect and mean time to contain. Raw volumes are hard to interpret, because better detection raises them, and measures of effort or preparation are inputs rather than outcomes. A metric is evidence only if its definition is stable: if the point at which an incident counts as finished moves earlier, average duration improves on paper while nothing improves in practice, so the auditor tests the definition before trusting the trend. Likewise, lessons-learned meetings are only valuable if their actions are carried out; recurring weaknesses in the minutes call for each action to have an owner, a due date and tracking to closure reported to management.
Evidence collection and forensics
Digital forensics is the collection, preservation and analysis of electronic evidence in a way that keeps it unaltered and provably so, which rests on four practices: a chain of custody, collection in order of volatility, bit-stream imaging through a write blocker with hash verification, and analysis of copies only. The auditor's role is usually to evaluate whether the organization's procedures and the investigator's work meet these standards, so that evidence will stand up in court or in a disciplinary hearing.
Chain of custody and what hashes prove
A chain of custody is a documented, unbroken record of who collected, handled, transferred and stored each item of evidence, when and why, from seizure until it is presented. It lets the organization show that the evidence presented is the evidence collected and has not been altered. A hash (for example SHA-256) proves that a forensic image has not changed between two points in time, such as creation and analysis. It cannot prove the condition of the original before it was imaged: a custody gap before imaging leaves the evidence open to challenge however often the image is re-hashed.
Order of volatility
Collect the evidence most likely to be lost first. On a running system, memory (running processes, network connections, logged-on users, encryption keys) is lost at shutdown and changes constantly, so it is captured before disk images; logs held centrally and backups stored elsewhere are stable and can wait. Pulling the plug or shutting down a running compromised system destroys memory evidence.
Acquisition and analysis
- For a powered-off device, acquire the whole storage medium bit for bit as a bit-stream (physical) image, because evidence often sits outside the visible file system, in deleted files and unallocated space.
- Connect the source through a write blocker: a hardware device or a validated software write blocker (NIST's Computer Forensics Tool Testing program tests both). An application that merely opens files read-only is not a write blocker, because the operating system can still mount the drive and change metadata.
- Record cryptographic hash values at acquisition so the copy can be shown to match its source, and preserve the source.
- Examination works on verified copies; the source stays untouched, because any change to it undermines admissibility.
- Use validated tools and qualified examiners, and document every step.
Legal hold
When litigation is reasonably anticipated, the organization must preserve relevant information. A legal hold suspends normal deletion for the specific custodians and data involved (for example the records of the people and systems involved in the dispute), while routine retention continues for everything else. It is targeted rather than a rewrite of the retention policy, and it must actually stop automated deletion: controls that document the integrity of what is kept do not preserve what a schedule is about to remove.
Tip. Questions on this topic are written from the IS auditor's chair: what is the best evidence a program or capability works, what the primary concern is in a described situation, which control best addresses an attack, and what to confirm, recommend or do first. Expect scenarios on awareness metrics and simulated phishing, training timing and coverage, pretexting, business email compromise and push fatigue, SQL injection versus XSS versus CSRF, logic bombs, ransomware with data theft and volumetric DDoS, credentialed scans and disputed false positives, penetration test authorization, cloud-hosted targets and stop criteria, blind, double-blind, targeted and internal tests, SIEM coverage, clock synchronization and alert overload, IDS detection methods, IPS rollout and honeypots, incident phases and evidence-preserving containment, the auditor discovering an intrusion, severity criteria and notification deadlines, misleading response metrics, chain of custody, order of volatility, write-blocked imaging and legal holds. Several options are usually defensible; the item turns on root cause over defence in depth, preventive over detective, sequence, and the auditor's independence.
- Judge awareness programs by behaviour (trended phishing click and report rates with varied lures), not completion or quiz scores; train everyone, contractors included, before access
- Social engineering is stopped by out-of-band verification using contact details already on record, and push fatigue by number matching or phishing-resistant MFA
- Root-cause fixes: parameterized queries for SQL injection, output encoding for XSS, session-bound anti-forgery tokens for CSRF
- Volumetric DDoS must be filtered upstream; ransomware with data theft is also a breach that needs a notification assessment
- Scans list potential weaknesses (credentialed scans see more, false positives must be verified); penetration tests show exploitability but never prove absence
- Penetration tests need written authorization, scope and rules of engagement first; double-blind tests the response team, targeted tests are efficient, internal tests show lateral movement
- A SIEM is only as good as its log sources, synchronized clocks and tuned, risk-ranked alerts; run a new IPS in detect-only mode and tune before blocking
- Incident response: contain first, preserve evidence before rebuilding; an auditor who finds an intrusion escalates to management rather than acting
- Severity criteria must include data sensitivity, and notification decisions run during the investigation; track MTTD/MTTC and lessons-learned actions to closure
- Forensics: unbroken chain of custody, most volatile first, bit-stream image through a write blocker, hash original and image, analyse copies only, legal hold to stop deletion
Frequently asked questions
What is the difference between a blind and a double-blind penetration test?
In a blind penetration test the testers receive little or no information about the target, so they simulate an outside attacker. In a double-blind test the target organization's security and IT staff are also not told the test is happening, so it measures both the strength of the defences and the security team's ability to detect and respond to a realistic attack.
Why is a credentialed vulnerability scan better than an uncredentialed one?
A credentialed scan logs in to each host and reads installed software versions, patch levels and local configuration, while an uncredentialed scan sees only services exposed to the network. Uncredentialed results therefore tend to understate missing patches and local weaknesses, and a low finding count from them is weak evidence that patching is effective.
What does a hash prove in a forensic investigation, and what does it not prove?
A hash value proves that a forensic image or file has not changed between the two times it was hashed, for example at acquisition and at analysis. It does not prove the condition of the original evidence before it was imaged; only an unbroken chain of custody from seizure can show the original was not altered in that period.
What is the order of volatility in digital forensics?
The order of volatility is the principle of collecting the evidence most likely to be lost first. On a running system, memory contents such as running processes, network connections and encryption keys are collected before disk images, because they disappear at shutdown; stable sources such as central logs and offsite backups are collected later.
What should an IS auditor do on discovering an ongoing intrusion during an audit?
The IS auditor should report it immediately to the appropriate level of senior management so the organization's incident response process can begin. Containment and remediation are management decisions; an auditor who acts on systems directly compromises independence and risks destroying evidence, and any delay lets the damage continue.
How do signature-based and anomaly-based intrusion detection differ?
Signature-based intrusion detection matches activity against patterns of known attacks, so it is accurate for known threats but cannot detect new ones. Anomaly-based (statistical) detection learns a baseline of normal behaviour and alerts on deviations, so it can detect previously unseen attacks but produces more false positives and depends on a sound baseline.
What is the best evidence that a security awareness program works?
The best evidence is a behavioural outcome measured over time, such as a falling click rate and a rising report rate across realistic, varied simulated phishing campaigns, or fewer real incidents caused by user error. Completion rates and quiz scores show that training was delivered and remembered, not that behaviour changed.
What is a legal hold?
A legal hold is an instruction that suspends the normal deletion of specific information, such as the email and files of the people involved, when litigation or an investigation is reasonably anticipated. It preserves the relevant evidence while routine retention and deletion continue for unrelated records.
Source
This lesson covers the "Protection of Information Assets" domain of the official CISA exam guide. Vendors revise their guides — check the source for the current version.
- ISACA CISA Exam Content Outline — ISACA
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.
Social engineering attacks and out-of-band verification
Social engineering manipulates people rather than technology into handing over access, money or information, and the controls that stop it are procedures that verify the request through an independent, trusted channel instead of trusting what the request itself claims.
Controls that work, and why others fail
When a request that would grant access or release information arrives by phone or message, the preventive control is to verify the requester's identity through a channel the requester does not control, using details or verification factors the organization registered beforehand, before acting. The general principle: controls that only record or review what happened are detective and cannot stop the deception, and controls built against guessing are beside the point when the attacker is simply given what they ask for.
BEC from a compromised supplier mailbox is hard to catch by inspecting the message, because it genuinely comes from the supplier's address and technical checks on the sender pass. The reliable control therefore sits in the payment process rather than the mailbox: a change to bank details is confirmed out of band through contact information the organization recorded before the request arrived, never through anything supplied in the request. Any review step adds protection only if it includes that independent confirmation; reviewers who rely on the same message inherit the same deception.
For MFA fatigue, the fix is in the authentication design: approval should depend on something only the person who actually started the sign-in can supply. Number matching ties each prompt to the session on the user's own screen, and phishing-resistant authenticators bind approval to the genuine site. Controls triggered by wrong passwords never fire, because the attacker already holds the right one.