Knowledge of common security tool categories, their purpose, and how they are used within an organization. This includes Security Information and Event Management for centralized logging and alerting, Data Loss Prevention for controlling sensitive data exfiltration, Endpoint Detection and Response for workstation and server telemetry and remediation, vulnerability scanners and management platforms for identifying and tracking software and infrastructure weaknesses, firewalls and intrusion detection and prevention systems for network defense, and application security testing tools including Static Application Security Testing and Dynamic Application Security Testing. Candidates should be able to explain how each category works, typical deployment patterns, how to interpret tool outputs, how to prioritize findings, methods to reduce false positives, and how these tools fit into incident detection, vulnerability remediation, and compliance workflows.
EasyTechnical
56 practiced
Explain Endpoint Detection and Response (EDR): describe typical telemetry types EDR collects (processes, command line, file events, network connections, registry changes), how EDR differs from traditional antivirus, common remediation actions (isolate, kill process, rollback), and key deployment considerations for enterprise endpoints and servers.
Sample Answer
**What EDR is (brief)** I describe EDR as a platform that continuously records endpoint telemetry, detects suspicious behavior using analytics/rules, and enables investigation + automated or manual response to contain threats across desktops, laptops, and servers.**Typical telemetry EDR collects** - Processes: parent/child relationships, hashes, start/stop times - Command line: full args for process launches (useful for living-off-the-land) - File events: creates, writes, deletes, file hashes - Network connections: IPs, ports, process owning connection, DNS queries - Registry changes: keys created/modified/removed (Windows) - Additional: DLL loads, driver installs, memory artifacts, scheduled tasks**How EDR differs from traditional AV** - AV: signature-based, focused on known malware prevention. - EDR: behavior and telemetry-driven detection, retrospective hunt, richer context for investigations, supports rollback and containment.**Common remediation actions** - Isolate endpoint from network (full/quarantine) - Kill malicious process and block executable/hash - Remove/quarantine files and delete persistence (scheduled tasks, services, registry keys) - Rollback changes (file restore, registry restore) where supported - Trigger forensic capture and ticketing**Key deployment considerations** - Coverage: deploy to all user endpoints and critical servers; consider offline agents for disconnected hosts - Performance: lightweight agent, tuning to avoid noisy telemetry costs - Integration: feed alerts to SIEM/SOAR, central logging, identity context (AD), and patch management - Policy & tuning: detection rules, allowlists, and retention windows for telemetry - Testing & runbooks: validate isolation, rollback, and escalation playbooks before incidentsI’d emphasize tuning alerts, ensuring server agents respect uptime/availability policies, and having clear escalation steps tied to SOC processes.
HardTechnical
112 practiced
Create a Sigma rule or YARA-like detection that combines multiple conditions to detect a malware campaign that persists via scheduled tasks and performs C2 beacons using base64-encoded HTTP POSTs: provide the detection logic in pseudo-YAML or pseudo-signature form, explain mapping to Splunk or EDR query fields, and discuss performance considerations when running this rule at scale.
**Mapping to Splunk / EDR fields**- Scheduled task creation: Splunk sourcetypes "WinEventLog:Security" EventCode 4698 -> fields: TaskName, SubjectUserName.- Process creation: Sysmon EventID 1 -> NewProcessName, CommandLine, ParentImage.- HTTP POST / C2: proxy or WAF logs, Zeek/HTTP logs -> method (http.method), http.user_agent, http.request_body. Use rex to extract base64: rex field=request_body "(?<b64>(?:[A-Za-z0-9+/]{4}){3,}={0,2})".- Correlation: join by src_ip, dst_ip, process_guid, or host (host, ComputerName).**Performance considerations at scale**- Prefer steering detection to indexed fields (http.method, EventID) to avoid full-text scans.- Use regex sparingly; restrict with prefilters (http.method=POST and content-length>200).- Run heavy regex in dedicated parsing or enrichment pipeline (e.g., ingest-time or scheduled analytics) rather than high-frequency streaming searches.- Implement lookback windows (e.g., 24h) and aggregate by host/IP to reduce cardinality.- Use sampling for threat hunting; escalate to full scan only on correlated indicators (task creation + suspicious process).- Monitor false positives and tune TaskName/UA patterns; consider threat intel for known C2 URIs.I would implement this as a correlation rule in the SIEM that first filters indexed fields, then performs regex/extraction and host-IP joins in a second stage to balance detection fidelity and performance.
MediumTechnical
64 practiced
Your vulnerability management system surfaces many duplicate findings for the same underlying issue across multiple hosts and scan dates, producing ticket overload. Propose an operational plan to deduplicate and normalize findings, including canonical asset identifiers, vulnerability fingerprinting, merge/aggregation rules, and validation steps to ensure deduplication does not obscure unique risks.
Sample Answer
**Clarify goals & constraints**- Reduce ticket noise while preserving unique risk context, preserve SLA routing, and keep audit trail.**Framework / Approach**1. Inventory normalization - Build canonical asset ID (asset-tag + stable attributes: MAC, UUID, cloud instance-id, primary FQDN). Source of truth: CMDB; fallback rules for NetBIOS/IP mapping.2. Vulnerability fingerprinting - Create deterministic fingerprint: concatenate vendor/product (CPE), version, vulnerability id (CVE), vuln-type (RCE/priv-esc), and scanner-evidence hash (e.g., first 256 bits of proof). Example: SHA256("cpe:/a:nginx:nginx:1.18|CVE-2020-1234|RCE|resp-headers").3. Merge/aggregation rules - Merge findings with identical fingerprint across assets into one vulnerability entity with per-asset instances. - Aggregate repeat findings on same asset/time-window (e.g., 30 days) into open ticket; append occurrences to ticket comments. - Preserve exceptions: differing ports, protocol, exploitability, or unique evidence remain separate.4. Validation & monitoring - Backtest on 90-day historical data; compare ticket volume, time-to-remediate, and false merge rate. - Manual review sample (statistically significant) weekly for first 8 weeks. - Alerts when aggregation would close a ticket that had active remediation tasks.5. Implementation & ops - CI: deploy rules as reversible feature flags; maintain immutable raw findings store; log merge lineage (source IDs -> canonical). - KPIs: tickets/day, duplicates reduced, missed-unique-risk incidents.Rationale: canonical IDs + deterministic fingerprints ensure identical root causes merge while evidence/port/exploitability exceptions prevent masking real differences.
EasyTechnical
69 practiced
List and explain common techniques an analyst can use to reduce false positives emitted by security tools (SIEM, IDS/IPS, DLP, EDR), including contextual enrichment, whitelisting/scoped exceptions, threshold tuning, reputation scoring, implementing feedback loops from analysts, and testing in pre-production environments.
Sample Answer
**Brief framing (role):** As an Information Security Analyst I focus on reducing false positives so SOC time is spent on true threats. Common, practical techniques:**Contextual enrichment**- Add asset criticality, user role, geolocation, process ancestry, vulnerability status to alerts so rules can consider context (e.g., admin travel vs. risky nation).**Whitelisting / scoped exceptions**- Create narrow exceptions for known benign sources (specific IPs, processes, service accounts) with expiration and review to avoid blind spots.**Threshold tuning**- Raise counts/duration triggers or require multiple correlated events (e.g., X failed logins within Y minutes + unusual source) to prevent noisy single-event alerts.**Reputation scoring**- Incorporate IP/domain/file reputation and threat intelligence feeds; only promote alerts above a risk score threshold.**Feedback loops from analysts**- Record analyst dispositions and automate learning (rule adjustments, tag suppression); maintain runbook for repeated false-positive patterns.**Pre-production testing**- Validate rules/rule changes against replayed logs or synthetic traffic in staging before prod rollout.Measure success with alert volume, true-positive rate, mean time to detect, and periodic review.
MediumSystem Design
53 practiced
Design a log retention policy for security logs in a cloud environment that balances forensic needs, compliance requirements (example: PCI, HIPAA), and storage costs: include retention tiers (hot/warm/cold/archival), indexing strategies, encryption-at-rest, access controls, and sample retention durations for different log types (auth, network, application, cloud-audit).
Sample Answer
**Clarify requirements**- Preserve forensic fidelity, meet PCI/HIPAA minima, minimize cost, enable fast search for incidents, support legal hold.**High-level design**- Tiered retention: Hot (SIEM indexed), Warm (nearline), Cold (object blob), Archival (WORM).- Encryption-at-rest using KMS with separate keys per environment; TLS in transit.- RBAC + MFA + privileged access logging; least privilege to SIEM/query roles; break-glass process with approval and audit.**Retention tiers & durations (samples)**- Auth logs (failed/successful login): Hot 90 days, Warm 1 year, Cold 7 years, Archive 10+ years (PCI: 1 year accessible, HIPAA: 6 years)- Network flow (netflow, VPC flow): Hot 30 days, Warm 6 months, Cold 3 years- Application logs (business logic): Hot 30–90 days, Warm 1 year, Cold 3–7 years- Cloud-audit (IAM changes, config): Hot 365 days, Warm 3 years, Cold 7 years**Indexing strategy**- Full indexing in Hot for recent 30–90 days; fielded/inverted indexes for auth, src/dst, user, event_type.- Warm: reduced indexes (timestamp + keys) for faster restores; Cold: no index, use manifest/catalog and on-demand rehydration.**Access & monitoring**- SIEM alerts for retention policy violations; automated lifecycle policies to move data; immutable storage for archive (WORM); periodic key rotation and key access audits.**Trade-offs**- More indexing increases cost but speeds investigations. Use adaptive indexing and compression to balance.
Unlock Full Question Bank
Get access to hundreds of Security Tools and Technologies interview questions and detailed answers.
