CH3: Network Architecture, Identity, and Data Protection

Introduction

A SOC analyst's job begins with understanding the environments they defend. In Chapter 2, we examined the foundations: logging, operating systems, cloud models, and device management. Now we layer in the architectures and technologies that make modern networks both powerful and complex. How are networks designed to be defensible? How do organizations manage who accesses what? How is data protected as it travels and rests? And how does critical infrastructure, which controls physical systems, differ fundamentally from traditional IT?

This chapter moves from the SOC operations center outward to the networks and identities it monitors. We examine zero-trust architecture, a paradigm shift that assumes all access is suspect until verified. We study how privileged accounts are managed, how encryption protects data in motion and at rest, and how secrets are stored safely. Finally, we encounter operational technology (OT) and industrial control systems (ICS) environments, where a breach doesn't compromise a database, it can halt a power plant or disrupt a hospital's critical devices.

For the blue team, understanding these architectures is not optional. It is the prerequisite for knowing what normal looks like, what indicators matter in each environment, and how to respond when defenses fail.

Learning Objectives

By the end of this chapter, you will be able to:

Explain the philosophical differences between traditional network perimeter security and zero-trust network architecture (ZTNA).
Describe how secure access service edge (SASE) integrates multiple security functions into a unified cloud platform.
Identify the roles and risks associated with privileged access management (PAM) and key components of a PAM solution.
Compare authentication and authorization methods, including single sign-on (SSO), multifactor authentication (MFA), and role-based access control (RBAC).
Analyze encryption techniques for data in transit and at rest, and explain their role in defense-in-depth strategies.
Distinguish between operational technology (OT) and information technology (IT), and explain why OT environments require specialized monitoring and incident response approaches.

3.1 Modern Network Architecture: From Perimeter Defense to Zero Trust

For decades, network security relied on a simple metaphor: the castle and moat. Build strong perimeter defenses, firewalls, intrusion prevention systems, and demilitarized zones, and assume everything inside the perimeter is trustworthy. This model, often called castle-and-moat or perimeter security, works when the network boundary is clear and most users and devices are physically inside the organization.

That assumption no longer holds. Employees work from coffee shops and their homes. Cloud applications live outside the corporate network. Contractors and partners need access to specific resources. Mobile devices connect from unpredictable locations. The perimeter has become invisible and porous.

Zero Trust Network Architecture (ZTNA) is a security framework built on a single principle: never trust, always verify. This means that every access request, whether from an employee, a contractor, a device, or a service, must be authenticated, authorized, and continuously validated, regardless of the requester's location or prior access history.

Core Principles of Zero Trust

The NIST Cybersecurity Framework and the U.S. Department of Defense both endorse zero-trust architectures. The model is built on several key assumptions:

Assumption 1: The network is always compromised. An attacker can be anywhere at any layer, on your internal network, in a cloud provider's infrastructure, or compromised user endpoint. Trust nothing based on location.

Assumption 2: Every access request must be verified. Authentication alone is not enough. Every request must be evaluated against policy: who is the user, what device are they using, where are they connecting from, what resource do they want, and why do they want it at this moment?

Assumption 3: Access must be granted at the minimum necessary level. Even if a user is verified, they get access only to the specific resource they need, for the specific time they need it. This principle is called least privilege or need-to-know.

Assumption 4: Networks should be segmented. Instead of one large internal network, organizations divide their network into smaller, isolated zones. A breach in one zone doesn't automatically grant access to another.

Assumption 5: Defense-in-depth means multiple overlapping controls. A single point of failure should not compromise the entire system. Monitoring, logging, encryption, and network segmentation all work together.

Zero-Trust Architecture in Practice

A practical zero-trust implementation typically includes these components:

Identity-centric access control. Instead of saying "employees on the corporate network can access the file server," a zero-trust system says "Jane's account, using a company-managed laptop, connecting from the Chicago office, can access the HR files folder, and only during business hours."

