Security Architecture

Network security is the oldest layer of defense and the one most CISOs inherit in some form. Even as workloads move to the cloud and the perimeter dissolves, understanding how networks are segmented, monitored, and defended remains essential — because every attack eventually traverses a network.

The Evolving Perimeter

Traditional network security was built around a clear perimeter: the corporate network was "inside" (trusted), the internet was "outside" (untrusted), and a firewall sat between them enforcing rules. This model worked when all employees, applications, and data lived inside corporate walls.

That model is dead. Today's reality: employees work from home, coffee shops, and airports. Applications run in multiple clouds. Data flows between SaaS platforms, mobile devices, and partner systems. The "inside" and "outside" distinction has collapsed. But the principles of network security — segmentation, monitoring, access control, defense in depth — still apply. The implementation just looks different.

Defense in Depth

Network Segmentation

Segmentation divides a network into isolated zones so that a breach in one zone doesn't automatically give an attacker access to everything. The classic example is separating the production environment from the corporate network — a compromised laptop shouldn't be able to reach the production database directly.

Key Network Security Controls

• Firewalls (next-gen): Beyond port/protocol filtering — application awareness, user identity integration, SSL/TLS inspection, threat intelligence feeds. Vendors: Palo Alto, Fortinet, Check Point.
• IDS/IPS: Intrusion Detection/Prevention Systems monitor network traffic for malicious patterns. IDS alerts; IPS blocks. Increasingly integrated into NGFW and cloud-native services.
• DNS security: DNS is a common exfiltration and C2 channel. DNS filtering blocks known-malicious domains; DNS monitoring detects anomalous query patterns.
• Network Access Control (NAC): Verifies device health and identity before granting network access. Important for environments with BYOD or IoT devices.
• DDoS protection: Volumetric attack mitigation at the network edge. Cloud-based (Cloudflare, AWS Shield, Akamai) or on-premise appliances.

Cloud computing has fundamentally changed security architecture. The infrastructure you're securing is no longer in a building you control — it's in someone else's data center, managed through APIs, provisioned in minutes, and potentially misconfigured just as fast. Understanding the shared responsibility model is non-negotiable for any CISO.

The Shared Responsibility Model

The Top Cloud Security Mistakes

Most cloud breaches aren't sophisticated attacks — they're misconfigurations. The most common ones, in order of frequency:

1. Publicly exposed storage buckets. S3 buckets, Azure Blob containers, or GCS buckets left with public read access. This is the #1 cause of cloud data breaches. Always default to private; audit regularly.
2. Overly permissive IAM policies. Granting `*:*` (all permissions on all resources) because it's easier than figuring out the minimum required. Attackers who compromise one credential get access to everything.
3. Unencrypted data. Data at rest without encryption, data in transit without TLS, or encryption keys stored alongside the data they protect.
4. Missing logging and monitoring. CloudTrail (AWS), Activity Log (Azure), or Audit Logs (GCP) not enabled or not monitored. Without logs, you can't detect breaches or investigate incidents.
5. Stale credentials and access keys. Long-lived API keys that were created for a project two years ago and never rotated, still active, with admin permissions.

Multi-Cloud Reality

Most organizations use multiple cloud providers — sometimes by design (avoiding vendor lock-in), often by accident (one team uses AWS, another prefers Azure, someone signed up for GCP for a specific AI service). As CISO, you need a consistent security posture across all of them, which means either cloud-native tools per provider or a third-party cloud security platform (CSPM) that spans all three.

Identity is the new perimeter. When your employees, contractors, partners, and customers access resources from anywhere on any device, the one constant is who they are. IAM is the discipline of ensuring the right people have the right access to the right resources for the right reasons — and that everyone else is denied.

Core IAM Concepts

• Authentication (AuthN): Proving identity — "who are you?" Passwords, MFA, biometrics, certificates, tokens.
• Authorization (AuthZ): Granting permissions — "what can you do?" Role-based (RBAC), attribute-based (ABAC), policy-based access control.
• Accounting/Auditing: Tracking actions — "what did you do?" Audit logs, session recording, access reviews.
• Federation: Trusting identity from another system — SSO, SAML, OIDC, OAuth 2.0. Users authenticate once, access multiple systems.
• Lifecycle management: Provisioning, modifying, and deprovisioning access as people join, move, and leave the organization (joiner-mover-leaver).

Multi-Factor Authentication

