CH2: System and Network Architecture in Security Operations

Introduction

Risk and controls exist in context. The most carefully designed risk management strategy fails if the infrastructure that implements it is poorly designed, inadequately monitored, or fundamentally misunderstood by the teams responsible for its operation. In this chapter, we shift perspective from strategic governance to operational reality: the systems, networks, and devices that a SOC analyst monitors every day.

A SOC analyst's primary responsibility is to understand the environment being defended. What systems are running? What data flows across the network? Where are logs being collected from, and are they reliable? What architecture decisions create security gaps or blind spots? How do cloud, virtualization, and containerization change the monitoring problem? Without this foundational understanding, an analyst cannot effectively detect threats or respond to incidents.

This chapter establishes the operational context for the rest of the course. We will examine the SOC's role, logging architecture, operating system fundamentals, modern infrastructure (cloud, containers, APIs), and device management strategies.

Learning Objectives

Upon completion of this chapter, students will be able to:

Explain the core responsibilities and workflow of a SOC analyst
Identify and configure logging at the operating system and application levels to support threat detection
Evaluate operating system security controls including hardening, file system structure, and process management
Analyze infrastructure architectures including cloud-native, virtualization, containerization, and API ecosystems
Assess device management strategies for mobile and endpoint systems in organizational security posture

2.1 The Security Operations Center: Role and Responsibilities

The Security Operations Center (SOC) is the "nerve center" of an organization's security program. It is the team that monitors systems 24/7, detects incidents, and initiates response. Understanding what SOC analysts do, and what they cannot do, is essential for designing monitoring infrastructure and incident response processes.

SOC Analyst Workflow: From Alert to Escalation

A typical SOC analyst's day involves:

Alert Monitoring and Triage: Analysts monitor a queue of security alerts generated by detection tools (SIEM, IDS, EDR, firewalls, etc.). Each alert requires triage: determining whether it represents a real security event or a false positive. This is critical because SOCs receive thousands of alerts per day; without effective filtering, analysts spend 80% of their time investigating alerts that are not real incidents.

Triage requires:

Understanding the alert rule and what behavior triggered it
Checking for context: Is the user or system known? Is the behavior consistent with baseline operations?
Correlating the alert with other logs to confirm or refute the alert's premise
Classifying the alert (true positive, false positive, informational, or escalate for deeper investigation)

Investigation: When an alert is classified as a potential true positive, the analyst conducts an initial investigation. This involves:

Reviewing logs from the affected system or user
Checking for lateral movement or data exfiltration
Identifying the scope of compromise (one user, one system, or multiple systems)
Determining if the incident is contained or still ongoing

Escalation Decision: Based on the investigation, the analyst decides whether to:

Close the alert (confirmed false positive or non-malicious activity)
Create a ticket for tracking and assign it a severity level
Escalate to an incident response team if the incident is confirmed and requires deeper forensics or remediation
Escalate to management and legal if the incident involves sensitive data or regulatory implications

Documentation and Communication: Throughout this workflow, analysts document their findings in ticketing systems, write notes in the incident record, and communicate status to stakeholders. This documentation is critical for the incident response team and for post-incident analysis and metrics.

SOC Tiers and Career Progression

Most SOCs organize analysts into tiers based on skill, experience, and responsibility:

Tier 1 (T1) Analysts are typically early-career analysts with less than 2 years of SOC experience. They focus on:

Alert triage and initial investigation
Running playbooks (documented procedures) for common alert types
Gathering evidence and initial log review
Filtering false positives and informational alerts
Escalating true positives to Tier 2

T1 is the entry point to SOC work and often has the highest turnover because the work is repetitive and the on-call requirements are demanding. Organizations invest in T1 training and mentorship to develop career analysts.

Tier 2 (T2) Analysts have intermediate experience (2-5 years) and deeper technical skills. They focus on:

Complex incident investigation and analysis
Developing new detection rules and improving existing rules
Threat hunting: proactively searching logs for signs of compromise
Supporting T1 with escalations and complex cases
Tuning alerting to reduce false positives

T2 work is more investigative and creative. T2 analysts spend time understanding the threat landscape, building expertise in specific attack techniques, and improving the organization's detection capability.

Tier 3 (T3) Analysts are expert-level analysts (5+ years) who focus on:

Deep forensic analysis and malware analysis
Developing automation and playbooks
Advanced threat hunting and hunt hypothesis development
Architecture and tool recommendations
Training and mentorship of T1 and T2 analysts

T3 analysts often transition into management, architecture, or specialized roles (incident response manager, threat intelligence, forensics).

SOC Operations and Staffing Models

Because threats do not respect business hours, SOCs must operate 24/7/365. Common staffing models include:

Shift-based: Multiple teams on rotating shifts (day, evening, night). Typically requires 3-4 teams to cover 24/7 with time off and overlap for knowledge transfer.
Follow-the-sun: Teams in multiple geographic locations (e.g., one team in the U.S. East, one in Europe, one in Asia), so coverage shifts naturally as the sun moves around the globe.
On-call rotation: A small team handles non-critical alerts during business hours; additional analysts are on-call outside business hours for critical incidents.

Staffing is expensive and challenging. A SOC requires not just analysts but also SOC engineers (who maintain tools and infrastructure), tool administrators, and managers. Organizations struggle to find and retain skilled SOC analysts because the on-call requirements, burnout from alert fatigue, and lower salaries compared to other security roles make retention difficult.