Device posture checking. Before granting access, the system verifies that the device meets security requirements: the OS is patched, antivirus is active, disk encryption is enabled, and no unauthorized software is installed. A compromised personal laptop may be denied access even if the user's credentials are valid.

Continuous authentication. Access is not granted once and then forgotten. The system continuously re-evaluates whether the session is still valid. If a user accesses resources at 2 AM (unusual for them), or from a geographic location that would be impossible to reach in the time since their last known location, the system may revoke access or demand additional verification.

Microsegmentation. Instead of having one "internal network," the infrastructure is divided into small zones. A user's laptop accesses a gateway for email, a separate gateway for cloud apps, and another for on-premises servers. Each zone enforces its own access policies.

Encrypted end-to-end communication. All traffic, even between internal systems, is encrypted. This means an attacker who gains access to one system cannot simply read the traffic to other systems.

Analyst Perspective

A SOC analyst benefits from zero-trust architecture because it generates visibility. Every access request is logged. Unusual patterns, a user accessing resources at odd hours, from a new location, or outside their normal job function, surface as alerts. In a traditional perimeter-based network, those same activities might go unnoticed because "they're inside the network." In zero-trust, nothing is assumed to be safe just because of location.

Hybrid Cloud and the Expansion of Security Scope

Hybrid cloud describes an environment where workloads run across both on-premises infrastructure and cloud providers (such as AWS, Azure, or Google Cloud). This is the norm in modern enterprises. An organization might run its database on-premises, its email on Microsoft Azure, and its customer-facing web application on AWS. Development teams use local resources, while production services scale in the cloud.

The challenge for the security operations center is that the traditional network perimeter no longer exists. You cannot put a firewall in front of AWS. You cannot segment Azure the same way you segment a corporate LAN. Instead, security must be applied at each layer: network policies in each cloud provider, identity controls in cloud-specific platforms like Azure AD, and monitoring that spans from on-premises systems to cloud APIs.

Security teams must understand:

Cloud provider native controls. AWS has security groups and network ACLs. Azure has network security groups (NSGs). Each cloud provider's controls are slightly different, and misconfiguration is common.
Shared responsibility. The cloud provider manages the physical infrastructure, but the organization is responsible for the operating system, applications, and access controls on its instances.
Cross-cloud data flow. Data moves between on-premises systems and cloud services continuously. That traffic must be monitored and protected regardless of whether it crosses the public internet or a private connection.

A SOC in a hybrid cloud environment must monitor logs from multiple sources: firewalls, on-premises servers, cloud provider audit logs, identity systems, and applications scattered across regions and vendors.

3.2 Identity and Access Management (IAM)

If zero-trust networks require continuous verification, the foundation of that verification is identity. Who are you? Can you prove it? And what are you allowed to do?

Identity and Access Management (IAM) is the discipline of managing user and service identities, authenticating them securely, and controlling what they are authorized to do. A robust IAM system is the gatekeeper of the entire organization.

Privileged Access Management (PAM)

Some identities are more powerful than others. A database administrator can drop entire tables. A domain administrator can create new user accounts and reset passwords for anyone in the organization. A system owner can access sensitive files. These are privileged accounts, and they are high-value targets for attackers.

Privileged Access Management (PAM) is a specialized subset of IAM that focuses specifically on controlling access to and usage of accounts with elevated permissions. The core principle is simple: minimize who has administrative access, log everything those accounts do, and know when they use their privileges.

A mature PAM solution includes:

Privileged identity governance. A formal process determines who should have admin rights. It's not "everyone in IT gets admin." Instead, specific roles require specific privileges, and each assignment must be documented and approved by a manager.

Just-in-time (JIT) access. Instead of giving an administrator permanent admin rights, they get temporary access only when needed. A security engineer might request temporary admin rights on a specific server for 2 hours. The request is logged, approved (or denied) by another administrator, and the access automatically expires after the time limit.

Session recording and monitoring. Everything a privileged account does is recorded. If an administrator connects to a server, that session is captured and can be reviewed later. This creates accountability and provides evidence if something goes wrong.

Password vaulting. Privileged account passwords are stored in a secure, encrypted vault, not in plaintext files or shared among team members. When someone needs to use a privileged account, they request it from the vault, the system logs the access, and the password is retrieved without the human ever knowing the actual password.

Critical Distinction

Privileged Access Management is NOT the same as Active Directory or general user account management. PAM is specifically about controlling high-risk accounts. An organization can have excellent Active Directory governance but still have poor PAM if administrators are sharing passwords or have permanent universal admin rights. PAM is a dedicated system or service, often from vendors like CyberArk, Delinea, or BeyondTrust.

Authentication Methods

Authentication is the process of verifying that someone (or something) is who they claim to be. The first factor is typically a credential: something the user knows (a password), something they have (a key, a hardware token), or something they are (a fingerprint).

Single Factor Authentication relies on one credential type. A password alone is single-factor. It is vulnerable: passwords are guessed, leaked, phished, and shared.

Multifactor Authentication (MFA) combines two or more independent factors. For example:

Something you know (password)
Something you have (your phone, which receives an SMS code, or a hardware security key)
Something you are (your fingerprint, checked on your phone)

The advantage of MFA is that an attacker needs more than just a stolen password. If a phishing email tricks a user into revealing their password, the attacker still cannot log in without the second factor.

Common MFA implementations:

Time-based One-Time Passwords (TOTP). An authenticator app on your phone generates a 6-digit code that changes every 30 seconds. Examples include Google Authenticator and Microsoft Authenticator. The app doesn't require a network connection.

SMS or email one-time codes. A code is sent via SMS text or email. This is convenient but less secure than TOTP because SMS can be intercepted or SIM-swapped.

Hardware security keys. A physical device (like a FIDO2 key) is plugged into the computer or tapped to a phone. It performs cryptographic verification with the server. This is highly secure but requires users to carry an additional device.

Push notifications. A user logs in, and the app on their phone shows a notification asking, "Is this you?" They approve or deny with one tap. This provides some defense against phishing but is vulnerable to push notification fatigue (users approving logins without checking).

Single Sign-On (SSO) and Federation

Users today need access to dozens of applications: email, productivity tools, specialized business applications, cloud services. Asking users to maintain separate passwords for each is impractical and insecure.

Single Sign-On (SSO) allows a user to authenticate once and gain access to multiple applications without re-authenticating. After logging in to the corporate identity system, a user can access Slack, Salesforce, and Jira without entering credentials again.

Common SSO protocols:

SAML (Security Assertion Markup Language). An older, XML-based standard that was widely used in enterprise. An identity provider (like Okta) asserts that a user is authenticated, and the application trusts that assertion.

OAuth 2.0. A newer standard that separates authentication from authorization. It's commonly used for consumer applications (logging in with Google or Facebook) and is increasingly used in enterprises.

OpenID Connect (OIDC). A layer on top of OAuth 2.0 that adds standardized authentication. It's becoming the preferred modern standard.

Federation extends SSO across organizational boundaries. A user from Company A can authenticate using Company A's identity system and gain access to resources at Company B. This is useful for partners, contractors, and acquisitions.

Authorization: RBAC and ABAC

Authentication answers "Who are you?" Authorization answers "What can you do?"

Role-Based Access Control (RBAC) assigns users to roles, and roles have permissions. For example:

Role: Database Administrator. Permissions: Create databases, modify schemas, grant permissions to other users.
Role: Data Analyst. Permissions: Query specific tables, generate reports, export data to CSV.
Role: Intern. Permissions: View read-only dashboards, request access to data by ticket.

RBAC is simple and scalable. An organization might have hundreds or thousands of users, but only a few dozen distinct roles.

Attribute-Based Access Control (ABAC) is more granular. Instead of assigning users to roles, access is determined by policies that evaluate attributes. For example:

If (user department = "Finance") AND (user clearance level = 3) AND (resource classification = "Internal") AND (time is during business hours), then permit.

