How to Use Graph-Driven Visualization for Threat Hunting | Cy5 CSPM Tool

Graph-driven threat hunting in CSPM uses a cloud asset/identity relationship graph to visualize attack paths, expose toxic IAM chains, map lateral movement, and estimate blast radius. Teams pivot by entity (principal, resource, network hop) and apply risk-based prioritization to fix the few misconfigurations that collapse many paths—across AWS, Azure, and GCP. Platforms like Cy5 (Ion Cloud Platform) operationalize this with graph-native analytics and least-privilege workflows.

Executive TL;DR.
Lists tell you what is wrong; graphs show how attackers get to data—and which single fix blocks many routes. By unifying IAM, network reachability, data sensitivity, and Kubernetes context into a cloud security graph, your team can simulate/detect cloud attack paths, cut blast radius, and drive risk-based remediation. Cy5 / Ion Cloud Platform automates this pipeline: ingest → graph → attack paths → explainable risk scores → IaC-safe remediation PRs.

Key Takeaways

• Graph-driven threat hunting converts posture noise into fixable attack paths.
• Graph visualization for security exposes lateral movement and toxic permissions.
• CSPM threat hunting = findings + IAM graph + risk scoring + validation.
• Attack path analysis (cloud) focuses work on the highest blast radius reductions.
• Works across AWS/Azure/GCP, including Kubernetes; maps to CIS/NIST/ISO.
• Cy5 (Ion Cloud Platform) adds graph-native analytics and push-button remediation.

What & Why: Graph visualization for security

A cloud security graph models principals, roles/policies, resources, network paths, and Kubernetes RBAC as nodes/edges so you can literally see the route from an external foothold to a crown-jewel dataset. This enables Zero Trust behaviors (least privilege, segmentation, continuous verification) and directly limits lateral movement.

Where Cy5 / Ion Cloud Platform fits:

• Builds a multi-cloud relationship graph (AWS/Azure/GCP + K8s) within hours.
• Resolves effective permissions and cross-account trusts (STS, role bindings).
• Highlights entity pages (roles, SAs, buckets, DBs) with connected paths and recommended path-breaking fixes.

How it works: From CSPM findings to an IAM/asset relationship graph

Posture → Graph → Detection → Response.

1. Ingest (agentless): enumerate identities, policies, resources, network rules, secrets/KMS, K8s RBAC.
   Cy5 automatically normalizes providers into a unified graph schema.
2. Build the graph: nodes (principal, policy, resource, network hop, finding); edges (assumeRole/STS, roleBinding, grants, routes, peering).
3. Resolve effective permissions: include conditions, inheritance, federations, cross-project/account links.
4. Run attack path analysis (cloud): compute exploitable routes to crown-jewels; surface toxic chains (e.g., AssumeRole → s3:PutBucketPolicy → public exposure).
5. Score risk: explainable risk score = exploitability × privilege depth × data sensitivity × exposure window; compute blast radius.
6. Validate & remediate: Cy5 proposes least-privilege diffs (Terraform/CloudFormation/Bicep PRs), runs pre-merge path re-checks, and enforces guardrails.

---

Attack path analysis (cloud): IAM / Network / Data / Kubernetes

Patterns you’ll see most:

• Identity-first (IAM): public workload → credential harvest → assume role → policy change → data access/exposure.
• Network-assisted: over-permissive SG/NSG → lateral move → management plane abuse via broad role.
• Data-centric: misconfigured share/bucket → key/secret exfil → persistence via CI/CD token.
• Kubernetes: Pod ServiceAccount → list/read Secrets → cloud role pivot (K8s→cloud).

Cy5 cue: Every path in Cy5 includes the single smallest change that breaks the most routes (e.g., tighten one trust policy, remove a high-risk action, or close a peering path).

Kubernetes Pivots – Patterns, Controls, and Quick Queries

Why it matters. Many real incidents jump from Pod to Cloud via tokens and secrets. K8s needs to be in the same graph as IAM.

Pattern	Graph shape	Path-breaking fix	Cy5 help
Pod SA can read Secrets	Pod → SA → Secret	Scope Secret to namespace; use CSI driver; limit SA	K8s Graph highlights SA→Secret edges; proposes RBAC diff
SA mapped to cloud Admin	SA → IRSA/Workload ID → Cloud Role(Admin)	Map to least-privilege role; add conditions	Shows which cloud actions the SA unlocks
Wildcard RBAC	SA → ClusterRoleBinding(:)	Replace with verb/resource scoped roles	RBAC Explorer simulates effective perms
Node compromise	DaemonSet → host mounts	Enforce PSP/Gatekeeper; block hostPath	Policy pack flags unsafe workloads

