Blog

Web Application Firewall (WAF)

WAFs inspect HTTP/HTTPS traffic to web applications and block requests matching attack patterns — SQL injection, XSS, CSRF, path traversal, and other OWASP Top 10 vulnerabilities. Operates at Layer 7, inline between the internet and the application. Can be deployed in detection mode (log only) or prevention mode (block matching requests).

Operational consideration

WAF rules require tuning — default rule sets generate significant false positives for legitimate application traffic. Starting in detection mode, reviewing alerts, and adjusting rules before switching to prevention mode prevents blocking legitimate users. WAF bypasses (encoding variations, protocol edge cases) make WAFs a necessary but not sufficient control — they must be combined with secure coding practices and DAST testing.

Real-world example

The 2019 Capital One breach was enabled by a misconfigured WAF — but that same breach illustrates WAF value: the SSRF attack that succeeded would have been blocked by a correctly configured WAF rule. Cloud-native WAFs (AWS WAF, Azure WAF, Cloudflare WAF) provide managed rule sets that are updated by the vendor as new attack patterns emerge — but custom application-specific rules still require manual tuning and regular review.

Sandboxing

Sandboxing detonates suspicious files, URLs, or code in an isolated, instrumented environment and observes their behavior. Unlike signature-based detection (which compares files to a database of known malicious patterns), sandboxing detects novel malware by observing what it actually does — makes network connections, drops files, modifies registry keys, spawns processes. Effective against zero-day and polymorphic malware that evades signatures.

Sandbox evasion

Sophisticated malware actively detects sandbox environments (checking for mouse movement, human user activity, VM artifacts, specific hardware configurations) and behaves benignly when sandboxed. Anti-evasion techniques: extended detonation periods (minutes rather than seconds), human interaction simulation, bare-metal sandboxes, and behavioral analysis that detects evasion attempts as suspicious in themselves.

Real-world example

FireEye’s sandbox (now Trellix) detected the SUNBURST malware in the SolarWinds supply chain attack months before it became publicly known — but the detection was initially attributed to legitimate SolarWinds behavior. The malware was designed to lie dormant for up to two weeks and check for sandbox indicators before activating. This dormancy period was specifically chosen to exceed most sandboxing detonation windows. The incident drove the industry to extend sandbox detonation periods and add time-based dormancy detection as an analysis dimension.

Honeypots and honeynets

Honeypots are decoy systems designed to attract and detect attacker activity. A honeypot looks like a legitimate target (a server with an interesting hostname like “payroll-backup” or “admin-console”) but has no legitimate user traffic. Any access to a honeypot is by definition suspicious — there is no legitimate reason for a user or system to contact it. A honeynet is a network of honeypots providing a richer deception environment.

High-fidelity detections

Honeypot alerts have extremely low false positive rates — a legitimate user or system should never contact a honeypot. This makes honeypot alerts high-priority indicators of either reconnaissance activity (an attacker scanning the network) or active compromise (malware performing lateral movement). Honey credentials (fake credentials planted in configuration files or password managers) detect credential theft — when the fake credentials are used, the theft is confirmed.

Real-world example

The Conti ransomware gang’s internal playbooks — leaked in 2022 — specifically instructed operators to avoid connecting to honeypot indicators and to check hostnames and service banners for common honeypot signatures (“honey”, “trap”, “decoy”) before proceeding. The fact that sophisticated ransomware operators train their affiliates to evade honeypots confirms that honeypots are effective enough to be operationally consequential to attackers. Financial sector honeypots have detected active banking trojan infections before the malware reached production systems by monitoring for connections to decoy banking API endpoints.

EDR and anti-malware

Traditional antivirus matches files against signature databases — effective against known malware, ineffective against novel threats, fileless attacks, and living-off-the-land techniques. EDR (Endpoint Detection and Response) monitors endpoint behavior continuously — process creation, file system changes, network connections, registry modifications, memory injection — and detects malicious behavior patterns regardless of whether a specific signature exists.

NGAV vs EDR

NGAV (Next-Gen AV): Machine learning-based prevention, behavioral analysis, reputation scoring. Replaces signature-based AV for prevention. EDR: Continuous monitoring, threat hunting capability, automated response (isolate host, kill process), forensic telemetry for investigation. Modern platforms (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) combine NGAV prevention with full EDR telemetry and response in a single agent.

Real-world example

In the 2021 Kaseya VSA ransomware attack, endpoints with CrowdStrike Falcon’s behavioral detection caught the REvil ransomware execution attempt and blocked it within seconds — before any encryption occurred. Endpoints without EDR (relying on signature-based AV) were fully encrypted within minutes of the malicious update being pushed. The post-incident analysis showed that EDR behavioral rules for ransomware-typical behavior (rapid file renaming with encryption extensions, shadow copy deletion) triggered immediately on the first affected endpoint, demonstrating that effective EDR makes ransomware a recoverable incident rather than a catastrophic one.

AI and machine learning security tools