Analyst Perspective

If you are considering a SOC career, understand that the first year is often the hardest. You will see thousands of alerts and investigate false positives frequently. Your value comes from the quality of your investigation, the accuracy of your triage, and your ability to learn the environment, more than from the number of alerts you close. The analysts who succeed are those who build expertise in their organization's specific systems, understand what "normal" looks like, and ask good questions when something looks suspicious.

2.2 Logging Architecture and Ingestion

Effective SOC operations depend on comprehensive, reliable logging. But logging is not free: collecting, storing, and analyzing logs requires infrastructure, bandwidth, and expertise. Understanding what to log, how to log it reliably, and how to retain it cost-effectively is a key responsibility of SOC engineers and security architects.

Logging Fundamentals

Logging is the process of recording timestamped events for later analysis. A log is simply a record that something happened: a user logged in, a file was accessed, a process started, a firewall rule matched, a database query ran. Logs are the primary data source for threat detection, incident investigation, and compliance auditing.

Log sources include:

Operating systems (Windows Event Logs, syslog, auditd): Record authentication, process execution, file system changes, and system configuration changes
Applications (web servers, databases, email servers): Record application-specific events like user login, transaction, or configuration changes
Network devices (firewalls, routers, switches): Record allowed and denied traffic, configuration changes, and system events
Cloud services (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs): Record API calls, identity and access management changes, resource provisioning
Security tools (EDR agents, DLP, IDS, scanners): Record potential threats and suspicious behavior

Logging Infrastructure: Collection and Aggregation

A mature logging architecture has three components: collection, aggregation, and storage/analysis.

Collection begins at the log source. Operating systems and applications write logs to local storage or send them to a collector. Common collection mechanisms:

Syslog: A standard protocol for sending logs over UDP or TCP. Most Unix/Linux systems use syslog; many appliances and cloud services support syslog export.
Windows Event Log Forwarding: Windows systems forward event logs to a Windows Event Collector or a third-party agent
Sysmon (System Monitor): A Microsoft Sysinternals tool that records process, network, registry, and file system activity in far more detail than the standard Windows Event Log. Section 2.3 covers what it captures and how it is configured.
Agents: Third-party agents (EDR, logging service agents, SIEM agents) installed on systems to collect and forward logs
APIs: Cloud services export logs through APIs that agents or collectors retrieve

Syslog Levels

Syslog assigns each event a severity level from 0 (most severe) to 7 (least severe):

Level	Name	Description
0	Emergency	System is unusable
1	Alert	Immediate action is required
2	Critical	Critical condition, such as a hardware or application failure
3	Error	Error condition that may affect operations
4	Warning	Warning about a possible problem
5	Notice	Significant normal condition
6	Informational	General operational information
7	Debug	Detailed diagnostic information

Do not automatically collect all syslog levels. In particular, informational and debug events can generate very large volumes of data, increasing storage requirements and costs. Collect the levels needed for security monitoring and troubleshooting, and enable more verbose levels selectively when investigating a specific issue.

Aggregation collects logs from many sources and normalizes them into a searchable format. The aggregation layer typically includes:

A log collector/forwarder (Beats, Logstash, Fluentd, native agents) that runs on systems and sends logs to a central platform
A log aggregation platform (Splunk, Elastic Stack, Sumo Logic, CloudWatch, Stackdriver) that receives logs, parses them, extracts fields, and stores them in an index for searching

Aggregation must handle the high volume of logs. A busy organization can generate terabytes of log data per day. The aggregation platform must be able to ingest, parse, and index this volume without losing data or falling behind.

Storage and Analysis stores logs for a defined retention period and provides search and analysis capabilities. Key considerations:

Hot storage (immediate access): Recently ingested logs are stored on fast disks and can be searched in seconds
Warm storage (slower, older logs): Older logs are moved to slower storage with slightly longer search times but lower cost
Cold storage (archival, compliance only): Very old logs are archived (often compressed) for regulatory retention requirements but are rarely searched
Search performance: The ability to search and correlate logs across days or weeks of data is essential for incident investigation

Log Configuration and Collection Strategy

Not all logs are equally valuable, and collecting everything creates its own problems. A mature organization thinks strategically about what to log:

High-value log sources (always log):

User authentication (success and failure)
Privileged account activity (anyone with admin or root access)
System configuration changes (firewall rules, user accounts, services)
Database access and queries (especially to sensitive tables)
File access to sensitive data (document management systems, data repositories)
Network connections from unusual ports or to external IP addresses
Process execution (what programs are running and who started them)

Medium-value log sources (log unless volume is prohibitive):

Application errors and warnings
Failed access attempts (file access, API calls)
Scheduled task execution
Network traffic (for organizations with network telemetry)

Lower-value log sources (selective logging):

Informational events (successful routine operations that do not indicate security significance)
Verbose application logging (often creates noise)
Routine file access and read operations (volume is typically very high; selective logging is more practical)

A common challenge is log tuning: reducing noise while maintaining visibility. An organization might log all process execution events (high value for threat detection) but find that this creates so much volume that it becomes cost-prohibitive and hard to analyze. Tuning might mean:

Logging process execution only for certain users (e.g., admin accounts)
Excluding known legitimate processes (e.g., Windows antivirus processes)
Aggregating routine events (e.g., daily summary instead of every event)

Log Integrity and Tamper Detection

Logs are evidence. If an attacker can modify or delete logs, they can hide their tracks. If logs are corrupted or lost, investigators cannot determine what happened. Log integrity is therefore a critical control.

Cryptographic signing ensures that logs cannot be modified without detection. Each log entry is signed with a cryptographic hash. If the log is modified, the signature becomes invalid. Some logging systems use blockchain-style chaining, where each log entry is signed together with the previous entry, making it impossible to modify any entry without invalidating all subsequent entries.

Immutability means logs cannot be modified or deleted. This can be enforced technically (write-once-read-many storage) or procedurally (separation of duties: analysts can read logs but only administrators can delete them, and deletion is logged and audited).

Tamper detection and monitoring continuously checks log integrity. Any attempt to modify or delete logs triggers an alert. Some systems send logs to immutable external storage immediately after writing to prevent tampering.

Critical Distinction

A log that has been tampered with may be worse than no log at all, because it provides false evidence. If an attacker can modify logs, they can create a false timeline, hide their activities, or implicate innocent parties. Log integrity protections (encryption, signing, immutability) must be considered as important as collecting the logs in the first place.

Time Synchronization

Logs are only useful if their timestamps are accurate and consistent. If one system's clock is 1 hour behind another system's clock, a timeline of events will be incoherent: something that actually happened at 14:00 on system A and 15:00 on system B will appear to have happened in reverse order.

Network Time Protocol (NTP) is the standard for keeping system clocks synchronized. Systems should synchronize their clocks to NTP servers at least daily, and more frequently (every 5-30 minutes) during normal operation.

Clock skew is the difference between a system's clock and the true time. Even with NTP, some skew is normal; the goal is to keep skew under 1 second. Large skew (> 5 seconds) indicates either a system time configuration problem or a security issue (an attacker might change system time to hide their activities or to cause log entries to be discarded).

Time zone handling is also important. An organization with systems in multiple time zones should standardize on Coordinated Universal Time (UTC) for all log entries. Converting to local time for analysis is simple; converting from local time back to UTC is error-prone.

Forensic accuracy depends on correct timestamps. In a investigation, you might need to establish the exact sequence of events: when was a system compromised, when was data exfiltrated, when were logs deleted? Even a 1-minute error in timeline can obscure the sequence and weaken forensic conclusions.

Log Retention and Lifecycle

Log storage is expensive, and retention requirements vary by regulation and industry. An organization must balance retention requirements, compliance mandates, cost, and the need to maintain search performance.

Retention requirements are driven by:

Regulatory requirements: HIPAA requires 6 years of healthcare records; PCI DSS requires 1 year of logs; GDPR requires retention only as long as necessary for the purpose; SOX requires 7 years for financial records
Business requirements: Organizations may want to retain logs longer than required (for long-term trend analysis or cold cases)
Incident response needs: You cannot investigate a breach that happened 3 years ago if you only keep 1 year of logs. Some organizations extend retention for critical systems.

A typical retention strategy uses tiered storage:

Hot tier (1-3 months): Recently ingested logs available for immediate search. Stored on fast SSD or NVMe storage. Highest cost per gigabyte but enables fast investigations.
Warm tier (3-12 months): Older logs moved to slower disk storage. Search takes longer (seconds to minutes instead of milliseconds) but cost per gigabyte is lower.
Cold tier (1-7 years): Archived logs, typically compressed. May require hours to retrieve and search. Used mainly for compliance and rare investigations. Cost per gigabyte is very low (sometimes pennies).

Many organizations find that 1-3 months of hot storage is cost-effective because most incident investigations require recent logs. Warm storage for longer-term trend analysis and cold storage for compliance and rare cases where you need to investigate events from years ago.

2.3 Operating System Security Fundamentals

Before a SOC analyst can detect attacks on a system, the analyst must understand the system: its normal operation, its security mechanisms, and how to interpret its logs.

OS Hardening Concepts

Hardening is the process of reducing the attack surface by removing unnecessary services, ports, and features. A default OS installation often includes services and features that are unnecessary in a particular environment and increase the attack surface.

An attack surface is the total of all possible entry points that an attacker can use. The more services running, the more ports open, and the more features enabled, the larger the attack surface. Hardening reduces the attack surface by disabling or removing unnecessary components.

For example, a Windows Server that is configured as a web server does not need: - Remote Desktop Services (if not needed for administration) - File and Printer Sharing (if not needed to share files with other systems) - Windows Fax and Scan (rarely used in server environments) - Bluetooth (unnecessary on a server)

Disabling these features reduces the attack surface. If a vulnerability in Bluetooth driver is discovered, it cannot be exploited if Bluetooth is disabled.

Security baselines are standardized configurations for specific OS and use cases. Reputable sources include:

CIS Benchmarks (Center for Internet Security): Community-developed benchmarks for most operating systems and applications. CIS Level 1 is appropriate for most organizations; CIS Level 2 is suitable for high-security environments.
DISA STIGs (Defense Information Systems Agency, Security Technical Implementation Guides): U.S. Department of Defense technical standards for secure system configuration. Very detailed and often very restrictive; typically used for government systems.
Vendor best practices: Most vendors (Microsoft, Red Hat, etc.) publish hardening guidance and configuration baselines

A hardening workflow typically involves:

Selecting an appropriate baseline for the OS and use case
Creating a hardened OS image using automated configuration tools
Testing the hardened image against security and operational requirements
Deploying the image to production systems
Continuously monitoring for configuration drift (changes that compromise hardening)