Quick Checks

List wildcard roles/bindings.

kubectl get clusterrole -o json | jq '.items[] | select(.rules[]?.resources[]? == "*") | .metadata.name'
kubectl get clusterrolebinding -o json | jq '.items[] | select(.subjects[]? | .kind=="ServiceAccount") | .metadata.name'

Detect Pods with SA tokens mounted.

kubectl get pods -A -o json | jq '.items[] | select(.spec.automountServiceAccountToken!=false) | .metadata|{ns:namespace,pod:name}'

“Kubernetes isn’t just ‘runtime’—it’s an identity amplifier. If a Pod’s SA can reach a cloud role with policy-editing actions, your blast radius expands to your entire account/project. Break the SA→CloudRole link or scope it to a narrow, auditable purpose.” – Cy5 (Ion Cloud Platform) | Cloud Security Team

Risk scoring & contextual cloud security for Prioritization – transparent math + example

Goal. Make ranking explainable so security, platform, and auditors agree on why item X is top-priority.

Scoring model

risk_score(path) = Wexp*Exploitability + Wpriv*PrivilegeDepth + Wdata*DataSensitivity + Wtime*ExposureWindow

0–100 scale per factor; default weights: Wexp=0.35, Wpriv=0.25, Wdata=0.25, Wtime=0.15

Factor Guides

• Exploitability (0–100): internet exposure (+30), known CVE on entry (+20), default creds/weak control (+20), public endpoint reachable without WAF (+30).
• PrivilegeDepth (0–100): number of hops (0–40), power of terminal action (e.g., policy write, KMS decrypt) (0–40), cross-account/project jump (0–20).
• DataSensitivity (0–100): none (0), internal (30), confidential (60), regulated/PII/keys/secrets (100).
• ExposureWindow (0–100): <1d (10), ≤7d (30), ≤30d (60), >30d (100).

Example: S3 Policy-Edit Path

• Exploitability: 85 (public SG + known CVE + no WAF)
• PrivilegeDepth: 70 (2 hops, policy write, cross-account)
• DataSensitivity: 100 (PII lake)
• ExposureWindow: 60 (23 days)

Compute:-

risk = 0.35*85 + 0.25*70 + 0.25*100 + 0.15*60

     = 29.75 + 17.5 + 25 + 9

     = 81.25

Interpretation. ≥80 = urgent: must break within current sprint.

Cy5 bonus. Shows the delta after proposed fix; e.g., removing s3:PutBucketPolicy drops PrivilegeDepth to 40 → new score ≈ 70 (and path count falls from 12 to 3).

Blast Radius Math

blast_radius(entity) = count(unique crown_jewel assets reachable via any path containing entity)

Before: AnalyticsRole reaches 17 sensitive assets (S3, Glue, Redshift).

After trust tightening: 5 assets.

Cy5 UI: “This PR reduces blast radius by ~71%.”

Cy5 application: The Attack Path Board ranks fixes by total blast radius reduced per change, then auto-creates a remediation PR and Jira ticket with evidence links.

Provider Mini-Runbooks — AWS, Azure, GCP + Terraform Diffs

Goal: transform CSPM findings into entity-centric investigations and risk-based remediation.

AWS: Break an S3 exfiltration path via cross-account AssumeRole

Scenario. Internet-exposed EC2 in Acct-A can assume AnalyticsRole in Acct-B and run s3:PutBucketPolicy on a PII bucket.

What the graph shows (Cy5 Attack Path Board).

• Entry: EC2PublicSG ➜ instance metadata ➜ AppProdRole
• Hop: sts:AssumeRole ➜ AnalyticsRole (Acct-B)
• Action: s3:PutBucketPolicy on bkt-pii-prod
• Crown-jewel: bkt-pii-prod (tag: data_sensitivity=PII)

Fix strategy (smallest change that breaks the most paths).

1. Constrain trust on AnalyticsRole so only the CI/CD role in Acct-A can assume it.
2. Remove policy-altering power (s3:PutBucketPolicy) from AnalyticsRole.

Before (trust policy excerpt).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::<AcctA>:root"},
    "Action": "sts:AssumeRole"
  }]
}

After (least-privilege trust).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::<AcctA>:role/ci-cd-runner"},
    "Action": "sts:AssumeRole",
    "Condition": {"StringEquals": {"aws:PrincipalTag/purpose": "release"}}
  }]
}

