CySA+ System and Network Architecture: Logging, OS, Cloud, IAM, Encryption and OT

A SIEM can only detect what reaches it as structured, searchable fields, so ingestion and configuration decide its visibility before any rule is written. Configuration is the source side: whether the system records the event at all, and with which details. Ingestion is the collection side: how events are transported, parsed and normalized into the SIEM's common schema.

Configuration: turn on the fields you need

Default audit settings often leave out the detail that hunting depends on. The classic Windows example is process creation (event 4688): enabling process creation auditing records that a program started, but the command line is written into the event only when the separate policy setting "Include command line in process creation events" is also enabled. PowerShell script block logging is a useful near-twin, but it records PowerShell code only, not the arguments of every process such as cmd.exe or rundll32.exe. The general rule: a missing detail is fixed by the specific setting that writes it, not by collecting more of something else.

Ingestion: parse and normalize

Onboarding a log source means more than events arriving on time. Each source needs a parser (connector, add-on or decoder) that maps its fields to the SIEM's normalized schema: source IP, destination, user, action, result. Without one, the values stay buried in an unstructured message field, the events are stored, and every correlation rule that keys on a field silently never fires. Agents, syslog forwarders and API pulls (common for SaaS and cloud sources) are the usual transport methods; transport should be encrypted (TLS) and reliable, but protecting or storing an event is a different job from turning it into fields.

Logs are evidence only if they cannot be quietly altered, carry timestamps that line up across sources, and are kept long enough for the investigations and regulations that need them.

Integrity and security

An attacker with administrative rights on a host controls everything stored on that host: the local event log, a second disk, a nightly local copy. Clearing the Security log is a routine anti-forensics step. The protections that work move the evidence out of the attacker's reach:

• Near-real-time forwarding to a collector or SIEM that the host's administrators do not control, so each event leaves before it can be cleared.
• Immutable storage for the central copy: write-once (WORM) storage or a retention lock, so even a privileged user cannot delete or change logs during the retention period.
• Hashing or signing of stored log files so tampering can be detected, plus access control and separate administration for the logging platform itself.

The principle: anything kept on the host stays under the control of whoever controls the host, so local measures alone cannot protect evidence from an administrator-level attacker.

Time synchronization

Correlation assumes every source stamps events with the same clock. Point all devices at a common, hierarchical NTP source; when clocks drift, the same session appears minutes apart in the firewall, proxy and domain controller logs and the order of events cannot be trusted. Two distinct time problems look different:

Time also matters to protocols. Kerberos authenticators carry timestamps that the KDC or service checks to block replay, and an Active Directory domain controller rejects clients whose clocks differ from its own by more than the maximum tolerance (five minutes by default). It logs event 4771 with failure code 0x25 (KRB_AP_ERR_SKEW); a wrong password shows 0x18 instead. When authentication failures and out-of-step log timestamps appear together on the same systems, check time synchronization first.

Retention

The minimum retention period for each log type is set by legal, regulatory and contractual requirements, and investigation needs may extend it. Operational factors such as storage cost shape how logs are stored, never how short a mandatory minimum can be. PCI DSS v4.0.1 (Requirement 10.5.1), for example, requires at least 12 months of audit log history with the most recent three months immediately available for analysis. The cost-efficient design is tiered: recent logs in fast, indexed ("hot") SIEM storage and older logs in cheaper archive storage that can be restored. Keeping everything hot meets the rule at higher cost; deleting after the hot period or archiving everything breaks one half of it.

Analysts use operating system knowledge to know what "normal" looks like: a hardened configuration to measure against, the files attackers tamper with, and the expected tree of core processes.

System hardening

Hardening reduces attack surface by applying least functionality: remove or disable unneeded services, ports, accounts and software, enforce secure authentication, permissions and logging settings, and patch. It starts from a documented baseline. CIS Benchmarks are consensus-developed, version-specific configuration guides for operating systems and applications that can be applied to a build image and audited automatically afterwards (DISA STIGs play the same role for US government systems). A hardening baseline answers "how should this system be configured?"; frameworks that score vulnerabilities, catalog attacker behaviour or rank application risks answer different questions.

File structure and critical files

An /etc/passwd entry has seven colon-separated fields: name, password placeholder, UID, GID, comment (GECOS), home directory and shell. The x in the second field only means the hash lives in /etc/shadow. The kernel grants superuser rights to any account whose UID is 0, so a line such as sysmaint:x:0:0:maintenance:/var/lib/sysmaint:/bin/sh that is not in the baseline is a full root login dressed as a service account. GID 0 is the root group, and the comment field has no security effect.

System processes

Malware often borrows the names of core Windows processes, so hunting rules check their parents, counts and paths. On a healthy Windows 10/11 or Server system:

