Entry-Level Cybersecurity Engineer Interview Preparation Guide for Airbnb

Direct answer

Start by scoping the problem precisely enough that ownership boundaries become visible, then build a coalition of every team whose work the fix touches rather than waiting for someone to volunteer ownership. Secure a sponsor with authority spanning those teams who can prioritize the fix against each team's other work, and sequence the remediation so early, low-risk wins buy the credibility needed to sustain a multi-month effort.

Structured elaboration

1. Scope with evidence. Document the pattern concretely enough, which systems or teams are affected and how you know, that it reads as a shared problem rather than one team's incident. Vague framing invites everyone to assume it is someone else's issue.
2. Coalition, not delegation. Identify every team whose systems or processes need to change and bring them into a kickoff where they see the evidence directly, rather than hearing about it secondhand from you.
3. Sponsorship. Find someone with authority spanning all the affected teams who can prioritize the fix against each team's existing roadmap. Without this, the effort re-competes for attention every sprint and eventually loses.
4. Phased roadmap. Ship interim mitigations that reduce risk within days to weeks, while the durable fix is designed and rolled out over the following weeks to months. The organization should not be fully exposed while waiting for the complete fix.
5. Communication rhythm. A lightweight, regular update, what is done, what is blocked, what is next, keeps the effort visible to the sponsor and affected teams over a multi-month timeline, instead of fading once the initial urgency wears off.
6. Closure and verification. Define what "done" looks like before you start, and verify it at the end. A systemic fix without a defined closure condition tends to drift indefinitely.

Worked example

Suppose the systemic problem is a class of vulnerability that recurs across several services owned by different teams (the same shape applies to a systemic reliability gap or an accessibility gap spanning many product surfaces). Six teams share the affected pattern. A kickoff is scheduled within the first week so all six see the evidence together. A low-risk compensating control is rolled out across all six teams within the first two weeks, buying time while the durable fix, a shared library or pattern change, is designed and rolled out over roughly two months. Progress is reported every two weeks to the sponsoring lead and the six teams. The effort closes only once every team has migrated to the durable fix and the compensating control has been verified safe to remove.

Trade-offs & pitfalls

• Trying to fix it yourself across every team's codebase does not scale past a handful of teams and burns out the person carrying it.
• Skipping interim mitigation and going straight for the durable fix leaves the organization exposed to the systemic risk for the entire multi-month build, a costly bet if anything slips.
• Junior candidates tend to focus on getting the technical fix right. Senior candidates weight the coalition and sponsorship just as heavily, because a correct fix with no organizational backing stalls the moment it competes with someone's sprint commitments.
• Not defining "done" is a common pitfall: an effort with no closure condition can run indefinitely, consuming goodwill and losing the sponsor's attention long before every team has actually migrated.

Direct answer

Elliptic curve cryptography (ECC) does the same job as RSA, public-key encryption and
signatures, using the algebraic structure of points on an elliptic curve instead of large
integer factorization. It reaches the same security level as RSA with much smaller keys,
because the best known attack against the underlying elliptic-curve discrete-log problem has
no sub-exponential shortcut, unlike RSA's factorization problem.

Structured elaboration

• Key sizes: a 256-bit elliptic-curve key (P-256) provides roughly the same security as a
  3072-bit RSA key; a 384-bit curve (P-384) roughly matches a 7680-bit RSA key. The gap widens
  as the target security level rises.
• Computational cost: ECC signing and key-generation operations are cheap compared to RSA
  at an equivalent security level, since RSA's cost grows faster than ECC's as key size
  increases. RSA public-key verification is actually cheap in absolute terms (a small public
  exponent keeps that operation fast), but RSA's private-key operations and key generation get
  noticeably expensive at 3072+ bits.
• Bandwidth: ECC keys and signatures are dramatically smaller, a P-256 ECDSA signature is
  roughly 64 bytes versus roughly 256 to 384 bytes for an RSA-2048/3072 signature. This matters
  directly for TLS handshake size, mobile bandwidth, and embedded/IoT devices with tight memory
  budgets.
• Use cases: ECDSA for digital signatures, ECDH (and its ephemeral form, ECDHE) for key
  exchange, both filling the same roles RSA and classic Diffie-Hellman fill, just cheaper.
• Named curves: P-256 (also called secp256r1, a NIST-standardized curve) is the most
  widely deployed; Curve25519 (used for X25519 key exchange) and Ed25519 (its signature
  counterpart) are increasingly preferred, in part because their parameters were generated
  through a fully documented, deterministic process, addressing concerns some practitioners
  raised about the opacity of how certain NIST curve constants were originally chosen.

Worked example

A mobile app performs 1,000,000 TLS handshakes a day against its API. Each handshake carries
one server certificate signature. An RSA-3072 signature runs roughly 384 bytes; a P-256 ECDSA
signature runs roughly 64 bytes, a saving of 320 bytes per handshake. Across a day:
1,000,000 x 320 bytes = 320,000,000 bytes, that is, about 320 MB of signature bytes saved
daily just from the certificate switch, before counting any of the other handshake fields ECC
also shrinks. For a bandwidth-constrained mobile client population, that is a real, measurable
reason to prefer ECDSA over RSA beyond the abstract "smaller keys" framing.