File System Structure and Permissions

Different operating systems organize files differently, but the principle is the same: restrict access to critical files based on the principle of least privilege (users and processes should have only the minimum permissions needed to perform their function).

Windows NTFS (New Technology File System) is the modern Windows file system. It supports:

Access Control Lists (ACLs): Detailed per-file/folder permissions. Each ACL can grant or deny permissions for specific users, groups, or service accounts.
Permission types: Read (view file contents), Write (modify), Execute (run programs), Take Ownership, Delete, Modify Permissions, etc.
Inheritance: Permissions can be inherited from parent folders, reducing administration burden but requiring careful planning
Ownership: Files have an owner (typically the creator) who can change permissions

Critical Windows directories and their typical protections:

C:\Windows\System32\: Contains core system binaries. Only administrators should be able to modify files here.
C:\Windows\System32\drivers\etc\hosts: The hosts file that maps hostnames to IP addresses. A compromised hosts file can redirect network traffic. Only administrators should be able to modify it.
C:\ProgramData\: Application data directories. Applications should have write access to their own directories but not to others'.
User profile directories (C:\Users\username\), Each user's personal files. Users should have read/write access to their own profile but not others'.

Linux/Unix file permissions are simpler than NTFS but still powerful:

Three permission types: Read (r), Write (w), Execute (x)
Three categories: Owner (user), Group, Others
Notation: -rwxr-xr-x means owner can read/write/execute, group and others can read/execute only

Critical Linux directories and their typical protections:

/etc/passwd and /etc/shadow, User authentication. /etc/shadow must be readable only by root.
/etc/sudoers: Defines which users can run administrative commands. Only root should be able to modify it.
/root/: Root's home directory. Only root should have access.
/tmp/: Temporary directory. All users can write here, but execute permissions should be restricted to prevent execution of temporary files
/var/log/: Log directories. Only root should be able to delete or modify logs (to prevent tampering).

Process and Execution Management

A process is a running instance of a program. Process management is essential for security because:

Understanding what processes are running helps detect malware (unexpected processes)
Restricting who can execute programs prevents unauthorized code execution
Monitoring process activity (file access, network connections, parent-child relationships) reveals malicious behavior

Process lifecycle:

Creation: A parent process (often the shell or application launcher) creates a new process by calling an OS system call
Execution: The process runs, using memory, CPU, and other resources
Child processes: A running process can create child processes (e.g., a shell script that calls other programs)
Termination: The process ends and releases its resources

Understanding the parent-child process relationship is important for forensics. Malware often starts as a child process of a legitimate application (e.g., a Word macro spawning cmd.exe). The parent-child chain reveals how the process was started.

Privileged processes are processes that run as root (Linux) or System (Windows). These processes have access to all system resources and are common targets for privilege escalation attacks. A malware that can run a shell as root has complete control of the system.

Service accounts are special user accounts used to run background services (databases, web servers, etc.). Service accounts typically have permissions limited to what the service needs (e.g., a database service account has read/write access to the database directory but no user login capability).

Application allowlisting (also called whitelisting or "application control") restricts which programs can run. Instead of trying to block known malware (blacklisting, which is always incomplete), an allowlist specifies exactly which programs are permitted. Any other program is blocked. This is a strong control but requires careful configuration because legitimate updates and new applications must be added to the allowlist.

Memory protections defend against certain attack techniques:

Data Execution Prevention (DEP) marks memory regions as non-executable. Code cannot run from data regions, preventing attacks that inject malicious code into data areas.
Address Space Layout Randomization (ASLR) randomizes the memory addresses of programs and libraries. This prevents attackers from reliably targeting specific memory addresses in their exploits.
Code signing and integrity checking ensure that programs and libraries have not been modified. Operating systems can verify signatures and refuse to run unsigned code.

Security Event Logging in OS

Operating systems generate security events that are invaluable for threat detection and forensics.

Windows Event Log categorizes events by type:

Security log: Authentication events (logon success/failure, user account creation, password changes, privilege changes), file access, object access, policy changes, privilege use
System log: Service failures, driver loading, system startup/shutdown
Application log: Application-specific events
PowerShell log (on modern Windows): PowerShell command execution and script activity (critical for detecting living-off-the-land attacks)

Key security event IDs to monitor (examples):

Event ID 4624 (Logon Success): A user successfully authenticated. Baseline: how many logons per user per day? Spike: possible brute force or account compromise.
Event ID 4625 (Logon Failure): A logon failed. Baseline: occasional failures are normal; high failure rates indicate brute force attempts.
Event ID 4688 (Process Creation): A process was started. Essential for detecting malware execution or living-off-the-land attacks (using legitimate tools for malicious purposes).
Event ID 4698 (Scheduled Task Created): A scheduled task was created. Used to detect malware persistence mechanisms.
Event ID 4720 (User Account Created): A new user account was created. Can indicate an attacker establishing persistence.

Linux auditd is the Linux audit framework. It provides fine-grained monitoring of system calls, file access, and authentication. Example audit rules:

-w /etc/passwd -p wa -k passwd_changes
-a always,exit -F dir=/home/ -F perm=x -F auid>=1000 -k unauthorized_execution
-a always,exit -F arch=b64 -S execve -k executed_commands

These rules monitor password file changes, executable file access in user directories, and all command execution, respectively.

Analyst Perspective

