Internal Controls Design and Effectiveness Testing Questions

Designing security and compliance controls and evaluating whether they operate effectively. Covers control objectives, preventive vs detective vs corrective controls, control mapping to risks and frameworks, design-effectiveness vs operating-effectiveness testing, and corrective and preventive action when a control fails. The 'do the controls actually work' discipline.

EasyTechnical

106 practiced

Explain the differences between preventive, detective, and corrective security controls. For each control type provide two concrete examples that apply to a cloud-native environment (IaaS/PaaS/SaaS). Describe how these control types should be combined to reduce risk in an application deployment lifecycle.

HardTechnical

108 practiced

Propose an architecture and algorithm to enable encrypted, searchable logs for a SIEM so analysts can run queries without exposing plaintext to operators. Discuss searchable encryption approaches (deterministic, order-preserving, searchable symmetric encryption), indexing strategy, threat model, performance trade-offs, and key distribution/rotation concerns.

Sample Answer

**Approach summary**Design a client-side / analyst-side encryption layer so logs are ingested encrypted and indexed with searchable tokens. Analysts hold decryption/search keys; operators never see plaintext keys.

**Searchable-encryption choices**- Deterministic encryption (DE): use for exact-match fields (user IDs, IPs). Pros: simple, fast equality search; cons: frequency leakage, vulnerable to frequency analysis.- Order-preserving/encryption (OPE/ORE): use only for low-entropy numeric range queries (timestamps, bytes). Trade-offs: strong leakage of order; prefer order-revealing encryption (ORE) with careful parameterization.- Searchable Symmetric Encryption (SSE): use for full-text or multi-term queries. Choose structured SSE (inverted-index based) with encrypted posting lists and capability-based tokens (trapdoors) to reduce leakage.

**Indexing strategy**- Per-field encrypted inverted indices stored separately from encrypted blobs.- For DE fields store token -> encrypted docID list (compressed, padded to mitigate size leakage).- For SSE text fields build term -> encrypted posting lists; use bloom filters per document for AND/OR optimizations.- Shard indices by time windows to limit scan scope.

**Algorithm / flow**1. Client/collector encrypts log blob with AES-GCM (unique IV), stores ciphertext.2. For each indexed field/term generate search token: - DE: token = HMAC(key_DE, value) - SSE: trapdoor = SSE.Trapdoor(key_SSE, term) - ORE: encrypt numeric to order-preserving token with ORE key3. Send tokens and document pointers to SIEM indexer which stores tokens->docIDs.4. Analyst constructs query locally into tokens/trapdoors, sends to SIEM. SIEM returns encrypted docIDs/ciphertexts matching tokens. Analyst fetches and decrypts locally.

**Threat model**- Honest-but-curious operators: can read storage and index but not keys.- Adversary can observe access patterns and token reuse; mitigate with padding, query obfuscation, ORAM for strong protection (expensive).- Not protected: frequency and access-pattern leakage unless using ORAM/obfuscation.

**Performance trade-offs**- DE: high throughput, low CPU, high leakage.- SSE: moderate CPU, extra storage for index, supports phrase/boolean but reveals access patterns.- ORE: enables range queries but leaks order; more expensive than DE.- ORAM: strongest privacy, large latency and I/O.

**Key distribution & rotation**- Use a central KMS (HKDF-wrapped keys) with role-based access; store keys in HSM. Analysts get ephemeral session keys via mutual TLS + MFA.- Rotate index keys periodically: re-key by issuing new per-field keys and re-encrypt indices lazily; maintain key-versioned tokens so old tokens still readable until reindexing completes.- Use forward secrecy: derive per-session search keys from long-term master using HKDF; revoke by rotating master and expiring sessions.

**Operational controls & mitigations**- Audit trapdoor issuance, rate-limit queries, pad posting lists, time-windowed sharding, differential privacy noise for aggregate queries.- Start with hybrid: DE for low-risk, SSE for sensitive text, evaluate latency; consider ORAM only for high-value subsets.

This design balances analyst usability with realistic leakage/operational constraints; choose protections according to data sensitivity and acceptable performance.

MediumTechnical

93 practiced

Design a SOAR playbook for automated containment and initial response when an endpoint is flagged by EDR with ransomware-like indicators (rapid file modifications, suspicious child processes, persistence changes). Include safe automation steps, which actions require human-in-the-loop approval, evidence collection steps, rollback strategies, and methods to avoid unnecessary collateral damage.

Sample Answer

**Situation & Goals**Design a SOAR playbook that performs safe automated containment and initial response when EDR flags ransomware-like behavior (rapid file writes, suspicious child processes, persistence changes). Goals: stop active encryption, preserve evidence, minimize business disruption, and enable quick rollback.

**Automated safe steps (immediate, no human)**- Enrich alert: pull process tree, hash binaries, user/session, open file handles, recent file change list, network connections, host asset tags, running AV status.- Quarantine suspicious binary from endpoint filesystem (read-only copy) and upload to sandbox for detonation/hash analysis.- Apply temporary network isolation via host-level micro-segmentation (block outbound SMB, RDP, common C2 ports) but keep management/control-plane allowed.- Snapshot host state (EDR snapshot, memory capture) and take forensic disk image or targeted file snapshots for changed directories.