Terraform diff (Cy5-generated PR).

 resource "aws_iam_role_policy" "analytics_inline" {
   role = aws_iam_role.analytics_role.name
-  policy = data.aws_iam_policy_document.analytics_policy.json
+  policy = data.aws_iam_policy_document.analytics_policy_hardened.json
 }
 
 data "aws_iam_policy_document" "analytics_policy_hardened" {
   statement {
     actions = [
-      "s3:*"
+      "s3:GetObject",
+      "s3:ListBucket"
     ]
     resources = [
       aws_s3_bucket.pii.arn,
       "${aws_s3_bucket.pii.arn}/*"
     ]
   }
 }

Validation.

• Re-run path calc in Cy5 → AnalyticsRole no longer grants policy mutation; path score drops; blast radius across S3/Glue/Redshift goes down.

---

Azure: Collapse a Key Vault path by replacing over-broad Contributor

Scenario. Public VM ➜ lateral move ➜ principal with Contributor at subscription scope ➜ access to Key Vault policies.

Fix strategy.

1. Replace Contributor with a custom role scoped to the resource group.
2. Enforce PIM/JIT for any elevation, and add Private Endpoints for Key Vault.

Custom role (minimal KV mgmt, no policy edits).

{
  "Name": "KV-Operator-Min",
  "IsCustom": true,
  "Description": "Operate Key Vault without policy changes",
  "Actions": [
    "Microsoft.KeyVault/vaults/read",
    "Microsoft.KeyVault/vaults/secrets/*/readMetadata"
  ],
  "NotActions": [
    "Microsoft.KeyVault/vaults/accessPolicies/write",
    "Microsoft.Authorization/roleAssignments/write"
  ],
  "AssignableScopes": [
    "/subscriptions/<sub>/resourceGroups/rg-prod-sec"
  ]
}

CLI steps.

az role definition create --role-definition kv-operator-min.json
az role assignment delete --assignee <principalId> --role "Contributor" --scope /subscriptions/<sub>
az role assignment create --assignee <principalId> --role "KV-Operator-Min" --scope /subscriptions/<sub>/resourceGroups/rg-prod-sec

Cy5 assist. RBAC Explorer fingerprints the exact permissions keeping the path open, simulates the new role, and shows “path will break” before you commit.

---

GCP: Kill BigQuery exfil by replacing Basic Role + harden SA keys

Scenario. External identity ➜ Shared VPC host project ➜ roles/editor on data project ➜ BQ dataset export.

Fix strategy.

1. Replace roles/editor with scoped roles/bigquery.dataViewer on only the needed dataset.
2. Rotate or remove service account keys; enforce VPC-SC for exfil barriers.

gcloud quick wins.

# Remove Editor
gcloud projects remove-iam-policy-binding $PROJECT \
  --member="group:[email protected]" \
  --role="roles/editor"

# Grant least-privilege on dataset only
bq add-iam-policy-binding project:dataset \
  --member="group:[email protected]" \
  --role="roles/bigquery.dataViewer"

Cy5 assist. Policy Lens shows which bindings and SA keys keep the path viable, recommends replacements, and previews the attack exposure drop.

Kubernetes (all clouds): Audit ClusterRoleBinding/RoleBinding; limit Secret access; confirm Pods lack superfluous SA tokens. Cy5 K8s Graph visualizes Pod→SA→Secret→Cloud pivots and offers RBAC diffs.

Compliance & GEO Mapping

Use your graph as audit evidence: each control maps to a broken attack path, a least-privilege change, and an evidence trail (who/what/when).

1) NIST SP 800-53 Rev.5 — Practical Mapping

Control	What auditors look for	Graph-driven evidence (what to export)	Example “path-breaking” fix
AC-2 / AC-3 / AC-6 (Accounts/Access/Least Priv)	Provisioning, authorization, least privilege	Identity node → effective permissions before/after; role bindings & conditions; change ticket	Replace Contributor/Editor with scoped custom role; add JIT/PIM
AC-17 / AC-20 (Remote/External)	Controlled external connections	Path start = internet/external principal; SG/NSG rules; WAF; private endpoints	Move KV/S3/Blob behind private endpoints; block 0.0.0.0/0
AU-2 / AU-12 (Logging/Audit)	Coverage & integrity of logs	Which graph edges came from which logs/APIs; retention policy; immutable store	Route security logs to central lake; S3 Object Lock/immutability
CM-6 / CM-7 (Config/Least Functionality)	Hardened configs, no wildcards	Policy diff (before/after); wildcard detection report; IaC PR refs	Remove s3:*; scope to ARN; deny by default
RA-3 / RA-5 (Risk/Scanning)	Risk-based prioritization	Risk score formula + inputs; top paths ranked; MTTR per class	Prioritize externals → crown-jewel paths first
SC-7 (Boundary Protection)	Segmentation / egress controls	Network hops; peering/route tables; VPC-SC (GCP)	Kill peering; VPC-SC service perimeter
IR-4 (Response)	Verification of fix	Pre/post path recompute; artifact IDs; rollout time	Prove path score drop after PR merge