AI/ML-based security tools apply machine learning models to detect anomalies, classify threats, prioritize alerts, and automate response. Applications include: network traffic anomaly detection (detects C2 communication patterns without signatures), email security (detects phishing based on content and behavioral signals), UEBA (behavioral baseline deviations), vulnerability prioritization (predicts exploitability based on contextual signals), and SOAR (automated playbook execution).

Strengths and limitations

AI/ML tools excel at processing high volumes of data and identifying subtle patterns humans would miss. Limitations: model drift (performance degrades as environments change and models are not retrained), adversarial inputs (attackers can deliberately craft inputs to evade ML-based detection), explainability (black-box models may not be able to explain why an alert was generated — problematic for analysts who need to investigate), and false positives from legitimate anomalies during business changes (acquisitions, new system deployments).

Real-world example

Darktrace’s AI-based network detection identified an unusual pattern in a European bank’s network in 2017: a device on the internal network was beaconing to an external IP address at 3am, transferring small amounts of data at precise intervals — a pattern consistent with C2 communication but too subtle to trigger threshold-based alerts. Human analysts would not have found this in the noise of millions of daily network events. The ML model had identified the periodicity as anomalous against the device’s behavioral baseline established over weeks of observation. Investigation confirmed a banking trojan. The bank had been compromised for approximately 6 weeks before the ML detection — but the compromise was caught before credentials were used for fraud.

Federated Identity Management (FIM)

FIM extends identity trust across organizational boundaries. Rather than maintaining separate accounts in each partner organization’s systems, a user’s identity established in their home organization (the Identity Provider, IdP) is trusted by partner organizations (Service Providers, SPs). SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC) are the protocols that implement federation. The trust is established through cryptographic assertions — signed tokens the IdP issues that the SP verifies.

Key protocols

SAML 2.0 — XML-based federation protocol; widely used for enterprise SSO to web applications. OAuth 2.0 — authorization framework (not an authentication protocol); grants delegated access to resources. OIDC — authentication layer on top of OAuth 2.0; provides identity tokens (JWT format).

Real-world example

When a user clicks “Sign in with Google” on a third-party application, OIDC federation is in action. Google is the IdP; the third-party application is the SP. The user authenticates with Google (not the application), and Google issues a signed ID token the application verifies. The application never sees the user’s Google password — it only receives a cryptographically verified claim that Google authenticated this user with this email address. If the user’s Google account is compromised, so is every OIDC-federated application — the trust chain is only as strong as the IdP.

Credential management systems

Credential management systems (password managers, enterprise vaults, privileged access management platforms) store, generate, and manage credentials securely — removing the human tendency to reuse weak passwords and write down complex ones. Enterprise PAM systems (CyberArk, Thycotic, BeyondTrust) additionally rotate credentials automatically, check out credentials to authorized sessions, and record all use.

Password vault essentials

Generates random, unique credentials for each system. Provides credentials at session checkout, not stored in configuration files or scripts. Rotates credentials on schedule or after each use (for privileged accounts). Audits every credential access. The vault’s master secret is the highest-risk credential in the environment — it must be protected with the strongest available controls (HSM-backed, requires multiple custodians for root access).

Real-world example

In the 2020 SolarWinds breach, investigators found hardcoded credentials in SolarWinds’ update server: the password “solarwinds123” was used to protect the update build server. This password was reportedly posted publicly on GitHub for months before the breach. A credential management system that generated and rotated credentials for build infrastructure would have prevented this specific vulnerability. Post-breach, CISA mandated that federal agencies use PAM tools for privileged credential management.

Just-In-Time (JIT) access provisioning

JIT access grants privileged access only when needed and for the minimum duration required — then automatically revokes it. Rather than administrators having persistent standing privilege (always-on admin rights that exist whether being used or not), JIT provides ephemeral privilege: an administrator requests elevated access for a specific task, it is granted (with approval if required), used, and then expires automatically after a defined window.

Security benefit

Persistent standing privilege is an attacker’s dream: any compromise of a privileged account grants immediate, unlimited access. JIT eliminates the standing privilege window — an attacker who compromises an account without an active JIT session gains only standard user access. They must additionally trigger a JIT request (which generates an alert) to gain elevated access.

Real-world example

Microsoft’s internal “Just Enough Administration” (JEA) and “Just-In-Time Administration” (JITA) programs implement JIT for Azure infrastructure management. Engineers have zero standing access to production. For each maintenance task, they request access to specific resources for a maximum of 8 hours via an approval workflow. All sessions are recorded. Microsoft’s internal security team reduced its privileged access standing footprint by over 90% through JIT implementation — dramatically reducing the value of any single compromised account.

Session management

Session management governs how authenticated sessions are created, maintained, extended, and terminated. After authentication, a session token represents the user’s authenticated state — its security properties determine whether the authentication investment is preserved or undermined. A strong authentication process followed by a weak session token is equivalent to a strong lock on a door with the key taped to the frame.

Session security requirements

