MediumTechnical

39 practiced

You must collect forensic evidence from a remote contractor laptop subject to a legal hold while the device is located in another country. Describe how you would document chain of custody, perform secure remote collection, maintain integrity and provenance of evidence, and address jurisdictional or legal constraints that could affect admissibility.

Sample Answer

**Situation & high-level approach**I would treat the laptop as evidence under legal hold and follow forensically sound remote-collection procedures: document chain of custody, perform secure remote acquisition with verified tools, preserve integrity/provenance, and engage legal counsel for cross-border constraints.

**Chain of custody & documentation**- Create an evidence form recording: item ID, owner, device make/model, serial, IP, geolocation, date/time (UTC), reason for collection, legal hold reference, collecting analyst, receiving custodian.- Log every access/change with immutable entries (append-only log) and sign entries with analyst’s PGP key or enterprise HSM.- Photograph screen/desktop remotely (if allowed) and record live-session video when practical.- Retain copies of authorizations: legal hold notices, warrants, consents, and communications with local counsel.

**Secure remote collection & integrity**- Pre-authorize a collection plan with legal: scope, data types (volatile vs persistent), and timeframe.- Establish a secure channel (site-to-site VPN or WireGuard + mutual certs) and use a hardened, patched forensic workstation.- Prefer agentless imaging where possible (remote FTK Imager / Magnet ACQUIRE, Linux dd over SSH with pv) or deploy a vetted, signed remote forensics agent. Always use read-only methods; if live response required, document reasons and steps.- Capture volatile data first (RAM, network connections, process list) using trusted tools (LiME, Volatility schemas), then acquire full disk image.- Compute cryptographic hashes (SHA-256 and SHA-512) on-source and on-copy; record hashes, tool versions, and commands. Sign final hash with enterprise key.

**Preserving provenance**- Store images in WORM or S3 with Object Lock; record storage location, access controls, and retention.- Maintain original device state: do not alter disk contents beyond necessary live collection; document any changes.- Validate images by re-hashing and independent verification by a second analyst; include verification logs in chain-of-custody.

**Jurisdictional/legal constraints**- Consult internal counsel and local counsel immediately to confirm lawfulness (consent, warrant, MLAT, data sovereignty).- If local law prohibits remote access, coordinate with local authorities or request the device be imaged onsite by an approved third party; obtain judicial orders as required.- Limit transfer of data across borders where prohibited; consider processing data in-region or using privacy-preserving techniques (review and filter in-country, then export extracts with redaction).- Document all legal advice and authorization to defend admissibility.

**Standards & admissibility**- Follow NIST SP 800-86/800-101 and ISO 27037 guidance; preserve metadata, timestamps, tool logs, and analyst signatures to support authenticity and chain of custody in court.- Prepare an evidence report summarizing methods, tools, hashes, verification steps, and legal authorizations; be ready to testify to chain-of-custody and technical choices.

This approach ensures forensic soundness, reproducibility, and legal defensibility while respecting cross-border constraints.

MediumTechnical

27 practiced

Write a Splunk SPL query or Elastic KQL that identifies potential credential stuffing by finding source IPs that attempted logins across more than 10 distinct usernames within a 10-minute window, excluding a list of known internal IP ranges. Provide the query and briefly explain performance considerations and ways to reduce false positives.

Sample Answer

**Approach (brief)** Count distinct usernames per source IP in 10-minute rolling windows, exclude internal IP ranges, alert when >10 usernames. Use event timestamps and lightweight aggregations.

**Splunk SPL**

spl

index=auth sourcetype=auth_logs (action=login OR event=login) 
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| bin _time span=10m
| stats dc(username) as distinct_users earliest(_time) as window_start by src_ip _time
| where distinct_users > 10
| sort - distinct_users

**Elastic KQL / Elasticsearch DSL (KQL for Kibana + agg example)**

text

# Kibana Discover filter:
event.type: "login" and not ip.src: ("10.0.0.0/8" or "192.168.0.0/16")
# Use a terms + cardinality aggregation:
# in Dev Tools (DSL) aggregate by date_histogram (10m) -> terms src.ip -> cardinality of user.name > 10

**Performance considerations**- Limit time range and use indexed fields (src_ip, username, event.type). - Use bin/date_histogram to reduce cardinality churn. - In Splunk, use tstats for accelerated datasets if available.

**Reducing false positives**- Exclude known automation/bastion IPs, VPN/proxy ranges, and legitimate SSO/IPs. - Require failed login events only, or weight by failure ratio. - Correlate with geo-velocity, user agent diversity, or threat intel on IPs before alerting.

EasyTechnical

38 practiced

List and categorize common detection sources an analyst uses to identify incidents (for example: EDR telemetry, firewall logs, authentication logs, cloud audit logs, IDS alerts, user reports). For each source explain one example of a signal that could indicate a true incident and one common limitation or noise source for that detection source.

Sample Answer

**Overview — categories:** Endpoint, Network/Perimeter, Identity/Authentication, Cloud/Platform, Detection systems, Human/Business.

**Endpoint (EDR telemetry)**- Signal: Unusual parent-child process chains (e.g., cmd.exe spawned by msiexec) combined with network beaconing → possible lateral movement/implant.- Limitation/noise: Legitimate admin tools (PsExec, RMM) create similar chains; false positives without allowlist/context.

