Vulnerability Assessment and Penetration Testing Methodologies Questions
Deep understanding of the complementary roles, methodologies, and tooling for vulnerability assessment and penetration testing within a security program. Candidates should be able to explain that vulnerability assessment emphasizes systematic discovery and cataloging of weaknesses using automated scanners and targeted manual review, while penetration testing simulates realistic attack paths to validate controls end to end. Discuss scoping considerations, rules of engagement, expected deliverables and reporting styles, recommended cadence, when to choose one approach or to combine them, and how results from vulnerability assessment can inform targeted penetration testing. Cover common automated scanning tools and manual testing techniques, approaches to prioritizing findings based on business context and compensating controls, stakeholder communication and remediation tracking, and how to adapt or combine formal frameworks such as the Penetration Testing Execution Standard, the National Institute of Standards and Technology Special Publication eight hundred fifteen on technical security testing, and the Open Web Application Security Project testing guidance for network assessments, cloud infrastructure, application programming interface security, and internal testing.
HardTechnical
65 practiced
For a Kubernetes cluster security assessment, outline steps to evaluate the control plane, node and pod security, RBAC configuration, admission controllers, network policies, container image provenance, and runtime behavior. Describe how a misconfigured PodSecurityPolicy or permissive ServiceAccount can be exploited to gain access to the node or cluster.
Sample Answer
**Approach overview (high level)**I would run a layered assessment: control plane, nodes/pods, RBAC, admission controllers, network policies, image provenance, and runtime behavior — combining automated scans (kube-bench, kube-hunter, trivy), manual inspection, and exploitation attempts.**Control plane**- Check API server flags, unauthenticated endpoints, audit logging, etc.- Verify etcd access controls and TLS; try read-only access to etcd snapshots where permitted.**Node & pod security**- Inspect kubelet settings (anonymous auth, read-only port), hostPath mounts, privileged containers, CAP_SYS_ADMIN.- Use kubectl exec/attach to test lateral movement; attempt container escape primitives (mounting /proc, abusing ptrace, CVEs).**RBAC**- Inventory ClusterRoleBindings and ServiceAccounts with wide scopes.- Attempt privilege escalation via impersonation or token theft (read secrets via API).**Admission controllers**- Verify PodSecurity admission, PSP/PSA enforcement, and dynamic admission webhook behavior; bypass misconfigured webhooks.**Network policies**- Map pod-to-pod connectivity (calico/iptables) via port scans from pods; identify permissive all-allow policies.**Image provenance**- Scan images with trivy; check registries for unsigned images, use of latest tags, accessible private registries.**Runtime behavior**- Monitor processes, capabilities, syscalls; test detection by EDR; simulate persistence (create CronJobs/DaemonSets).**Exploit example: permissive PSP / ServiceAccount**- If PSP allows privileged containers or hostPath and a ServiceAccount is bound to cluster-admin, I would: 1) create a Pod using that SA with hostPath / and privileged true; 2) mount host filesystem and kubelet credentials (/var/lib/kubelet) to retrieve node creds; 3) use host namespace or docker/socket to run containers on host, escalate to root and pivot to other nodes or to the API server using stolen tokens.- If a ServiceAccount has TokenReview or secrets get, I can read other SA tokens and chain to cluster-admin.**Remediation highlights**- Enforce least privilege RBAC, restrict PSP/PSA to non-privileged, disable kubelet anonymous/read-only ports, enable audit logging, sign images, and enforce strict NetworkPolicies and admission webhooks.
HardSystem Design
76 practiced
Design a full penetration testing engagement plan for a cloud-native enterprise application that uses microservices, a service mesh, Kubernetes for orchestration, serverless functions for certain features, and an automated CI/CD pipeline. Define scope, threat models, test cases, allowed techniques, safety constraints, required logs and telemetry, and the expected format of deliverables and remediation tracking.
Sample Answer
**Scope (what I will test)** - In-scope: Kubernetes control plane and worker nodes, namespaces, microservice APIs, service mesh data/control planes (e.g., Istio), serverless functions (FaaS), CI/CD pipeline (build, artifact repo, deploy hooks), secrets/storage (Vault, K8s secrets), ingress/egress, IAM/policy configurations, observability endpoints. - Out-of-scope: vendor-managed cloud control plane operations, production data exfil beyond agreed limits (see safety).**Threat Models (attacker profiles & goals)** - Compromised developer workstation → supply-chain/backdoor in CI → production deploy. - Malicious internal user with dev privileges → lateral movement between namespaces. - External attacker exploiting service mesh misconfig/TLS gaps → API compromise. - Compromised function runtime → secrets exfiltration. - Privilege escalation from pod → node → cluster-admin.**Test Cases / Techniques** - Recon: cluster enumeration, kube-apiserver exposure, role bindings, admission controllers. - Configuration flaws: RBAC over-perms, PodSecurityPolicy/PSP bypass, weak network policies. - Service mesh: mTLS disabled, mis-routed traffic, control plane auth bypass, envoy filters. - Workload attacks: container escape, capability abuse, hostPath mounts, sidecar interaction. - Serverless: event trigger injection, insecure function packages, improper IAM roles. - CI/CD: insecure secrets in pipeline, artifact poisoning, webhook abuse, rollback attack. - Secrets: K8s secrets, Vault policies, IAM key rotation tests. - Exploitation: credential harvesting, lateral movement, chained exploits to cluster-admin. Allowed techniques: authenticated and unauthenticated tests, safe exploit proofs-of-concept, targeted payloads, simulated exfil using honeypot endpoints. Disallowed: destructive commands that delete PII, intentional downtime, brute-force that triggers alerts without consent.**Safety Constraints** - Testing windows, throttling limits, no destructive write/delete to production data, no exfil beyond 1MB to pre-approved sink, use test accounts and namespaces when possible, immediate stop on detected system instability, rollback plan with contacts.**Logs & Telemetry Required** - Kubernetes audit logs, control plane metrics, cloud provider audit (CloudTrail/Azure Activity), service mesh telemetry, container logs, CI/CD pipeline logs, Vault/audit logs, network flow logs, alerting outputs (SIEM). Provide timestamps, correlated IDs.**Deliverables & Remediation Tracking** - Executive summary (risk-focused), Technical report: finding description, evidence (screenshots/log snippets), exploit PoC (non-destructive), risk rating (CVSS + business impact), remediation steps and priorities, suggested mitigations (IaC policy, RBAC least-privilege, image signing, mTLS enforcement). - Appendix: test plan, tools used, commands. - Remediation tracking: issue tracker CSV/JSON with unique IDs, severity, owner, ETA, retest flag. Offer retest and verification steps and a 30/90-day follow-up retest.I will coordinate with stakeholders, sign rules-of-engagement, and maintain an audit trail of all actions.
MediumSystem Design
74 practiced
Design a remediation tracking and verification workflow for penetration testing findings that integrates with an issue tracker such as Jira. Include ticket fields, severity mapping, SLAs for fix and re-test, automation hooks for re-scan, evidence requirements for verification, stakeholder notifications, and audit logging.
Sample Answer
**Clarify requirements**- Track PT findings from discovery → verify remediation; integrate with Jira; support automation for rescans; provide audit trail and evidence for compliance.**High-level workflow**1. Create Jira ticket per finding (or group by asset/component).2. Triage → assign severity/SLA → remediation owner.3. Dev fixes → attach evidence → automated re-scan trigger → verifier closes ticket after validation.**Ticket fields (Jira)**- Summary, Description (POC, impacted host/port), Finding ID, CVE/CWE, Severity (Critical/High/Med/Low), Risk Rating (CVSS v3), Affected Component, Reporter, Assignee, SLA Due Date, Remediation ETA, Fix Commit/PR, Evidence (screenshots/logs), Re-test Job ID, Verification Status, Audit Log link, Linked Change Request.**Severity → SLA mapping**- Critical (CVSS ≥9): Fix 3 business days, Re-test 2 days- High (7–8.9): Fix 7 days, Re-test 3 days- Medium (4–6.9): Fix 30 days, Re-test 7 days- Low (<4): Fix 90 days, Re-test 14 days**Automation hooks**- On ticket creation: call vulnerability management API to record finding.- On status "Ready for Test": trigger CI/CD job (Nessus/OWASP ZAP/Custom PT script) via webhooks; store scan job ID in ticket.- On scan completion: webhook updates Re-test Job ID and provisional result; if pass → change Verification Status to "Verified"; if fail → reopen ticket.**Evidence requirements for verification**- Before re-test: remediation description, code/patch ref, configuration diff.- For verification: signed scan report (hash), screenshots, proof-of-fix test cases, logs showing exploit no longer reproducible.**Stakeholder notifications**- Jira watchers + email for status changes and SLA breaches; PagerDuty for Critical SLA misses; weekly digest for owners.**Audit logging & compliance**- Immutable append-only log (ELK/S3 with object versioning) capturing events: ticket create/update, webhook payloads, scan artifacts, user comments, verification decision, timestamps and actor IDs. Include hash of evidence artifacts stored on ticket.**Trade-offs**- Automated rescans speed verification but require safe test environments; manual verification for logic flaws or business logic issues.
EasyTechnical
72 practiced
You are preparing the Rules of Engagement (RoE) document for an external penetration test. Describe every essential element that must be agreed and documented before testing begins: scope boundaries, authorized IPs and assets, out-of-scope systems, time windows, allowed and disallowed techniques (e.g., destructive tests, social engineering), escalation contacts, legal approvals, and emergency stop conditions. Explain why each element matters.
Sample Answer
**Situation:** As the engagement pentester I ensure the Rules of Engagement (RoE) clearly reduce risk and legal exposure while enabling meaningful testing.**Essential RoE elements (what to document and why)**- **Scope boundaries** - Exact IP ranges, domains, subnets, applications, APIs, cloud tenants. - Why: prevents accidental testing of unrelated systems and defines blast radius.- **Authorized assets / IPs** - Whitelisted hosts, FQDNs, environments (prod/stage/dev) with versions. - Why: ensures only consented targets are probed and supports whitelisting in WAFs/IDS.- **Out-of-scope systems** - Third-party systems, partner networks, safety-critical devices (medical/SCADA), payment processors. - Why: avoids legal issues and prevents catastrophic impacts.- **Time windows / maintenance windows** - Test dates/times, timezone, blackout periods, expected monitoring windows. - Why: reduces operational disruption and coordinates with ops/on-call.- **Allowed techniques** - e.g., vulnerability scanning, credentialed checks, exploit verification limits. - Why: sets expectations for depth of testing and acceptable risk.- **Disallowed techniques** - e.g., destructive exploits, data exfiltration, denial-of-service, unsanctioned phishing/social engineering (unless authorized). - Why: prevents service outages, data loss, and legal/regulatory violations.- **Social engineering rules** - Whether phone, phishing, physical social engineering allowed; approved templates and targets. - Why: high risk for reputation/legal exposure; requires explicit consent.- **Escalation & contact list** - Primary/secondary technical contacts, legal, incident response, emergency 24/7 numbers. - Why: immediate coordination for suspected compromise or outages.- **Legal approvals & attestations** - Sign-off from legal, PO/contract, proof of authorization, NDA terms, data handling rules. - Why: provides legal cover and defines liability and data retention.- **Emergency stop / abort conditions** - Clear triggers (service degradation thresholds, data exposure, safety alerts), stop word/procedure, rollback expectations. - Why: ensures rapid halting to protect systems and safety.- **Reporting & evidence handling** - What logs/screenshots are allowed, sensitive data handling, timeline for deliverables. - Why: protects sensitive info and clarifies deliverable expectations.**Closing:** I always confirm RoE in writing with signatures, perform a kickoff call to review, and capture change control for any amendments during the test.
MediumTechnical
76 practiced
Explain how you would adapt OWASP testing guidance specifically to API security assessments. Cover testing areas such as authentication and authorization, token handling (JWT), rate limiting, input validation, parameter tampering, object-level authorization, and recommended tools and techniques for REST and GraphQL APIs.
Sample Answer
**Approach overview**I map OWASP API Top 10 controls to practical tests: focus on authn/authz, token handling, rate limits, input validation, parameter tampering, and object-level authorization. I combine automated scans with directed manual attacks and custom scripts.**Authentication & Authorization**- Test for weak creds, default accounts, credential stuffing, and MFA bypass. Use Burp Intruder, Hydra, and SSO replay with intercepted SAML/OIDC flows.- Verify role separation by exercising endpoints with different roles and expired/privilege-lifted sessions.**JWT / Token handling**- Inspect token contents (alg, kid) for none/alg=none flaws.- Test key confusion, signature bypass (change alg), token replay, reuse after logout, and tampering of claims (sub/roles/exp).- Tools: jwt.io, jwt-tool, Burp extensions (JWT auth).**Rate limiting & DoS**- Fuzz endpoints with increasing concurrency to find per-IP/user/global limits using JMeter, k6, or custom Python+asyncio. Check for slow endpoints (Slow POST) and missing global throttles.**Input validation & parameter tampering**- Fuzz JSON, headers, GraphQL queries. Try SQL/NoSQL injection, prototype pollution, path traversal. Use Burp Suite, ffuf, sqlmap, and GraphQLmap.- For GraphQL: enumerate schema via introspection, test complex queries, large depth, and resolver-specific auth checks.**Object-level authorization (IDOR)**- Enumerate predictable IDs, force access to other users’ objects, toggle ID formats, and test lateral movement via parameter substitution.**Techniques & tooling**- Burp Suite + Extender, Burp Collaborator, wfuzz/ffuf, sqlmap, jwt-tool, Postman, GraphQLmap, ZAP, nmap, custom Python scripts.- Combine automated discovery with manual logic testing and proof-of-concept exploitation; always document reproducer steps and remediation (least privilege, claim validation, signed tokens, input sanitization, strict rate limits, allowlist schemas).
Unlock Full Question Bank
Get access to hundreds of Vulnerability Assessment and Penetration Testing Methodologies interview questions and detailed answers.