Tokens must be cryptographically random (not predictable or enumerable); bound to context (IP, user-agent) to prevent theft and replay; transmitted only over TLS with secure and httponly flags; have defined expiry times appropriate to the sensitivity of the application; and be invalidated on logout (server-side invalidation — not just cookie deletion on the client).

Real-world example

The 2017 Equifax breach involved attackers maintaining persistent access for 78 days using session tokens obtained from the compromised web application. The application’s session tokens had no time limit and were not rotated after privilege changes — once obtained, a token was valid indefinitely. Continuous session validation (re-verifying the token’s validity against server-side session state on each request) and short absolute timeout periods (regardless of activity) would have invalidated the attacker’s sessions periodically, requiring re-exploitation to maintain access.

Registration, proofing, and establishment of identity

Identity proofing is the process of verifying that a claimed identity corresponds to a real, specific individual before issuing credentials. The strength of all subsequent authentication depends on the quality of initial identity proofing — if anyone can register as anyone, strong authentication merely proves “this is the person who enrolled under this identity,” not “this is the person they claim to be.”

NIST SP 800-63A identity assurance levels

IAL1 — No requirement to link claimed identity to a real person. Self-assertion acceptable. Suitable for low-risk applications. IAL2 — Evidence of real-world existence required (government ID). Remote or in-person verification. Suitable for most enterprise and government applications. IAL3 — In-person proofing with physical inspection of identity documents by a trained agent. Required for highest-assurance applications (e.g., issuance of federal credentials).

Real-world example

COVID-19 unemployment fraud in the US (2020–2021) resulted in an estimated $163 billion in fraudulent claims — the largest government benefits fraud in US history. State unemployment systems had IAL1 or weak IAL2 identity proofing: identity was verified by checking a Social Security Number against existing records, without verifying the claimant was actually that person. Fraudsters used stolen identities (purchased from breach data) to file claims at scale. ID.me and similar identity proofing services implemented IAL2 verification (government ID + facial matching) as a remediation — a control that should have been in place before billions were lost.

Cloud identity federation

Cloud-native IdPs (Microsoft Entra ID / Azure AD, Okta, Ping Identity cloud, Google Workspace) host identity infrastructure in the cloud. Organizations federate their applications — both cloud and on-premises — to the cloud IdP. Authentication flows through the cloud IdP regardless of whether the user or the application are on-premises.

Advantages

Elastic scale, automatic updates, no hardware to maintain, high availability SLAs (99.99% for major providers), built-in MFA and Conditional Access capabilities, native integration with cloud applications. Faster to deploy new application integrations. Geographic distribution provides resilience.

Disadvantages and risks

The cloud IdP becomes a critical dependency — its availability and security directly affect all federated applications. Third-party security posture is outside organizational control. Data residency concerns for identity attributes stored in cloud IdP. Vendor lock-in risk if migration away from the cloud IdP is required.

Real-world example

The 2023 Microsoft Entra ID (Azure AD) compromise by the Storm-0558 threat actor — later attributed to Chinese espionage — involved the theft of a Microsoft signing key that could forge authentication tokens for any Entra ID tenant. Multiple US government agencies’ Microsoft 365 email was accessed. The attack was discovered because one agency had Microsoft’s audit logging at a tier that captured the anomalous access — agencies on lower-tier licenses did not have the logging visibility to detect the compromise. Cloud IdP security is only as good as the provider’s controls — and the customer’s ability to detect anomalies requires appropriate logging tier.

Hybrid identity federation

Organizations maintain both on-premises Active Directory and a cloud IdP, with identity synchronization between them. Microsoft Entra Connect (formerly Azure AD Connect) synchronizes on-premises AD identities to Entra ID — users authenticate with on-premises credentials to access both on-premises and cloud resources. Password hash synchronization, pass-through authentication, and ADFS are the three hybrid connectivity options.

Architecture considerations

The synchronization mechanism (Entra Connect) becomes critical infrastructure — it runs with highly privileged access to both on-premises AD and cloud Entra ID. Compromise of the Entra Connect server provides a pivot point between on-premises and cloud environments. The security of hybrid identity is bounded by the security of the on-premises AD — a golden ticket attack on on-premises AD in a hybrid environment can be used to forge tokens that are accepted by cloud resources.

Real-world example

In multiple incident response engagements following on-premises Active Directory compromises, the responders found that attackers had pivoted from on-premises AD to Microsoft 365 by exploiting the hybrid identity synchronization. After compromising the on-premises AD, attackers added credentials to cloud-only accounts (which are not synchronized from on-premises) using the elevated permissions from the on-premises compromise. Remediating a hybrid identity breach requires simultaneous remediation of both on-premises AD and cloud Entra ID — an operationally complex process that many organizations underestimate.

LDAP and Active Directory

LDAP (Lightweight Directory Access Protocol) is a protocol for querying and modifying directory services — the phone book of an organization’s identities, groups, and resources. Microsoft Active Directory (AD) is the dominant enterprise implementation of LDAP, extended with Kerberos authentication, Group Policy, and domain trust mechanisms. Almost every enterprise authentication system ultimately queries AD to resolve identities and group memberships.

