ISC Area II.B Security: Understanding Threats, Controls, and Assurance

Threats and attacks (II.B.1)

Security in an information system is about protecting assets—data, applications, infrastructure, and business processes—from events that could harm confidentiality (unauthorized disclosure), integrity (unauthorized alteration), or availability (unreliable access). In CPA contexts, you care about security not only because it’s “IT hygiene,” but because security failures can directly create financial misstatement risk, operational disruption, regulatory exposure (privacy laws and contractual commitments), and breakdowns in internal control over financial reporting.

A useful way to learn threats is to separate three ideas that are often blurred:

Threat: a potential cause of an unwanted incident (e.g., a motivated attacker, a careless employee, a natural disaster).
Vulnerability: a weakness that could be exploited (e.g., unpatched software, weak passwords, overly broad access).
Attack/exploit: the action that uses a vulnerability to cause harm (e.g., phishing for credentials, SQL injection, ransomware).

As an auditor or advisor, you’re constantly mapping: What could go wrong? How could it happen? What would the impact be? That map is the foundation for choosing controls in II.B.2 and for testing them in II.B.3.

Common threat sources: who/what causes security incidents

External adversaries include cybercriminal groups, hacktivists, competitors, and nation-state actors. Their motivations differ—financial gain, disruption, espionage—but the techniques often overlap.

Insider threats are risks from people who already have legitimate access (employees, contractors, system admins). Insider risk can be malicious (fraud, sabotage, data theft) or accidental (sending sensitive files to the wrong recipient, misconfiguring cloud storage). Insider threats matter in CPA work because insiders can bypass “perimeter” defenses and because access and segregation-of-duties weaknesses often show up here.

Third parties (vendors, managed service providers, SaaS providers) expand your attack surface. A vendor breach can become your breach through shared credentials, integrations, or data hosting.

Environmental/physical threats include fire, flood, power loss, theft of devices, and unauthorized entry to facilities. These affect availability and can also lead to data exposure if devices or backups are stolen.

How attackers actually get in: major attack patterns

Instead of memorizing a long list, it’s more useful to understand the few “paths” attackers use repeatedly.

1) Credential and identity attacks

Most real-world compromise starts with identity—because if an attacker can log in as a valid user, many security tools treat them as “normal.” Key examples:

Phishing: deceptive messages that trick users into revealing credentials or running malicious actions. Phishing can be mass (“spray and pray”) or targeted.
Spear phishing / business email compromise (BEC): tailored phishing aimed at finance, payroll, or executives—often to redirect payments or change vendor bank details. This is especially relevant to accounting processes.
Credential stuffing: using stolen username/password pairs from other breaches to try logins at scale (works when users reuse passwords).
Password spraying: trying a few common passwords across many accounts to avoid lockout thresholds.
Session hijacking / token theft: stealing authentication tokens (for example, from an infected endpoint) so the attacker doesn’t need the password.

Why it matters: If identity controls are weak (single-factor passwords, weak reset processes, poor monitoring), downstream application controls—like approvals—can be undermined because the attacker is “acting as” an authorized user.

2) Malware and ransomware

Malware is malicious software designed to damage systems, steal data, or enable unauthorized access. A major category is ransomware, which encrypts or locks data/systems and demands payment.

How it works, step-by-step (typical chain):

Initial access (often phishing, stolen credentials, or exploiting an exposed service).
Establish persistence (so the attacker can return).
Privilege escalation (gain higher access).
Lateral movement (spread to servers, file shares, backups).
Impact (encrypt, exfiltrate data, threaten disclosure).

What goes wrong in organizations: teams focus only on “preventing infection” but neglect containment (segmentation) and recovery (tested backups). In practice, ransomware resilience is as much about recovery controls as prevention.

3) Network and communications attacks

Denial of service (DoS) / distributed DoS (DDoS): overwhelming a service so legitimate users can’t access it. Availability is the primary target.
Man-in-the-middle (MITM): intercepting or altering communications—often via insecure Wi‑Fi, spoofing, or compromised routing.
DNS attacks (like spoofing or poisoning): redirecting users to malicious destinations.

Why it matters: even if data isn’t “stolen,” downtime can stop billing, payroll, or transaction processing—directly affecting financial operations and reporting timelines.

4) Application and data attacks

Applications are frequent targets because they directly expose data and business logic.

SQL injection: attacker inputs crafted text that changes database queries when inputs aren’t properly handled. Impact can be data theft or data manipulation.
Cross-site scripting (XSS): attacker injects scripts that run in a user’s browser, often to steal sessions or alter displayed information.
Broken access control: users can access data/functions they shouldn’t (for example, changing a URL to view another customer’s invoice).
Insecure APIs: weak authentication/authorization on system-to-system interfaces.