ABAC is more powerful but also more complex. It allows for much more nuanced policies but requires careful management to avoid misconfiguration.

Secrets Management

In modern applications, code needs to authenticate to databases, APIs, and services. Instead of hard-coding passwords in the application, secrets management systems store and control access to credentials.

A secret is any credential needed to access a resource: database passwords, API tokens, SSH keys, encryption keys. A proper secrets management solution includes:

Secure storage. Secrets are encrypted at rest. Even if someone breaches the secrets manager database, they cannot read the secrets without the encryption key.

Access control. Access to a secret is logged and can be restricted by policy. An application running on server A can access its database password, but a random server cannot.

Rotation. Secrets are automatically rotated on a schedule or on demand. A database password might be rotated every 90 days. If a password is compromised, rotation limits the time window in which it can be exploited.

Audit logging. Every access to a secret is logged, including when, by whom or what, and why.

Examples of secrets management platforms include HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Kubernetes Secrets.

Analyst Perspective

From a SOC perspective, secrets management is a visibility challenge. If your organization rotates secrets frequently, you need to monitor for legitimate applications failing to authenticate (they're using an old secret). You also need to look for suspicious secret access: a user or service accessing secrets they shouldn't need. A well-configured secrets manager logs every access, giving analysts data to correlate with other security events.

3.3 Encryption Techniques

Encryption is a fundamental defense against unauthorized access to data. It answers a simple question: if an attacker gains physical or logical access to data, can they read it?

Symmetric Encryption

Symmetric encryption uses a single key to encrypt and decrypt data. If you want to send an encrypted message, you encrypt it with the key, and the recipient decrypts it with the same key.

Examples include AES (Advanced Encryption Standard), which is the U.S. government standard. AES-256 uses a 256-bit key and is considered secure against current and foreseeable computational attacks.

The challenge with symmetric encryption is key distribution. How do you securely give the key to the recipient? If the key travels over the same insecure channel as the message, an attacker can intercept both.

Symmetric encryption is fast and efficient, making it ideal for encrypting large amounts of data, like a hard drive or a database.

Asymmetric (Public-Key) Encryption

Asymmetric encryption uses two mathematically related keys: a public key and a private key. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

Example use case: A user wants to send an encrypted message to Company A. The user encrypts the message with Company A's public key. Company A decrypts it with their private key. Even if an attacker intercepts the public key, they cannot decrypt the message.

The mathematics are such that deriving a private key from the public key is computationally infeasible (as of 2026). Common asymmetric algorithms include RSA and elliptic-curve cryptography (ECC).

The advantage is that public keys can be shared freely, they're public. The private key never needs to be transmitted. The disadvantage is that asymmetric encryption is slow. It's impractical to encrypt large amounts of data asymmetrically.

Encryption in Transit vs. at Rest

Encryption in transit (or in motion) protects data while it travels over networks. When a user connects to a website, TLS (Transport Layer Security) encrypts the data in both directions. The user's browser and the web server authenticate each other (the server proves it is who it claims to be), and then all traffic is encrypted symmetrically using a session key negotiated during the TLS handshake.

Other protocols that encrypt in transit:

VPN (Virtual Private Network). Encrypts all traffic from a user's device to a company network, protecting it from eavesdropping on public Wi-Fi.
HTTPS. TLS on top of HTTP, standard for web browsing.
SSH. Secure shell for remote command-line access.
SFTP. Secure file transfer.

Encryption at rest protects data stored on disks, in databases, and in backups. This includes:

Disk encryption. Tools like BitLocker (Windows) and FileVault (macOS) encrypt an entire disk. If a laptop is stolen, the data is inaccessible without the correct key or passphrase.
Database encryption. Records in a database are encrypted before being written to disk. Even if an attacker accesses the database files directly, they cannot read the plaintext data.
Backup encryption. Backups stored off-site or in the cloud are encrypted so that the backup provider cannot read the data.

The two are complementary. Encryption in transit prevents an attacker on the network from reading data. Encryption at rest prevents an attacker with access to the storage device from reading data. A defense-in-depth strategy uses both.

Encryption Key Management

Encryption is only as strong as key management. If encryption keys are poorly protected, the encryption is useless.

Key generation. Keys should be generated using a cryptographically secure random process, never by humans. A human-generated "password" like "MySecret123" is orders of magnitude weaker than a 256-bit randomly generated key.

Key storage. Keys should be stored securely, typically in a hardware security module (HSM) or a key management service (KMS). These systems protect keys from being read, even by administrators.

Key rotation. Keys should be rotated on a schedule or when there is reason to believe they may have been compromised. Older keys are retained for decryption of archived data, but new encryption uses the new key.

Key escrow and recovery. Organizations should have a process for recovering encrypted data if the original key is lost, but this process must be tightly controlled to avoid unauthorized access.

3.4 Data Protection Concepts

Encryption is a tool, but data protection is a broader discipline that includes understanding what data exists, where it lives, who needs access, and what controls protect it.

Data Classification

Not all data has the same risk. A public-facing website about company information has a different risk profile than employee salaries or medical records.

Data classification assigns a level to data based on sensitivity and potential impact if disclosed:

Public. Can be shared freely. Marketing materials, published blog posts.
Internal. Should not be disclosed outside the organization, but is not restricted within. Most company documentation.
Confidential. Restricted to a need-to-know basis. Employee information, internal financial data, customer relationships.
Restricted. Highly sensitive. Health information, financial records, intellectual property. May be subject to legal or regulatory protection.

Classification affects how the data is protected: where it is stored, who can access it, what encryption is applied, and how long it is retained.

Data Loss Prevention (DLP)

Data Loss Prevention (DLP) systems monitor and prevent unauthorized transmission of sensitive data.

A DLP system might:

Monitor emails. If a user tries to email a list of salaries or customer credit cards, the email is blocked and the user is warned.
Monitor file transfers. If a user tries to upload a confidential document to a personal cloud storage account (Dropbox, Google Drive), the system blocks it.
Monitor printing. If a user tries to print a document labeled "Confidential," the printer may refuse or log the print job for review.

DLP can be rule-based (block emails containing credit card patterns) or pattern-based (learn what normal data transfers look like and alert on anomalies).

Putting It Together: Data Protection in a Hybrid Environment

Imagine a financial services company with:

On-premises databases containing account information (confidential).
A data warehouse in AWS for business intelligence (confidential).
A Salesforce instance for customer relationship management (internal).
Employee laptops with local copies of reports (confidential).

The company's data protection strategy might include:

Classification. All account data is labeled "Confidential."
Encryption. Database encryption in both on-premises and AWS. TLS for data in transit between systems.
Access control. Only financial analysts can access account data. Access is via SSO with MFA.
Monitoring. Logging for all database queries. Alerts for unusual access patterns (an analyst querying accounts outside their region, or at 3 AM).
DLP. Employees cannot email customer account data. Reports can be generated but are watermarked and cannot be saved locally.
Secrets management. Database passwords are rotated monthly and stored in a vault. Applications retrieve passwords at runtime.
Data retention. Account data is deleted after 7 years per regulatory requirement.

When a SOC analyst investigates a suspected data breach, they look at logs from all these layers: Did someone access the database with unusual credentials? Did they transfer data to an external service? Did a DLP rule fire when data was exfiltrated?

3.5 Critical Infrastructure: Operational Technology and Industrial Control Systems

Most of the infrastructure you interact with daily, power grids, water treatment facilities, traffic signals, hospital equipment, runs on Operational Technology (OT), not the information technology (IT) you are familiar with.

OT vs. IT: Fundamental Differences

Information Technology (IT) is what we've discussed so far: computers, networks, applications, databases. IT systems are designed for confidentiality, integrity, and availability of information. A breach might steal data or disrupt a service, but the physical world isn't directly affected. If a payroll system is down for an hour, employees aren't paid on time, but no one is physically harmed.

Operational Technology (OT) is technology that directly controls physical processes. A power plant's control system regulates voltage and frequency. A hospital's infusion pump delivers medication. A water treatment facility manages chemical dosing. OT systems are designed for availability and safety. They must not fail, and they must operate safely.

The differences create distinct security challenges:

Aspect	IT	OT
Primary Goal	Confidentiality, Integrity, Availability	Availability, Safety, Reliability
Uptime Requirement	Hours to days tolerable	Often 24/7/365, any downtime is serious
Change Management	Patches applied regularly	Changes are planned, tested, and scheduled far in advance
Network Access	Constantly connects to new systems and networks	Relatively static, designed to be isolated
Monitoring	Security monitoring, intrusion detection	Process monitoring, system health
Typical Lifespan	3-5 years	15-30 years
Default Posture	Zero-trust (verify everything)	Presumed safety (trust the system)

Industrial Control Systems (ICS) and SCADA

Industrial Control Systems (ICS) are the broad category of systems that control physical processes. Supervisory Control and Data Acquisition (SCADA) systems are a specific type of ICS used in utilities and critical infrastructure.

A SCADA system includes:

Sensors and programmable logic controllers (PLCs). Devices installed at the facility measure conditions (temperature, pressure, flow rate) and execute commands (open a valve, increase pump speed).

Remote Terminal Units (RTUs). Devices that communicate between sensors/PLCs and a central control station.

Human-Machine Interface (HMI). A human operator sees dashboards showing the state of the system (the power plant is currently generating 500 MW) and can issue commands (increase generation by 10 MW).

Historian. A database that logs all sensor readings and commands for auditing and analysis.

A typical SCADA system might be designed like this:

Sensors/PLCs <--Modbus/DNP3--> RTU <--Ethernet--> Central Station/HMI <-- Historian

The communication protocols (Modbus, DNP3, Profibus) were designed in the 1970s-1990s, long before cybersecurity was a primary concern. They typically lack authentication and encryption.

Security Challenges in OT Environments

Legacy systems and long lifecycles. A SCADA system installed in 2005 may still be in use in 2026. The operating system may be unsupported, patches are unavailable, and replacement is prohibitively expensive.

Safety-first design. Unlike IT systems, OT systems are designed so that failure is safe. A SCADA system that can't communicate with the control center will shut down the process safely, not continue blindly. Security measures that interfere with safety are rejected.

Limited monitoring. Traditional OT systems were not designed for comprehensive security logging. Adding detailed logging and monitoring can impact performance and may require upgrades the facility cannot afford.

Isolation expectations. OT systems were traditionally isolated from corporate IT networks. They ran on separate networks with minimal external connectivity. Today, organizations want to integrate OT and IT for efficiency (remote monitoring, predictive maintenance using machine learning), but integration increases attack surface.

Insider threats and operator access. Unlike IT systems, OT systems often have operational staff who need hands-on access: maintenance engineers, shift operators, field technicians. Controlling that access without hampering legitimate operations is difficult.

Case Study: Colonial Pipeline (2021)

In May 2021, the Colonial Pipeline, which supplies 45% of the East Coast's fuel, suffered a ransomware attack that shut down operations for 6 days. The attack was attributed to the group DarkSide.

What happened:

Attackers gained access via a legacy VPN account that had no multifactor authentication.
They moved laterally through the network to the operational technology environment where the pipeline control systems run.
They deployed ransomware that encrypted critical systems, rendering the pipeline unable to safely operate.
The company shut down operations to assess the damage and prevent further spread.

Impact:

5.55 million barrels of fuel were not delivered.
Gas prices spiked, and some stations ran out of fuel.
The company paid a $4.4 million ransom (though law enforcement later recovered the majority of the funds).

Security failures:

No MFA on a remote access VPN account, which is a legacy protocol used for administrative access.
Insufficient network segmentation between IT and OT systems.
Limited visibility into the OT network, so attackers had time to move laterally before being detected.

Lessons Learned:

Legacy access methods are high-value targets. A forgotten VPN account with no MFA is a critical vulnerability.
OT and IT should be segmented. Even if attackers compromise the corporate IT network, they should not automatically have access to industrial control systems.
Monitoring OT is different. You cannot simply apply IT security best practices to OT. The Colonial Pipeline did not detect the attack because monitoring was insufficient and alerts for unusual activity were not properly configured.

Critical Distinction

Defending OT requires specialized knowledge. A SOC analyst who has only worked with IT systems should not assume their knowledge transfers directly to OT. OT systems have different protocols, different failure modes, and different consequences for disruption. Organizations operating critical infrastructure should have OT-specific security teams or consultants.

3.6 Putting It Together: Designing Secure Access in a Modern Environment

A financial services company needs to design access controls for a hybrid environment: on-premises core banking systems, customer-facing applications in AWS, and development teams using cloud IDEs and collaboration tools.

Zero-trust network architecture requires:

Identity as the primary control. Employees log in via SAML/OIDC with MFA. Contractors use federated identity from their company. Service accounts retrieve credentials from a secrets manager.
Device posture checking. Before accessing core banking systems, a laptop must prove it is company-managed, has antivirus active, and is running the latest OS patches.
Microsegmentation. Core banking systems are isolated from cloud applications. A developer cannot access banking systems even if their credentials are compromised. Separate networks and firewalls enforce this.
Continuous authentication. If a developer logs in from a new country (they're traveling), their access to sensitive systems is temporarily blocked pending additional verification.
Audit logging. Every access is logged: who (user), what (resource), when (timestamp), where (IP, device), and why (requested access to project X).
Data encryption. Customer data is encrypted in the database and in transit between systems.
Secrets management. Banking system credentials are stored in a vault, rotated monthly, and accessed only by applications.

When a suspicious event occurs, say, an account is used to access resources from an unusual location, the SOC analyst can correlate data:

Identity logs: Did the user actually authenticate from that location?
Device logs: What device was used? Is it company-managed?
VPN/proxy logs: What path did the traffic take?
Application logs: What resources were accessed and what actions were taken?
DLP logs: Was sensitive data downloaded or transferred?

This defense-in-depth approach ensures that a single compromised credential or device does not immediately grant full access to the entire environment.

Chapter Summary

Zero Trust Network Architecture (ZTNA) abandons the perimeter security model and assumes all access is suspicious until verified. It emphasizes identity-centric access, device posture checking, microsegmentation, and continuous authentication.
Hybrid cloud environments span on-premises and cloud providers, creating complex security scopes that require monitoring and control across multiple platforms and providers.
Privileged Access Management (PAM) focuses on high-risk accounts, using techniques like just-in-time access, session recording, and password vaulting to limit and log privileged activities.
Authentication verifies identity. Multifactor authentication (MFA) combines two or more independent factors (something you know, have, or are) to improve security.
Single Sign-On (SSO) allows users to authenticate once and access multiple systems via protocols like SAML, OAuth 2.0, or OpenID Connect.
Authorization controls what authenticated users can do. Role-Based Access Control (RBAC) assigns permissions to roles, while Attribute-Based Access Control (ABAC) uses policies to evaluate permissions based on attributes.
Secrets management systems store and control access to credentials, including encryption keys, database passwords, and API tokens.
Encryption in transit (TLS, VPN) protects data while traveling over networks. Encryption at rest (disk encryption, database encryption) protects stored data.
Data classification assigns sensitivity levels to data, which determines access controls, encryption, and retention policies.
Data Loss Prevention (DLP) systems monitor and prevent unauthorized transmission of sensitive data.
Operational Technology (OT) differs fundamentally from Information Technology (IT). OT systems prioritize availability and safety, have long lifecycles, and use legacy protocols. SCADA systems in critical infrastructure have unique security challenges.
Critical infrastructure attacks, like the 2021 Colonial Pipeline ransomware attack, can have cascading impacts on public safety and the economy. OT-specific monitoring and segmentation are essential.