Entry-Level Information Security Analyst Interview Preparation Guide - Amazon

Definition (brief)
Privilege escalation is when an actor or process gains higher access than originally granted. As an analyst, I monitor for these to prevent lateral movement and data exfiltration.

Vertical vs Horizontal

• Vertical (privilege elevation): low-privilege user or process becomes admin/root. Example: exploiting a setuid binary on Linux to get root.
• Horizontal (privilege lateral): user accesses another user’s account or resources at same level. Example: accessing another employee’s files after stealing credentials.

Common techniques

• Windows: abusing weak service permissions, DLL search-order hijacking, unquoted service paths, exploiting vulnerable drivers, Kerberoasting for service account creds.
• Linux: exploiting setuid binaries, writable cron jobs, SUID/SGID misconfigurations, PATH/LD_PRELOAD abuse, kernel exploits (e.g., Dirty COW historically).

Indicative logs/behaviors

• Unexpected process spawning from low-privilege accounts to privileged binaries
• Service installs/privilege change events (Windows Event IDs: 4698/4697, 4670; Linux: sudo/sshd logs, auth.log with unusual sudo success)
• Creation of new admin users, suspicious driver/service loads, unusual use of credential dumping tools, privilege-related audit failures/successes

Three controls (preventive/detective)

1. Least-privilege + hardening: remove local admin rights, restrict write access to service paths and binaries, enforce sudo policies.
2. Patch & inventory: timely OS/driver/third-party patching and regular attack-surface scans for setuid/writable files.
3. Detection & logging: forward Windows Security and Linux auditd logs to SIEM, alert on new admin creation, service installs, abnormal use of privileged commands and credential-dumping signatures.

I would prioritize tuning SIEM alerts to reduce noise and verify alerts with endpoint process trees and file integrity checks.

Brief framing (why different from IT)
OT/ICS assessments prioritize physical safety and process integrity over discovery breadth. As an InfoSec Analyst I treat availability and human safety as primary constraints and adapt methodologies accordingly.

Non‑intrusive scanning

• Prefer passive monitoring (SPAN/mirror ports, network taps, protocol parsers for Modbus/DNP3/IEC 61850).
• Use read‑only queries and vulnerability feeds tuned for ICS; avoid broad TCP/UDP sweeps or credentials brute force.
• Example: deploy passive IDS signatures and periodic safe active checks (SNMP read‑only, authenticated API health endpoints) during low-impact windows.

Vendor coordination & testing windows

• Obtain vendor approval and documented change control before active tests.
• Schedule tests in agreed maintenance windows with plant operators, SMEs, and control engineers.
• Share test plans, rollback steps, and risk assessments ahead of time.

Emergency response & safety constraints

• Predefine abort criteria (process deviation thresholds, safety interlocks trip, unusual device behavior).
• Maintain on‑call contacts: ICS operator, control engineer, vendor, and plant safety officer.
• Ensure immediate revert/backout and grounding procedures in runbook.

Validating fixes safely

• First validate in lab/replica, then in isolated staging segment mirroring PLCs/RTUs.
• Apply fixes during maintenance window with monitoring (SCADA dashboards, process KPIs).
• Use canary devices or phased rollouts and monitor for control anomalies before full deployment.

This approach balances security discovery with operational safety, reduces outage risk, and ensures stakeholders remain informed and empowered to abort if process safety is impacted.

Definition (brief)
Insider threats are risks posed by employees, contractors, or partners who intentionally or accidentally misuse access to harm confidentiality, integrity, or availability of systems/data.

1) Malicious insider

• Behavioral indicators: unexplained access to sensitive data outside role, data staging to removable media/cloud, odd work hours, disgruntlement or policy violations.
• Telemetry to prioritize: DLP alerts, access logs (file shares, databases), UEBA (anomalous read/download patterns), endpoint EDR.
• Control: Enforce least privilege + privileged access reviews and just-in-time (JIT) elevation to limit standing access.

2) Negligent insider

• Behavioral indicators: repeated policy violations, clicking phishing links, improper data handling, weak password reuse.
• Telemetry to prioritize: email/web proxy logs, DLP policy violations, phishing click telemetry, MFA/credential failures.
• Control: Mandatory security awareness + technical DLP enforcement (blocking/fencing exfil attempts) and conditional access.

3) Compromised insider (account takeover)