In CPA scenarios, integrity is a major concern: an attacker changing master data (vendor bank accounts, customer addresses, pricing tables) can create fraudulent payments or misstatements without “stealing” data outright.

5) Misconfiguration and cloud-specific exposures

Many incidents are not from “advanced hackers” but from preventable setup errors:

Publicly exposed storage buckets or databases
Overly permissive access roles
Lack of network segmentation in cloud environments
Disabled logging

These matter because modern environments are configurable at high speed; without governance and review, the configuration becomes the vulnerability.

6) Physical attacks and device loss

Stolen laptops, unencrypted portable drives, tailgating into secure areas, and improper disposal of media can all lead to data breaches. Physical security is often underestimated because it feels “non-technical,” yet it’s a straightforward way to bypass digital controls.

Example: mapping a threat to business impact (how you’d think on the exam)

Imagine an AP clerk receives an email “from the CFO” requesting a new vendor be set up and paid urgently. The email is actually a BEC attempt.

Threat/attack: spear phishing/BEC; social engineering.
Vulnerability: lack of strong vendor setup verification; weak email authentication; insufficient segregation of duties.
Impact: fraudulent disbursement; potential financial misstatement; control deficiency.

Notice that the core issue is not “email” alone—it’s how the security event exploits a business process weakness.

Exam Focus

Typical question patterns:
- Identify the most likely attack type given symptoms (e.g., encrypted files + ransom note → ransomware; urgent wire request + spoofed executive email → BEC).
- Map a described vulnerability to a plausible exploitation path (e.g., “no MFA + remote access” → credential compromise leading to unauthorized entry).
- Distinguish which part of CIA is primarily impacted and what downstream business risks follow.
Common mistakes:
- Treating “threat” and “vulnerability” as the same thing—on exam questions, controls address vulnerabilities and reduce likelihood/impact of threats.
- Over-focusing on exotic attacks and missing basics (credential compromise, misconfiguration, weak approvals).
- Assuming confidentiality is always the main issue—availability (DDoS, ransomware) and integrity (unauthorized changes) are just as testable.

Mitigation (II.B.2)

Mitigation means reducing security risk to an acceptable level by implementing controls. In practice, you mitigate risk by:

Reducing the likelihood of an incident (prevention)
Increasing the chance you detect it quickly (detection)
Limiting damage and restoring operations (response and recovery)

A foundational idea for ISC is that “security controls” aren’t only technical tools. They include administrative controls (policies, training, governance), technical controls (system configurations, encryption, authentication), and physical controls (locks, badges, cameras). Strong programs layer these—often called defense in depth—so failure of one control doesn’t equal a breach.

Control objectives and the CIA lens

Before choosing controls, be clear on what you are protecting:

Confidentiality: prevent unauthorized access/disclosure.
Integrity: prevent unauthorized or undetected changes.
Availability: ensure reliable access and timely recovery.

Different threats target different objectives. For example, DDoS drives availability controls (rate limiting, redundancy), while BEC drives identity and process controls (MFA, call-back verification).

Preventive controls: stopping incidents before they happen

Identity and access management (IAM)

Access control is often the highest-leverage mitigation because so many attacks revolve around identity.

Authentication confirms who you are (passwords, tokens, biometrics). Multi-factor authentication (MFA) reduces the value of stolen passwords.
Authorization determines what you can do once authenticated. Key principles are:
- Least privilege: give only the access needed.
- Role-based access control (RBAC): assign access by job role to reduce ad hoc permission sprawl.
- Segregation of duties (SoD): prevent one person from controlling an entire transaction end-to-end (e.g., vendor setup + payment approval).

What commonly goes wrong: organizations implement MFA for employees but ignore privileged accounts, service accounts, and third-party access. Attackers target those “exceptions.”

Secure configuration and patch management

Many exploits depend on known vulnerabilities.

Patch management is the process of identifying, evaluating, testing, and deploying updates.
Secure baselines standardize hardened configurations (e.g., disabling unnecessary services, strong encryption settings).

Why it matters: unpatched systems are predictable targets. In audit scenarios, weak patch governance can be a systemic control deficiency because it affects many systems at once.

Network security and segmentation

Firewalls control allowed inbound/outbound traffic.
Network segmentation limits lateral movement—if a workstation is compromised, segmentation reduces the attacker’s ability to reach finance servers or domain controllers.
Zero Trust (as an approach) emphasizes verifying access based on identity, device, and context rather than trusting “inside the network.”