OS-level logging is foundational. If you cannot see what processes are running or what files are being accessed, you cannot detect malware. Ensure that systems are configured to log security events, that logs are centrally collected and retained, and that your SIEM has rules to detect suspicious patterns (logon spikes, process execution from unusual locations, privilege escalation).

Extending Windows Logging with Sysmon

The native Windows Event Log answers many investigative questions, and it leaves gaps in several of the ones analysts ask most often. Event ID 4688 records that a process started, but it omits the hash of the file that ran, and it records the command line only after an administrator enables two settings that are off by default: the Audit Process Creation subcategory, and the policy "Include command line in process creation events." Windows also has no practical way to record one process opening a handle to another, and its per-process view of domain name resolution is limited to the DNS Client operational log, which is disabled by default and does not capture queries answered from cache.

System Monitor (Sysmon) closes those gaps. Sysmon is a free tool in the Microsoft Sysinternals suite that installs as a Windows service with a boot-start device driver, so it captures activity from early in the startup sequence. It writes to its own log, which appears in Event Viewer under Applications and Services Logs > Microsoft > Windows > Sysmon > Operational and is addressed by Get-WinEvent and wevtutil by its channel name, Microsoft-Windows-Sysmon/Operational. Sysmon has no alerting engine and ships no detection content, so organizations use it as a telemetry source and leave detection to the SIEM. Recent versions do add a small set of blocking rules, including FileBlockExecutable (Event ID 27) introduced in Sysmon 14.0, which prevents an executable file from being written rather than only recording it.

The Sysmon events an analyst uses most:

Event ID	What it records	Why it matters
1	Process creation	Full command line, parent process image path, user context, and file hashes in a single record
3	Network connection	Ties an outbound connection to the specific process that opened it
7	Image loaded	Shows a process loading a dynamic link library (DLL), including from an unusual directory
8	Remote thread created	One process starting a thread inside another, a common code injection technique
10	Process access	One process opening a handle to another. Access to `lsass.exe` is the standard credential dumping signal
11	File created	Files written to disk, including payloads dropped into temporary directories
12, 13, 14	Registry activity	Event 12 covers key and value creation and deletion, Event 13 covers a value being set, and Event 14 covers a key or value rename. Persistence is commonly written to run keys and service definitions
15	File stream created	Alternate data streams, including the `Zone.Identifier` marking Windows applies to downloaded files
22	DNS query	The domain a process resolved, recorded per process and including cached lookups

Configuration determines whether Sysmon is useful. Installing it with no configuration file enables a narrow default set: process creation, process termination, driver load, file creation time change, and SHA-1 hashing of images. Network connections, image loads, file creation, registry activity, process access, and DNS queries stay off until a configuration turns them on. Enabling every event type produces the opposite problem, burying useful records and driving up SIEM ingest costs.

Sysmon reads an Extensible Markup Language (XML) configuration file that sets include and exclude rules for each event type, for example excluding the routine network connections a backup agent makes every minute while including every connection opened by a process running from a user directory. Administrators commonly start from a maintained community configuration, such as SwiftOnSecurity's sysmon-config or Olaf Hartong's sysmon-modular, then tune it for their environment. The configuration is applied at install with sysmon -i config.xml from an elevated command prompt and updated later with sysmon -c config.xml.

Sysmon data reaches the SIEM the same way other Windows logs do, through a forwarding agent or Windows Event Forwarding, as described earlier in this chapter.

Analyst Perspective

Two Sysmon questions come up regularly in entry-level SOC interviews. What does Sysmon capture that native Windows logging does not? Full command lines without additional audit policy, file hashes, the parent process image path, network connections and DNS queries attributed to a process, and visibility into process access and remote thread creation. How do you keep Sysmon from overwhelming a SIEM? Filter at the endpoint using include and exclude rules in the configuration file, so unwanted events are never written in the first place.

2.4 Infrastructure Architectures in Modern Environments

Modern organizations use diverse infrastructure: traditional data centers with physical servers, virtualized environments, cloud services, containerized microservices, and hybrid combinations. A SOC analyst must understand each architecture to identify threats and misconfigurations.

Virtualization and Hypervisors

Virtualization allows multiple operating systems and applications to run on a single physical machine, each in its own isolated environment called a virtual machine (VM). The software layer that manages VMs is called a hypervisor.

Type 1 hypervisors run directly on hardware (bare metal): - VMware vSphere, Microsoft Hyper-V, KVM, Xen - Used in data centers for performance and isolation - Each VM is a complete OS with its own kernel, processes, and file system

Type 2 hypervisors run as software on top of a host OS: - VMware Workstation, Oracle VirtualBox, Parallels - Used for development and testing - Each VM is isolated from others but less isolated from the host OS

VM escape is an attack where malware running in a VM breaks out of the VM's isolation and gains access to the hypervisor or other VMs. VM escapes are rare but possible; they typically require exploiting hypervisor vulnerabilities. The impact is severe because once an attacker escapes the VM, they have access to all VMs and the host hardware.

VM sprawl is a common operational problem: virtual machines are created for temporary projects, cloned for testing, or forgotten after a pilot. Over time, an organization loses track of how many VMs it has. Unmaintained VMs are a security risk because they may not receive patches or monitoring.

Cloud-Native Architecture

Cloud services (AWS, Azure, Google Cloud) introduce architectural patterns and responsibilities that differ from traditional data centers.

Shared responsibility model: The cloud provider is responsible for infrastructure (physical security, network, hypervisor patching); the customer is responsible for the OS, applications, and data. The boundary between these responsibilities depends on the service model:

Infrastructure-as-a-Service (IaaS): Customer manages OS, applications, patches, firewalls; provider manages hardware and virtualization
Platform-as-a-Service (PaaS): Customer manages applications and data; provider manages OS, runtime, patches
Software-as-a-Service (SaaS): Provider manages everything; customer manages identity and data

Infrastructure-as-Code (IaC) defines cloud infrastructure (networks, servers, storage) using configuration files (Terraform, CloudFormation, Ansible). IaC enables rapid deployment and repeatability but introduces risk: if the code contains a misconfiguration (e.g., an overly permissive security group), that configuration is deployed to all instances.

Configuration drift occurs when deployed infrastructure diverges from the defined IaC. A cloud instance might be manually modified for troubleshooting and never reverted, causing it to differ from the standard configuration. Detecting and preventing drift is a critical operational task.

Cloud service logging:

CloudTrail (AWS): Records all API calls (who, when, what resource, success/failure)
Azure Activity Log: Records control plane operations and events
Cloud Audit Logs (GCP): Records admin activity and data access

These logs are essential for detecting unauthorized access, misconfiguration, and data exfiltration.

Cloud-specific threats:

S3 bucket misconfiguration: AWS S3 is an object storage service often used for backups and data archives. If bucket permissions are misconfigured (publicly readable or writable), anyone on the internet can access or modify data. This has led to numerous data breaches.
Overly permissive security groups: If a cloud instance allows inbound access from 0.0.0.0/0 (anywhere) on sensitive ports (RDP, SSH), the instance is vulnerable to brute force attacks
Exposed credentials: AWS access keys, database passwords, and other secrets are often accidentally committed to GitHub or stored in configuration files. Attackers monitor public repositories for exposed secrets.

Containerization and Orchestration

Containers are a lightweight alternative to virtual machines. A container includes an application and its dependencies (libraries, runtime) but shares the OS kernel with the host. This makes containers much smaller and faster to start than VMs but introduces different security challenges.

Docker is the most popular containerization platform. A Docker image is a template for a container; a container is a running instance of that image.

Kubernetes is the standard container orchestration platform. It manages running containers across a cluster of machines, automatically scaling, restarting, and updating containers.

Container security challenges:

Image vulnerabilities: Container images may contain vulnerable software. Image scanning tools scan for known vulnerabilities and can block deployment of images with critical issues.
Runtime protection: Even with a clean image, a container can be compromised at runtime. Runtime security agents monitor container behavior for suspicious activity (process execution, network connections, file access).
Lateral movement: Containers in a Kubernetes cluster communicate with each other through a service mesh. Compromised containers can potentially communicate with other containers. Network policies and service mesh security controls are needed.
Container escape: Like VMs, containers can potentially be escaped. A container escape allows an attacker to break out of the container's isolation and access the host or other containers.

Container logging is essential for detecting attacks:

Container logs: stdout/stderr from the application
Docker daemon logs: Container lifecycle events (creation, start, stop, configuration changes)
Kubernetes logs: Pod creation/deletion, deployment updates, resource events
Container runtime logs: Process execution, network connections, file access (from runtime security agents)

APIs and Microservices

Modern applications are built as microservices: small, independent services that communicate through APIs. This architecture provides benefits (agility, scalability) but introduces security complexity.

API authentication secures communication between services:

API Keys: Simple shared secrets; lower security than other methods
OAuth 2.0: Standard for delegated access; used for third-party app integration
Mutual TLS (mTLS): Both client and server authenticate using certificates; provides strong authentication and encryption

API gateways sit in front of microservices and enforce policies:

Authentication and authorization: Verify that the caller is authorized
Rate limiting: Prevent abuse by limiting requests per second per user
Request validation: Ensure that requests conform to expected formats
Request/response logging: Log all API calls for security and debugging

Service mesh (Istio, Linkerd) manages communication between microservices:

mTLS between services: Encrypts and authenticates service-to-service communication
Network policies: Controls which services can communicate with which other services
Circuit breaking: If a service is failing, automatically stop routing traffic to it
Observability: Provides detailed logs and metrics for service communication

Monitoring APIs and microservices for security:

Unusual API patterns: Unexpected spike in requests, requests from unusual sources, unusual parameter values
Authentication failures: Failed API authentication attempts (possible brute force)
Unauthorized access: Requests to protected endpoints without proper authorization
Data exfiltration: Large volumes of data being retrieved through APIs (unusual query patterns, large batch requests)

Hybrid Cloud and Multi-Cloud

Many organizations use multiple cloud providers and maintain some systems on-premises. This creates operational complexity: monitoring must span multiple environments, data must be synchronized across environments, and identity management must be unified.

Network connectivity between on-premises and cloud:

VPN (Virtual Private Network): Encrypted tunnel over the public internet; simpler to configure but lower performance
Dedicated connection (AWS Direct Connect, Azure ExpressRoute): Private network connection between on-premises and cloud; more expensive but higher performance
VPC peering (for multi-cloud): Direct connectivity between virtual networks in different clouds

Data residency and sovereignty requirements in some industries mandate that data be stored in specific geographic regions or countries. Multi-cloud and hybrid cloud architectures must respect these requirements.

Unified logging and monitoring is challenging across multiple cloud providers and on-premises systems. Organizations typically use a SaaS logging solution (Splunk Cloud, Datadog, Sumo Logic) that can ingest logs from all environments.