Security considerations

LDAP traffic is unencrypted by default — LDAPS (LDAP over TLS, port 636) or LDAP with STARTTLS must be enforced to prevent credential interception during LDAP bind operations. AD’s attack surface is vast: domain controllers hold the master copy of all credentials; the KRBTGT account’s hash enables Golden Ticket forgery; replication traffic between DCs contains password hashes.

Real-world example

In the 2020 SUNBURST/SolarWinds breach, threat actors performed AD reconnaissance using LDAP queries to map the victim organization’s structure — identifying high-value targets (domain admins, service accounts) and trust relationships to adjacent domains. Standard LDAP queries authenticated as a normal user (already compromised) returned enough information to plan privilege escalation paths. AD monitoring tools (BloodHound / PlumHound equivalent in defensive mode) that visualize attack paths from current access to domain admin are essential for identifying exposure before attackers do.

RADIUS and TACACS+

RADIUS (Remote Authentication Dial-In User Service) and TACACS+ (Terminal Access Controller Access Control System Plus) are protocols for centralized authentication, authorization, and accounting (AAA) — primarily for network device access and VPN authentication. RADIUS combines authentication and authorization in a single response; TACACS+ separates them (more flexible). Both provide centralized logging of authentication events.

RADIUS vs TACACS+

RADIUS — UDP-based, encrypts only the password, combines AuthN+AuthZ. Widely supported — essentially every VPN, Wi-Fi controller, and network device supports RADIUS. TACACS+ — TCP-based, encrypts the entire payload, separates AuthN/AuthZ/Accounting. Preferred for network device (router, switch) administration because the separation of AuthN and AuthZ allows fine-grained command authorization. Cisco proprietary historically but now open.

Real-world example

In the 2023 Cisco IOS XE vulnerability exploitation (CVE-2023-20198), attackers exploited a zero-day to create local administrator accounts on Cisco devices. Organizations using TACACS+ for centralized network device authentication with command authorization could detect anomalous local account creation and unauthorized configuration changes — TACACS+ logs every command executed on every device. Organizations relying on local authentication with no TACACS+ centralization had no visibility into account creation until a scan revealed the implants weeks later.

OAuth 2.0 and OpenID Connect (OIDC)

OAuth 2.0 is an authorization framework — it enables a user to grant a third-party application access to their resources on another service without sharing their credentials. The user authorizes the application; the authorization server issues an access token the application uses to access the resource server on the user’s behalf. OAuth 2.0 alone does not provide identity — it provides delegated authorization.

OIDC extends OAuth 2.0

OpenID Connect adds an identity layer to OAuth 2.0 — in addition to the access token, the authorization server issues an ID token (JWT format) that contains claims about the authenticated user (sub, email, name, etc.). OIDC provides authentication; OAuth 2.0 provides authorization. Modern SSO implementations use OIDC for authentication and OAuth 2.0 for API authorization.

Real-world example

The 2023 GitHub OAuth token theft: Heroku and Travis CI had OAuth tokens that granted access to GitHub repositories on behalf of their users. When attackers stole these tokens, they could access private GitHub repositories for thousands of organizations — without knowing any user’s GitHub credentials. OAuth tokens with excessive scope (repository read/write on ALL repositories, not scoped to specific ones) and no expiry amplified the damage. OAuth tokens must be scoped to minimum required permissions and have defined expiry — treating them with the same care as passwords.

SAML 2.0

Security Assertion Markup Language 2.0 is an XML-based federation protocol for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). The IdP authenticates the user and issues a signed XML assertion; the SP validates the signature and grants access based on the assertion’s claims. SAML 2.0 is the dominant enterprise SSO protocol for browser-based applications.

Assertion types

Authentication assertion — confirms the user authenticated at the IdP at a specific time using a specific method. Attribute assertion — carries user attributes (name, email, department, role) from IdP to SP. Authorization assertion — carries access rights (rarely used in practice; most SPs determine authorization locally based on attributes).

Real-world example

The “Golden SAML” attack technique (discovered 2017, weaponized in SolarWinds 2020): if an attacker obtains the ADFS token-signing certificate’s private key, they can forge SAML assertions for any user to any SAML SP — gaining access to Microsoft 365, AWS, Salesforce, and any other SAML-federated application as any user, including global administrators, without triggering any authentication events. The IdP’s signing key is the crown jewel of a federated identity deployment. Token-signing certificates must be HSM-protected, rotated regularly, and any changes to them must generate high-priority alerts.

PKI and certificate-based authentication

Certificate-based authentication uses X.509 digital certificates — binding a public key to a verified identity — for authentication. The subject presents their certificate and proves possession of the corresponding private key via a cryptographic challenge. The relying party validates the certificate chain back to a trusted root CA. Used for smart card / PIV card authentication, mTLS (mutual TLS) for service-to-service authentication, and client certificate authentication in high-assurance environments.

Advantages over passwords