• Behavioral indicators: impossible travel, IP/geolocation changes, sudden spike in data exfil, atypical application usage.
• Telemetry to prioritize: UEBA (session anomalies), authentication logs (MFA failures/successes), network traffic, SIEM correlation.
• Control: Enforce MFA, adaptive risk-based conditional access, and rapid account suspension playbooks.

I would tune alert thresholds to reduce noise and ensure playbooks map telemetry to response actions (contain, investigate, remediate).

Situation & goal
Start by stabilizing: reduce noise, surface true risk, and ensure repeatable documentation so incidents and metrics are clear.

Triage workflow

• Prioritize by risk:

  • Score alerts via: asset criticality (Crown Jewels first), alert confidence (IDS signature severity, anomaly score), threat context (IOC matches, active campaigns).
  • Quick triage categories: High (critical asset + confirmed IOC), Medium (suspicious but unconfirmed), Low (known false positives).

• Reduce noise:

  • Deduplicate and group by common fields (source IP, destination asset, signature ID, time window).
  • Apply short-term suppression for confirmed noisy signatures; whitelist only after root-cause review and change control.
  • Use correlation rules in SIEM to collapse repetitive IDS hits into single incidents.

• Automatic enrichment:

  • Auto-enrich alerts with: asset owner and classification, vulnerability/patch status, WHOIS/GeoIP, passive DNS, threat-intel score (MISP/CTI), recent user/auth logs.
  • Attach enrichment results to the incident ticket for analyst review.

• Escalation decisions:

  • Follow playbook thresholds: isolate or block if confirmed compromise on high-value asset; otherwise escalate to Tier 2 if lateral movement, persistence, or data exfil suspected.
  • Notify stakeholders based on impact matrix (IT ops, incident response lead, legal/PR as required).

• Documentation & metrics:

  • Create/update ticket with timeline, enrichment evidence, investigation steps, and action taken. Use standardized templates.
  • Capture metrics: MTTR, alerts ingested vs investigated, false-positive rate, suppression rules added.
  • Log lessons and tune detection rules; schedule follow-up for remediation and rule improvements.

This workflow balances speed and accuracy, reduces repetitive work, and produces measurable improvements.

Brief approach

• Read /dev/sda raw (read-only), stream-compress, send over SSH to remote server, compute SHA256 on both sides for verification, minimize writes on host.

Command (run as root; replace host/user/paths):

# create compressed image on remote, compute remote checksum, and save local checksum
dd if=/dev/sda bs=4M conv=sync,noerror status=progress \
  | gzip -c \
  | tee >(ssh forensics@forensic-server "cat > /evidence/host1_sda.img.gz; sha256sum /evidence/host1_sda.img.gz > /evidence/host1_sda.img.gz.sha256") \
  | sha256sum > /root/host1_sda.img.gz.sha256
# optionally set remote image timestamp to match device (if desired)
ssh forensics@forensic-server "touch -r /dev/sda /evidence/host1_sda.img.gz || true"

Explanation / rationale

• dd with conv=sync,noerror reads device safely, avoiding halts on read errors.
• Streaming via gzip avoids local disk write; tee with process substitution streams concurrently to ssh while producing local checksum for independent verification.
• Compute SHA256 on both ends and compare checksums off-host to verify integrity.
• touch -r attempts to preserve timestamp; may fail if /dev/sda has no meaningful timestamp—kept optional.
• Minimal contamination: single streamed read, no extra packages, limited disk writes.

Direct answer: Insecure deserialization happens when an application reconstructs an object from untrusted byte data using a mechanism that can be tricked into instantiating arbitrary classes or invoking arbitrary methods as a side effect, letting an attacker achieve remote code execution or bypass application logic without the application's own code ever intentionally calling anything malicious.

How it leads to RCE or a logic bypass. Deserialization mechanisms like Java's native serialization, Python's pickle, and PHP's unserialize() are designed to reconstruct arbitrary object graphs, which means they can call constructors, setters, and "magic methods" (__reduce__ in Python, readObject() in Java, __wakeup() in PHP) automatically during the reconstruction process - a data format that CAN execute code by definition can be steered into executing the WRONG code by an attacker who controls the byte stream. Even without full RCE, tampering with a serialized object's fields (an admin flag, a price, a permission level) before it's deserialized back can bypass application logic that assumed the object was only ever produced by the application's own trusted serialization step.