MFA is the single most impactful security control you can deploy. Microsoft estimates that MFA blocks 99.9% of automated account compromise attacks. Yet adoption remains shockingly low — many organizations still treat it as optional or apply it only to VPN access.

Privileged Access Management

Privileged accounts (admin, root, service accounts) are the keys to the kingdom. If an attacker compromises a standard user, the blast radius is limited. If they compromise an admin account, they own the environment. PAM controls include:

• Just-in-time access: Admins don't have standing privileges. They request elevated access for a specific task, for a limited duration, with approval required.
• Credential vaulting: Privileged passwords stored in a vault (CyberArk, HashiCorp Vault, Delinea), rotated automatically, never known to the human using them.
• Session recording: All privileged sessions recorded for audit. Deters insider misuse and enables investigation.
• Break-glass procedures: Emergency access process for when normal PAM channels are unavailable. Documented, audited, used rarely.

Zero trust is the most over-marketed and under-implemented concept in cybersecurity. Every vendor claims to sell it, few organizations have actually adopted it, and most people can't agree on what it means. Let's cut through the noise.

What Zero Trust Actually Is

NIST Zero Trust Architecture (SP 800-207)

NIST's framework defines the key components:

• Policy Engine (PE): Makes access decisions based on policy — "should this subject be allowed to access this resource?"
• Policy Administrator (PA): Executes the PE's decisions — creates/destroys session tokens, configures data plane components.
• Policy Enforcement Point (PEP): The gateway that enforces access decisions — permits or denies the connection at the data plane level.

Every access request flows through this: subject → PEP → PE evaluates → PA acts → PEP allows/denies.

Zero Trust in Practice

Zero trust isn't a weekend project. It's a multi-year transformation. Most organizations adopt it incrementally, starting with the highest-value assets:

You can't protect what you don't understand. Data classification is the process of categorizing data based on its sensitivity and business value, so you can apply the right level of protection to each category. It's one of the least glamorous and most impactful things a CISO does.

Classification Levels

Most organizations use 3–4 classification levels. More than that adds complexity without meaningful security benefit:

Data Loss Prevention

DLP is the technology layer that enforces data classification policies. It monitors data in three states:

• Data in motion: Email, web uploads, file transfers, API calls. DLP inspects outbound traffic for sensitive patterns (credit card numbers, SSNs, source code) and blocks or alerts.
• Data at rest: Files on endpoints, servers, cloud storage, databases. DLP scans repositories to find sensitive data that shouldn't be there — the customer database on a developer's laptop, the spreadsheet with salary data on a shared drive.
• Data in use: Copy/paste, screen capture, printing, USB transfer. Endpoint DLP agents control what users can do with sensitive data while they're working with it.

Encryption is the last line of defense. If every other control fails — if the attacker gets past the firewall, bypasses segmentation, compromises credentials, and reaches the data — encryption ensures they get ciphertext instead of customer records. But encryption is only as strong as the key management behind it.

Encryption Fundamentals

• Symmetric encryption (AES-256): Same key encrypts and decrypts. Fast, used for bulk data. The standard for data at rest (disk encryption, database encryption, file encryption).
• Asymmetric encryption (RSA, ECDSA): Public key encrypts, private key decrypts (or vice versa for signatures). Slower, used for key exchange and authentication. The foundation of TLS/SSL.
• Hashing (SHA-256, bcrypt, PBKDF2): One-way transformation. Used for passwords, integrity verification, digital signatures. Not encryption — you can't reverse a hash.

Where Encryption Must Be Applied

Key Management

All the concepts in this module come together in the security architecture review — the process of evaluating a system's design from a security perspective before it's built or changed. This is where the CISO's team earns its keep as enablers rather than blockers.

When to Review

Not every change needs a full architecture review. The trigger should be risk-based:

• Always review: New systems handling customer data, changes to authentication/authorization systems, new external integrations, infrastructure migrations, any system processing payment or health data.
• Light review: New internal tools, changes to non-sensitive systems, standard library updates.
• No review needed: UI changes, content updates, documentation, non-production environments (unless they contain production data).

The Review Framework

Threat Modeling

Threat modeling is the structured process of identifying what can go wrong with a system and what to do about it. The most widely used approach is STRIDE:

Lesson 06 covered encryption at the architecture level — where to apply it and how to manage keys. This lesson goes deeper into the protocols themselves: which algorithms are safe, which are broken, how hashing and salting work, and how to evaluate whether your organization's cryptographic choices are adequate. You don't need to implement these yourself, but you need to know enough to audit what your team is using and raise the alarm when something is wrong.

Encryption Algorithms: The Good, The Broken, and The Dangerous

TLS Protocol Versions

TLS (Transport Layer Security) protects data in transit. Version matters enormously — older versions have known vulnerabilities that are actively exploited.

Password Hashing: Why Encryption Is Wrong

Passwords should never be encrypted — they should be hashed. Encryption is reversible (with the key). Hashing is a one-way function: you can verify a password by hashing the input and comparing, but you can't reverse the hash to get the password back. If your database is breached, hashed passwords give attackers ciphertext they can't reverse.

But not all hashing is equal. Using a fast hash like SHA-256 directly on a password is almost as bad as storing plaintext — modern GPUs can compute billions of SHA-256 hashes per second, making brute-force trivial.

Hashing, Salting, and Key Stretching

Password Hashing Algorithms Ranked

Where Protocols Are Used in Practice

Post-Quantum Cryptography

Quantum computers, when they reach sufficient scale, will break RSA and ECC (the asymmetric algorithms behind TLS, SSH, and code signing). Symmetric algorithms (AES) and hashes (SHA-256) are affected less — roughly halved in effective security, which means AES-256 becomes equivalent to AES-128, still adequate.

NIST standardized the first post-quantum algorithms in 2024:

• ML-KEM (formerly CRYSTALS-Kyber): Key encapsulation mechanism for key exchange. Already being deployed in Chrome (hybrid with X25519) and Signal.
• ML-DSA (formerly CRYSTALS-Dilithium): Digital signatures. Replacement for RSA and ECDSA in certificates and code signing.
• SLH-DSA (formerly SPHINCS+): Stateless hash-based signatures. Backup option if lattice-based schemes are broken.

APIs are the new front door. Modern applications are built as collections of services communicating through APIs — and each API endpoint is an attack surface. The OWASP Top 10 gives you the vocabulary to discuss web application risks; the API security layer gives you the architecture patterns to prevent them.

OWASP Top 10 (2021) — What a CISO Needs to Know

API Security Architecture

OWASP API Security Top 10 (2023)

OWASP published a separate Top 10 specifically for APIs, recognizing that API risks differ from traditional web application risks:

• Broken Object Level Authorization (BOLA): The #1 API vulnerability. User A can access User B's data by changing an ID in the request: GET /api/users/123/orders → change to /api/users/456/orders. Every endpoint must verify the requesting user owns the requested resource.
• Broken Authentication: Weak token validation, missing token expiration, predictable tokens.
• Broken Object Property Level Authorization: API returns more data than the user should see (mass assignment, excessive data exposure).
• Unrestricted Resource Consumption: No rate limiting, no pagination limits, no file upload size limits. Leads to DoS and cost explosion in cloud environments.
• Broken Function Level Authorization: Regular users can access admin endpoints by guessing the URL.

Security that's bolted on after development is expensive, slow, and incomplete. Security built into the development process — "shift left" — catches vulnerabilities when they're cheap to fix (design and coding phase) instead of when they're expensive (production). This isn't about making developers into security engineers; it's about embedding security tools and processes into their existing workflow.

The Shift-Left Model

Security Testing Tools in the CI/CD Pipeline

Developer Security Culture

Tools alone don't work. The CISO's role is building a culture where developers see security as part of their job, not an obstacle imposed by another team:

• Security champions: One developer per team designated as the security point of contact. They receive extra training, participate in security reviews, and mentor their team. This scales security knowledge without hiring more security staff.
• Secure coding training: Annual training tailored to the team's tech stack (OWASP for web, SANS for C/C++, specific training for cloud-native). Make it practical — CTF exercises beat slide decks.
• Blameless post-mortems: When a vulnerability reaches production, analyze the process failure, not the person. "Why didn't our pipeline catch this?" not "Who wrote this code?"
• Fast feedback loops: If a security scan takes 45 minutes, developers won't wait. Security checks must be fast enough to fit in the existing development workflow. A 2-minute SAST scan in the PR pipeline is adopted; a 45-minute scan is bypassed.

Endpoints (laptops, desktops, mobile devices) and email are where humans interact with technology — and where most attacks begin. Phishing delivers the payload, the endpoint executes it. Securing both is the front line of defense.

Endpoint Protection Evolution

Mobile Device Management & BYOD

• MDM/UEM (Unified Endpoint Management): Enforces security policies on corporate and personal devices: encryption required, screen lock, remote wipe capability, app whitelisting. Tools: Intune, Jamf, VMware Workspace ONE.
• BYOD policy: If employees use personal devices for work (they do, whether you allow it or not), you need a policy. Options: full MDM enrollment (intrusive), MAM-only (manage apps, not the device), or containerization (work data in a secure container, personal data untouched).
• Conditional access: "You can access corporate email from your personal phone, but only if the device is encrypted, has a PIN, and is running a supported OS version." This is the zero trust approach applied to endpoints.

Email Security Architecture

Email remains the #1 attack vector. Over 90% of cyberattacks begin with a phishing email. Your email security architecture needs multiple layers:

You can build perfect perimeter defenses, implement zero trust, deploy the best EDR — and still get breached. The difference between a minor incident and a catastrophe is how quickly you detect it. The average dwell time (time between compromise and detection) is still over 200 days globally. Your logging and monitoring architecture is what shrinks that number.

What to Log (And What Not To)

SIEM Architecture

A SIEM (Security Information and Event Management) collects, normalizes, correlates, and alerts on log data from across your environment. It's the nervous system of your security operations.

Vendor landscape: Splunk (powerful, expensive), Microsoft Sentinel (good for Microsoft shops, consumption pricing), Elastic Security (open source option), CrowdStrike LogScale (fast ingestion), Google Chronicle (fixed pricing model). For SMBs: Wazuh (open source) or Microsoft Sentinel with limited data sources.

Alert Fatigue — The Silent Killer

The average SOC receives 10,000+ alerts per day. Most are false positives or low-priority. If your analysts are drowning in noise, they'll miss the real attack buried on page 47 of the alert queue. This is alert fatigue, and it's the most common reason breaches go undetected despite having a SIEM.

• Tune relentlessly. Every false positive is a tax on your team's attention. If a rule generates 50 false positives per week, fix the rule or disable it. A SIEM with 20 well-tuned rules beats one with 500 noisy rules.
• Tier your alerts. Critical (immediate response required), High (investigate within 1 hour), Medium (investigate within 4 hours), Low (batch review). Don't make everything high priority.
• Automate the repetitive. SOAR (Security Orchestration, Automation, and Response) automates common playbooks: auto-enrich IP addresses with threat intel, auto-block known-malicious indicators, auto-close alerts matching whitelist patterns. This frees analysts for work that requires human judgment.
• Measure and improve. Track: false positive rate per rule, MTTD (time to detect), MTTR (time to respond), alert-to-investigation ratio. If 95% of alerts are false positives, your SIEM is a liability.

AI is simultaneously the most powerful tool and the most dangerous attack surface in modern security. As a CISO, you need to understand three dimensions: using AI to defend, defending against AI-powered attacks, and securing your organization's own AI deployments. This lesson focuses on the architecture — Module 05 (AI Security & Governance) will go deeper into governance, regulation, and policy.

AI for Defense

AI is already embedded in security tools you're probably using — EDR behavioral detection, email anti-phishing, SIEM anomaly detection, and fraud prevention all use machine learning models. Understanding what AI actually does (and doesn't do) in these tools helps you evaluate vendor claims and set realistic expectations.

AI-Powered Attacks

Securing Your AI Deployments

If your organization uses AI/ML (and it almost certainly does, or will soon), you're responsible for securing those systems. AI introduces unique attack surfaces that traditional security controls don't address:

• Prompt injection: Tricking an LLM into ignoring its instructions and performing unintended actions. If your customer service chatbot can access customer records, prompt injection can leak those records. Defense: input sanitization, output filtering, principle of least privilege for LLM access to data.
• Data poisoning: Corrupting training data to make the model behave incorrectly. If you're fine-tuning models on internal data, an insider could poison the training set. Defense: training data provenance tracking, anomaly detection on training data, model validation before deployment.
• Model theft: Extracting a proprietary model's weights or behavior through repeated queries. If your model represents significant IP, this is a real risk. Defense: rate limiting on model APIs, monitoring for systematic probing patterns, differential privacy techniques.
• Training data extraction: Tricking a model into revealing its training data, which may include sensitive information. GPT-style models have been shown to memorize and reproduce training data under specific prompts. Defense: data minimization in training sets, PII scrubbing before training, output filtering.
• Shadow AI: Employees using public AI tools (ChatGPT, Claude, Gemini, Copilot) with company data without approval. The data goes to third-party servers, potentially violating confidentiality, compliance, and IP protections. Defense: AI acceptable use policy, approved tools list, DLP monitoring for AI platform uploads, sanctioned enterprise AI deployments.