Not phishable — the private key never leaves the device (HSM or smart card). Provides non-repudiation — the authentication event is cryptographically tied to the certificate holder’s identity. Revocation via CRL/OCSP enables immediate invalidation if a certificate is compromised. Government PIV (Personal Identity Verification) and CAC (Common Access Card) cards implement certificate-based auth for physical and logical access.

Real-world example

US federal agencies implementing zero trust under OMB M-22-09 are required to use phishing-resistant MFA — which in practice means PIV/CAC certificate-based authentication or FIDO2 hardware tokens. Certificate-based authentication on smart cards has been the US federal standard since HSPD-12 (2004). The DoD’s CAC (Common Access Card) program — 4 million cards issued — provides certificate-based authentication for logical access to DoD systems, physical access to facilities, and digitally signed email. Physical smart card presence is required for authentication — a remote attacker with the user’s credentials cannot authenticate without the physical card.

Video conferencing

The COVID-19 pandemic accelerated adoption of video conferencing platforms — and simultaneously expanded the attack surface. Video conferences often include highly sensitive discussions; unauthorized access (meeting bombing) exposes confidential information; and the use of consumer-grade platforms for sensitive government or commercial discussions creates compliance and security risks.

Key vulnerabilities

Meeting bombing (unauthorized participants joining unsecured meetings), screen sharing of sensitive content to unauthorized parties, recording without consent, malicious software installed via meeting client updates, credential theft targeting video conference accounts, and data residency issues for recordings stored in cloud platforms.

Mitigations

End-to-end encryption for all meetings (verify the platform supports E2EE — many advertise “encryption” that only covers transport, not E2E); waiting rooms and admission controls; unique meeting IDs per meeting; password-protected meetings; disable unnecessary features (file transfer, annotation); enterprise platforms with contractual data processing agreements; separate platforms for classified discussions.

Real-world example

In April 2020, Zoombombing became widespread — attackers found publicly shared Zoom meeting links (often posted on social media) and joined meetings to display offensive content. In some cases, attackers joined sensitive corporate strategy meetings that had been shared via company Slack channels indexed by search engines. The lesson: meeting links are credentials and must be treated with the same confidentiality as passwords. Waiting rooms and per-meeting passwords prevent uninvited access even if the link is exposed.

Collaboration platforms (Teams, Slack, etc.)

Modern collaboration platforms consolidate messaging, file sharing, video, and workflow integration into a single platform — creating a highly sensitive data repository that contains strategy discussions, customer data, code snippets, credentials (frequently shared in chat “temporarily”), and sensitive files. Compromise of a collaboration platform account often provides more useful intelligence than email access.

Key vulnerabilities

Phishing via platform-native messaging (more trusted than email), malicious file sharing through platform channels, third-party app integrations with excessive permissions, sensitive data (including credentials) shared informally in channels, insider threat via message export, and former employee access not revoked promptly.

Mitigations

MFA enforced for all accounts; DLP integration to detect sensitive data in messages; third-party app permission reviews; channel and workspace data retention policies; immediate account deactivation on employee departure; data classification applied to files shared in channels; guest access controls for external collaborators; audit logging of all platform activity.

Real-world example

The 2022 Uber breach began when an attacker purchased corporate network credentials on the dark web, then used social engineering (pretending to be Uber IT security) to convince an employee to approve an MFA push notification. Once authenticated, the attacker found network admin credentials in a PowerShell script stored in an internal network share — but also discovered that an internal Slack channel contained additional privileged credentials shared informally between engineers. Sensitive credentials stored in collaboration platforms are among the most common findings in enterprise penetration tests.

Industrial Control Systems (ICS) / SCADA

Key vulnerabilities: legacy protocols with no authentication (Modbus, DNP3), air-gap assumptions eroded by IT/OT convergence, limited patch cycles (systems cannot be taken offline), lack of encryption, default credentials, and remote access paths added for operational convenience without security review.

Mitigations

IT/OT network segmentation with unidirectional data diodes where possible; compensating controls for unpatchable systems (application allowlisting, network access controls); anomaly detection (Claroty, Dragos); strict change management; regular assessments against IEC 62443; incident response planning specific to OT environments.

Real-world example

The 2021 Oldsmar water treatment attack: an attacker remotely accessed the plant’s HMI via TeamViewer (a remote access tool that had been left installed and active) and increased sodium hydroxide levels to dangerous concentrations. An operator noticed the cursor moving and manually reversed the change within minutes. No authentication, no access logging, no alerting on chemical setpoint changes outside normal ranges. The attack required no exploitation — just valid credentials to a publicly accessible remote desktop.

Internet of Things (IoT)

Key vulnerabilities: default credentials never changed, no update mechanism or infrequent patches, minimal compute for security controls, unencrypted communications, wide attack surface (millions of devices), physical accessibility, and weak or absent authentication between devices.

Mitigations

Network segmentation (IoT devices on isolated VLANs with no lateral movement path to corporate systems); mandatory credential change at enrollment; device identity management; encrypted communications (TLS/DTLS); regular firmware update processes; asset inventory of all connected devices; monitoring for anomalous behavior (unexpected outbound connections).