Identity federation allows users to authenticate once and access resources across all environments. Federated identity (using OAuth or SAML) is often preferable to managing separate credentials for each environment.

2.5 Device Management and Mobile Security

The perimeter of the modern organization is no longer the network edge (firewalls, routers); it is distributed across employees' devices (laptops, desktops, phones, tablets). Device management is therefore a critical security function.

Mobile Device Architecture and Threats

Mobile operating systems (iOS, Android) have different security models than desktop OSes:

iOS (Apple): Closed ecosystem. Apps run in sandboxes. App distribution through Apple App Store only. Users cannot install apps from third-party sources. Strong security by default but limited customization.
Android (Google): Open ecosystem. Apps run in sandboxes but can request permissions. App distribution through Google Play Store or side-loading from third-party sources. Users have more control but more risk.

Mobile malware includes:

Banking trojans: Malware that steals login credentials or intercepts one-time codes to compromise bank accounts
Spyware: Malware that records user activity, calls, messages, location, and other sensitive data
Ransomware: Increasingly targeting mobile devices; locks the device or encrypts data and demands ransom
Adware: Aggressive advertising; sometimes steals data or redirects users to phishing sites

Mobile attack vectors include:

App store attacks: Malicious apps in legitimate app stores; attackers distribute free or low-cost apps with malware
SMS/phishing: Smishing (SMS phishing) tricks users into clicking links or providing credentials
WiFi attacks: Public WiFi with malicious access points intercepts unencrypted traffic
Supply chain: Compromised third-party SDKs or libraries embedded in legitimate apps
USB attacks: Connecting a device to a malicious USB charger or charging station can install malware

Data exfiltration from mobile devices is a major concern:

Email: Mobile email apps often cache messages and attachments
Cloud sync: Photos, documents synced to cloud services
Screenshots: Users take screenshots of sensitive documents, customer data, source code
Logs and cache: Apps store sensitive data in local caches
Removable storage: Older Android devices with microSD card support

Mobile Device Management (MDM)

Mobile Device Management solutions provide centralized management and security for mobile devices:

Device enrollment: Register devices with MDM system; install MDM agent on device
Configuration management: Push security configurations (password policy, encryption, WiFi settings) to devices
App management: Control which apps users can install; push apps to devices; revoke app access
Threat detection: Monitor devices for malware and suspicious behavior
Compliance enforcement: Ensure devices meet security requirements (encryption enabled, latest OS version, no jailbreak/rooting)
Containment and wipe: Remotely lock or wipe compromised devices

Endpoint Detection and Response (EDR)

EDR agents run on computers (laptops, desktops, servers) and provide deep visibility into system activity:

Process monitoring: Track all process execution, parent-child relationships, command-line arguments
File monitoring: Monitor file creation, modification, deletion
Network monitoring: Track network connections, DNS requests, data transferred
Registry monitoring (Windows): Track changes to Windows Registry (configuration database)
Memory analysis: Detect malware running in memory
Behavior analysis: Use machine learning to detect anomalous behavior

Common EDR platforms used in the industry include:

Microsoft Defender for Endpoint: Microsoft's endpoint protection and detection platform, integrated with the Microsoft security ecosystem
CrowdStrike Falcon: Cloud-native endpoint protection, detection, and response platform
SentinelOne Singularity: AI-powered endpoint protection and autonomous response platform
VMware Carbon Black: Endpoint security platform focused on prevention, detection, and behavioral analysis
Sophos Intercept X: Endpoint protection and response platform with malware prevention and exploit protection

EDR also provides response capabilities:

Process termination: Kill suspicious processes
File quarantine: Isolate suspicious files
Network isolation: Disconnect device from network to prevent lateral movement

Bring Your Own Device (BYOD)

Some organizations allow employees to use personal devices for work (BYOD). This introduces significant security challenges:

Less control: The organization cannot enforce full hardening or control what else is installed on the device
Detection challenges: Personal devices are not enrolled in MDM; visibility into threats is limited
Data separation: Work data must be separated from personal data; if the device is compromised, only work data should be at risk
Incident response: Responding to a compromise on a personal device is complicated by privacy and legal issues

BYOD controls typically include:

MDM containerization: Install a container on the personal device that isolates work apps and data from personal use
VPN requirement: All work traffic must flow through a VPN, allowing monitoring and enforcement of policies
Conditional access: Allow or deny device access based on device health (encryption enabled, no jailbreak, current antivirus, etc.)

USB and Removable Media

USB drives and removable media are a major data exfiltration risk. An employee can connect a USB drive and copy entire databases or source repositories in minutes.

Technical controls include:

USB port disable: Disable USB ports via BIOS or policy (though this prevents use of wireless mouse/keyboard)
USB whitelist: Allow only pre-approved USB devices
Data Loss Prevention (DLP): Monitor and block copy of sensitive data to USB
Read-only mode: Mount USB as read-only, preventing any modification

Monitoring and alerting:

Alert when USB devices are connected
Alert when large files are copied to USB
Maintain inventory of USB devices connected to systems

Printers and IoT Devices

Printers are often overlooked as security risks but can be significant:

Network endpoints: Printers have IP addresses and can be compromised like any network device
Data storage: Printers may store copies of documents printed to them
Authentication bypass: Printer web interfaces sometimes have default credentials
Firmware vulnerabilities: Printer firmware may contain vulnerabilities

