L
←

1Password

Editing is locked. Unlock with an edit token →

Core AppSec technical depth

  • OWASP Top 10 in detail — not just names, but how each vuln class works and how to remediate it (injection, broken auth, SSRF, XXE, insecure deserialization, broken access control)
  • Authentication vs. authorization — be ready to explain the difference cleanly and give an example of each failing
  • Cryptography fundamentals — symmetric vs. asymmetric, when to use each, hashing vs. encryption, salting, why ECB mode is bad, what a nonce/IV does. Given 1Password's product, expect at least one crypto question.
  • Key management — key derivation (your HKDF work is gold here), key rotation, secure storage of secrets, what happens if a key leaks
  • Secure SDLC — where security fits (design → threat model → code review → SAST/DAST → pentest → monitoring), shift-left concepts
  • Threat modeling — STRIDE framework basics; be ready to threat-model something simple on the spot (e.g., "how would you threat model a password manager's sync feature?")

Web/application-specific

  • SQL injection and XSS — mechanics, not just definitions; how a WAF or parameterized query stops them
  • CSRF — how it works, how SameSite cookies/tokens prevent it
  • SSRF — increasingly popular interview topic; know the mechanics and mitigations
  • JWT vulnerabilities — alg confusion, weak secrets, missing signature verification
  • API security — rate limiting, broken object-level authorization (BOLA), input validation

Code review / secure coding

  • Be ready to spot a vulnerability in a short code snippet if shown one (classic intern-interview move)
  • Input validation vs. sanitization vs. encoding — know the distinction

Incident response / detection

  • Given your Snort/MQTT labs — be ready to explain detection logic choices, false positive/negative tradeoffs, and what you'd do if you found something mid-attack

Behavioral "worst case" questions

  • "Tell me about a time you found a vulnerability others missed" (BD Alaris is your answer)
  • "Tell me about a time you disagreed with a team decision on security" (be ready with something honest, even minor)
  • "Describe a time you had to learn something completely new under time pressure" (eCTF or Flixverse)
  • "How do you stay current on new vulnerabilities/CVEs?" (have a real answer — feeds, Twitter/X security researchers, NyxKernel research)
  • "Tell me about a mistake you made in a security context and what you learned"

Things that catch people off guard

  • "Why AppSec specifically, not pentesting/blue team/etc.?" — have a genuine, specific answer
  • "Why 1Password?" — know their product, not just "it's a password manager." Mention their security architecture (zero-knowledge, Secret Key model) if you can speak to it credibly
  • A curveball asking you to explain a technical concept simply — like you're teaching a non-technical person what encryption is. Tests communication, not just knowledge.

1Password AppSec Intern Interview — Full Prep Topic List (60+)

1. Web Vulnerability Classes (OWASP-adjacent)

  1. SQL Injection (classic, blind, second-order)
  2. Cross-Site Scripting (reflected, stored, DOM-based)
  3. Cross-Site Request Forgery (CSRF) and SameSite cookie defenses
  4. Server-Side Request Forgery (SSRF)
  5. XML External Entity (XXE) injection
  6. Insecure Deserialization
  7. Broken Access Control / IDOR (Insecure Direct Object Reference)
  8. Broken Object-Level Authorization (BOLA) in APIs
  9. Command Injection / OS Injection
  10. Path Traversal / Local File Inclusion (LFI) / Remote File Inclusion (RFI)
  11. Open Redirects
  12. Clickjacking and frame-busting defenses
  13. Mass Assignment vulnerabilities
  14. Race conditions (TOCTOU) in web apps
  15. HTTP Request Smuggling

2. Authentication & Session Management

  1. Password hashing (bcrypt, scrypt, Argon2) vs. plain hashing (MD5/SHA1 pitfalls)
  2. Salting and peppering
  3. Multi-factor authentication (TOTP, WebAuthn/FIDO2, push-based)
  4. Session fixation attacks
  5. Session token entropy and secure cookie flags (HttpOnly, Secure, SameSite)
  6. OAuth 2.0 flows and common misconfigurations
  7. OpenID Connect basics
  8. JWT vulnerabilities (alg=none, weak secret brute-force, kid injection)
  9. Credential stuffing vs. brute force vs. password spraying
  10. Account lockout / rate limiting strategies

3. Cryptography

  1. Symmetric vs. asymmetric encryption — when to use each
  2. AES modes (ECB vs. CBC vs. GCM) and why ECB leaks patterns
  3. Hashing vs. encryption vs. encoding (conceptual distinction)
  4. HMAC and message authentication
  5. Key derivation functions (PBKDF2, HKDF, scrypt)
  6. Key management lifecycle (generation, rotation, revocation, destruction)
  7. Public Key Infrastructure (PKI) and certificate chains
  8. TLS handshake basics and common misconfigurations
  9. Perfect Forward Secrecy
  10. Zero-knowledge architecture concepts (highly relevant to 1Password's Secret Key model)
  11. Nonces, IVs, and why reuse breaks crypto

4. Secure Development Lifecycle

  1. Threat modeling frameworks (STRIDE, DREAD, PASTA)
  2. Shift-left security principles
  3. SAST vs. DAST vs. IAST vs. SCA — differences and when each is used
  4. Secure code review methodology
  5. Dependency/supply chain risk management (SBOM concepts)
  6. CI/CD pipeline security (secrets in pipelines, build integrity)
  7. Secure design patterns (least privilege, defense in depth, fail-closed)
  8. Input validation vs. sanitization vs. output encoding

5. API & Cloud Security

  1. REST API security best practices
  2. API rate limiting and abuse prevention
  3. GraphQL-specific vulnerabilities (query depth, introspection exposure)
  4. Cloud misconfigurations (S3 buckets, IAM over-permissioning)
  5. Secrets management (Vault, KMS, environment variable pitfalls)
  6. Container security basics (image scanning, least-privilege containers)
  7. Zero Trust Architecture principles

6. Network & Infrastructure Security

  1. Firewall / IDS / IPS fundamentals (ties to your Snort lab)
  2. DoS/DDoS attack types and mitigations (ties to your MQTT lab)
  3. Man-in-the-middle attack scenarios
  4. DNS security basics (DNSSEC, cache poisoning)
  5. VPN and secure remote access concepts

7. Vulnerability Management & Disclosure

  1. CVE/CVSS scoring — how severity is calculated
  2. Responsible disclosure process
  3. Bug bounty program mechanics
  4. Patch management prioritization

8. Incident Response & Detection

  1. Incident response lifecycle (prepare, detect, contain, eradicate, recover)
  2. Log analysis fundamentals
  3. False positive vs. false negative tradeoffs in detection rules
  4. Basic forensics concepts (chain of custody, volatile data capture)

9. Behavioral / Soft-Skill Angles

  1. "Tell me about a vulnerability you found" — have BD Alaris ready
  2. "Tell me about a disagreement over a security decision" — have a real, honest example
  3. "How do you stay current on threats/CVEs?" — have a genuine answer (feeds, researchers you follow, your own research)
  4. "Explain a technical concept to a non-technical person" — practice explaining encryption or MFA simply
  5. "Time you learned something fast under pressure" — eCTF or Flixverse
  6. "Why AppSec, why 1Password" — know their zero-knowledge architecture and Secret Key model specifically

How to use this list

  • Skim all 70 — flag any topic where you can't explain it out loud in 30 seconds
  • Prioritize deep review on: crypto (26-36), OWASP-style vulns (1-15), and threat modeling (37) — these map most directly to a password manager's core product
  • For each of your personal projects (eCTF, BD Alaris, MQTT lab, Snort lab, Flixverse), pre-map which 3-5 topics above it demonstrates, so you can pivot naturally between "here's what I know" and "here's what I've done"

Q1: Walk me through how you'd triage an incoming vulnerability report.

"First thing I'd want is reproducibility — can I confirm this is real before I even think about severity. Once confirmed, I'd score it with CVSS, but I don't stop at the number — I'd weigh exploitability against actual blast radius. That's something I took away from studying CVE-2016-9355 on the Alaris infusion pump: technically it was a trivial CWE-798 hardcoded credential, 'summit,' cracked in under a second, so CVSS alone undersells it. But the deployment context — hospitals, patient-connected devices — made the real-world risk far higher than the exploit complexity suggested. So my triage instinct is: confirm, score, then sanity-check the score against actual deployment context before it goes to engineering."

Q2: How would you think about rolling out or prioritizing SAST/DAST tooling in a codebase?

"I'd start by asking where in the SDLC we're bleeding the most time — if most vulns are getting caught late, post-deploy, that tells me we need SAST in CI, gating merges, so issues get caught at commit time when they're cheapest to fix. DAST I'd treat as a second layer — periodic runs against staging to catch what static analysis structurally can't, like runtime auth bypasses or environment misconfig. The prioritization judgment call is really about noise: SAST tools are notorious for false positives, so I'd rather roll it out on a subset of rules tuned to what's actually shipped historically, and expand coverage instead of turning on everything and burning trust with the eng team on day one."

Q3: Tell me about your cryptography work — go deeper than the surface level.

"On MITRE eCTF, I was Team Lead on NEU-1, and the piece I owned most closely was the key hierarchy — a three-tier HKDF derivation: ROOT_SEED derives DEVICE_SEED, which derives ENC_SEED and SESSION_SEED separately. The reasoning behind that separation is compromise containment — if a session key leaks, you haven't touched the device seed, so you haven't burned the whole device's trust. We paired that with AES-CBC-256 run through a hardware AESADV peripheral with DMA-driven crypto, so encryption wasn't blocking the main core, and HMAC-SHA256 for integrity on top, since encryption alone doesn't guarantee the ciphertext wasn't tampered with. We also built in PIN rate limiting and a fail-closed permission model — meaning if anything about the auth check is ambiguous or errors out, the system denies access by default rather than falling open. That fail-closed default is the piece I'd generalize to any local authentication system, including biometrics — ambiguous states should never resolve to access granted."

Q4: Where do you see cryptography heading, especially with post-quantum in mind?

"The threat model shift is that RSA and ECC rely on problems — integer factorization, discrete log — that Shor's algorithm breaks efficiently on a sufficiently large quantum computer. That's not an immediate threat today, but it's a 'harvest now, decrypt later' risk — adversaries can capture encrypted traffic now and decrypt it once quantum capability catches up. NIST has already standardized lattice-based alternatives — Kyber for key encapsulation, Dilithium for signatures — because lattice problems don't have a known efficient quantum algorithm yet. For a password manager specifically, I'd think about this less as 'panic migrate everything' and more as crypto-agility — designing systems so the underlying algorithm can be swapped without re-architecting everything around it, which honestly maps to the same key-hierarchy separation principle I used in eCTF: isolate the crypto primitive from the system logic that depends on it."

Q5: How would you think about securing identity for AI agents acting on behalf of users?

"The core shift is that traditional access control assumes a human is the identity behind every action, and that assumption breaks the moment an agent is executing autonomously across systems. I spent time on this conceptually in a NIST CSF 2.0 paper I co-authored with BU and NU collaborators — Zero Trust Architecture was one of the areas I went deep on, and the principle that applies most directly here is 'never trust, always verify' extended to non-human identities: every agent action needs to be scoped, time-bound, and attributable, not just authenticated once and trusted indefinitely. Practically, that means least-privilege by default for agents — narrower and more revocable than you'd even give a human — plus clear audit logging so if an agent's credentials are misused, you can trace exactly what it touched and attribute it. The hard part isn't the theory, it's that agents often need broad enough access to be useful, so the real engineering problem is making that access dynamically scoped rather than statically over-provisioned."

Q6: If I described a new feature to you right now, how would you approach a security design review?

"I'd start with STRIDE to walk the trust boundaries — spoofing, tampering, repudiation, info disclosure, denial of service, elevation of privilege — because it stops me from anchoring on the one obvious attack and missing the rest. I did something structurally similar on an infrastructure paper I wrote modeling the Boston electric grid as an 8-node network — I used centrality metrics to figure out which nodes were highest-value before reasoning about specific attack vectors, because attacking the wrong node first wastes your analysis. Same order of operations for a feature: map what's a trust boundary, then ask what breaks at each one, then rank by impact — not by whichever vulnerability is easiest to describe first."

1Password AppSec Interview — Full Prep Doc

Interviewer: Avi Singh, Senior Engineering Manager, Product Security Date: Friday

Format: concept → concrete example from your own work → the underlying principle. That's the pattern to hit on every answer.

Vulnerability Management & Bug Bounty

1. Walk me through how you'd triage an incoming vulnerability report. First thing I want is reproducibility — confirm it's real before I think about severity. Once confirmed, I'd score it with CVSS, but I wouldn't stop at the number — I'd weigh exploitability against actual blast radius. That's something I took from studying CVE-2016-9355 on the Alaris infusion pump: technically a trivial CWE-798 hardcoded credential, "summit," cracked in under a second, so CVSS alone undersells it. The deployment context — hospitals, patient-connected devices — made the real-world risk far higher than the exploit complexity suggested. So: confirm, score, then sanity-check the score against deployment context before it goes to engineering.

2. How do you decide severity when CVSS score and real-world impact disagree? I treat CVSS as a starting point, not a verdict. If a "medium" CVSS bug sits on an internet-facing service handling customer vault metadata, I'd escalate it regardless of the raw score, because exposure and blast radius matter more than exploit complexity alone. I'd document the override reasoning explicitly so triage decisions stay auditable and aren't just gut calls.

3. Tell me about a CVE you've studied or worked with in depth. CVE-2016-9355 is the one I know best — a hardcoded default password shared across every account on the BD Alaris 8015 infusion pump, working with Professor Kevin Fu. It cracked in under a second. What stuck with me wasn't the technical simplicity — it's about as basic as CWE-798 gets — it's that this was deployed in hospitals. It reframed how I think about severity: impact matters as much as exploit complexity.

4. How would you prioritize a backlog of 50 open vulnerabilities with limited engineering bandwidth? I'd bucket by exploitability and exposure first — is it internet-facing, does it require auth, is there a known public exploit — then layer in remediation cost, because a quick config fix should jump the queue ahead of a slower one even at similar severity. I'd also flag anything with regulatory or customer-trust implications separately, since those carry urgency beyond the technical score.

5. What makes a vulnerability report "not reproducible," and how do you handle that with a researcher? Usually it's missing environment details — version, config, auth state — or the researcher assumed a precondition that isn't actually true in production. I'd go back with specific questions rather than closing it outright, since a badly-described real bug and a false report look identical from the outside until you dig in.

6. How would you structure a bug bounty program's scope and reward tiers? I'd scope tightly around what's actually exploitable and impactful — production systems handling sensitive data first — and exclude noisy, low-value categories like missing security headers unless chained into something real. Reward tiers should map to blast radius: full vault compromise or auth bypass at the top, informational findings at the bottom, with clear examples in the policy so researchers aren't guessing.

7. What's the difference between a false positive and a low-severity true positive, and why does that distinction matter operationally? A false positive isn't a real issue at all — the scanner or reporter misjudged the code. A low-severity true positive is real but low-impact. Conflating them is dangerous because teams start ignoring "low severity" tags altogether if too many turn out to be false positives — so triage accuracy directly protects the credibility of the whole pipeline.

SAST / DAST / Security Tooling

8. What's the difference between SAST and DAST, and when do you use each? SAST scans source code without running it — good for catching hardcoded secrets or insecure function usage early, shift-left in the SDLC. DAST tests the running application from the outside, catching things SAST structurally can't see, like runtime auth bypasses or environment misconfigurations. In practice you want both — SAST in CI on every commit, DAST periodically against staging.

9. How would you roll out SAST into a CI/CD pipeline without alienating the engineering team? I'd start with a subset of high-confidence rules tuned to what's actually shipped historically, gating only clearly critical findings on merge, and treat everything else as visibility first. Turning on every rule at full severity on day one just burns trust with engineering the first time they hit a false positive blocking a release.

10. What is SCA (software composition analysis), and why does it matter for dependency risk? SCA scans your dependency tree for known vulnerabilities and license issues in third-party packages. It matters because most orgs' attack surface today isn't code they wrote — it's the hundreds of dependencies nobody audited. I went deep on supply chain risk in a NIST CSF 2.0 paper I co-authored with BU and NU collaborators, and it's one of the areas the 2.0 update explicitly elevated.

11. How do you deal with alert fatigue from security scanning tools? Tune the ruleset to your actual codebase and threat model instead of running every default rule, triage aggressively so engineers only see things worth their time, and track false-positive rate as a metric — if a rule keeps firing wrong, it gets fixed or disabled rather than tolerated.

12. What would you look for when evaluating a new AppSec tool for adoption? Signal-to-noise ratio first — a tool that's technically thorough but drowns engineers in noise won't get used. Then integration friction into existing CI/CD, and whether findings come with enough context (file, line, remediation guidance) that a developer can act without needing a security engineer to translate.

Cryptography

13. Explain the difference between hashing and encryption. Encryption is reversible — if you have the key, you get the plaintext back. Hashing isn't meant to be reversible at all, which is why you hash passwords instead of encrypting them — even if the database leaks, there's no key that unlocks it back to the original.

14. Why do password managers use slow, salted KDFs like PBKDF2 or Argon2 instead of fast hashes? A fast hash like SHA-256 is designed for speed, which is exactly wrong for password storage — it lets an attacker brute-force billions of guesses per second on a leaked hash. PBKDF2 and Argon2 are deliberately slow and memory-hard, so each guess costs real compute, and the salt ensures identical passwords don't produce identical hashes across users.

15. Walk me through your eCTF key hierarchy — why separate root, device, and session keys? On MITRE eCTF, I was Team Lead on NEU-1, and I owned the key hierarchy — a three-tier HKDF derivation: ROOT_SEED derives DEVICE_SEED, which derives ENC_SEED and SESSION_SEED separately. The reasoning is compromise containment — if a session key leaks, you haven't touched the device seed, so you haven't burned the whole device's trust.

16. What is a fail-closed vs. fail-open permission model, and why does it matter for authentication? Fail-closed means if anything about an auth check is ambiguous or errors out, the system denies access by default. Fail-open does the opposite — defaults to allowing access on error. We built fail-closed into eCTF's permission model deliberately, because an ambiguous state should never resolve to access granted. I'd generalize that to any local authentication system, including biometrics.

17. Explain zero-knowledge architecture in the context of a password manager. The company holding your data literally cannot read it, even if they wanted to, because the encryption key never leaves your device and is derived from your master password — the server never sees the key material at all. It's the same containment principle as my eCTF key hierarchy, just taken further: no single stored value on the server side is enough to decrypt anything.

18. What is post-quantum cryptography, and why does "harvest now, decrypt later" matter today? RSA and ECC rely on problems — integer factorization, discrete log — that Shor's algorithm breaks efficiently on a sufficiently large quantum computer. That's not an immediate threat today, but adversaries can capture encrypted traffic now and decrypt it later once quantum capability catches up, so long-lived sensitive data is at risk even before quantum computers exist at scale.

19. What are NIST's standardized post-quantum algorithms, and what problem do they solve for? NIST standardized Kyber for key encapsulation and Dilithium for digital signatures, both lattice-based, because lattice problems don't have a known efficient quantum algorithm yet. They're meant as drop-in replacements for the asymmetric primitives quantum computing threatens.

20. What is crypto-agility, and how would you design a system to support it? Crypto-agility means designing a system so the underlying algorithm can be swapped without re-architecting everything around it. I'd isolate the crypto primitive behind an interface the rest of the system depends on, the same way I isolated key derivation from application logic in eCTF — so migrating to a post-quantum algorithm later is a targeted change, not a rewrite.

21. Why pair encryption (AES) with an integrity check (HMAC) instead of relying on encryption alone? Encryption alone guarantees confidentiality but not integrity — an attacker could tamper with ciphertext and you wouldn't know. In eCTF we paired AES-CBC-256 with HMAC-SHA256 specifically so any tampering would be caught, since a valid-looking decrypted output isn't the same as an authentic one.

22. What's the difference between symmetric and asymmetric encryption, and when would you use each? Symmetric uses one shared key for both encryption and decryption — fast, good for bulk data, which is why we used AES for the actual payload encryption in eCTF. Asymmetric uses a public/private key pair — slower, but solves key distribution, which is why it's typically used to exchange or wrap a symmetric key rather than encrypt bulk data directly.

Identity, Access & Zero Trust

23. How would you think about securing identity for AI agents acting autonomously on behalf of users? Traditional access control assumes a human is the identity behind every action, and that breaks the moment an agent executes autonomously across systems. I went deep on Zero Trust Architecture in a NIST CSF 2.0 paper I co-authored, and the principle that applies here is "never trust, always verify" extended to non-human identities — every agent action should be scoped, time-bound, and attributable, not authenticated once and trusted indefinitely.

24. What does "least privilege" mean in practice, and how do you enforce it for machine identities vs. humans? It means granting only the access needed for a specific task, nothing broader "just in case." For machine identities I'd actually be stricter than for humans — narrower scopes, shorter-lived credentials, automatic expiry — because an agent can't exercise judgment about when access is inappropriate the way a human might.

25. Explain Zero Trust Architecture and its core principle. The core principle is "never trust, always verify" — no implicit trust based on network location or prior authentication. Every request gets evaluated on its own, against identity, device posture, and context, rather than assuming that once you're inside the perimeter you're safe.

26. How would you design audit logging so an agent's or user's actions are always attributable? Every action needs to carry the identity that initiated it, the credential used, and enough context to reconstruct intent — not just "system did X" but "agent Y, acting under credential Z, did X at this time." Without that granularity, you can detect that something happened but not who's accountable for it.

27. What's the risk of over-provisioning access for automation/agents, and how would you avoid it? Agents often need broad-enough access to be useful, so the default temptation is to over-provision for convenience — which turns a single compromised agent into a much bigger blast radius. I'd push toward dynamically scoped access, granted per-task and expiring after, rather than statically provisioned once and left standing.

28. What is OAuth/SSO, and what's a common misconfiguration that leads to compromise? OAuth lets a user grant an application limited access without sharing their password directly, and SSO extends that to authenticate once across multiple services. A common misconfiguration is an overly permissive redirect URI validation — if an attacker can register or manipulate the redirect target, they can intercept the auth code or token meant for the legitimate app.

Web/App Security Fundamentals

29. Walk me through the OWASP Top 10 — which ones do you think are most underrated? I'd say broken access control and cryptographic failures are underrated relative to how often they show up versus how much attention injection gets. Access control bugs are especially dangerous because they're logic errors, not pattern-matchable by scanners the way SQL injection often is — they require actually understanding the intended authorization model.

30. Explain a broken access control vulnerability you've seen or studied. The clearest example I can speak to conceptually is IDOR — where an app checks that you're authenticated but not that you're authorized for the specific object you're requesting, like changing an ID in a URL and pulling someone else's data. It's dangerous because functionally everything "works," which is exactly why it's easy to miss without explicit authorization testing.

31. What is CSRF, and how do modern frameworks mitigate it by default? CSRF tricks a logged-in user's browser into submitting a request they didn't intend, relying on the browser automatically attaching session cookies. Modern frameworks mitigate it with anti-CSRF tokens tied to the session and validated server-side, plus SameSite cookie attributes that restrict when cookies get sent cross-site at all.

32. What is SSRF, and why is it especially dangerous in cloud environments? SSRF is when an attacker tricks a server into making requests on their behalf, often to internal resources the attacker couldn't reach directly. It's especially dangerous in cloud environments because internal metadata endpoints — like AWS's instance metadata service — can leak credentials if an SSRF vulnerability can reach them.

33. What's BOLA (broken object-level authorization), and how would you test for it? BOLA is when an API checks that a request is authenticated but doesn't verify the requester is authorized for the specific object referenced — very similar to IDOR at the API layer. I'd test it by authenticating as one user, then swapping object IDs in requests to see if I can access another user's resources.

Threat Modeling & Security Architecture

34. Walk me through how you'd approach a security design review for a new feature. I'd start with STRIDE to walk the trust boundaries — spoofing, tampering, repudiation, info disclosure, denial of service, elevation of privilege — because it stops me from anchoring on one obvious attack and missing the rest. I did something structurally similar on an infrastructure paper modeling the Boston electric grid as an 8-node network, using centrality metrics to figure out which nodes were highest-value before reasoning about specific attack vectors — same order of operations: map trust boundaries first, then rank by impact.

35. What is STRIDE, and how do you use it in practice? STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. In practice I walk each trust boundary in a system and ask which of those six categories applies there, which turns a vague "is this secure" question into a structured checklist.

36. How do you decide which trust boundaries matter most in a system? I look at where data or control crosses from a lower-trust context into a higher-trust one — user input hitting a backend, an external service call, a privilege escalation point. On the grid paper, I used centrality metrics like betweenness and eigenvector centrality to identify which nodes were structurally most critical; the same logic applies to picking which boundaries deserve the deepest review first.

37. Describe a time you modeled risk or threat exposure in a system (technical or infrastructure). I built an 8-node model of the Boston Metropolitan Electric Power Distribution Network for Professor Papageorge, using an adjacency matrix and centrality metrics — degree, betweenness, eigenvector — plus spectral radius analysis to rank nodes by systemic risk, framed against the DHS Energy Sector risk model. It reinforced that you can't treat every node or component as equally worth defending — some failures cascade much further than others.

Network & Infra Security

38. Walk me through your Snort IDS/IPS lab — how does inline IPS differ from passive detection? For Professor Amorin's Network Security Practices course, I wrote Snort detection rules for real CVEs — ProxyLogon, the F5 BIG-IP RCE, and Drupalgeddon — including SQL injection detection and PCAP analysis. What made it click was setting up NFQUEUE so Snort ran inline as an actual IPS instead of just passive detection — traffic gets inspected and can be dropped in real time, versus passive detection which only alerts after the fact without stopping anything.

39. Describe the MQTT DoS lab — what protocol-level weakness did you exploit, and what was the impact? I ran it against a Mosquitto broker on a Raspberry Pi 4 — retain flood, wildcard subscription storms, and session exhaustion, all via Python scripts I wrote myself. The underlying weakness is that MQTT doesn't enforce rate limiting by default, so a handful of scripts pushed RAM from 600MB to 8GB and throughput from under 1 Mbit/s to 600-700 Mbit/s, causing a full outage of about 49 minutes.

40. What's your experience with reverse shell detection, and how would you detect one on a network? In the Snort lab, I built rules to catch reverse shell traffic by pattern — unusual outbound connections to non-standard ports, or shell prompt signatures in the payload. Beyond signature matching, I'd also look at behavioral indicators, like a normally quiet internal host suddenly initiating an outbound connection to an unfamiliar external IP, since attackers can trivially obfuscate signatures but behavioral anomalies are harder to hide.