Real-world example

Mirai botnet (2016): 600,000+ IoT devices infected via default credentials, used to launch a 1.2Tbps DDoS attack against Dyn DNS — taking down Twitter, Netflix, Reddit, GitHub. No exploitation required. Devices were discovered via Shodan, credentials tried from a list of 61 factory defaults. Default credential requirements in regulations (UK PSTI Act 2023) directly resulted from this incident.

Containerization

Key vulnerabilities: container escape to host OS (containers share the host kernel — a kernel vulnerability affects all containers), insecure base images with known vulnerabilities, overprivileged containers (running as root), insecure secrets management (hardcoded credentials in images or environment variables), and insecure container registries.

Mitigations

Run containers as non-root users; use minimal base images (distroless/scratch); scan images for vulnerabilities at build and registry time (Trivy, Snyk); use secrets management systems (Vault, Kubernetes Secrets); enable security profiles (AppArmor, seccomp); network policies to control inter-container traffic; runtime security monitoring (Falco).

Real-world example

In 2019, a container escape vulnerability in runc (CVE-2019-5736) — the container runtime used by Docker and Kubernetes — allowed a malicious container to overwrite the host runc binary and gain root access to the host system. Any organization running Docker or Kubernetes was vulnerable. The fix required updating runc — but organizations running unpinned images or without container vulnerability scanning had no visibility into whether they were exposed.

Microservices and APIs

Key vulnerabilities: broken object-level authorization (BOLA — API returns objects the caller shouldn’t see), broken authentication, excessive data exposure (APIs returning more fields than needed), lack of rate limiting enabling enumeration and brute force, injection attacks through API parameters, insecure direct object references, and insecure inter-service communication.

Mitigations

OAuth 2.0 / OpenID Connect for API authentication and authorization; enforce object-level authorization checks server-side on every request; API gateway for rate limiting, authentication enforcement, and input validation; mTLS (mutual TLS) for service-to-service communication; API inventory and discovery; OWASP API Security Top 10 as a baseline testing checklist.

Real-world example

The Facebook (2019) API vulnerability allowed attackers to access any user’s private posts by passing another user’s ID to a specific API endpoint — a classic BOLA vulnerability. The API checked that the caller was authenticated but did not check whether the caller was authorized to access the requested user’s data. 29 million user accounts were affected. Authorization checks must be applied at the object level on every API call — authentication alone is insufficient.

Database systems

Key vulnerabilities: SQL injection (unparameterized queries), excessive database user privileges, unencrypted sensitive columns, audit logging disabled, direct internet exposure of database ports, default or weak database credentials, and unsecured database backups.

Mitigations

Parameterized queries / prepared statements (eliminates SQL injection); least-privilege database accounts (application accounts have SELECT/INSERT only on required tables — no DDL); column-level encryption for sensitive fields; Database Activity Monitoring (DAM); no direct internet access to database ports; encrypted backups stored separately from production; regular database vulnerability assessments.

Real-world example

The 2008 Heartland Payment Systems breach — affecting 130 million payment card records — was initiated via SQL injection against a web application. The application’s database account had excessive privileges allowing the attacker to install malware on the database server that intercepted card data in transit. Parameterized queries would have prevented the initial SQL injection; least-privilege database accounts would have prevented the subsequent malware installation.

Embedded systems

Key vulnerabilities: hardcoded credentials and backdoors in firmware, no update mechanism, unencrypted firmware (reversible via binwalk/Ghidra), debug interfaces left enabled in production (JTAG, UART), outdated third-party libraries, limited or no runtime security monitoring, and physical access attacks.

Mitigations

Secure boot to verify firmware integrity; encrypted firmware images; disable debug interfaces before production deployment; firmware signing and update authentication; minimal attack surface (disable unused services and interfaces); secure coding practices for C/C++ (bounds checking, safe functions); hardware security for physical attack resistance; regular firmware security assessments.

Real-world example

In 2022, security researchers discovered hardcoded backdoor credentials in Hikvision IP cameras (CVE-2021-36260) — a command injection vulnerability in the web server allowing unauthenticated remote code execution as root. Over 80,000 cameras remained publicly exploitable months after the patch was released, because embedded device owners rarely apply firmware updates. The vulnerability was discovered via firmware analysis — the binary was not encrypted, allowing researchers to identify the flaw through static analysis.

Virtualized systems

Key vulnerabilities: VM escape (hypervisor vulnerability allowing a VM to access the host or other VMs), VM sprawl (unmanaged VMs accumulating outside change management), snapshot security (snapshots contain full disk state including encryption keys and credentials), insecure VM migration (live migration traffic is unencrypted by default in some hypervisors), and hypervisor compromise.

Mitigations

Keep hypervisor software patched promptly; encrypt VM migration traffic; restrict hypervisor management access (dedicated management network, MFA, least privilege); VM lifecycle management to prevent sprawl; encrypt VM snapshots at rest; monitor for unusual inter-VM traffic; use confidential computing (Intel TDX, AMD SEV) for sensitive workloads requiring isolation even from the hypervisor.