Trade-offs & pitfalls

• ECC implementations are more delicate than RSA's: incorrect point validation, timing
  side-channels during scalar multiplication, and "invalid curve" attacks are all
  ECC-specific implementation pitfalls that a naive from-scratch implementation is likely to
  get wrong. "Don't roll your own crypto" applies even more strongly to ECC than to RSA.
• Choice of curve matters beyond raw key size: Curve25519/Ed25519 are designed to make
  several classes of implementation mistakes (like weak point validation) structurally harder
  to make than the older NIST curves do.

Direct answer

Treat this as a graph traversal, not a recursive tree walk: each role is a node, an inheritance edge points from a role to the roles it inherits from, and a user's effective permissions are the union of every role's direct permissions reachable from their assigned roles. Track visited roles explicitly so a cycle in the hierarchy, which is a real misconfiguration a permissions table can accumulate after enough ad hoc edits, terminates instead of looping forever, and let a plain set naturally deduplicate the result.

Structured elaboration (approach)

Use an iterative traversal with an explicit visited set and a work stack, rather than plain recursion. Two reasons: it sidesteps Python's recursion limit on a very deep hierarchy, and, more importantly, the visited set is exactly what makes a cycle safe: once a role has been processed, revisiting it through a different inheritance path is a no-op instead of a second traversal down the same cycle.

Function signature:

def effective_permissions(
    user_roles: list[str],
    role_hierarchy: dict[str, list[str]],   # role -> parent roles it inherits from
    role_permissions: dict[str, set[str]],  # role -> permissions granted directly
) -> set[str]:
    ...

Worked example (executed)

def effective_permissions(user_roles, role_hierarchy, role_permissions):
    visited = set()
    permissions = set()
    stack = list(user_roles)

    while stack:
        role = stack.pop()
        if role in visited:
            continue
        visited.add(role)
        permissions |= role_permissions.get(role, set())
        stack.extend(role_hierarchy.get(role, []))

    return permissions


def run_demo():
    # admin -> manager -> editor -> admin is a cycle: a real misconfiguration
    # a permissions table can end up with after enough ad hoc edits. Each role
    # also grants its own permission, so we can confirm every permission in
    # the cycle is collected exactly once.
    role_hierarchy = {
        "admin": ["manager"],
        "manager": ["editor"],
        "editor": ["admin"],   # closes the cycle back to admin
        "viewer": [],
    }
    role_permissions = {
        "admin": {"users:delete"},
        "manager": {"reports:export"},
        "editor": {"posts:write"},
        "viewer": {"posts:read"},
    }

    results = []

    perms = effective_permissions(["admin"], role_hierarchy, role_permissions)
    results.append((
        "cyclic hierarchy resolves to all reachable permissions, terminates",
        perms == {"users:delete", "reports:export", "posts:write"},
    ))

    perms2 = effective_permissions(["viewer", "manager"], role_hierarchy, role_permissions)
    results.append((
        "two directly-assigned roles union correctly",
        perms2 == {"posts:read", "reports:export", "posts:write", "users:delete"},
    ))
    # reports:export pulls in editor -> admin transitively from "manager",
    # confirming multi-hop inheritance beyond the direct assignment.

    perms3 = effective_permissions(["ghost-role"], role_hierarchy, role_permissions)
    results.append(("unknown role degrades to empty set, no exception", perms3 == set()))

    all_pass = True
    for name, passed in results:
        print(f"[{'PASS' if passed else 'FAIL'}] {name}")
        if not passed:
            all_pass = False
    print(f"\neffective_permissions(['admin'], ...) = {sorted(perms)}")
    print(f"ALL_PASS={all_pass}")


if __name__ == "__main__":
    run_demo()

Output, from an actual run (python3 effective_permissions.py):

[PASS] cyclic hierarchy resolves to all reachable permissions, terminates
[PASS] two directly-assigned roles union correctly
[PASS] unknown role degrades to empty set, no exception

effective_permissions(['admin'], ...) = ['posts:write', 'reports:export', 'users:delete']
ALL_PASS=True

The first case is the one that actually tests what the question asks for: admin -> manager -> editor -> admin is a genuine cycle, and the function both terminates (rather than looping until the process is killed) and still collects all three permissions reachable around that cycle, not just the ones on the role the traversal happened to start from.

Complexity and edge cases

Let V be the number of distinct roles reachable from user_roles and E the number of inheritance edges among them; the traversal itself is O(V + E), since the visited set guarantees each role is popped from the stack and expanded at most once regardless of how many cycles or redundant paths reach it. Building the final permission set costs O(P), where P is the total number of permission entries across every visited role, since each is inserted into the result set at most once. Space is O(V + P) for the visited set and the accumulated permissions.

Edge cases demonstrated above: a genuine cycle in the hierarchy (the core requirement in the question), a user with multiple directly-assigned roles that overlap in what they transitively grant, and a role name with no entry in either input dictionary (a stale assignment after a role was renamed or deleted), which degrades to contributing nothing rather than raising.