Language-specific risks: Java native serialization is exploited via "gadget chains" - sequences of otherwise-legitimate classes already present on the classpath (from common libraries) whose methods, when chained together during deserialization, achieve code execution the developer never intended. Python's pickle explicitly supports arbitrary callable invocation via __reduce__ by design, which is why the Python documentation itself warns never to unpickle untrusted data. PHP's unserialize() similarly invokes magic methods on class reconstruction, and PHP-specific "POP chain" (property-oriented programming) techniques chain together classes already loaded by the application to the same effect.

Where deserialization typically occurs, often less obviously than a dedicated "deserialize" API call: session storage (a serialized session object read back on every request), inter-service message queues (one service serializes an object, another deserializes it), cookies used to persist client state, and RPC/remote object protocols.

Secure design patterns and mitigations:

1. Prefer data-only formats (JSON, Protocol Buffers) with no code-execution surface at all, wherever the use case allows - this is the strongest fix, since it removes the vulnerability class structurally rather than trying to use a code-capable format safely.
2. If a code-capable format must be used, apply strict type allowlisting so only explicitly-trusted classes can be instantiated during deserialization, never accepting "whatever class the byte stream names."
3. Runtime mitigations: sandboxing/isolating the deserialization step, and monitoring for deserialization exceptions or unexpected class-instantiation patterns as a detection signal.

A small, concrete trace of the mechanism, executed. Real gadget chains are hard to show in full (they typically chain several existing classes together), but the core mechanism - that reconstructing an object can trigger an arbitrary call, not just populate fields - is easy to demonstrate directly and I ran this:

class CacheWarmer:
    def __reduce__(self):
        # pickle calls __reduce__ automatically while RECONSTRUCTING the
        # object, and __reduce__ is free to name any callable with any
        # arguments - a real gadget reuses a class already on the classpath
        # for a legitimate reason, choosing which already-present callable
        # to invoke rather than injecting new code.
        return (print, ("[gadget fired] code ran during deserialization",))

malicious_bytes = pickle.dumps(CacheWarmer())  # 86 bytes on the current default pickle protocol, looks like ordinary data
pickle.loads(malicious_bytes)  # the victim app just wants to load a cached object

Running this prints [gadget fired] code ran during deserialization at the pickle.loads() line itself, before the victim application's own code ever runs anything - confirming the call happened as a side effect of reconstruction, not because the application explicitly invoked print. A real Java gadget chain follows the identical shape with readObject() instead of __reduce__, and a PHP POP (property-oriented programming) chain follows it with __wakeup()/__destruct(): an attacker who cannot inject new code can still reach a dangerous outcome (a real attack typically ends at something like a file write, a command execution primitive, or a class constructor with a serious side effect) by choosing which already-loaded class's magic method fires next, then which method THAT one calls, walking through classes already present in the application rather than introducing any new code of its own - "chain" refers to that sequence of hops through existing code, each one legitimate in isolation.

Detection signals in logs/crash traces: unexpected ClassNotFoundException/InvalidClassException-style errors (an attacker probing with class names that don't exist on the classpath), unusually large serialized payloads, or a spike in deserialization exceptions correlated with requests from a single source.

Trade-offs and pitfalls: type allowlisting has to be maintained as the application's legitimate object model evolves, and a too-broad allowlist (allowing a class merely because it's "already used somewhere in the app") can still admit a usable gadget if that class happens to have a dangerous side effect in its constructor or setters - the allowlist needs review, not just existence.

Direct answer
Different companies name the same underlying idea, owning an outcome end to end and beyond your formally assigned scope, under different labels. Recognizing which of a specific company's named principles maps to that idea, and then having a real, specific story ready, is the actual skill being tested.

Structured elaboration

1. Read the company's actual published list and identify the principle whose description centers on end-to-end accountability and going beyond formal scope, rather than assuming it is whichever principle happens to sound closest to the word "ownership."
2. Select a real story where you did something that was, strictly, not your job, or continued past the point where you could have handed it off to someone else.
3. Structure it briefly: what you noticed, why you didn't wait for someone else to take it on, what you actually did through to completion, and the outcome.
4. Include one honest lesson, ideally something you would do differently next time; a story with no self-critique at all tends to read as less genuine.