A practical analogy: segmentation is like watertight compartments on a ship—it doesn’t prevent a leak, but it prevents a single leak from sinking the whole ship.

Secure software and change management

Security also depends on how changes are made.

Change management requires authorized requests, testing, approvals, and controlled deployment.
Secure development practices reduce vulnerabilities like injection and broken access control.

CPA-relevant connection: unauthorized or untested changes can break application controls (e.g., three-way match, credit limit logic), creating both security and financial reporting risk.

Encryption and key management

Encryption protects data by making it unreadable without the key.

Encryption in transit (e.g., TLS) protects data moving across networks.
Encryption at rest protects stored data (databases, disks, backups).

What commonly goes wrong: teams “turn on encryption” but mishandle key management (who can access keys, how keys rotate, how keys are backed up). If keys are stored with the encrypted data and broadly accessible, encryption provides little real protection.

Detective controls: finding incidents quickly

Even strong prevention fails sometimes. Detective controls reduce impact by shortening the time between compromise and response.

Logging and monitoring: recording events (logins, privilege changes, data exports) and reviewing them.
Security information and event management (SIEM) tools can centralize logs and alert on suspicious patterns (e.g., impossible travel logins, repeated failed logins, mass file access).
Intrusion detection systems (IDS) detect suspicious network or host behavior.

A key audit idea: a log that no one reviews is not an effective control. Exam questions often test whether monitoring is designed and operating effectively (e.g., alerts investigated, evidence retained, escalation documented).

Corrective controls: response and recovery

Corrective controls limit damage and restore normal operations.

Incident response (IR)

An incident response plan defines roles, escalation, evidence handling, containment steps, and communications. It should address:

Decision rights (who can take systems offline)
Legal/regulatory notifications (where required)
Coordination with vendors and law enforcement
Forensics and preservation of evidence

Where organizations stumble: they have a document but have never practiced it; during an incident, decisions become slow and inconsistent.

Backup and disaster recovery

Backups are central to resilience, especially against ransomware.

Backups must be protected (access-controlled, segmented) so attackers can’t encrypt/delete them.
Recovery requires defined recovery time objectives (RTO) and recovery point objectives (RPO)—targets for how fast you must restore service and how much data loss is tolerable.

Even without memorizing exact definitions, you should reason correctly:

Tighter recovery requirements generally mean higher cost (more redundancy, more frequent backups, more automation).
Untested backups are a common failure—restore can be slow or impossible.

Administrative and people-focused mitigations

Many high-impact incidents (phishing, BEC, insider mistakes) are human-driven. Controls include:

Security awareness training tied to real workflows (finance-specific examples are crucial).
Written policies (acceptable use, password policy, remote work, data handling) that are actually enforced.
Joiner/mover/leaver processes to provision and promptly deprovision access.
Vendor risk management: due diligence, contract clauses, and monitoring of third parties who store or process sensitive data.

A misconception to avoid: training is not a substitute for technical controls. You mitigate phishing best with layered controls—MFA, email filtering, user training, and payment verification procedures.

Example: building a mitigation set for BEC in accounts payable

If you want to reduce BEC-driven fraudulent payments, you rarely rely on a single “silver bullet.” A layered set might look like:

Preventive:
- MFA for email accounts; disable legacy authentication.
- SoD: vendor setup separate from payment release.
- Vendor banking changes require out-of-band verification (call-back to a known number).
Detective:
- Alerts on changes to vendor master data.
- Monitoring for unusual payment patterns (new vendor + urgent wire + high amount).
Corrective:
- Clear escalation path to freeze payments and notify the bank quickly.
- Documented incident process and evidence preservation.

Notice how some controls are “IT” (MFA) and others are “process” (call-back verification). ISC expects you to connect security controls to business processes.

Exam Focus

Typical question patterns:
- Given a threat scenario, choose the best mix of preventive/detective/corrective controls (often the best answer is layered).
- Identify which control principle is being applied (least privilege, SoD, defense in depth, encryption in transit vs at rest).
- Evaluate whether a described control is well-designed (e.g., logs exist but no review → weak detective control).
Common mistakes:
- Proposing only technical tools for problems that require process controls (e.g., BEC needs payment verification/SoD).
- Confusing authentication with authorization (MFA proves identity; it doesn’t ensure users have appropriate permissions).
- Ignoring operational reality—controls must be maintainable (patching requires governance, testing windows, ownership).

Testing (II.B.3)

Testing is how you gain confidence that security mitigations are not just written down, but actually effective. In ISC, testing shows up in two overlapping ways:

Security testing (technical assurance): finding vulnerabilities before attackers do.
Control testing (audit/attestation mindset): evaluating whether controls are designed appropriately and operating effectively over time.