Trade-offs and pitfalls

• A recursive implementation without an explicit visited set is the single most common wrong answer to this exact question. It will either hit Python's recursion limit or loop forever the instant the hierarchy has a cycle, and cycles do happen in real permission tables, usually after enough years of ad hoc "make this role also inherit from that one" edits by different people who never saw the whole graph at once.
• Returning a list instead of a set, or otherwise skipping deduplication, silently allows the same permission to be counted more than once when two different inherited roles both grant it. That's harmless for a plain membership check but can quietly break any downstream code that assumes the length of the result counts distinct permissions.
• This function is deliberately silent about an unknown role, treating it as contributing nothing rather than raising. That's a reasonable default for a stale role assignment (the role was deleted, but a user record still references it), but it is a choice, not a law: a system that wants to catch that condition as a data-integrity bug should log or raise instead, rather than assuming this function's leniency is the right default everywhere it's reused.

Mapping to CIA triad (brief)

• Firewalls — Availability & Confidentiality (traffic control, segmentation)
• Endpoint Detection & Response (EDR) — Integrity & Confidentiality (malware detection, containment)
• Multi-Factor Authentication (MFA) — Confidentiality & Integrity (auth assurance)
• Periodic Role Reviews — Confidentiality & Integrity (least privilege, privileges correctness)
• Encryption at Rest — Confidentiality (data protection)
• SIEM — Availability, Integrity & Confidentiality (detection, correlation, audit trail)

Control metrics, KPIs and data sources

1. Firewalls

• Mean time to block new malicious IPs (hours) — firewall logs, threat intel feeds, ticketing system
• Percentage of denied suspicious flows vs allowed risky flows (%) — firewall logs, NetFlow/PCAP samples
• Policy drift rate (policies changed without approval per month) — firewall config management, change logs, CMDB

2. EDR

• Detection coverage (%) = endpoints with agent + telemetry health — EDR inventory, MDM reports
• Mean time to detect (MTTD) and mean time to remediate (MTTR) for endpoint alerts (hours) — EDR alert logs, SOAR/ticketing
• Percentage of successful containment actions vs failed attempts (%) — EDR action logs, forensic snapshots

3. MFA

• MFA adoption rate for privileged accounts (%) — IAM logs, directory services
• Number of successful logins bypassing MFA (should be 0) — auth logs, conditional access reports
• Authentication failure spikes correlated to brute-force attempts — auth logs, WAF/IDS

4. Periodic Role Reviews

• Percentage of accounts reviewed and certified on schedule (%) — IAM access review reports, GRC tool
• Number of excessive privilege findings closed within SLA (%) — ticketing system, IAM logs
• Time-to-remediate orphaned or stale roles (days) — IAM audit logs, HR system

5. Encryption at Rest

• Percentage of sensitive data volumes encrypted at rest (%) — data discovery tools, storage inventory
• Key compromise incidents (count) and key rotation compliance (%) — KMS logs, HSM audit trails
• Time to detect unencrypted sensitive object (hours) — DLP/discovery scans, storage audit

6. SIEM

• Mean time to detect and escalate correlated incidents (MTTD) — SIEM alert timestamps, SOAR tickets
• False positive rate of prioritized alerts (%) — SIEM alert metadata, SOC feedback loop
• Log coverage completeness (%) = % of critical sources sending logs and within retention SLAs — log source inventory, logging pipeline metrics

Rationale: each metric ties to measurable outcomes (reduce exposure, speed of response, policy hygiene). Data sources listed are commonly available in production telemetry and integrate with SOAR/GRC for reporting.

Direct answer

I would stop new over-permissioning at the source with organization-level guardrails and paved-road defaults, then shrink existing excess using usage data, so that least privilege is the easy default rather than a periodic cleanup. Developers keep self-service inside a safe boundary, so security stops being a ticket queue.

Mechanisms, in the order I would roll them out

1. Organization guardrails (SCPs, service control policies: a permission ceiling no account below can exceed): deny the things nobody legitimately needs, such as disabling audit logging, creating long-lived access keys for users, or using unapproved regions.
2. Permission boundaries for delegated role creation. Teams may create their own roles, but only up to a maximum set of permissions, so self-service cannot become privilege escalation. A permission boundary is a policy attached to a role that sets its ceiling without granting anything: effective access is only what both the role's own policies and the boundary allow. For example, with a boundary that allows only s3:*, dynamodb:* and sqs:*, a team role that was given iam:* and s3:* ends up with S3 access only, because IAM actions fall outside the ceiling.
3. Paved-road templates. A paved road is the platform team's pre-approved, ready-made way to build and deploy a service, so the secure choice needs no extra effort. The standard infrastructure-as-code module (a reusable template that defines cloud resources as code) for a new service creates its own role with only listed actions on named resources and short-lived credentials. The easiest path is the safe path.
4. Policy checks in the pipeline. A change that adds a wildcard action or grants new access beyond an approved baseline fails the pull request (cloud providers offer policy-validation and policy-comparison checks; AWS IAM Access Analyzer provides both).
5. Right-sizing from usage. Unused-access findings (roles, keys and permissions not used within a window you set, such as 90 days) open automatic pull requests to remove them. A typical before and after, using illustrative names:

Before: Action "s3:*"                          Resource "*"
After:  Action ["s3:GetObject","s3:PutObject"]  Resource "arn:aws:s3:::orders-uploads/*"

The access logs showed the service only ever read and wrote objects in one bucket, so everything else could go.
6. Exceptions expire. Broad access is granted with an owner and an end date, enforced by the platform, rather than reviewed by hand.

Patterns across service types

Keeping it valid over time

Policies live in version control; the pipeline blocks regressions; unused-access findings flow to owners automatically; and a small sample audit (not a full review) checks the automation is working.

Not slowing developers

Measure request-to-working-permission time. A boundary that lets a team self-serve in minutes removes the incentive to ask for admin "just in case".

Existing creep

Do not try a big-bang cleanup. Fix the most dangerous first: roles with administrator-equivalent rights and cross-account trust (a role that principals in another cloud account are allowed to assume), then the unused ones, with usage data proving removal is safe.

1) Multiprocessing (multiprocessing module)

• Benefit: sidesteps GIL (Global Interpreter Lock: a lock inside CPython that only lets one thread execute Python bytecode at a time, which is why adding more threads alone does not speed up pure-Python CPU-bound work) by using multiple processes; good for CPU-bound tasks that can be partitioned.
• Limitations: IPC and data serialization overhead, higher memory usage per process.
• When: embarrassingly parallel workloads (map-style), batch processing across cores.

2) C-accelerated libraries (NumPy / vectorization)

• Benefit: move heavy numeric loops into C (SIMD, Single Instruction Multiple Data, a CPU feature applying one operation to many values in one step; contiguous memory), drastically faster for array math.
• Limitations: requires expressing work in array form; not helpful for complex control flow.
• When: numerical computations over arrays, matrix ops.

3) Just-in-time / ahead-of-time compilation (Numba or Cython)

• Numba: JIT-compiles (just-in-time compiles: instead of compiling ahead of time before the program ever runs, the function is compiled straight to machine code the first time it is actually called) Python functions to machine code with little code changes; excellent for loops on numeric data.
  • Benefit: low development cost, big speedups.
  • Limitation: not all Python features supported; first-call compilation overhead.
• Cython: compile Python to C for maximum control and speed; can produce greatest gains but requires typing and build step.
  • When: algorithmic hotspots that remain after vectorization or need fine-grained control.

A concrete contrast (real values, not timing, since exact speed depends on hardware and is not something to hardcode here):

import numpy as np

def squares_loop(n):
    return [i * i for i in range(n)]

def squares_vectorized(n):
    return np.arange(n) ** 2

print(squares_loop(5))
# [0, 1, 4, 9, 16]
print(squares_vectorized(5))
# [ 0  1  4  9 16]

Both produce the identical five values; squares_loop pays Python's per-element interpreter overhead five separate times, while squares_vectorized dispatches once into a single compiled C loop, the same mechanism that makes strategy 2 (vectorization) and strategy 3 (Numba/Cython compilation) both faster than a plain interpreted loop: removing per-element interpreter overhead, not changing the underlying arithmetic.

Choose based on workload: use vectorization first, then Numba for loop-heavy numeric code, and multiprocessing when parallelism across cores is needed and data can be partitioned.

Direct answer

A secure Application Programming Interface (API) gateway centralizes the security controls that would otherwise be duplicated (and inconsistently implemented) across every backend service: authentication, authorization, injection and protocol defense, Server-Side Request Forgery (SSRF)/egress control, and Single Sign-On (SSO) protections, all enforced at one well-instrumented choke point in front of a fleet of services that individually trust the gateway rather than the open internet. The design has to hold two things in tension: pushing enforcement to one place makes it consistent and auditable, but it also makes the gateway a single point of both failure and latency, so the architecture needs to be highly available and fast on the hot path while still being the place every security decision and every detection signal converges.

Structured elaboration

Component architecture.

flowchart LR
    Client -->|"1: TLS handshake"| GW[API Gateway]
    GW -->|"2: verify token"| AuthN[AuthN service<br/>OIDC/SSO IdP]
    GW -->|"3: check scopes"| AuthZ[AuthZ / policy engine]
    GW -->|"4: inspect request"| WAF[WAF layer]
    GW -->|"5: rate check"| RL[Rate limiter]
    GW -->|"6: emit signal"| Detect[Detection / SIEM pipeline]
    GW -->|"7: forward, mTLS"| Backend1[Backend service A]
    GW -->|"7: forward, mTLS"| Backend2[Backend service B]
    Backend1 -->|"egress request"| EgressCtl[Egress control /<br/>allow-listed destinations only]