• smss.exe starts a child smss.exe per session, which launches csrss.exe and wininit.exe (session 0) or csrss.exe and winlogon.exe (user sessions) and then exits, so those processes normally show a parent that is no longer running.
• wininit.exe starts services.exe (the Service Control Manager) and lsass.exe.
• services.exe starts every svchost.exe, so a dozen or more of those is normal.
• There is only ever one lsass.exe. A second instance, lsass.exe started by services.exe, services.exe started by winlogon.exe, or a core process running from outside System32 is a strong lead.

Behaviour that is normal by design should not alert on its own; a detection is only useful when it compares against the known-good baseline.

Each architecture moves the isolation boundary and the place where evidence lives, so the SOC has to change where it collects telemetry and how it preserves evidence.

Virtualization and containerization isolation

Separate VMs give stronger isolation than containers because each has its own kernel; controls that harden or verify a workload are valuable, but they do not add a kernel boundary. Where containers must stay, sandboxed runtimes add a kernel boundary without changing images or tooling: a micro-VM runtime (for example Kata Containers) gives each pod its own lightweight VM and guest kernel, and a user-space kernel (for example gVisor) intercepts the application's system calls. Kubernetes selects them per pod through a RuntimeClass. Hardening inside a container reduces what it can do, but unless a sandboxed runtime is used its system calls still reach the shared host kernel.

Containers are ephemeral

Containers are built from immutable images and replaced rather than repaired. Anything written to a container's own writable layer, logs included, disappears when an orchestrator replaces it. Applications should write to stdout/stderr (or use a logging sidecar) with a node-level agent shipping logs to a central platform. Collection has to be continuous and off the container, because a short-lived container may be gone before any later capture.

Memory and the container filesystem are lost the moment a compromised pod is deleted or restarted, so the evidence-friendly response is to take the pod out of service without killing it: change its labels so the Service and ReplicaSet no longer select it (the controller starts a clean replacement, so recovery is not delayed), quarantine it with a network policy, capture memory and filesystem, then delete it. Any action that terminates the container before capture loses the volatile evidence.

Cloud native and serverless

In function-as-a-service the provider runs the operating system and runtime, so host-based tools such as EDR agents and authenticated vulnerability scans have nothing to attach to. Visibility moves to the provider's function execution logs, control-plane (API) audit logs and configuration state, ingested into the SIEM. Monitoring has to follow the shared-responsibility line: the customer watches what the customer controls.

APIs expose application functions and data directly to callers, so every endpoint is an entry point that must authenticate, authorize, limit and log each call. In a microservice estate where each service implements those controls its own way, enforcement is inconsistent and access logs are scattered.

An API gateway sits in front of the services as the single entry point and applies the same authentication and authorization checks (API keys, OAuth 2.0 tokens), quotas and rate limiting, and request logging to every call, without rewriting each service. It also gives the SOC one consistent source of API access logs.

Gateways and WAFs are often deployed together; they answer different questions.

Mobile device management (MDM) and its broader successor, unified endpoint management (UEM), enroll phones, tablets and laptops and push, enforce and report on security policy: passcodes, encryption, app allow lists, patch levels, certificate and Wi-Fi profiles, and remote lock or wipe. Non-compliant devices can be blocked from corporate resources.

• Personal devices (BYOD): corporate apps and data go in a managed container or work profile. When the employee leaves, a selective (enterprise) wipe removes only that container and leaves personal photos, messages and apps alone.
• Corporate-owned devices: a full remote wipe erases the device, and it runs when the device next checks in with the management service.
• Lost or stolen devices: enforced full-disk encryption keeps data unreadable even if the drive is removed, and remote wipe erases it once the device comes online.

Match the control to the requirement: policies that restrict how a device is used are different from controls that protect or remove the data on it.

Modern network architecture assumes users, applications and data are spread across offices, homes and clouds, so access is decided per user, device and application rather than by being "inside" a network.

Zero trust network access (ZTNA)

A traditional remote-access VPN puts the user on the network, often with reach to whole subnets, so lateral movement is limited only by internal controls. ZTNA brokers each session to one named application after verifying identity and device posture, continuously and per connection. The applications accept connections only through the broker or its connector, so they are not exposed directly to the internet. The defining difference is the unit of access: a network for a VPN, a single application for ZTNA.

Secure access service edge (SASE)

SASE converges networking and security into one cloud-delivered service: SD-WAN for efficient branch connectivity and local internet breakout, plus security service edge (SSE) functions such as a secure web gateway (SWG), cloud access security broker (CASB), ZTNA and firewall as a service (FWaaS). Branch and remote users get the same policy wherever they connect, and branches stop backhauling internet traffic to headquarters.

Hybrid cloud

In a hybrid environment, administrative actions in the cloud (creating access keys, changing security groups, launching resources) are API calls to the provider's control plane. They happen in the provider's platform rather than inside your hosts or networks, so host and network telemetry cannot see them. The SOC needs the provider's control-plane audit logs in the same SIEM as on-premises data, so it can correlate identity and configuration changes across both environments.