Real-world example

CVE-2018-3646 (L1 Terminal Fault / Foreshadow): a speculative execution vulnerability in Intel processors allowed a malicious VM to read data from SGX enclaves and potentially from other VMs on the same physical host by exploiting L1 data cache state. Cloud providers had to apply hypervisor patches and, in some cases, disable hyper-threading — a performance impact of 10–30%. The vulnerability required no software exploitation — physical proximity via shared hardware was sufficient. Confidential computing architectures (encrypted memory per VM) mitigate this class of attack by ensuring VM memory is encrypted even from the hypervisor.

California Consumer Privacy Act (CCPA) / CPRA

Applies to for-profit businesses meeting any one of: $25M+ annual revenue; collecting data on 100,000+ consumers/households annually; or deriving 50%+ of revenue from selling personal data. Grants California residents rights to know, delete, opt-out of sale, and non-discrimination. Amended by CPRA (2023) to add correction rights and establish the California Privacy Protection Agency as an independent enforcement body.

Penalties

$2,500 per unintentional violation; $7,500 per intentional violation. Private right of action for data breaches: $100–$750 per consumer per incident — creating significant class action exposure for large breaches.

Real-world example

Sephora settled with California AG for $1.2M (2022) — the first major CCPA enforcement action — for failing to disclose it was selling consumer data and failing to honor opt-out requests via the Global Privacy Control signal. The case established that failure to recognize automated opt-out signals is a violation.

Personal Information Protection Law (PIPL) — China

Effective November 2021. Applies to processing of personal information of persons within China, regardless of where the processor is located. Requires explicit consent for most processing, separate consent for sensitive data, and mandatory data protection impact assessments. Cross-border data transfers require either government security assessment, certification by approved institution, or a standard contract filed with authorities.

Penalties

Up to ¥50M or 5% of prior year revenue for serious violations. Business operations may be suspended. Responsible individuals can be banned from serving as directors or senior management.

Real-world example

DiDi Chuxing was fined ¥8.026 billion ($1.2B) in 2022 for serious violations of PIPL and China’s cybersecurity law — including illegal collection of user data and serious security deficiencies. Regulators had flagged the risks before DiDi’s US IPO; the company proceeded anyway. The fine was accompanied by suspension of new user registration for over a year.

Protection of Personal Information Act (POPIA) — South Africa

Fully effective July 2021. Applies to any organization that processes personal information of South African data subjects. Based on eight conditions for lawful processing: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation. Established the Information Regulator as the supervisory authority.

Penalties

Fines up to R10 million (~$540K). Imprisonment of up to 10 years for certain offenses. The Information Regulator can also issue enforcement notices and compliance notices independently of fines.

Real-world example

The 2020 Experian South Africa breach exposed data on 24 million individuals and 793,000 businesses to a fraudster posing as a legitimate client. The Information Regulator issued an enforcement notice requiring Experian to notify affected data subjects and improve security. POPIA’s accountability condition was central to the regulatory response: Experian had processed data without adequate verification of the requester’s identity.

Criminal investigation

Conducted by law enforcement (FBI, national cybercrime units) to determine whether a crime was committed and to support prosecution. Security professionals play a supporting role: preserving evidence, maintaining chain of custody, and cooperating with investigators. Once law enforcement is involved, the organization should not independently conduct forensic analysis on the same systems without coordination — improper handling can contaminate evidence.

Standard of proof

Beyond reasonable doubt — the highest standard. Evidence must be collected with strict chain of custody. Digital forensics must follow validated methodologies (write-blockers, hash verification of forensic images).

Real-world example

The 2014 Sony Pictures hack was investigated by the FBI as a criminal matter. North Korean state actors were attributed. Sony’s internal security team had to coordinate evidence preservation with FBI agents while simultaneously trying to restore operations. The tension between forensic preservation (leave systems intact) and operational recovery (restore systems quickly) is a defining challenge of criminal investigations involving the organization’s own infrastructure.

Civil investigation

Conducted to support litigation between private parties — typically a breach of contract, negligence claim, or trade secret misappropriation. Discovery in civil litigation can compel the organization to produce emails, logs, security policies, audit reports, and forensic evidence. E-discovery obligations activate as soon as litigation is reasonably anticipated — a legal hold must be issued immediately to suspend normal data destruction schedules.

Standard of proof

Preponderance of evidence. But the scope of discovery is broad — opposing counsel can demand virtually any document, log, or communication relevant to the claim. Security records, incident reports, and internal audit findings are all discoverable.

Real-world example

After the 2013 Target breach, Target faced hundreds of civil lawsuits from banks seeking to recover card reissuance costs. Discovery required Target to produce internal security assessments, Trustwave QSA reports, and FireEye alert logs. Internal documents showing Target had received security warnings it did not act on were central to the civil liability argument. Security documentation that seems routine becomes litigation evidence in civil proceedings.