**Network / Perimeter (firewall, NGFW logs, proxy)**- Signal: Large data exfiltration to uncommon external IPs or spikes in outbound connections on nonstandard ports.- Limitation/noise: Cloud backups, SaaS syncs, or CDN usage can mimic exfil; need baselining.

**Network IDS/IPS**- Signal: Repeated signature hits for known exploit (e.g., MS-SQL exploit) from same source plus subsequent shell-like traffic.- Limitation/noise: Signature tuning gaps and encrypted traffic hide payloads; IDS evasion and false positives from scanners.

**Identity / Authentication logs (AD, Okta)**- Signal: Impossible travel or successful logins from new geo/IP immediately after password reset; vertical privilege escalation events.- Limitation/noise: VPN/proxy use, SSO federation changes, or legitimate traveling employees.

**Cloud audit logs (AWS CloudTrail, GCP)**- Signal: Creation of new IAM keys, privilege escalation API calls, or unusual region-specific resource creation.- Limitation/noise: Automation/CI pipelines and IaC deployments generate similar events; need correlation with owner/process.

**SIEM / Detection alerts (correlated alerts, threat intel)**- Signal: Correlated indicators (IOC hits + anomalous behavior + asset criticality) raising confidence score.- Limitation/noise: Poorly tuned correlation rules create alert storms; stale intel causes noise.

**User reports / Helpdesk**- Signal: Multiple users reporting password resets, locked accounts, or strange emails indicating phishing success.- Limitation/noise: Human error, training issues, or user misunderstanding; requires validation.

For each source, correlate enrichments (threat intel, asset context, baselines) to reduce noise and raise signal confidence.

HardTechnical

32 practiced

A third-party CI pipeline that your teams consume is suspected of injecting malicious code into a widely used dependency. Describe how you would detect which internal builds consumed the compromised artifact, contain distribution, verify integrity of binaries across environments, rotate build credentials, rebuild affected artifacts securely, and coordinate disclosure with the vendor and downstream customers.

Sample Answer

**Situation & goal**I would treat this as a high-severity supply‑chain incident: detect scope, stop further spread, verify integrity, remediate builds, rotate credentials, and coordinate disclosure.

**1) Detect which builds consumed the compromised artifact**- Query artifact metadata and provenance: search internal artifact registries (Artifactory/Nexus/AWS CodeArtifact) for the compromised artifact name + version.- Cross‑reference CI artifacts by querying build metadata / SBOMs (CycloneDX/ SPDX) and CI run logs (GitLab/GitHub Actions/Buildkite) for dependency downloads.- Use centralized telemetry: EDR, network proxy logs, and package manager caches to find hosts/build agents that fetched the artifact.- Produce an initial compromise list (build IDs, commit hashes, timestamps).

**2) Contain distribution**- Immediately remove or mark the compromised artifact as vulnerable in registries; implement immutable denylisting and orchestrator image policy (OPA/Gatekeeper) to block pulls.- Suspend or isolate affected CI runners and image registries pending investigation.- Deploy network controls (firewall/proxy) to prevent external distribution.

**3) Verify integrity of binaries across environments**- Collect hashes (SHA256) and signatures from suspected binaries.- Compare against known-good baselines: git commit signed artifacts, reproducible build outputs, archived golden images, or vendor signatures.- Use reproducible-build techniques: rebuild from pinned source and compare byte-for-byte or deterministic checksums.- Run static/dynamic analysis (YARA, binary diffing, strace sandbox) to detect injected behavior.

**4) Rotate build credentials**- Immediately revoke CI tokens, service principals, and short‑lived keys used by the compromised pipeline; revoke in IAM (AWS/GCP/Azure) and CI secrets manager.- Issue new credentials with least privilege and enforce ephemeral credentials via OIDC or short-lived role assumption.- Audit audit logs for lateral movement or exfiltration.

**5) Rebuild affected artifacts securely**- Establish a clean build environment (ephemeral runners with fresh images, air‑gapped where necessary).- Pin all inputs (source commit, compiler versions, dependency checksums) and enable reproducible build flags.- Sign new artifacts with organization’s key (hardware security module / cloud KMS) and publish SBOMs and signatures.- Run CI security gates: SCA, SAST, binary signing verification.

**6) Coordinate disclosure with vendor & downstream customers**- Notify the third‑party vendor immediately with IOCs, hashes, timelines; request root cause and mitigation.- Prepare coordinated disclosure: draft customer notification, recommended remediations, and indicators of compromise.- Engage legal/PR and provide clear remediation steps (revoke tokens, update pinned versions, install replacement artifacts).- If appropriate, file a CVE and share timelines under coordinated vulnerability disclosure best practices.

**Lessons & controls to prevent recurrence**- Enforce SBOM generation, reproducible builds, artifact attestation (Sigstore/rekor), ephemeral CI credentials (OIDC), runtime allowlists, and continuous integrity monitoring.

MediumTechnical

35 practiced

After malware eradication and restoring systems from backups, provide a practical validation checklist you would run to ensure systems are clean, integrity is intact, and services are safe to return to production. Include automated checks, manual verification steps, and acceptance criteria.

Security Incident Response Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank