Security Architecture Principles and Fundamentals Questions

Core principles and foundational knowledge for designing secure systems and architectures. Candidates should understand defense in depth, zero trust, least privilege, separation of duties, secure by design and fail secure thinking. Topics include attack surface reduction, secure defaults, threat modeling methodologies and how to translate high level principles into concrete controls. Coverage includes access control models such as role based and attribute based approaches, authentication and authorization architectures, secrets and key management basics, classification of controls as preventive, detective, or corrective, and integration of controls across identity, network, host, application, and data layers. Expect discussion of how to prioritize security requirements, make trade offs between security, performance, cost, and usability, and incorporate security requirements into the system development lifecycle.

EasyTechnical

71 practiced

Define 'least privilege' and 'separation of duties'. Describe three practical checks you would perform during a penetration test across cloud IAM, service accounts, and on-prem administrative roles to validate adherence to these principles.

MediumTechnical

69 practiced

Write a non-destructive Python 3 script (pseudocode or actual code) to scan a given CIDR for typical management ports (SSH, RDP, Kubernetes API, Docker API) and perform basic service fingerprinting (banner grab). The script should respect rate limits, avoid brute force, and output a CSV of host, open-ports, and banners. Explain safety precautions to avoid causing disruption.

Sample Answer

**Approach**- Use TCP connect scans to avoid SYN floods and raw sockets. Rate-limit per-host and overall. For each host in CIDR, attempt connect to management ports and read small banner non-destructively.

**Sample Python 3 (actual code)**

python

#!/usr/bin/env python3
import socket, csv, ipaddress, time
from collections import defaultdict

PORTS = {22:"SSH", 3389:"RDP", 6443:"K8S-API", 2375:"Docker-API"}
TIMEOUT = 3.0
DELAY_BETWEEN_CONN = 0.05  # 20 conn/sec overall
PER_HOST_DELAY = 0.1

def probe(addr, port):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(TIMEOUT)
    try:
        s.connect((addr, port))
        # try small recv for banner; don't send anything (non-destructive)
        try:
            b = s.recv(1024)
            return b.decode(errors="replace").strip()
        except socket.timeout:
            return ""
    except Exception:
        return None
    finally:
        s.close()

def scan_cidr(cidr, out_csv):
    results = []
    for ip in ipaddress.IPv4Network(cidr):
        ip=str(ip)
        openp=[]
        banners=defaultdict(str)
        for p in PORTS:
            res = probe(ip, p)
            if res is None:
                pass
            else:
                openp.append(str(p))
                banners[str(p)] = res
            time.sleep(DELAY_BETWEEN_CONN)
        if openp:
            results.append((ip, ";".join(openp), "|".join(f"{k}:{v}" for k,v in banners.items())))
        time.sleep(PER_HOST_DELAY)
    with open(out_csv,"w",newline="") as f:
        w=csv.writer(f)
        w.writerow(["host","open_ports","banners"])
        w.writerows(results)

if __name__ == "__main__":
    scan_cidr("192.0.2.0/29","scan_results.csv")

**Explanation & reasoning**- Uses TCP connect() (no raw packets) to keep traffic benign.- Reads only a small recv; doesn't authenticate or send protocol commands to avoid causing changes.- Rate limits (DELAY_BETWEEN_CONN, PER_HOST_DELAY) to avoid DoS and respect target capacity.- Outputs CSV: host, open_ports (semicolon), banners (pipe-separated port:banner).

**Safety precautions (must mention during engagement)**- Obtain written authorization and scope.- Confirm business hours, maintenance windows, and out-of-scope IPs.- Start with low rate, monitor for service degradation, have a kill-switch.- Avoid brute force, exploitation, or attempts to authenticate.- Log all actions and share findings responsibly.

EasyTechnical

84 practiced

Define attack surface reduction and secure defaults. For three environments (a public Kubernetes cluster, a public HTTP API, and a corporate VPN gateway), give two secure default settings each and describe automated checks or lightweight pentest probes you would run to confirm those defaults are present.

MediumSystem Design

139 practiced

You are handed an architecture diagram for a cloud-based web application: public CDN, API gateway, stateless microservices in private subnets, RDS databases, and S3 for object storage. The diagram shows an IAM role with wide S3 permissions attached to multiple services. Identify likely misconfigurations and produce a prioritized pentest plan (area-by-area) to validate and exploit them where possible.

Sample Answer

**High-level issues (likely misconfigurations)**- Over‑privileged IAM role shared across services (wide S3 perms).- Public CDN + API Gateway: insufficient auth/authorizers, broken CORS, excessive methods.- Microservices in private subnets may still access RDS/S3 with broad network ACLs/security groups.- S3 buckets possibly misconfigured (public ACLs, bucket policies, object ACL inheritance).- RDS exposure via mis-scoped SGs or weak DB credentials.

**Prioritized pentest plan (area-by-area)**

1) IAM & role abuse — Highest priority- Goal: validate ability to read/write S3, assume/chain roles, exfiltrate.- Tests: enumerate attached roles/policies via metadata endpoints (EC2/ECS/EKS), probe for instance/task metadata SSRF/SSM endpoints; attempt sts:GetCallerIdentity using leaked creds; attempt sts:AssumeRole if trust policy allows.- Exploits: use obtained temporary creds with awscli to list/read/write S3 buckets, create backdoor objects, test policy boundaries (s3:PutObjectAcl).- Tools: curl, awscli, boto3.

2) S3 object storage- Goal: discover public buckets, ACL weaknesses, object enumeration.- Tests: bucket enumeration (wordlists, DNS queries), HEAD/GET on common keys, test public list/put/delete.- Exploits: host web‑backdoors in writable buckets, poison files, exfiltrate DB dumps.- Tools: s3scanner, awscli, curl.

3) API Gateway & CDN- Goal: auth bypass, broken CORS, parameter tampering, SSRF.- Tests: fuzz endpoints, test for missing authorizers, replay/forge JWTs, check for overly permissive CORS, inject host headers to trigger SSRF to metadata service.- Exploits: SSRF -> metadata -> retrieve role creds -> escalate; unauthenticated endpoints for admin functions.- Tools: Burp, ffuf, sqlmap.

4) Microservices & lateral movement- Goal: find trust relationships, sensitive configs, hardcoded creds.- Tests: enumerate internal services via proxy, test for exposed management endpoints, check container metadata endpoints (ECS/EKS).- Exploits: use creds to access RDS/S3, pivot to other services.

5) RDS & data exfiltration- Goal: confirm DB access, extract sensitive data.- Tests: attempt DB connections using obtained creds, test SQL injection in APIs, check for automated backups to S3.- Exploits: dump PII, write to writable S3 for persistence.

**Evidence & validation**- Retain proof-of-concept logs, minimal non-destructive reads where possible, follow rules of engagement.

**Remediation highlights**- Least privilege IAM roles, unique roles per service, restrict S3 access to least privileges and VPC endpoints, enforce API Gateway authorizers + strict CORS, lock down SGs, rotate creds and enable logging/alerting.

This plan focuses on attack paths from public-facing components to internal credentials and S3 exfiltration, prioritizing fast wins that yield persistent access.

HardSystem Design

75 practiced

Design deception and detection controls to integrate into application and infrastructure architecture: API honeytokens, host canaries, network sinkholes, and telemetry pipelines feeding SIEM. Explain how a penetration tester would validate these controls' deployment, measure their effectiveness, and tune to reduce false positives.

Sample Answer

**Clarify goals & constraints**- Deploy low-noise deception (honeytokens, canaries, sinkholes) that produce high-fidelity alerts into SIEM with minimal business impact and privacy concerns.- Must be discoverable by realistic attacker techniques and instrumented for measurable telemetry.

**High-level architecture**- API honeytokens: deploy fake API keys, endpoints, or OAuth clients with tight scopes; each token tagged with unique ID and owner metadata.- Host canaries: lightweight Canaryfiles/credentials, scheduled fake cron jobs, or ephemeral user accounts on non-production hosts.- Network sinkholes: internal DNS entries and routing rules redirecting suspicious C2/domains to isolated honeypot VLANs that capture traffic.- Telemetry pipeline: agents/ingest -> normalization/enrichment (asset/user context) -> SIEM rules & UEBA -> alerting & case creation.

**Pentester validation approach**- Discovery tests: use automated scanning and credential stuffing to find honeytokens and canaries.- Trigger tests: intentionally use a honeytoken (e.g., call API with fake key, exfil fake file, SSH with canary account) from controlled lab C2 to simulate attacker actions.- Network tests: resolve sinkholed domains, simulate DNS/tunnel behaviors, and attempt to C2 to sinkhole IPs.- End-to-end: verify telemetry (raw event), enrichment (token ID, host), SIEM correlation, alert generation, and notification pathways.

**Effectiveness metrics**- Detection Rate: fraction of triggered deception items that generated SIEM alerts.- Time-to-Detect (TTD): time from trigger to analyst notification.- Precision / False Positive Rate: alerts that are true deception triggers vs benign noise.- Coverage: percentage of critical asset classes instrumented.

**Tuning to reduce false positives**- Add context enrichment: tag tokens with expected source ranges, service owners, and allowed test-IPs to filter benign integrations.- Implement whitelists for legitimate automated systems; require honeytokens to be inaccessible to normal workflows.- Adjust correlation/thresholds: require multiple independent signals (e.g., honeytoken use + unusual process spawning) before high-severity alerts.- Rotate and diversify tokens: unique per environment to trace accidental use.- Feedback loop: include pentest & ops test runs; measure changes (precision, TTD) and iterate rules.

**Practical examples / tools**- Simulate API honeytoken use via curl/postman; run Mimikatz-like lab tools to attempt credential theft; use C2 frameworks (Caldera, Covenant) pointing at sinkhole to validate capture.- Monitor SIEM dashboards for fields: honeytoken_id, source_ip, user_context, and attach telemetry screenshots as evidence.

This demonstrates how, as a penetration tester, I would both validate deployments realistically and provide measurable feedback to tune the detection stack for high fidelity and low false positives.

Unlock Full Question Bank

Get access to hundreds of Security Architecture Principles and Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.