Worked example
A project's launch depended on a piece of infrastructure owned by a team that had deprioritized it. Rather than escalating and waiting, or quietly working around the gap, the candidate built the missing piece directly, with the owning team's agreement, on a tight timeline, then handed it back afterward with documentation so that team could maintain it going forward, and followed up a month later to confirm it had actually been adopted rather than quietly abandoned. The lesson: doing the initial work wasn't the hard part; making sure ownership genuinely transferred back afterward, rather than quietly staying with the person who had stepped in, was the part that mattered most and the part that was easiest to skip.

Trade-offs and pitfalls
A story where you took something over and never handed it back can read as scope-grabbing rather than ownership; the follow-through and handoff matter as much as the initial action. Mapping too literally from a principle's name, rather than its actual published description, risks picking the wrong principle for a company whose specific wording differs from what the word alone suggests. A story with no genuine lesson or self-critique often reads as rehearsed rather than reflective.

Approach (brief)
Design detections mapped to MITRE ATT&CK techniques for container escape (e.g., TESC: Escape to host) and lateral movement (e.g., Lateral Movement via kubectl, API abuse). Combine host/container runtime, kube-audit, node logs, and network flow telemetry; enforce network/RBAC controls to reduce blast radius.

Required telemetry

• Container runtime events: process execs, new privileges, filesystem mounts, container start/stop, capabilities changes (Falco, Docker/CRI-O events).
• Kube-audit: all API server requests, impersonation, exec/attach events, pod creation with hostPath/hostNetwork/privileged.
• Node logs: syscalls denied, kernel messages (dmesg), SSH/cron/cronlogs, kubelet logs.
• Network flows: Cilium/Calico flows, service-to-service connections, pod-to-node, DNS queries.

Example detection rules

• Falco (container escape indicator):

# falco rule
- rule: Privileged Container Changed / HostPath Mounted
  desc: Detect containers with privileged flag or hostPath mounts
  condition: container.privileged=true or container.mounts.path startswith /host
  output: Privileged/HostPath mount in container (user=%user.name container=%container.name)
  priority: CRITICAL

• SIEM/KQL (kube-audit):

KubeAudit
| where verb in ("exec","attach") and (requestObject.spec.containers[*].securityContext.privileged == true or requestObject.spec.volumes[*].hostPath != "")
| extend user = user.username, pod = requestObject.metadata.name

• Network flow anomaly (NetFlow):
  • Alert when pod makes outbound connections to >50 unique IPs in 10m or to internal node SSH ports.

Network & RBAC controls

• NetworkPolicy: default deny ingress/egress; explicit service whitelists; isolate namespaces; restrict hostNetwork=true usage.
• CNI-level egress controls + eBPF policy enforcement to block lateral SSH/RDP and limit pod-to-node access.
• RBAC: least privilege for service accounts, deny wildcard verbs in ClusterRoleBindings, require OPA/Gatekeeper admission to prevent hostPath/privileged/hostPID usage.
• Pod Security Admission: enforce baseline/restricted profiles.

Detection playbook / investigation steps

• On alert, collect: pod manifest, kube-audit trail for user/serviceAccount, container process tree (ps + pcap if available), node syslogs, network flows in window. Quarantine pod via NetworkPolicy and scale down service account tokens.

Trade-offs

• High-fidelity vs noise: prioritize rules that combine multiple signals (audit + runtime + network) to reduce false positives. Use enrichment (image vulnerability, SA policies) to prioritize response.

This strategy gives layered telemetry, concrete detections, and controls to limit attacker movement inside the cluster.

Direct answer

Preserve API and registry access logs immediately, revoke or scope down the suspected insider's credentials while investigating, coordinate with legal and HR before confronting the individual, and put token scoping and data-loss-prevention controls in place to prevent recurrence.

Structured elaboration

Evidence to gather and preserve. API access logs showing exactly which model artifacts were downloaded, when, and via which credential; registry activity logs confirming download events distinct from routine access (a normal deployment pull versus an unusual bulk download pattern); and any database logs showing access to the underlying model metadata, all preserved before the individual might realize they're suspected and potentially cover their tracks.

Immediate containment: full revocation versus scoped limits. Full credential revocation stops any further access immediately but may tip off the individual before you've gathered enough evidence or coordinated with HR and legal on timing; scoped limits (restricting the credential's access to only what's needed for their current legitimate work, or throttling download rate) can buy investigative time while still meaningfully reducing further risk, similar to the broader insider-threat timing consideration of not tipping off a subject prematurely.