IoT (Internet of Things) devices include cameras, sensors, thermostats, and other smart devices increasingly connected to corporate networks:

Inventory: Organizations often don't know all IoT devices on their networks
Patching: IoT devices frequently have no update mechanism or receive infrequent updates
Segmentation: IoT devices should be isolated on a separate network to prevent lateral movement
Monitoring: Limited logging from most IoT devices makes detection of compromise difficult

Critical Distinction

Device diversity (desktops, laptops, mobile, IoT) means that a comprehensive security program must address not just servers and traditional computers but also phones, tablets, printers, and specialized devices. A focused attack on non-traditional devices (a printer, a smart display) can sometimes bypass security controls designed for traditional computers.

2.6 Putting It Together: Real-World SOC Scenarios

Scenario 1: Detecting Lateral Movement Through Logging

A mid-market manufacturing company discovers unauthorized access to its ERP (Enterprise Resource Planning) system. The CISO asks the SOC to determine whether the attacker accessed other systems.

Investigation approach:

Identify the compromised account: Query the SIEM for logon events (Event ID 4624) for the compromised user over the past week. Identify successful logons from unusual locations or times.
Review process execution on the ERP server: Check Windows Event Log for process execution (Event ID 4688) on the ERP server around the time of unusual logons. Look for cmd.exe, PowerShell, or other tools that might indicate attacker activity.
Check for lateral movement: Query logs from network devices (firewall, router) for network connections initiated from the ERP server to other systems. Check DNS logs for domain names the attacker queried. Check EDR logs from other systems for connections from the ERP server.
Identify affected systems: For any systems the attacker reached, review their logs for unusual activity (process execution, file modifications, data access).
Determine data accessed: Review file access logs on systems with sensitive data (databases, document repositories) to determine what information the attacker accessed.

Controls that would have prevented or detected this:

Preventative: Network segmentation so the ERP server cannot directly reach other systems; firewall rules limiting what systems the ERP server can communicate with
Detective: EDR agents on all systems; centralized log collection; SIEM rules for unusual logons or network connections
Responsive: Automated isolation of systems showing signs of compromise
Corrective: Regular backups of critical systems to enable recovery

Scenario 2: Cloud Misconfiguration Leading to Data Exposure

A SaaS company stores customer data in AWS S3 buckets. During a security assessment, a researcher discovers that one S3 bucket is publicly readable, exposing sensitive customer data.

Investigation:

Determine bucket contents: What data was exposed? Customer PII? API keys? Source code?
Review CloudTrail logs: When was the bucket created? Who created it? When was it made public? What permissions changes were made?
Check for unauthorized access: Did anyone download data from the bucket? CloudTrail shows who accessed the bucket and when.
Review IaC configuration: Was the public permission intentional or a misconfiguration? If IaC (Terraform, CloudFormation) is used, review the code that created the bucket.
Determine scope: Are other S3 buckets misconfigured? Run an automated scan of all S3 bucket permissions.

Controls that would have prevented this:

Preventative: Default-deny S3 permissions; code review of IaC; automated policy enforcement (e.g., AWS Config rules that prevent public buckets)
Detective: CloudTrail logging; automated scanning of S3 bucket permissions; alerts for permission changes
Responsive: Automatic remediation of public buckets; alert to security team for investigation
Corrective: Incident response procedure; notification of affected customers; credential rotation if credentials were exposed

Chapter Summary

SOC analysts investigate security alerts, triage incidents, and escalate true positives. Tier 1 analysts focus on triage; Tier 2 on investigation; Tier 3 on advanced analysis and automation. Career progression depends on developing technical depth and understanding the organization's specific environment.
Logging architecture must balance visibility (comprehensive logging), cost (storage and compute), and performance. Critical logs include user authentication, privileged activity, system changes, database access, and network connections. Logs must be protected for integrity and integrity violations must trigger alerts.
Time synchronization (NTP) is essential; unsynchronized clocks corrupt the timeline of investigations. Log retention depends on regulatory requirements and business needs; tiered storage (hot/warm/cold) optimizes cost and performance.
Operating system hardening reduces attack surface by removing unnecessary services and features. Security baselines (CIS, DISA STIGs) provide standardized configurations. File permissions, process monitoring, and security event logging are foundational for threat detection. Sysmon extends native Windows logging with process command lines, file hashes, parent process paths, per-process network and DNS activity, and process access events, and it is configured with an XML file that filters events at the endpoint.
Virtualization introduces new architectures and attack vectors. VM escape is rare but severe. VM sprawl is common and represents ongoing risk. Virtual machine logs must be centrally collected and analyzed.
Cloud architectures shift responsibilities between provider and customer (shared responsibility model). IaC enables rapid deployment but introduces misconfiguration risk. Cloud-specific threats (S3 bucket leaks, overly permissive security groups, exposed credentials) are common.
Containerization and Kubernetes are now standard in modern deployments. Container image vulnerabilities, runtime attacks, and lateral movement through service mesh are key security concerns. Container logging spans multiple sources (application logs, Docker daemon, Kubernetes, runtime agents).
APIs and microservices require strong authentication, rate limiting, and comprehensive logging. Unusual API patterns (unexpected spikes, unusual parameters) can indicate attacks or data exfiltration.
Device management (mobile, endpoint, IoT, printers) requires both preventative (MDM, hardening) and detective (EDR, network monitoring) controls. BYOD introduces specific challenges around data separation and compliance.