Comprehensive knowledge of the Open Web Application Security Project Top Ten categories and the Common Weakness Enumeration Top Twenty Five weaknesses, focused on identification, exploitation mechanisms, root causes, business impact, and prevention. Candidates should understand each vulnerability class in depth, including injection, broken authentication and authorization, cross site scripting, cross site request forgery, security misconfiguration, insecure design, vulnerable and outdated components, cryptographic and data integrity failures, logging and monitoring gaps, server side request forgery, and related common weakness patterns. Assessment covers how to find these issues in source code and running applications, how attacks are constructed, secure coding fixes and remediation, threat modeling and secure design choices to prevent them, use of static and dynamic analysis and dependency scanning tools, vulnerability prioritization and patching strategies, and runtime detection and monitoring practices. Candidates should be able to explain concrete code examples, demonstrate fixes, and map specific code patterns to CWE entries when relevant.
HardTechnical
43 practiced
Discuss limitations of CVSS when prioritizing OWASP/CWE issues across the enterprise. Propose an enterprise-weighted risk model that supplements CVSS with exploit maturity, business asset criticality, internet exposure, detection coverage, and compensating controls. Provide a sample scoring formula or category breakdown.
Sample Answer
**Limitations of CVSS (from a Security Architect view)** - CVSS focuses on technical severity (impact/complexity) but omits business context: asset value, regulatory impact, compensating controls. - It doesn't capture exploit maturity or active threat intelligence well. - Lacks visibility into detection and response capability (means prioritization may overload SOC). - Not designed for enterprise-wide prioritization across OWASP/CWE categories.**Enterprise-weighted risk model (concept)** Use CVSS Base as technical baseline, then multiply by contextual modifiers: Exploit Maturity (E), Asset Criticality (A), Internet Exposure (I), Detection Coverage (D), Compensating Controls (C). Normalize to 0–100.**Sample scoring formula**
- BaseNorm = CVSS_base / 10 (0.0–1.0) - E,A,I,D,C between 0.0–1.0 (higher = more risk, except D/C where higher reduces risk) - Example weights: Wb=50, W_e=0.6, W_a=1.2, W_i=0.8, W_d=0.7, W_c=0.9 (tune to org risk appetite)**Category thresholds (0–100)** - 75–100: Immediate remediation (patch/compensating controls + SLA 7 days) - 50–74: High — schedule within 30 days + monitoring - 25–49: Medium — patch in next cycle, validate detection - 0–24: Low — track and exception if mitigated**Implementation notes** - Populate A from CMDB (business impact scoring), E from threat feeds (proof-of-concept =1.0, PoC-only=0.6, theoretical=0.2), I from exposure scan, D from SOC playbook coverage metrics, C from control effectiveness testing. - Periodically calibrate weights with risk committee; automate calculation in ticketing/VM platforms.
MediumTechnical
44 practiced
You must map common insecure code patterns to specific CWEs so the security team can tune SAST rules. Describe an approach for identifying patterns, mapping them to CWEs (examples: use of eval, unsanitized format strings, unsafe deserialization), and integrating the mapping into developer remediation workflows.
Sample Answer
**Approach overview**I would treat this as a repeatable pipeline: discovery → canonicalization → mapping → validation → integration into developer workflows.**1) Identify common insecure patterns**- Collect SAST alerts, incident post-mortems, PR review comments, and OWASP top issues.- Mine codebases with token/AST pattern searches and regex for hotspots (e.g., use of eval, format strings, deserialization APIs).- Prioritize by exploitability, occurrence frequency, and business impact.**2) Canonicalize and map to CWEs**- For each pattern create a canonical descriptor (AST snippet, taint-flow signature, example code).- Map to authoritative CWE entries (examples): - use of eval with untrusted input → CWE-95 (Improper Neutralization of Directives/Commands) - unsanitized format strings (printf/format) → CWE-134 (Use of Externally-Controlled Format String) - unsafe deserialization (Java/ObjectInputStream) → CWE-502 (Deserialization of Untrusted Data)- Store mappings in a machine-readable registry (YAML/JSON) with severity, exploitability notes, and example fixes.**3) Validate and tune SAST rules**- Convert signatures into precise SAST rules (AST/taint-based) and run on representative code to measure TPR/FPR.- Iterate rule precision, add suppressions for false positives, and include CWE ID in rule metadata.**4) Integrate into developer remediation workflows**- Surface findings in PR checks and CI with clear CWE, vulnerable code snippet, recommended fix, and one-click links to secure-code examples.- Auto-create or link tickets in tracking systems when critical (include CWE, risk rationale).- Feed patterns into secure coding training, cheat-sheets, and pre-commit hooks.- Track metrics: time-to-remediate, recurrence rate by CWE, rule precision.This approach ensures traceability from concrete code pattern to CWE and operationalizes remediation across SAST, CI, and developer training.
MediumTechnical
40 practiced
How would you integrate external threat intelligence feeds into your vulnerability prioritization and incident response workflows? Describe ingestion, enrichment (asset mapping, CVSS, exploit maturity), alerting thresholds, and automated SOAR playbooks for high-confidence threats.
Sample Answer
**Clarify goals & constraints**- Prioritize actionable threats that reduce risk to crown-jewel assets, minimize false positives, and enable rapid containment with measurable SLAs.**Ingestion**- Consolidate feeds via a TI platform (MISP/Recorded Future/Anomali) or MSSP API gateway.- Normalize to STIX2/TAXII; deduplicate by IOC hash, CVE, TTP id (ATT&CK).- Store raw and normalized records in searchable DB with provenance and confidence scoring.**Enrichment**- Asset mapping: join IOCs/CVEs to CMDB/CMDB-backed asset inventory using IPs, hostnames, app tags, business owner, and exposure (internet-facing).- CVSS: ingest vendor CVSSv3, translate to risk score adjusted by asset criticality (weighted formula).- Exploit maturity: add fields for exploit availability (PoC, exploit in-the-wild, exploitability index) and attacker interest (darknet chatter).- Produce final risk = f(CVSS, asset_criticality, exploit_maturity, intelligence_confidence).**Alerting thresholds**- Define tiers: High (risk > 8 and asset_criticality high + exploit in-the-wild) → immediate SOC alert + auto-containment; Medium → ticket to vuln mgmt with SLA 7 days; Low → passive monitoring.- Use adaptive thresholds: increase sensitivity for internet-facing or critical business services.**Automated SOAR playbooks**- High-confidence playbook: 1. Enrich alert with Endpoint context (EDR), network telemetry, user identity. 2. If IOC confirmed on high-value asset → quarantine host, block IOCs on firewall/proxy, create incident ticket, notify owners. 3. Kick off patch/remediation workflow in ITSM and schedule forensic snapshot. 4. Log actions, update TI platform (feedback loop).- Medium/Low playbooks: create vuln ticket, schedule scan, monitor for exploit signs; escalate if new intelligence raises exploit maturity.**Metrics & governance**- Track MTTR, false-positive rate, percent of critical assets covered, and feedback loop accuracy. Regularly tune thresholds and validate feeds.
EasyTechnical
45 practiced
You receive an automated scan that flags many findings across projects including 'SQL Injection', 'Outdated Library', and 'Missing Secure Headers'. Describe a triage and prioritization approach for thousands of findings with limited remediation capacity. What criteria and compensating controls do you use?
Sample Answer
**Approach — high level**I first convert raw scan output into an actionable backlog: normalize findings, deduplicate by asset/endpoint, and enrich with context (asset criticality, exposure, exploit maturity).**Triage steps**1. Filter by exposure: - Internet-facing and customer-facing apps get top priority.2. Risk scoring: - Combine CVSS, CWE/OWASP category (e.g., SQLi = OWASP A1), and business impact (data sensitivity, uptime).3. Exploitability & maturity: - Prioritize findings with public PoC, active exploits, or high ease-of-exploit (SQLi > outdated header).4. Compensating controls & compensations window: - If immediate patching impossible, require WAF rules, network ACLs, IPS signatures, or microsegmentation.5. Remediation runway: - Group similar findings (library versions, missing headers) and plan bulk fixes or platform-level mitigations.**Prioritization criteria (ordered)**- Exposure (internet-facing) - Exploit maturity (PoC/active exploit) - Business impact (PII/financial systems) - CVSS temporal factors (availability of exploit) - Remediation cost/time and blast radius**Compensating controls (examples)**- SQL Injection: WAF rules, parameterized queries enforcement, input validation, DB permissions tightening, monitoring/alerts for anomalous queries.- Outdated library: Virtual patch via WAF, isolate service, plan dependency update pipeline with automated tests.- Missing headers: App gateway insert headers (HSTS, X-Frame-Options, CSP) centrally; CDN or load balancer fixes.**Governance**- Define SLA tiers (72h critical, 2 weeks high, 90 days low) and track through ticketing with risk acceptance for any deviations. Use dashboards for exec visibility and continuous reassessment based on new threat intel.
HardTechnical
33 practiced
An external penetration test revealed a chained attack: SSRF to internal service -> access to internal metadata service -> retrieval of IAM credentials -> using those credentials to access an internal admin API and perform SQL injection. As Security Architect, produce detection, containment and remediation steps, and an incident-response playbook for this chain.
Sample Answer
**Situation summary (1 line)**Chained external SSRF → internal metadata service exfil of IAM creds → use creds to call internal admin API → SQL injection against DB.**Detection**- Network: alerts for unusual internal-to-internal calls from public-facing app; lateral flow to 169.254.169.254 (IMDS) or cloud metadata endpoints.- Identity: spikes in STS/GetSessionToken or AssumeRole from unexpected source IPs; new long-lived keys creation.- Application: anomalous admin-API calls (privileged endpoints) from service principal; high-rate or malformed SQL payloads; WAF/IDS SQLi signatures.- Data: unusual data exports, large SELECTs, or schema enumeration patterns.**Containment**- Immediate: revoke compromised IAM credentials (temporary tokens + access keys) and rotate; block source IPs and disable affected service accounts/roles.- Network: apply ACLs to block access from public-facing app to internal metadata endpoints; isolate impacted hosts/subnets.- Application: disable/rollback the vulnerable endpoint, deploy WAF rules to block SSRF and SQLi patterns.**Remediation**- Fix SSRF: input validation, allowlist outbound hostnames, egress proxy with URL parse and block metadata addresses; implement DNS and HTTP allowlists.- Harden metadata access: enable IMDSv2 (require session token), enforce IAM role session policies and least privilege, shorten token TTL.- Fix SQLi: parameterized queries, ORM use, query whitelisting, input validation and prepared statements.- IAM: enforce MFA, credential rotation, long-term key audits, role separation, and monitoring.- Deploy runtime protections: eBPF-based network policies, WAF, RASP for admin APIs.**Incident-response playbook (play-by-step)**1. Triage: confirm chain (logs: web, proxy, IAM, API, DB), mark scope.2. Contain: revoke creds, isolate host, block metadata access, suspend affected roles.3. Eradicate: patch SSRF and SQLi bugs, enable IMDSv2, rotate all secrets in scope.4. Recover: restore from safe backup, re-enable services after verification, monitor closely.5. Post-incident: root-cause report, update threat model, run adversary simulation, improve detection rules, exec briefing and adjust SLA/controls.**Metrics & governance**- Time-to-detect, time-to-contain, number of rotated credentials, replayed attack prevented. Review in quarterly risk board and embed fixes into architecture standards.
Unlock Full Question Bank
Get access to hundreds of OWASP Top Ten and CWE Top Twenty Five interview questions and detailed answers.