Authentication. Terminate authentication at the gateway, not in each backend, so there is exactly one place that validates tokens and exactly one place a token-validation bug can exist. For interactive users, the gateway participates in an SSO flow (OpenID Connect (OIDC) or SAML) against a central identity provider, exchanging the SSO session for a short-lived, gateway-issued access token that backends actually see. For service-to-service and third-party callers, validate a JSON Web Token (JWT) or opaque token via introspection against the issuing authorization server (OAuth 2.0 token introspection, RFC 7662) rather than trusting a locally cached public key indefinitely, so a revoked token stops working immediately instead of only once it naturally expires.

Authorization. Authentication answers "who is this," authorization answers "what are they allowed to call," and these need to be separate, composable decisions. A centralized policy engine (attribute-based, evaluating caller identity, requested route, and request context together) lets the gateway make a coarse-grained allow/deny decision before the request ever reaches a backend, while fine-grained, resource-level authorization (can this specific user see this specific record) still belongs in the backend service, which is the only place that actually knows the resource's ownership. The gateway's job is to cut off the large class of requests that should never reach a backend at all (wrong scope, wrong audience, expired token), not to replace the backend's own authorization logic.

Web Application Firewall (WAF). Sits in the request path to catch the OWASP-Top-Ten-shaped payloads (SQL (Structured Query Language) injection patterns, script-injection payloads, path traversal sequences, known exploit signatures for the frameworks in use) before they reach application code, as a defense-in-depth layer, never as a substitute for parameterized queries and output encoding in the backend itself. Tune it in detection-only mode first against real production traffic to characterize false positives before flipping to blocking mode, because a WAF that blocks legitimate traffic on day one erodes trust in the whole control and invites teams to request exceptions that quietly widen the hole.

Mutual TLS (mTLS). Two distinct mTLS relationships exist in this design and they serve different purposes: gateway-to-backend mTLS establishes that traffic reaching a backend really came through the gateway (backends can then refuse any connection that does not present the gateway's client certificate, closing off direct-to-backend bypass), while client-to-gateway mTLS (where the caller is a service or partner rather than a browser user) provides strong caller authentication independent of, and in addition to, the token-based authentication above.

Rate limiting. Apply it at multiple granularities simultaneously: per-caller-identity (the primary control, since it survives the caller rotating IPs), per-route (protecting expensive endpoints specifically, like search or export), and a coarse per-source-IP limit as a backstop against unauthenticated abuse before a caller identity is even established. Rate limiting is also a security control, not just a cost control: it is what turns a credential-stuffing or brute-force attempt from "instant" into "slow enough to detect and block."

Token introspection. Beyond initial validation, route sensitive operations through live introspection against the authorization server rather than relying solely on a cached JWT's embedded expiry, specifically because token revocation (a compromised session being killed, a user being deprovisioned) needs to take effect immediately, and a purely local, stateless JWT validation cannot express "this specific token was just revoked" without either a short token lifetime plus refresh (acceptable staleness window) or introspection (immediate, at the cost of a network round-trip per request).

Egress controls. The gateway is the natural place to also enforce outbound rules for any backend that itself makes server-side requests to caller-influenced URLs (an SSRF vector): centralizing an allow-list of legitimate outbound destinations here means one policy update closes the hole for every backend, instead of relying on each service team to have implemented its own allow-list correctly.

SSO protections. Beyond the authentication flow itself, this means the gateway (or the identity provider (IdP) it delegates to) enforces: strict redirect-URI allow-listing on the OAuth/OIDC flow (an open redirect here is a full account-takeover primitive, not a cosmetic bug), state/nonce validation to prevent cross-site request forgery (CSRF) and replay against the SSO callback, and short-lived session tokens with refresh rotation so a leaked session token has a bounded window of usefulness. Because SSO centralizes identity, a flaw in this specific flow compromises every downstream service simultaneously, which is exactly why it deserves explicit design attention rather than being treated as "just OAuth, handled by the library."

Detection instrumentation. Every one of the layers above should emit a structured event on both allow and deny decisions (not just denials; a stream of "everything is fine" telemetry is what lets you notice when it suddenly stops), feeding a Security Information and Event Management (SIEM) pipeline that correlates: repeated authentication failures for one identity (credential stuffing), authorization denials clustering on one route (probing for a missing check), WAF signature matches, and rate-limit trips. Because the gateway sees 100% of external traffic, it is the single richest source of this signal in the whole architecture, and instrumentation here should be treated as a first-class design requirement, not an afterthought bolted on after the routing logic is done.

Policy enforcement mechanics. Represent authentication and authorization requirements as declarative, versioned policy (per route: required scopes, rate limits, WAF ruleset, mTLS requirement) rather than as imperative code scattered through gateway plugins, so that a policy change is reviewable in a pull request and consistently applied, and so that a new backend service is secure by default the moment it is registered with the gateway rather than requiring every team to independently remember every control.

Worked example

A concrete route: POST /api/v1/payments/refund. The gateway's policy for this route declares: scope=payments:refund, rate_limit=10/min per identity, mtls_required=true for the calling service, waf_ruleset=strict. A request arrives with a valid SSO-derived JWT, but for a caller whose token has scope=payments:read only. The gateway's authorization check denies the request with a 403 before it reaches the payments backend at all, and emits a structured denial event tagged with the caller identity, the requested scope, and the granted scope. If ten of these denials arrive from the same caller identity within a minute, the SIEM correlation rule for "scope-probing" fires and pages the on-call security engineer, who can see from the single gateway log stream exactly which route and which identity, without needing to correlate logs across the payments service, the auth service, and the network layer separately. This is the concrete payoff of centralization: one denial is noise, ten correlated denials from one identity against one sensitive route is a signal, and the gateway is the only place positioned to see that pattern in real time.

Trade-offs and pitfalls

The single biggest pitfall in this design is architectural: building "one big gateway that does everything" without separating the concerns of authentication/authorization (identity-plane), WAF/rate-limiting (traffic-plane), and egress/SSRF control (network-plane) into independently scalable, independently failable components. A monolithic gateway that couples all three tends to fail all three together under load, exactly when the security controls matter most.

Direct answer

Use find with -xdev (stay on the starting filesystem) and a permission test for "the other-write bit is set": files with find /var -xdev -type f -perm -0002 and directories with find /var -xdev -type d -perm -0002 ! -perm -1000. The second command excludes directories that have the sticky bit (mode 1777, like /var/tmp), where world-writable is intentional because users can delete only their own files. Then triage every hit: is it supposed to be like this, which package or application owns it, and can the cause be fixed at the source so the permission does not come back? Never run a blanket chmod -R o-w.

The commands, flag by flag

Two behaviours I checked in a container. A mount point is reported as an entry itself (a tmpfs mounted at /var/mnt-data with mode 1777 appeared in the sticky-bit list), but its contents are not scanned, so a mode-666 file inside it was not reported with -xdev and was reported without it. If /var itself is a symbolic link, plain find /var examines only the link: use find -H /var or find /var/, both of which follow it. Because -xdev leaves other filesystems unscanned, run the audit on each mount of interest too (findmnt -rn -o TARGET | grep '^/var' lists the mount points under /var).

A reusable audit script

#!/usr/bin/env bash
# List world-writable files and non-sticky world-writable directories under one tree,
# staying on a single filesystem. Read-only: it changes nothing.
set -euo pipefail

root=${1:-/var}

pkg_of() {
  local p=""
  if command -v dpkg >/dev/null 2>&1; then
    p=$(dpkg -S -- "$1" 2>/dev/null | head -n1 | cut -d: -f1) || true
  elif command -v rpm >/dev/null 2>&1; then
    p=$(rpm -qf -- "$1" 2>/dev/null | head -n1) || true
  fi
  printf '%s' "${p:-unpackaged}"
}

report() {
  local kind=$1
  shift
  local path
  while IFS= read -r -d '' path; do
    printf '%s\t%s\t%s\t%s\n' \
      "$kind" "$(stat -c '%a %U:%G' -- "$path")" "$(pkg_of "$path")" "$(printf '%q' "$path")"
  done < <(find "$root" -xdev "$@" -print0)
}

report FILE -type f -perm -0002
report DIR  -type d -perm -0002 ! -perm -1000

Every expansion is quoted, read -d '' consumes the NUL-separated names, and printf '%q' prints a name with spaces or newlines in a form that stays on one line. ShellCheck reports nothing on it. It targets bash 4 or later with GNU find and stat.

Reading the script, line by line

Reading the output. Each line has four tab-separated columns:

The -print0 option in the flag table is meant to be paired with a consumer that reads NUL-separated names, which is what read -d '' does above. The same pairing works with xargs -0 when you want to run another command on the hits. On the test tree below, this lists the files with their modes:

find /var -xdev -type f -perm -0002 -print0 | xargs -0 ls -l --

-rw-rw-rw- 1 root root 0 Oct  6 08:18 /var/lib/myapp/spool dir/report with spaces.txt

Without -print0 and -0 (a plain find ... | xargs ls -l) the same name was split at its spaces into four bogus arguments (/var/lib/myapp/spool, dir/report, with, spaces.txt) and ls reported four "No such file or directory" errors.

Run against a test tree on Ubuntu 24.04:

mkdir -p "/var/lib/myapp/spool dir" /var/www/uploads
touch "/var/lib/myapp/spool dir/report with spaces.txt"
chmod 666 "/var/lib/myapp/spool dir/report with spaces.txt"
chmod 777 /var/www/uploads /var/log/apt
# a separate filesystem is mounted at /var/mnt-data and holds a mode 666 file
bash world-writable-audit.sh /var

FILE	666 root:root	unpackaged	/var/lib/myapp/spool\ dir/report\ with\ spaces.txt
DIR	777 root:root	apt	/var/log/apt
DIR	777 root:root	unpackaged	/var/www/uploads

The package column comes from dpkg -S on Debian and Ubuntu and rpm -qf on the RHEL family. The file in the other filesystem and the sticky /var/tmp do not appear, as intended. After chmod o-w on the report file and chmod 1775 /var/www/uploads, a second run listed only /var/log/apt.

What to do with what you find

Work each hit through the same four questions, in order:

1. Is it supposed to be world-writable? Sticky-bit directories are expected and the command already excludes them. Anything else needs a named reason.
2. Who owns it? If a package owns it (the package column is not unpackaged), a world-writable mode is a deviation: on RPM systems rpm -V <package> flags a changed mode with M, and the fix is to restore the mode the package ships, then find who changed it. If nothing owns it, it is application data or a leftover, so find the application (ls -l, the owning user, and the service that writes there).
3. Why is the bit set? Usual causes: a directory made with mkdir -m 777 to "make the upload work" (give it the application's group and mode 2775 or 1775 instead); a process running with umask 000 (the mask a process applies to the permissions of files it creates); a log file created by a script without a mask. A one-time chmod is wasted if the application recreates the file wrongly, so fix the source. Which mechanism fits depends on who creates the path:
   • A service creates files itself (logs, sockets, spool files): set UMask= in its systemd unit. A umask is the set of permission bits removed from newly created files; UMask=0027 means new files lose group-write and all of the other bits. The default for system units is 0022.
   • The path is the service's own data directory: use StateDirectory=myapp with StateDirectoryMode=0750. systemd creates /var/lib/myapp when the service starts, with that mode.
   • The directory is not tied to one service (a shared spool, a path another package expects): declare it in a tmpfiles.d file (a small systemd configuration file whose lines create and repair paths at boot). d /var/lib/myapp 0750 myapp myapp - creates the directory with a mode and owner (d = create directory), and z /var/lib/myapp 0750 myapp myapp - restores the mode and ownership on an existing path (z = adjust, never creates).
4. Can I change it without breaking something? Before changing, save the listing (the script's output records the old mode), change one directory at a time, test the application as its own user, and watch its error log. If the application breaks, the usual fix is giving it write access through a group, not through the world bit.

Record whatever stays as a documented exception (path, owner, reason, review date), and keep the script's output sorted as a baseline. Run it from a scheduled job and diff against the baseline, so a new world-writable path becomes an alert and not a surprise at the next audit.

Complexity and edge cases

• Cost: find makes one pass over the directory entries on that filesystem, so time grows with the number of files under /var, and the per-hit package lookup adds one dpkg -S or rpm -qf per match, so it grows with the number of hits. Both are small next to a full-disk scan.
• Permissions to run it: run as root. As an ordinary user find prints Permission denied for every directory it cannot enter and the result is silently incomplete. Read stderr, do not discard it with 2>/dev/null.
• Other file types: the commands cover regular files and directories. World-writable sockets and device nodes (-type s, -type b, -type c) are checked separately and most of them are legitimate.
• Files that change while scanning: log files rotate during the scan, so a path can disappear between find and stat. In that case stat prints an error on stderr and the report line is printed with an empty mode column (the script keeps going), so a line with a blank mode is a file that vanished, not a finding.
• Group-writable is a different finding: -perm -0020 finds it; whether it matters depends on who is in the group.

Direct answer

A 5x5 qualitative risk matrix scores each risk on two independent five-point scales, likelihood and impact, multiplies the two ranks into a single score from 1 to 25, and buckets that score into a color-coded band that maps directly to a decision (accept, mitigate, transfer, or avoid). The value over a coarser 3x3 matrix is resolution: five levels per axis let a team distinguish "rare" from "unlikely," which a 3x3's single "low" bucket collapses together.

Structured elaboration

Likelihood axis (rows, ranked 1 to 5): Rare, Unlikely, Possible, Likely, Almost Certain. This represents how probable the risk is to materialize in a defined period, typically annually.

Impact axis (columns, ranked 1 to 5): Negligible, Minor, Moderate, Major, Severe. This represents the business consequence if the risk materializes: financial loss, regulatory exposure, and reputational or operational damage combined into one judgment.

Mapping numeric or qualitative inputs into the matrix: when a quantitative estimate exists, bin it into the nearest rank using stated thresholds so different teams land on the same rank for the same underlying number, for example:

• Likelihood (annual probability): Rare under 5%, Unlikely 5 to 25%, Possible 25 to 50%, Likely 50 to 75%, Almost Certain over 75%.
• Impact (estimated loss): Negligible under $10,000, Minor $10,000 to $100,000, Moderate $100,000 to $500,000, Major $500,000 to $2,000,000, Severe over $2,000,000.
  When only a qualitative judgment is available (no hard number), rank by exploitability, exposure, and existing control maturity for likelihood, and by data sensitivity, regulatory scope, and blast radius for impact, and write down the reasoning so the rank is defensible later.

The matrix and color threshold rules (score = likelihood rank x impact rank, range 1 to 25):

Color thresholds applied to the score: Green (Low) 1 to 4, Yellow (Moderate) 5 to 9, Orange (High) 10 to 15, Red (Critical) 16 to 25.

Sample decision policy

• Accept (Green, 1 to 4): document the risk, the accepting owner, and a review date; no immediate action required beyond monitoring for the rating to change.
• Mitigate (Yellow, Orange, or Red, 5 to 25): the default treatment for anything above Green. Build a remediation plan with an owner and a target date sized to the score: normal backlog work at Yellow, a committed date at Orange, and immediate work plus interim compensating controls and executive escalation at Red. Track the residual score after the planned control is actually in place, and re-score rather than assuming the plan worked.
• Transfer (typically Yellow or Orange, evaluated case by case): use when the cost of mitigating controls exceeds the expected loss reduction they'd buy, and a viable transfer mechanism exists, cyber insurance or a vendor contract with a service-level agreement (SLA) and liability terms, for example.
• Avoid (Red, 16 to 25, and only once mitigation has been evaluated and found insufficient): stop or redesign the activity generating the risk rather than running it at that level. This is the escalation path for a risk no funded mitigation can bring out of the Red band, not the first response to a Red score.

Worked example

A critical data exposure risk is rated Likely (4) for likelihood and Major (4) for impact:

$\text{Score} = 4 \times 4 = 16$

That lands in the Red, 16 to 25 band. Per the policy above the treatment is Mitigate, at the Red tier's urgency: immediate remediation work with a named owner (here, access control tightening and encryption changes), interim compensating controls while that work ships, and escalation to whoever owns the risk policy rather than a line in the normal backlog. What the Red band changes is the urgency and the sign-off, not the treatment type. The team then re-scores the residual risk once the control is genuinely in place: if the control drops likelihood from Likely (4) to Unlikely (2), the residual score is $2 \times 4 = 8$, back in Yellow, and the risk moves to routine tracking. Avoid is the answer only if no mitigation the organization is willing to fund can pull the residual score out of Red; at that point the correct response is to stop or redesign the specific activity or data flow generating the exposure (for example, disable the feature that creates it) rather than keep running it at a Red rating with no path down. Treating Avoid as the automatic default for every Red score is the mistake to guard against here: it reads as decisive but in practice it turns every high-severity finding into a feature shutdown, which is why real policies reserve it for the case where mitigation has already been tried and priced.

Trade-offs and pitfalls

Multiplicative scoring has a known blind spot: a Severe-impact, Rare-likelihood risk (5 x 1 = 5) scores the same as a Minor-impact, Almost-Certain risk (1 x 5 = 5), landing both in the same Yellow band, even though a catastrophic-but-rare risk (data breach triggering regulatory shutdown, for example) often deserves board-level attention that a routine, low-impact, frequent nuisance does not. A senior answer flags this explicitly and applies a manual override rule for anything rated Severe impact regardless of score, rather than trusting the multiplication alone. A second pitfall is scoring drift: without the stated numeric thresholds above, different teams rating the same risk independently will disagree, and without written justification for each rank, ratings quietly shift over time to match whatever outcome someone wants. Finally, "accept" should never mean "ignore, no record kept": an accepted Green risk still needs an owner and a review date, because risk profiles change (a Rare likelihood can become Possible as an attack technique becomes commoditized) and an undocumented acceptance has no mechanism to catch that shift.

Overview — how MITM against TLS/HTTPS happens (enterprise examples)

• Rogue Wi‑Fi or tethering: attacker forces users to connect and intercept traffic, using forged certificates or a captive proxy.
• Malicious TLS interception appliances (corporate proxies with private CA): perform TLS interception by issuing on‑the‑fly certificates trusted by enterprise devices.
• Compromised/rotten certificates or private CA compromise: attacker uses stolen keys or fraudulent certs to impersonate services.

Detection signals (network + host)

• Certificate anomalies: unexpected subject names, weak algorithms (RSA‑1024), mismatched SANs.
• Unexpected chains: certificates chaining to unknown/private CAs or new intermediate CAs.
• OCSP/CRL changes: sudden OCSP responder changes, anomalous OCSP stapling absence, or revoked certs still presented.
• Browser warnings/logs: increased TLS warnings or users bypassing warnings; HSTS/HPKP violations.
• TLS fingerprinting: changes in client/server cipher suites, TLS versions, JA3/JA3S hash differences.
• Network signs: multiple TLS sessions terminated at internal proxies, unusual IP/ASN for expected endpoints.
• Host telemetry: new root CAs installed, unexpected processes performing TLS interception (proxy services), altered cert stores.

Practical mitigations

• mTLS for internal services: require client certs so a passive MITM cannot impersonate clients.
• Certificate pinning (or constrained pinning) for critical internal services and SDKs.
• HSM‑backed PKI and strict key custodianship: protect private keys and enforce MFA for key ops.
• Enterprise PKI hygiene: short lifetimes, automated rotation, CT (Certificate Transparency) monitoring, and strict issuance policies.
• Endpoint hardening: block unauthorized root CA installs, restrict local proxy software, enforce full disk and process whitelisting.
• Network controls: DNSSEC/DoT, DNS over HTTPS policies, egress filtering, TLS inspection only with approved appliances and auditable private CA usage.
• Detection automation: alert on JA3/JA3S anomalies, CT log monitoring for org domains, SIEM correlation of cert changes + user reports.
• User controls & training: disable ability to bypass browser warnings, educate on untrusted Wi‑Fi, require VPN with certificate validation for remote users.

I would combine telemetry (host cert store, JA3), network flow analysis, CT monitoring, and strict PKI controls to detect and prevent MITM while minimizing blind spots introduced by enterprise TLS inspection.