W2_ISSC636_Example

Example:

Adversary Modeling Over Guesswork

Select the Start button to begin

Start

Select the Listen button to play the narration for this slide

Navigation

Listen

buttons

Use the following buttons to navigate through the course content

Listen

Play the audio for the current page

hOME

nEXT

PREVIOUS

Return to the previous page

Return to the course home page

Move to the next page

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Hi, I’m Madison, and I want to tell you about a time when adversary modeling saved us from wasting weeks on the wrong fixes—because we stopped guessing and mapped what the attacker was actually likely to do.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

I worked at Northbay Health Analytics, a company that supported clinics with scheduling insights and reporting. We stored sensitive patient-related metadata, and we had a hybrid environment: some workloads in the cloud, some in an on-prem data center, and a lot of SaaS tools for daily operations.

We had just finished a compliance push. Leadership felt relieved. Then our monitoring team noticed something odd: a few service accounts were authenticating outside of normal hours, and some internal API calls looked unusually repetitive.

Nothing was on fire. No ransomware screen. No major outage. Just… weirdness. The security manager asked me to lead an investigation, but also to answer a bigger question:

“Is this random noise, or are we looking at the start of a campaign?”

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part I – Stop treating it like a single alert

A junior analyst wanted to chase each alert separately. But I suggested we step back and do adversary modeling first.

I asked:

• What would a real adversary want from us?
• What would be the easiest way to get it?
• What is most valuable in our environment?
• What would an attacker do after first access?

We identified the likely objectives:

• access to analytics datasets
• access to customer portals
• access to API keys and service accounts
• access to financial or billing workflows

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Stop treating it like a single alert

Then we listed plausible adversary types:

• opportunistic criminals looking for data for resale

• ransomware affiliates looking for extortion leverage

• a competitor-style actor looking for business intelligence
• a targeted actor looking for long-term access

We didn’t need to name a specific group. We needed a realistic model.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Part II - Build one realistic attack path

We asked: if an attacker wanted sensitive data, what path would they likely take? We mapped a likely sequence:

1. initial access via phishing or stolen credentials
2. establish persistence using a valid account or token
3. credential access: find API keys, service account secrets, or session tokens
4. privilege escalation or access expansion
5. data discovery and collection via internal APIs
6. exfiltration disguised as normal traffic

Then we aligned each step to ATT&CK-style thinking: what tactic is it, what technique might show up, and what would we observe?

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part III – Mark what we can actually see

Here’s where the truth shows up. Because mapping isn’t useful unless it connects to visibility.

We asked for each step:

We discovered three big gaps:

• do we have logs that would show it?
• do we have alerts that would trigger?
• do we have response playbooks?
• do we have owners?

• We had weak visibility on service account token creation and usage.
• We had limited detection for abnormal internal API patterns.
• We had inconsistent auditing of privilege changes for non-human identities.

So instead of trying to “fix everything,” we focused on those gaps because they aligned to the most likely adversary path.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part IV - Use the map to drive action

We implemented three targeted improvements:

Prevention improvement: We tightened how service account secrets were stored and rotated, reduced the number of long-lived tokens, and restricted service accounts to least privilege.

Detection improvement: We built detections for anomalous internal API behavior: unusual query volume, unusual time-of-day patterns, and unusual endpoints accessed by service accounts.

Response improvement: We created a playbook for “suspected token abuse,” including rapid token revocation, session invalidation, and a checklist for scoping which systems were accessed.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part v – What we found next

Once those detections were in place, the pattern became clear. A third-party contractor account had been compromised, and the attacker used that foothold to discover internal documentation. They found a stale token stored in a shared workspace and began using it to enumerate endpoints and pull data.

Without adversary modeling, we would have spent time “hardening desktops” and “tightening firewall rules,” which weren’t the main problem. The map told us where the attack path actually went: identity, tokens, internal APIs, and weak visibility.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Takeaway

The biggest lesson was this:

Adversary modeling helps you stop defending in random directions. It lets you prioritize like an adult security program. When you map likely behavior to your environment, you see where you’re blind and where you’re overconfident. Then you improve one path at a time—until the attacker’s easiest options disappear.

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Congratulations!

You've successfully completed the example

home

previous