Identity and access management decides who can do what; for an analyst, the important parts are how privileged access is controlled, which protocols prove identity versus grant access, and how machine credentials are kept out of code.

Privileged access management (PAM)

PAM replaces standing privilege with controlled, observable elevation:

• Just-in-time (JIT) elevation: time-limited group membership or rights granted on approval and removed afterwards, so administrators hold no standing privilege.
• Credential vaulting with injection: the PAM platform injects the privileged credential into the session so the user never sees it, then rotates it. Any approach that shows the administrator the password lets it be reused outside the controlled session.
• Session proxying and recording: privileged sessions run through a PAM proxy or jump host that records them. Authentication logs record that a session started, not the actions taken inside it.

Authentication and authorization methods

Signing users in by checking an OAuth access token alone is a known mistake; OIDC exists to provide the identity proof. SAML, OAuth 2.0, OIDC and WebAuthn all depend on TLS (HTTPS) to protect tokens in transit; Kerberos instead protects its tickets and authenticators with its own symmetric encryption. One-time codes (app or SMS) and simple push approvals can be relayed in real time by an adversary-in-the-middle phishing page, which is why phishing-resistant MFA means FIDO2-style origin binding.

Secrets management

Secrets (passwords, API keys, certificates, tokens) belong in a secrets vault that stores them centrally, controls and audits access, and serves them to applications at runtime, so nothing is hardcoded in code, configuration or Git history. Dynamic secrets go further: the vault creates a unique, short-lived database credential on request and revokes it when the lease expires, so a leaked credential is useful only briefly. The weakness of any static credential is its lifetime, and a secret protected by something stored beside it is not protected at all. A secret committed to Git must be revoked or rotated, not just deleted from the latest commit.

Encryption makes data unreadable without a key; data protection is the broader set of techniques (classification, DLP, tokenization, masking, hashing and encryption) chosen according to who must still use the data and how.

Encryption techniques

• Symmetric encryption (for example AES) uses one shared key and is fast enough for bulk data. Asymmetric encryption (RSA, elliptic curve) uses a key pair and is used for key exchange, digital signatures and certificates. TLS uses both: asymmetric cryptography to authenticate and agree keys, symmetric ciphers for the session.
• At rest vs in transit. TLS protects data on the wire. Full-disk encryption protects a powered-off or stolen drive, but decrypts transparently once the volume is mounted, so anyone who can query the running system reads plaintext, wherever the disk keys are kept and however often they rotate. Field-level (application-layer) encryption keeps a sensitive column as ciphertext to every query that cannot use the key, which protects against a compromised application account.
• Forward secrecy. TLS 1.3 removed static RSA key exchange; every handshake uses ephemeral (EC)DHE. The server's long-term private key only signs the handshake, so a passive sensor holding a copy of it can no longer decrypt sessions. Inspection then requires terminating TLS inline (reverse proxy, load balancer or decrypting gateway) or exporting per-session keys from an endpoint. Key length does not matter here; the key-exchange design does.

Data protection techniques

Choose by asking who needs the data and in what form: a consistent surrogate for linking, a partial view for people, full confidentiality for storage or transit, or a one-way check. Digital signatures prove origin and integrity but conceal nothing.

Operational technology (OT) is hardware and software that monitors and controls physical processes; industrial control systems (ICS) are the control systems within it, and SCADA (supervisory control and data acquisition) is the type of ICS that supervises geographically spread processes such as water, pipelines and power grids. Typical components are PLCs and RTUs at the process, HMIs for operators, and historians that store process data.

• Safety and availability come first. IT security is often summarized as confidentiality, integrity, availability; OT generally reverses that order because downtime or a bad command can harm people, equipment or the environment. Patches that need a reboot wait for planned outages, with compensating controls (segmentation, monitoring) until then.
• Fragile, long-lived devices. Controllers often run for decades and may fault when probed. Active scanning can stop a process, and anything that queries a device only learns what that device reports about itself.
• Insecure protocols. Industrial protocols such as Modbus/TCP and DNP3 were originally designed without authentication (DNP3 later added Secure Authentication, but optional add-ons like it are rarely deployed), so anyone who can reach a PLC can often command it.
• Passive monitoring. A sensor on a SPAN port or network tap that decodes industrial protocols (for example Modbus function codes) builds an asset inventory and learns normal traffic, then alerts on unusual commands without touching the devices. Passive network monitoring works because it does not depend on the devices themselves, which often log little.
• Segmentation. The Purdue model separates enterprise IT (levels 4–5) from operations (level 3) and from supervisory and control levels (0–2), with an industrial DMZ between IT and OT so no traffic passes directly from the enterprise to controllers.