Coordinating with legal and HR. This is a personnel matter as much as a technical one, and the timing of any access change or confrontation should be decided jointly with HR and legal, who understand the employment-law and evidentiary implications of each option.

Technical controls to prevent recurrence. Token scoping (limiting what any single credential can download in one action, rather than broad standing access to the full registry), data-loss-prevention monitoring specifically tuned to detect unusual bulk downloads of model artifacts, and applying least-privilege more aggressively to registry access so routine work doesn't require broad download rights in the first place.

Worked example

An unusual pattern emerges: a data scientist's API credential is used to download significantly more model artifacts, including several outside their current project, than their role would normally require, concentrated in the days following their resignation notice. Evidence: API logs are pulled immediately, confirming the specific artifacts and timestamps, and database access logs corroborate the pattern isn't a one-off anomaly. Containment: rather than immediately revoking all access (which could tip them off before HR has had a chance to plan the exit process and any necessary conversation), the credential's registry access is quietly scoped down to only what's needed for their remaining, legitimate handoff work. Legal and HR jointly decide on timing for a conversation, informed by the evidence gathered. Going forward, the organization implements token scoping so that any future bulk-download pattern like this one triggers an automated alert rather than requiring after-the-fact log analysis to notice.

Trade-offs and pitfalls

Immediately and visibly revoking all access the moment suspicion arises, without coordinating with HR and legal first, risks both tipping off the individual before evidence is fully preserved and creating unnecessary employment-law exposure if the explanation turns out to be legitimate. Relying solely on after-the-fact log review to catch this pattern, rather than building proactive detection (unusual-volume alerts, token scoping) into the platform, means the next instance of this exact behavior goes unnoticed until someone happens to look.

Brief answer / recommendation
Use symmetric AEAD (e.g., AES-GCM or ChaCha20-Poly1305) for the high-frequency path, combined with short‑lived per‑recipient session keys provisioned or wrapped by public-key ops only at key-establishment time. If nonce/IV misuse is a concern, use an AEAD with misuse-resistance (AES-GCM-SIV) or ChaCha20-Poly1305 with strict nonce management.

Trade-offs

• Throughput / Latency

  • Symmetric AEAD: very low latency and high throughput (hardware AES accel or software ChaCha20). Best for high-frequency messages.
  • Hybrid per-message (encrypt data with symmetric + encrypt symmetric key with recipient public key each time): higher CPU and latency due to public-key ops per message.
  • Public-key authenticated encryption (per-message): highest latency and CPU; impractical at scale for small, frequent messages.

• Key management complexity

  • Symmetric AEAD with session keys: moderate complexity (secure distribution/rotation required). Simpler runtime; scalable with a KMS or centralized key distributor.
  • Hybrid: simpler distribution semantics (each recipient has public key), but you still need to manage ephemeral symmetric keys per message — more complexity and CPU.
  • Pure public-key AE: simplest trust model (no shared secrets) but requires PKI, revocation, and heavier ops.

• Bandwidth

  • Symmetric AEAD: minimal overhead (author tag ~16 bytes + IV).
  • Hybrid/per-message public key: larger ciphertexts (key-wrapping blob per recipient adds bytes).

• Security properties

  • Confidentiality & integrity: AEAD provides both when used correctly.
  • Authentication: symmetric keys authenticate both sides; public-key auth encryption can provide non-repudiation if needed.
  • Replay/nonce risks: AES-GCM requires unique IVs; mitigate with counters or misuse-resistant AEAD.

Practical design (recommended)

• Use AEAD (AES-GCM with AES-NI or ChaCha20-Poly1305 for CPU-bound environments) for per-message encryption.
• Provision per-recipient session keys from a KMS or derive via HKDF from a short-lived master key. Rotate frequently (minutes–hours depending on threat model).
• Use public-key ops only for:
  • Initial session key establishment (e.g., ECDH) or
  • Wrapping rotated keys for long-term storage or cross-domain sharing.
• Enforce strict nonce strategy (counter per key) or choose misuse-resistant AEAD.
• Monitor metrics: CPU, latency percentiles, failed decrypts (nonce reuse), and KMS latency.

Justification
This hybrid operational model minimizes per-message latency and bandwidth overhead while keeping key distribution and rotation secure. It balances the Analyst’s operational needs: high throughput monitoring/alerting with strong confidentiality and auth, without the performance penalty of per-message public-key crypto.