**Human-in-the-loop approvals**- Full host quarantine from network/VLAN removal.- Automated mass-remediation (mass delete/quarantine of files across network).- User account disablement or password resets.- Re-imaging or rolling back to clean snapshot.

Require approval when business-impact > predefined threshold (asset criticality tag, uptime SLA, active RPO).

**Evidence collection**- Memory dump, process tree, DLLs, registry hives (persistence keys), collected changed file list with timestamps, file hashes, network PCAP for relevant timeframe, EDR telemetry timeline. Store signed/hashed artifacts in WORM evidence store.

**Rollback & remediation strategy**- Prefer non-destructive containment first (network isolation, process suspend, file system write-blocking).- If user/workflow impacted, allow temporary allowlist via change control with TTL.- For remediation: use verified clean snapshots or rebuild from golden image. Provide step to restore user files from validated backups; test restore on isolated host before production restore.

**Avoiding collateral damage**- Asset classification: run different play branches for Tier-1 (prod critical) vs Tier-3 endpoints.- Use throttled actions and staged containment (suspend process → isolate host → quarantine files).- Maintain allowlist for monitoring/management agents to avoid breaking EDR/ITSM channels.- Confirm with telemetry correlation (multiple indicators, sudden entropy changes, registry persistence) before destructive actions.

**Playbook metrics & post-incident**- Track MTTR, false-positive rate, number of human approvals, business-impacted hours.- Post-incident review: tune detection thresholds, update allow/deny lists, automate rollback test drills.

EasyTechnical

96 practiced

In Python, write a function verify_jwt(token: str, public_key_pem: str) -> dict that verifies an RS256 JWT signature, checks the exp and nbf claims, and returns the decoded claims. Raise an exception for invalid signatures, expired tokens, or invalid issuer. You may use PyJWT or describe equivalent steps if libraries are unavailable.

Sample Answer

**Approach (brief)** Verify RS256 signature using a PEM public key, validate exp and nbf claims, and enforce issuer check. I'll use PyJWT (recommended) and raise clear exceptions for invalid signature, expired, or invalid issuer.

python

import jwt
from jwt import InvalidSignatureError, ExpiredSignatureError, InvalidTokenError
from datetime import datetime, timezone

def verify_jwt(token: str, public_key_pem: str, issuer: str = None) -> dict:
    """
    Verify RS256 JWT and return claims.
    Raises InvalidSignatureError, ExpiredSignatureError, InvalidTokenError (for nbf/issuer/etc).
    """
    options = {"verify_aud": False}  # adjust if you need audience verification
    try:
        claims = jwt.decode(
            token,
            public_key_pem,
            algorithms=["RS256"],
            options=options,
            issuer=issuer,
        )
        # nbf is validated by PyJWT; double-check timestamps if needed
        return claims
    except ExpiredSignatureError:
        raise ExpiredSignatureError("Token has expired")
    except InvalidSignatureError:
        raise InvalidSignatureError("Invalid token signature")
    except InvalidTokenError as e:
        raise InvalidTokenError(f"Token invalid: {e}")

**Key notes**- PyJWT validates exp/nbf automatically when decoding.- For strict security: set leeway, verify audience, check token revocation (e.g., jti blacklist), and enforce accepted issuers.- Complexity: O(n) on token length; negligible for practical use.

**Edge cases**- Clock skew — consider small leeway.- PEM format errors — validate key parsing before use.

MediumTechnical

72 practiced

Review the following simplified web handler code and identify all security control gaps and specific remediations. Code (Python Flask-like):

python

def handle_request(req):
    username = req.args.get('username')
    query = 'SELECT * FROM users WHERE name = ' + username
    results = db.execute(query)
    return '<div>User: ' + results[0]['name'] + '</div>'

Explain vulnerabilities, how to remediate, and what controls you'd add at design and runtime to prevent similar issues.

Sample Answer

**Brief summary of issues**- SQL injection: string concatenation of user input into SQL.- Reflected XSS: user-controlled data rendered into HTML without encoding.- Lack of input validation, auth/authorization, error handling, and least-privilege DB access.- No logging/monitoring or runtime protections (WAF, parameterized query enforcement).

**Remediations (code)**- Use parameterized queries / prepared statements and HTML encoding:

python

def handle_request(req):
    username = req.args.get('username', '')
    # input validation: allowlist (e.g., alphanumeric + limited chars)
    if not VALID_USERNAME_REGEX.match(username):
        return 'Invalid username', 400
    # parameterized query
    results = db.execute('SELECT * FROM users WHERE name = %s', (username,))
    # escape output for HTML
    safe_name = html.escape(results[0]['name'])
    return f'<div>User: {safe_name}</div>'

**Design-time controls**- Secure coding standards, code reviews, SAST integrated into CI.- Use DB least-privileged accounts and stored procedures where appropriate.- Threat modeling to identify injection/XSS attack surfaces.- Input validation libraries and centralized output-encoding utilities.

**Runtime controls**- WAF with rules for SQLi/XSS, RASP to detect runtime injection.- Structured logging and alerting for suspicious queries or encoding failures.- Runtime secrets management, DB query parameter enforcement, and automated dependency scanning.

**Why these work**- Parameterized queries separate data from code preventing SQL execution.- Output encoding prevents script injection in HTML.- Controls at build and runtime provide defense-in-depth against developer mistakes and zero-day bypasses.

Unlock Full Question Bank

Get access to hundreds of Internal Controls Design and Effectiveness Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.