Skip to main content

How to Answer Security System Design Questions (SALT)

Premium

SALT

1. Scope the problem (5–10 minutes)

In this stage, you’re clarifying requirements, constraints, and success criteria before diving into design or implementation. The goal is to understand the scope, risks, and expectations of the system or problem you’re solving.

Here are some example questions you might ask:

  • "What's the scale? How many users or requests per second?"
  • "What's the most sensitive data we're protecting?"
  • "Are there compliance requirements (GDPR, HIPAA, SOC 2)?"
  • "What's our threat model—external attackers, insider threats, or both?"
  • "Are we building from scratch or working with existing infrastructure?"

Prompt: "Design a secure authentication service for millions of users."

Your response: "Let me clarify the scope. Are we targeting B2C or B2B users? What authentication methods do we need to support e.g. password, SSO, MFA? Are there specific compliance requirements? What's our availability target?"

2. Identify assets & threats (5–10 minutes)

In this stage, you’re determining what needs protection and what could go wrong. This involves understanding your system’s most valuable assets, identifying where trust breaks down, and anticipating likely attack paths.

Start by identifying critical assets: the components attackers are most likely to target or that would cause the most damage if compromised. These often include:

  • User credentials and tokens
  • Sensitive data (PII, financial records, health information)
  • API keys and secrets
  • Audit logs and monitoring data
  • Infrastructure access (admin panels, databases)

Next, map your trust boundaries: the points where data crosses from a trusted zone to an untrusted one. Examples include:

Where does data cross from trusted to untrusted zones?

  • Client ↔ Server
  • Public internet ↔ Internal network
  • Different microservices or services
  • User-controlled input ↔ System processing

Finally, consider potential attack vectors. Think about how an adversary might exploit weaknesses at these boundaries or target your critical assets. Common examples include:

  • Credential theft (phishing, breaches, weak passwords)
  • Session hijacking or token theft
  • Man-in-the-middle attacks
  • Injection attacks (SQL, command, XSS)
  • DDoS or resource exhaustion
  • Privilege escalation
  • Data exfiltration

By thinking through these dimensions (assets, trust boundaries, and attack vectors) you create a clearer picture of what needs protection and where your system is most vulnerable.

"The main assets are user credentials and session tokens. Key threats include credential stuffing attacks, token theft via XSS, and unauthorized access if sessions aren't properly validated. Trust boundaries exist between the client and API gateway, and between our services and the identity provider."

3. Design layered controls (20–30 minutes)

In this stage, you’re building your solution with defense in depth, layering multiple security controls so that if one fails, others still provide protection. The goal is to apply safeguards systematically across every part of your system rather than relying on a single point of defense.

Start with the identity and access layer.

  • Authentication mechanisms (passwords, MFA, SSO, biometrics)
  • Authorization models (RBAC, ABAC, least privilege)
  • Session management (token lifecycle, expiration, revocation)

Next, secure the network layer.

  • TLS/SSL for data in transit
  • Network segmentation and firewalls
  • Rate limiting and DDoS protection
  • API gateway security

Then move to the data layer.

  • Encryption at rest (database encryption, disk encryption)
  • Encryption in transit
  • Key management and rotation
  • Data masking or tokenization for sensitive fields

Finally, reinforce everything with a monitoring and detection layer.

  • Centralized logging (authentication events, API calls, failures)
  • Anomaly detection (unusual login patterns, geographic anomalies)
  • Alerting on suspicious activity
  • Audit trails for compliance

By layering controls across these domains, you ensure that your security posture remains resilient even if one safeguard is bypassed.

"Starting with the identity layer, we'll implement OAuth 2.0 with PKCE for the authorization flow and require MFA for all users. At the network layer, we'll enforce TLS 1.3 and implement rate limiting at the API gateway to prevent brute force attacks. For data protection, we'll use AES-256 encryption at rest with AWS KMS for key management. Finally, we'll centralize logs in a SIEM and alert on failed login attempts exceeding threshold."

Avoid tool-first thinking (e.g. "We'll use Okta, then AWS WAF, then..."). Instead, explain the security problem each control solves, then mention tools as implementation details.

Another common pitfall is focusing only on prevention. Your solution should include monitoring, logging, and incident response capabilities in your design.

4. Discuss tradeoffs (5–10 minutes)

In this stage, you’re weighing security against performance, cost, usability, and operational complexity. Strong security is essential but in real-world systems, it always comes with tradeoffs. Great engineers recognize these tensions early and design solutions that balance protection with practicality.

Security vs. performance

Adding layers of encryption or authentication inevitably introduces latency and overhead. For example, encryption might add 10–20 milliseconds of latency, but it’s essential for safeguarding sensitive data in transit. Similarly, multi-factor authentication (MFA) increases login friction, yet it’s one of the most effective defenses against account compromise.

A smart compromise might be risk-based authentication, where MFA is required only for high-risk actions or logins from unfamiliar devices.

Security vs. cost

Some controls deliver stronger protection but come at a premium. For instance, hardware security modules (HSMs) offer top-tier key protection but are far more expensive than cloud-based key management systems (KMS). In many cases, cloud KMS meets compliance requirements at a lower cost, making it a more practical choice for most organizations.

Security vs. usability

Tighter security can frustrate users if it interrupts workflow. Short session timeouts reduce exposure to hijacked sessions, but they can annoy users who need to log in repeatedly. A balanced approach is to use 15-minute idle timeouts combined with seamless background token refresh, preserving both usability and safety.

Security maturity is about progress, not perfection. The goal is to make deliberate, risk-informed choices and evolve your safeguards as your operations mature.

"Adding encryption at rest increases our storage costs by about 5% and adds minimal performance overhead. However, it's critical for compliance and protects us if backups are compromised. The tradeoff is justified given the sensitivity of user data."

5. Summarize & review (3–5 minutes)

At this stage, you’re summarizing your overall architecture and reinforcing the reasoning behind your key design choices.

  • High-level architecture summary e.g. "We've designed a three-tier authentication system with..."
  • Key security controls e.g. "The critical protections are MFA, TLS encryption, and anomaly detection."
  • Major tradeoffs e.g. "We prioritized availability over perfect consistency in session replication."
  • What you'd improve next e.g. "With more time, I'd add adaptive authentication and implement certificate pinning."

"To summarize: we've designed an OAuth 2.0-based authentication system with MFA, encrypted sessions, and defense in depth across identity, network, and data layers. Key tradeoffs include accepting slightly higher latency for encryption and using cloud-managed keys for operational simplicity. The highest priority controls are MFA enrollment, TLS enforcement, and real-time anomaly detection."

SALT acronym

Let’s wrap up with a simple way to remember this structured approach: SALT.

SALT stands for Scope, Assets, Layers, and Tradeoffs, representing the four main steps (minus the summary step) you’ve practiced throughout this lesson.

  • Scope (ties in with step 1): Start by defining the problem and its constraints. What system are you securing, and what’s in or out of scope?
  • Assets (ties in with step 2): Identify what needs protection and from what threats. This helps clarify priorities and guide your control choices.
  • Layers (ties in with step 3): Apply defense in depth by implementing controls systematically across the identity, network, data, and monitoring layers.
  • Tradeoffs (ties in with step 4): Weigh your decisions against performance, cost, and usability, and explain your rationale clearly.

By following SALT, you’ll present a security design that’s not only technically sound but also structured, balanced, and easy for interviewers to follow.

Next Lesson