Cy5 assist: one-click Evidence Pack (NIST) bundles the above with timestamps, reviewers, and PR IDs.

---

2) ISO/IEC 27001:2022 — Annex A

ISO 27001:2022 Annex A	Intent	Graph-based proof	Typical fix
A.5.15 Access control	Limit access to need-to-know	Effective-permission snapshot & diff	Replace basic roles; restrict trust relationships
A.5.18 Access rights	Joiner/mover/leaver discipline	Identity lifecycle graph + last use	Revoke unused roles; expire SA keys
A.8.16 Monitoring activities	Detect misuse, anomalies	Attack path detections, lateral movement edges	Alert on “externally-initiated path to data”
A.8.28 Secure coding (for IaC)	Controlled change to infra	PR diff, approvers, checks passed	Policy tighten via Terraform/Bicep with checks
A.8.9 Configuration management	Baselines & drift	Config drift timeline → path creation date	Guardrail policy to block drift re-introductions

Cy5 assist: Policy Lens shows which IaC change introduced a path; Drift Timeline timestamps exposure.

GDPR (EU/DACH) — Security of Processing (Art. 32) + Data Minimization (Art. 5(1)(c)) + Privacy by Design (Art. 25)

• What to prove: security appropriate to risk; data access minimized; changes tested before exposure.
• Graph evidence: crown-jewel labels (PII), who/what could reach them pre-fix, and the single change that removed reachability; show data-residency and role separation (no “data-admin = network-admin”).
• Operational move: keep attack-path simulations in-region where possible; redact PII in evidence exports.

Cy5 assist: Data Residency Mode + Redacted Evidence Pack (PII fields masked).

CERT-In (India) — Incident Reporting & Log Retention

• Practicals: keep cloud security logs for at least 180 days in India and be able to report qualifying incidents quickly (directive as of 2022).
• Graph evidence: show the path that led to the incident, affected identities/resources, and log pointers covering the full window.
• Ops tip: pre-stage an Incident Bundle template: path graph, timeline, log references, and containment PRs.

Cy5 assist: one-click Incident Bundle (CERT-In) with retention attestations.

MAS TRM (Singapore) — Access Governance, Monitoring, Incident Readiness

• Show: role design (least privilege), monitoring of sensitive access, and tested incident flows.
• Graph proof: access design per app/data domain; monitoring rules tied to path patterns (e.g., “external → key vault”).
• Ops tip: align SOAR playbooks to common path shapes (IAM-first, K8s-pivot, network-assist).

Cy5 assist: Path Pattern Library with mapped SOAR runbooks.

---

UAE NESA / TDRA IA — Segmentation, Logging, Privileged Access

• Show: segmented networks, logged admin actions, and constrained privileged roles.
• Graph proof: VNet/VPC segmentation in the path; admin actions removed; private links enforced.

Cy5 assist: Segmentation Map overlay inside the graph + audit export.

Tooling: Agentless vs Agent-Based vs Graph-Native

Approach	Strengths	Gaps for threat hunting	Best use
Agentless CSPM	Fast coverage; config drift; framework checks (CIS/NIST/ISO)	Finds issues but misses chained paths	Baseline posture & compliance. (AWS Documentation)
Agent‑based	Runtime & EDR telemetry	Limited cloud IAM context	Workload telemetry & runtime threats.
Graph‑native (our focus)	Entity‑centric, shows attack paths, blast radius, risk‑based prioritization	Needs high‑quality graph + IAM resolution	Threat hunting & fix‑what‑matters. (AWS Documentation)

Metrics & Analytics Playbook

Make improvement measurable and explainable. Tie every KPI to a path, a fix, and a business outcome.

Tier 1 — Executive KPIs (Board-Facing)

KPI	Formula	Target (first 90 days)	Why it matters
Critical Attack Paths Open	count(paths where risk ≥ 80)	↓ 60–80%	Directly tracks breach routes
Blast Radius (Crown-Jewel)	sum(unique assets reachable) per CJ	↓ 50–70%	“What can burn if X is hit?”
MTTR-Path	mean(time fix-merged − time path-created)	≤ 10 business days	Fast risk burn-down
Least-Privilege Delta	(pre − post) privileged actions / pre	≥ 40% reduction	Quantifies entitlement diet
Compliance Drift Days	Σ days out-of-policy (top 10 controls)	≤ 7 days each	Audit readiness