Regulatory investigation

Conducted by a regulatory authority (FTC, SEC, ICO, HHS OCR) following a reported breach, complaint, or routine audit. Regulators have subpoena power and can compel document production. The organization must cooperate fully and cannot destroy potentially relevant records once a regulatory inquiry begins. Regulatory investigations often run in parallel with civil litigation, creating complex legal obligations.

Standard of proof

Varies by regulator and jurisdiction. Regulators typically need to establish a violation of specific regulatory requirements — negligent security, failure to notify, inadequate safeguards. The burden is often on the organization to demonstrate it met the standard.

Real-world example

Following the Anthem breach (2015), HHS OCR opened a regulatory investigation under HIPAA. The investigation found Anthem had conducted an inadequate risk analysis — the foundational HIPAA Security Rule requirement. Anthem settled for $16 million. Critically, the settlement was not because Anthem was breached, but because the risk analysis process that should have identified and addressed the vulnerability had not been performed adequately. The breach was the trigger; the regulatory violation was the underlying failure.

Industry standards investigation

Conducted by industry bodies or their designated assessors (QSAs for PCI-DSS, auditors for SOC 2) following a suspected standards violation. PCI-DSS forensic investigations, for example, are conducted by PCI Forensic Investigators (PFIs) — qualified third parties who follow specific methodologies and report findings to the card brands. These investigations can result in fines from card brands, increased compliance requirements, or loss of ability to process card payments.

Standard of proof

Contractual and standards-based — not a legal standard. The question is whether the organization met the requirements of the standard at the time of the incident and maintained appropriate documentation.

Real-world example

Following a card breach at a restaurant chain, Visa initiates a PCI forensic investigation through a PFI. The PFI determines the POS systems were running out-of-date software and cardholder data was stored unencrypted after authorization — violations of PCI-DSS Requirements 3 and 6. The card brands levied fines and placed the chain in a remediation program with quarterly QSA assessments. The restaurant faced both the standards investigation and concurrent civil suits from issuing banks.

PASTA — Process for Attack Simulation and Threat Analysis

A risk-centric methodology in seven stages: define business objectives → define technical scope → decompose the application → threat analysis → vulnerability and weakness analysis → attack modeling → risk and impact analysis. PASTA explicitly ties technical threat analysis to business risk — making it particularly suitable for organizations that need to present threat modeling outputs to non-technical stakeholders.

Key advantage

Business-aligned output. The final stage produces a risk-prioritized list of threats with business impact quantification — directly usable in board-level risk reporting and security investment decisions.

Real-world example

A financial services firm uses PASTA when onboarding a new customer-facing payments application. Stage 3 (application decomposition) reveals a data flow between the mobile app and a legacy back-end processor that was not in the architecture diagram. Stage 5 identifies that this undocumented flow lacks encryption. The finding is prioritized in Stage 7 as high-risk (business impact: PCI-DSS violation, cardholder data exposure). It is remediated before go-live. Without PASTA, the undocumented flow might not have been discovered until post-launch audit.

DREAD

A quantitative risk rating model used to prioritize identified threats. Each threat is scored 1–10 across five dimensions, and an average score drives prioritization. Originally developed by Microsoft but since deprecated in favor of STRIDE for design-phase use; DREAD is now more commonly used for scoring and prioritizing a list of already-identified vulnerabilities.

The five dimensions

Damage potential — how much harm if exploited? Reproducibility — how easily can the attack be repeated? Exploitability — how much skill/resources are required? Affected users — how many users are impacted? Discoverability — how easily can the vulnerability be found?

Real-world example

A penetration testing team identifies 23 vulnerabilities in a web application. The client needs a prioritized remediation plan with limited budget. DREAD scoring on each finding produces a ranked list: an unauthenticated SQL injection affecting all users scores 9.2 (critical); a reflected XSS requiring user interaction affecting single sessions scores 4.8 (medium). Budget goes to the top 5 findings. DREAD makes prioritization explicit, auditable, and defensible to management.

Attack trees

A graphical, hierarchical representation of ways a goal (root node) can be achieved by an attacker. Sub-goals branch downward, with AND nodes (all children must be achieved) and OR nodes (any child is sufficient). Attack trees are valuable for communicating complex attack paths to non-technical stakeholders and for identifying which defenses break the most attack paths simultaneously.

Key advantage

Visual and intuitive. A single attack tree for “attacker achieves unauthorized admin access” makes the full range of attack vectors visible in one diagram — helping decision-makers understand why controlling a specific chokepoint is high-value.

Real-world example

A bank’s security team builds an attack tree for “attacker transfers funds without authorization.” The root has two major branches: compromise customer credentials (OR) and compromise internal banking system. The customer credentials branch has sub-nodes: phishing, credential stuffing, SIM swapping, malware. Analyzing the tree reveals that multi-factor authentication (MFA) breaks every credential sub-branch simultaneously — making it the highest-value single control in the tree. The tree made the investment case for MFA unambiguous to the board.