A crucial concept is the difference between design vs operation:

Design effectiveness: if the control works as intended, would it prevent/detect/correct the risk?
Operating effectiveness: is the control actually being performed consistently, by the right people, with evidence?

A control can be well-designed and still fail in operation (e.g., MFA policy exists but many privileged accounts are exempt). Or it can operate consistently but be poorly designed (e.g., logs reviewed weekly when the risk requires near-real-time detection).

Vulnerability assessment and scanning

A vulnerability scan uses automated tools to identify known weaknesses (missing patches, insecure configurations, outdated services). Think of scanning as breadth-first: it covers a lot quickly but may produce false positives and doesn’t always show real exploitability.

How it typically works:

Define scope (systems, networks, applications).
Run scans (credentialed scans are often more accurate than unauthenticated scans).
Validate results (remove false positives, confirm severity).
Remediate and retest.

What goes wrong: teams treat scanning as a one-time event rather than a lifecycle. Also, results may be ignored without ownership and timelines—testing without remediation is not risk reduction.

Penetration testing and red teaming

A penetration test (pen test) is a controlled attempt to exploit vulnerabilities to demonstrate impact. Compared with scanning, pen testing is deeper and tries to answer: “Can this weakness actually be used to compromise something important?”

A red team exercise is typically more adversary-emulated and goal-oriented (e.g., “access sensitive financial reporting data without detection”), often testing people and processes as well as technology.

Why it matters: pen tests and red team results often reveal control gaps in detection and response—such as inadequate monitoring, weak segmentation, or over-privileged accounts.

Key caution: testing must be authorized, scoped, and managed to avoid disrupting operations or violating laws/contracts.

Application security testing (SAST/DAST and code review)

Modern security testing often includes:

Static application security testing (SAST): analyzes source code or binaries without running the program to find patterns like injection risks.
Dynamic application security testing (DAST): tests a running application by sending inputs and observing responses.
Code review: human review of sensitive modules (authentication, access control, payment logic).

A common misconception: “DAST found nothing, so the app is secure.” DAST can miss issues that require specific business logic paths or authenticated context; combining methods gives better coverage.

Control testing in an assurance mindset (what CPAs often do)

When you test a control, you typically:

Understand the control: who performs it, what triggers it, what evidence exists.
Assess design: does it address the risk? Is it precise enough? Are there incompatible duties?
Test operation: select samples over a period and inspect evidence.
Evaluate exceptions: are failures isolated or systemic? What’s the impact?

Examples of security controls that are commonly tested this way:

User access provisioning and deprovisioning (joiner/mover/leaver)
Privileged access reviews
Patch management approvals and deployment evidence
Change management approvals and testing documentation
Log review and incident ticket follow-up
Backup job success reports and restore test results

Your goal is not to “prove no hacks happened.” Your goal is to conclude whether controls reduce risk to an acceptable level and whether failures indicate a material weakness, significant deficiency, or operational risk—depending on the engagement.

Testing incident response and disaster recovery

Plans must be exercised.

Tabletop exercises simulate incidents (ransomware, data breach, BEC) so teams practice decisions and communications.
Disaster recovery (DR) tests validate you can restore systems within required timeframes.
Backup restore tests confirm backups are usable and complete.

What goes wrong: organizations test only the “happy path” (restoring one server) but not dependencies (identity services, DNS, network routing, SaaS integrations). Real recovery fails because systems are interconnected.

Example: testing a user access review control

Suppose management says: “We review user access to the ERP quarterly.” To test operating effectiveness, you would typically look for:

Evidence the review occurred each quarter (dated sign-off).
A complete population (all users, including admins and service accounts, not just “employees”).
Evidence the reviewer is appropriate (independent of provisioning, knowledgeable).
Evidence exceptions were resolved (tickets showing access removed/adjusted, with dates).

If you find one quarter was skipped, or exceptions lingered for months, that’s not just “paperwork”—it means the control may not actually reduce the risk of inappropriate access.

Exam Focus

Typical question patterns:
- Choose the most appropriate testing method (scan vs pen test vs control sample testing) based on what assurance is needed.
- Distinguish design vs operating effectiveness and interpret what an exception implies.
- Identify the best evidence for a control (e.g., access review sign-offs plus remediation tickets, not just a policy statement).
Common mistakes:
- Assuming a tool output alone proves effectiveness—exam questions often expect you to look for review, follow-up, and remediation.
- Testing the wrong population (excluding privileged or service accounts is a frequent “gotcha”).
- Confusing vulnerability scanning with penetration testing (scanning finds potential issues; pen testing demonstrates exploitability and impact).