Cy5 dashboards: Executive Overview tiles for each KPI with deltas and spark-lines.

---

Tier 2 — Operational KPIs (Team-Level)

KPI	Definition	Collection
Path Density	paths per 100 cloud assets	Graph index nightly
Fix Leverage	paths closed per merged PR	Join graph events ↔ SCM
Regression Rate	% paths that reappear within 30 days	Compare daily snapshots
RBAC Wildcard Count	K8s ClusterRoles with *	K8s audit job
Basic Roles Remaining (GCP)	# members with roles/editor/owner	IAM export job
Public Endpoints to CJ	internet-exposed nodes within 2 hops of CJ	Graph query

Cy5 automations: scheduled Graph Jobs push these to a warehouse (BigQuery/Snowflake) and the built-in Ops Scorecard.

---

Targets & SLA ladders (make it “real”)

• SLA-Path-Critical: P0 (risk ≥ 90): fix ≤ 5 business days; P1 (80–89): ≤ 10 days; P2 (70–79): backlog.
• SLO-Blast Radius: each crown-jewel ≤ 5 reachable assets by end of Q2.
• SLO-Least Privilege: no wildcard (*) permissions in production by end of next sprint.

Cy5: enforce via Guardrails (policy checks) and PR Required Checks (path-recompute:pass).

---

Example Queries (Warehouse-Ready)

Paths closed per PR (last 30 days).

SELECT pr_id, COUNT(DISTINCT path_id) AS paths_closed
FROM graph.events
WHERE event_type='path_closed' AND event_ts >= CURRENT_DATE - 30
GROUP BY pr_id
ORDER BY paths_closed DESC;

Blast radius by crown-jewel (trend).

SELECT cj_id, DATE(snapshot_ts) d, COUNT(DISTINCT reachable_asset_id) blast_radius
FROM graph.snapshots_reachability
GROUP BY cj_id, d
ORDER BY cj_id, d;

GCP basic roles still present.

SELECT member, role
FROM iam.gcp_bindings
WHERE role IN ('roles/owner','roles/editor','roles/viewer');

K8s wildcard RBAC (ClusterRoles).

kubectl get clusterrole -o json | jq '.items[] | select(.rules[]? | .resources[]? == "*") | .metadata.name'

Scorecards you can ship tomorrow

Security Leadership (monthly)

• Critical paths open/closed, MTTR-Path trend, top 3 fix-leverage PRs, worst 3 regressions, compliance drift timeline.

Team/Tribe (bi-weekly)

• Paths per domain/service, PRs merged, “why still open” blockers (owner, dependency, blast-radius impact), next sprint targets.

Audit/Compliance (quarterly)

• Evidence summary by framework (NIST/ISO/CIS), control coverage vs drift days, incidents & lessons learned, top preventive guardrails added.

Cy5: prebuilt Executive, Ops, and Audit scorecards + CSV/PDF exports.

Decision tree: Where to start

• Internet-exposed assets near crown-jewels? → Run attack path analysis first.
• Broad roles (Owner/Admin/Contributor)? → Refactor to least-privilege with JIT.
• Too many highs, small team? → Use Cy5’s risk ranking to fix max impact first.
• Regulated region? → Export Evidence Pack for auditors.

---

6-Step Evaluation Checklist (CSPM/CNAPP Graph Capabilities)

1. Graph coverage: identities, policies, resources, network, K8s
2. Effective permissions across accounts/subscriptions/projects
3. Attack path engine: multi-hop, exploitability focus, data-aware
4. Explainable scoring + blast radius math
5. Safe remediation: Terraform/CFN/Bicep PRs; pre-merge re-checks
6. Compliance evidence: CIS/NIST/ISO mappings; drift timelines

(Cy5 checks all six.)

---

30/60/90-day adoption plan

• 0–30 days (Baseline): connect clouds; label crown-jewels; run first attack path sweep; close top 10 path-breaking fixes; enable MFA/JIT. (Cy5 QuickStart gets you a graph Day 1.)
  
• 31–60 (Harden): refactor broad roles; enforce private endpoints/segmentation; onboard K8s; define risk thresholds and SLAs; enable IaC PR flow.
  
• 61–90 (Operationalize): weekly path reviews; report on blast radius; export compliance evidence; integrate with SOAR for auto-validation.
  

---

Mini case vignette

A fintech across 3 clouds had 1,800 “highs” and no prioritization. A graph-driven pass in Cy5 surfaced 12 critical attack paths into a PII lake. Three changes (tightening one cross-account trust, closing a peering route, moving a key vault private) cut blast radius by 84% and closed 9/12 paths in two sprints.

---

Objections FAQ