System and Network Architecture for Security Operations

Suppose a ticket reports that a storage bucket holding customer exports became publicly readable overnight, and the sign-in history of the virtual machine that writes to the bucket shows no logins at all: MITRE ATT&CK describes adversaries who connect to available cloud services through the web console or through the cloud command line interface^[1] and perform management actions there, activity that a guest operating system's (the virtual machine's own operating system's) login history never sees. The mismatch is architectural: bucket permissions in a cloud service are changed through the provider's management API (application programming interface, the interface programs use to request operations), so look for the management action in the provider's control-plane audit log (its record of management API calls), if enabled and retained; a virtual machine login log alone may not explain it.

For each relevant part of an environment, ask what it controls, where its evidence lives, and what that evidence cannot prove.

The takeaway for the whole page: before you search, name the layer that would have recorded the action.

Ingestion is the path an event travels from the system that generated it to the place where analysts search it, and every break in that path is a gap in what you can see. NIST SP 800-92^[2], NIST's guide to computer security log management, says log management infrastructures usually use a three-tiered design^[2]:

• Log generation: the hosts that generate the original log data.
• Log analysis and storage: centralized log servers that consolidate and store the data.
• Log monitoring: consoles used to monitor and review the data.

SP 800-92 notes these infrastructures are typically built on either syslog-based centralized logging software or a SIEM (security information and event management system, the platform that centralizes and analyzes logs). The figure below traces the three tiers and marks two places where evidence can be lost.

Why the copy must leave the host

The host that generated an event may be the host under attack. SP 800-92 warns that many rootkits are specifically designed to alter logs to remove any evidence^[2] of their installation or execution, and it recommends that organizations consider log management infrastructures that includes centralized log servers and log data storage^[2]. A record kept only on the endpoint depends on that endpoint staying available and honest; a protected copy on a separate collection service does not, and it also lets you search across many systems at once.

A silent source may signal a visibility failure

Ingestion can fail without any alarm. SP 800-92 lists monitoring the logging status of all log sources^[2] among routine administrator duties and notes that a log reaching its size limit may overwrite old data with new data or stop logging altogether^[2]. The OWASP Logging Cheat Sheet^[3] likewise asks for processes to detect whether logging has stopped^[3] and to identify tampering. So when a SIEM shows no events from a source, the explanations include a stopped agent, a broken connection, a permission failure, full storage, or deliberate tampering, as well as genuine inactivity. Check the collection path (is the agent running, is the forwarder connected, are the source's other routine events still arriving?) before you close an investigation because the SIEM is empty.

Takeaway: centralization protects the evidence from the host, and the health of the path to the central copy is itself something to monitor.

Configuration decides which events a source writes and which details each event carries. It is set at the source, before anything is ingested, so an event or detail captured by no available source cannot be reconstructed later at the SIEM.

Record the actor, action, target, time, and outcome

The OWASP Logging Cheat Sheet^[3] says application logs must record "when, where, who and what" for each event^[3], and suggests also recording the action, the object it was aimed at, and the result status - whether the ACTION aimed at the OBJECT was successful^[3]. The outcome field separates an attempt from a completed action: an event reading mlee, delete, invoice 4471, fail is an unsuccessful attempt whose failure reason needs checking, while the same event with success is a change you must explain. The actor field (a user, a process, or a system) is what connects the event to someone.

Turn on the security-relevant categories

Among the events the cheat sheet says to log where possible are authentication successes and failures^[3], authorization (access control) failures, and use of higher-risk functionality such as user administration and changes to privileges^[3]. Application crash and error logs alone miss most of these, because a successful privileged change produces no error. Configure these categories deliberately rather than assuming a default configuration captures them.

Leave reusable secrets out of the record

Configuration also decides what must not be written. The cheat sheet lists data that should usually be removed, masked, sanitized, hashed, or encrypted^[3] rather than recorded directly, including session identification values, access tokens, authentication passwords, and encryption keys and other primary secrets. A full access token in a log makes every log reader a potential holder of a working credential, whereas the account name, a hashed session value, and the outcome keep the investigative value. NIST SP 800-92^[2] makes the same point: logs might intentionally or inadvertently capture sensitive information such as users' passwords^[2].

Takeaway: configure each source to answer who did what to which object, when, and with what result, and never to store a secret someone could reuse.

Time synchronization makes timestamps from different systems comparable, and without it the apparent order of events across systems can simply be wrong. NIST SP 800-92^[2] explains that each host references its internal clock when setting a timestamp^[2], so an inaccurate clock produces inaccurate entries; its example shows timestamps indicating that event A happened 45 seconds before event B, when event A actually happened two minutes after event B^[2].

The architectural answer is to keep each logging host's clock synched to a common time source^[2], and SP 800-92 recommends time synchronization technologies such as Network Time Protocol (NTP) servers^[2].

• Time zones. Organizations with systems in several time zones often need to convert all logged times to a single time zone^[2].
• Clocks you cannot fix. For out-of-sync sources it may be necessary to add or subtract times^[2]; record the estimated offset, or the uncertainty, alongside the evidence.
• Event time versus arrival time. The OWASP Logging Cheat Sheet^[3] notes that the event timestamp may be different to the time of logging^[3], for example on a device that is only intermittently online, and the collector's arrival time can differ again because of forwarding delays. Order activity by when it happened, not by when the collector received it.

Takeaway: synchronized clocks are an architecture decision made before an incident; arrival order at the SIEM is never a substitute for event time.

Logs are evidence, so an intruder has reasons to read them, change them, or forge them, and each of those threats needs its own control. NIST SP 800-92^[2] warns that logs secured improperly in storage or in transit might also be susceptible to intentional and unintentional alteration and destruction^[2], which can let malicious activity go unnoticed.

Disclosure and tampering need different controls

The OWASP Logging Cheat Sheet^[3] separates protection at rest from protection in transit. At rest, it asks you to build in tamper detection so you know if a record has been modified or deleted^[3], store or copy log data to read-only media as soon as possible^[3], record and monitor all access to the logs, and restrict and periodically review who may read them. In transit, it asks for a secure transmission protocol^[3] when log data crosses untrusted networks.

These controls are not interchangeable. Encrypted transport protects events while they travel; once they reach storage it does nothing to stop someone with write access from editing or deleting them. Read-only storage, tamper detection, and monitoring of access to the logs cover that part.

Forged entries: log injection

The third threat is a record that never happened. Log injection occurs when attacker-controlled input, such as a username field, contains characters the log format treats as a record boundary, such as a carriage return (CR), a line feed (LF), or a field delimiter. A username submitted as alice followed by a line break and the text user=admin action=login result=success can then display as a separate, trusted-looking event. The cheat sheet's fix is to perform sanitization on all event data to prevent log injection attacks^[3] and to validate event data from other trust zones, so supplied text stays data. Encrypting the log file does not help here: it protects the stored file, while the forged record boundary was created when the event was written.

Takeaway: protect logs in transit, make stored logs tamper-evident and read-only, monitor who reads them, and sanitize untrusted fields at write time.

Retention is how long logs, their archives, and their copies are kept, and it is a policy decision driven by investigative, contractual, and legal needs, not a storage default. NIST SP 800-92^[2] notes that logs often need to be preserved to meet legal or regulatory requirements^[2], and that meeting retention requirements can mean keeping copies longer than the original log sources can support, which requires archival.

SP 800-92 also separates two kinds of archival. Log retention is archiving logs on a regular basis as part of standard operational activities^[2]; log preservation is keeping logs that would normally be discarded because they record activity of particular interest, typically for incident handling or investigations.

Retention has an upper bound as well as a lower one. The OWASP Logging Cheat Sheet^[3] says log data, temporary debug logs, and backups or copies must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time^[3], and that legal, regulatory, and contractual obligations may affect those periods.

• If a source keeps only what fits on its disk, the investigation window is whatever happened to survive, not what the policy requires; a log at its size limit may overwrite old data, as the ingestion section above describes.
• The retention period covers archives and exported copies too, so a copy kept indefinitely on a file share breaks the policy as surely as one deleted early.

Takeaway: the approved retention policy, not free disk space or a product default, sets the investigation window, and it applies to every copy.

System hardening reduces a host's exposure by removing what it does not need, and the approved baseline that results is the expected state an analyst compares the host against. NIST SP 800-123^[4], NIST's guide to general server security, lists the steps to harden a server operating system (OS) as remove unnecessary services, applications, and network protocols^[4], configure OS user authentication, and configure resource controls appropriately.

Hardening is not patching

In its initial OS securing steps, SP 800-123 lists patch and upgrade the operating system^[4] as a step separate from removing unnecessary services. The two address different risk. Patching closes known vulnerabilities in software that is installed; hardening removes services, software, privileges, and insecure settings that should not be there at all. A fully patched server that still runs an unneeded file-sharing service, or gives every user local administrator rights, is not hardened.

How an analyst uses the baseline

The baseline (the organization's documented secure configuration for a type of system) tells you what exposure to expect. A new listening service, a re-enabled protocol, or an extra administrator on a hardened server is a deviation to explain, either through an approved change or as a finding.

Takeaway: judge a host against its hardening baseline, and never read patch status as hardening status.

Within an operating system's file structure, some files and configuration stores matter more than others because they govern authentication, which programs start automatically, and what security policy applies. A change to one of them can change who gets access or what runs, so it deserves more scrutiny than an ordinary file write.

MITRE ATT&CK's detection strategy for creation or modification of system processes^[5] shows what such objects look like for service startup on each platform, among others:

Platform	Startup object the strategy watches
Windows	The registry key HKLM\System\CurrentControlSet\Services, where services are defined
Linux	Service units under /etc/systemd/system and init scripts under /etc/init.d
macOS	LaunchDaemon and LaunchAgent property list files, such as those under /Library/LaunchDaemons/

The registry is a configuration store rather than a file, which is why the category is critical files and configuration stores together. The strategy's Linux analytic, for example, detects changes to service units and init scripts and monitors chmod +x and systemctl executions especially from non-root parent processes^[5].

When one of these objects changes, identify its role (authentication, startup, or policy) and compare the change with approved maintenance: was there a change ticket for this service, made by the expected administrator, at the expected time?

Takeaway: rank file changes by the security function the file controls, and reconcile changes to critical files against approved maintenance.

A process is a running instance of a program, with an execution identity (the account it runs as) and relationships to other processes. MITRE ATT&CK's Process Creation data component describes process creation as an event that can involve parent-child process relationships, process arguments, and environmental variables^[6], and calls monitoring it crucial for detecting execution of unauthorized binaries, scripting abuse, or privilege escalation attempts^[6].

A familiar process name does not establish legitimacy

Attackers choose names that look harmless. ATT&CK documents adversaries who match or approximate the name or location of legitimate files^[7], for example by placing an executable in a commonly trusted directory such as System32 or giving it the name of a legitimate, trusted program such as svchost.exe. So judge a process by its full execution context:

• Parent: which process started it, and is that a normal parent for this program?
• Executable path: where the file actually lives on disk.
• Arguments: what it was told to do.
• Account and privileges: who it runs as, and therefore what it can reach.

A process named svchost.exe running from a user's Downloads folder, started by a word processor, under a standard user account, contradicts what its name implies. Host process telemetry, the process creation records^[6] an EDR (endpoint detection and response) tool or other endpoint sensor collects, can capture these fields when the sensor supports and is configured to record them.

Takeaway: a familiar process name is a claim; the parent, path, arguments, and account are the evidence.

Device management is the central control of enrolled devices, and its records show a device's posture (whether it is enrolled, how it is configured, whether it complies with policy), but those records alone do not provide a complete process-behavior investigation.

Mobile device management

NIST SP 800-124 Rev. 2^[8], NIST's guidelines for managing the security of mobile devices, describes enterprise mobility management (EMM), sometimes referred to as UEM (unified endpoint management)^[8], as a solution used to deploy, configure, and actively manage mobile devices in an enterprise environment^[8]. An EMM suite may include mobile device management (MDM), mobile application management (MAM), and mobile threat defense (MTD), and it can monitor mobile devices, deploy device policies^[8] and configure device-side security technologies. For an analyst, the management records answer whether a phone is enrolled and meets policy. Enrollment and compliance records alone do not show the full behavior of a suspicious app or process; consult available endpoint threat telemetry, such as MTD or EDR records.

Personally owned devices have a privacy boundary

Bring your own device (BYOD) programs put organizational data on a device the organization does not own. SP 800-124 Rev. 2 notes that management systems such as EMM and MTD can collect data so that an employer may collect sensitive information about an employee^[8], and that for BYOD, the use of MAM functionality instead of MDM may help address users' privacy concerns^[8], because MAM can restrict app functions without affecting the entire device^[8]. Enrollment of a personal phone therefore does not give an analyst unrestricted investigative access: establish and respect the applicable law, policy, consent, and management configuration before inspecting personal or work data.

Endpoint management for workstations and servers

The same posture logic applies to laptops, workstations, and servers under endpoint management. Reconcile four kinds of record before you state a device's posture: enrollment (is it under management?), inventory (what hardware and software it has), configuration and compliance (does it meet current policy?), and lifecycle status (deployed, or removed from service). An old inventory entry identifies an asset but does not show that it still receives configuration updates or meets current policy. An EDR process tree is a different record again: it shows execution relationships, not enrollment or compliance.

Takeaway: use device management records for posture questions, current and within the device's ownership boundary, and endpoint telemetry for behavior questions.

Virtual machines (VMs) and containers both let many workloads share one physical host, but they draw the isolation boundary in different places, and that decides how far a host-level problem can reach. NIST SP 800-190^[9], NIST's application container security guide, explains that VMs use a hypervisor that provides hardware-level isolation of resources across VMs^[9], each VM including a complete guest OS, whereas with containers multiple apps share the same OS kernel instance^[9], the kernel being part of the host operating system.

SP 800-190 draws the consequence itself: containers do not offer as clear and concrete of a security boundary as a VM^[9], and a shared kernel invariably results in a larger inter-object attack surface than seen with hypervisors^[9]. SP 800-190's Figure 2 shows the VM deployment on the left, a container deployment without VMs (installed on “bare metal”) in the middle^[9], and the figure below redraws those two stacks.

What this means for an investigation

• Blast radius. A kernel vulnerability or kernel-level compromise on a container host can affect every container on that host, because they all run on that one kernel. A compromise inside one VM's guest OS does not automatically reach the other VMs' operating systems; the layer they share is the hypervisor.
• Telemetry layer. For a container you may need the host's records as well as the application's own logs, because the kernel that executed the activity belongs to the host; a VM's guest OS keeps its own logs.
• OS family. Containers are OS-family specific: a Linux host can only run containers built for Linux^[9].

Takeaway: treat each container as an isolated group of processes on a shared kernel, not as an independent guest operating system.

Cloud-native workloads (applications built to run as containers, functions, and automatically scaled instances in a cloud service) change the evidence problem in three ways: the workload may be gone when you investigate, the provider holds part of the evidence, and management actions happen through an API rather than on the workload.

Short-lived workloads need telemetry that outlives them

Replacement is normal operation. NIST SP 800-190^[9] explains that when a running container needs an update it is simply destroyed and replaced with a new container^[9], and that automatic deployment and destruction can also introduce some challenges for records retention, forensic, and event data requirements^[9]. Export security and audit events to central collection as they happen, and keep identifying context with them (image, instance or container identifier, host, account), so that an investigation does not depend on the original instance still existing.

The responsibility split decides who holds which evidence

Cloud services divide security responsibilities between the cloud service provider (CSP) and the customer, and the split depends on the service model. CISA's Cloud Security Technical Reference Architecture^[10] explains that securing a SaaS (software as a service) offering relies heavily upon the service provider^[10], whereas with IaaS (infrastructure as a service) much responsibility falls on the agency^[10], and that CSPs may define the split differently from one vendor to the next. Before requesting evidence, establish who controls the workload, the identity configuration, data access, and the underlying infrastructure. Identity permissions the customer configures remain the customer's to investigate even on managed infrastructure. In SaaS, the same document notes, tenants do not have the ability to collect additional log data for security purposes other than what the service provider offers^[10].

Management actions leave control-plane evidence

The cloud control plane is the provider's management layer, accessed through its APIs and console, through which resources, identities, and permissions are created and changed. For IaaS, the CISA architecture lists logs typically available from the CSP, including network flow logs, API call logs/service event logs, access and identity logs, and health logs^[10]. A permission change or a newly created resource can involve no interactive login to any workload, so guest login logs alone may not explain it; consult the control-plane audit log (the API call log), which records which identity called which operation and when.

Takeaway: export workload telemetry before the workload disappears, know which party holds each record, and look for cloud management changes in the control-plane audit log.

An API exposes operations and data to programs through defined requests, such as a request for invoice 4471 at a path like /api/invoices/4471. Every API request raises two separate questions: who is calling (authentication), and may this caller perform this action on this specific object (authorization).

The OWASP API Security Top 10^[11] ranks Broken Object Level Authorization (BOLA) first in its 2023 edition. Attackers exploit it by manipulating the ID of an object that is sent within the request^[11]; the defense is that every endpoint receiving an object ID checks that the logged-in user has permissions to perform the requested action on the requested object^[11]. OWASP stresses that in BOLA it's by design that the user will have access to the vulnerable API endpoint^[11]; the violation happens at the object level.

Picture an API log in which authenticated customer cust_1182 requests invoices 4471, 4472, 4473 and onward in sequence, each returning success. The successful authentication is exactly why the log looks normal, and it proves nothing about whether this customer may read those invoices. CISA's Cloud Security Technical Reference Architecture^[10] makes the same separation for cloud APIs: implement API authorization to enforce user permissions for API calls^[10], and use API access keys as identifiers that can be used to log which users make certain API calls^[10].

Takeaway: a successful login identifies the caller; only a per-object authorization check decides whether the caller may touch that record.

Zero Trust changes the question a network asks about a connection from where is it coming from to who is asking, from which device, for which resource. NIST SP 800-207^[12], NIST's zero trust architecture publication, describes zero trust as moving defenses from static, network-based perimeters to focus on users, assets, and resources^[12]. It assumes no implicit trust granted to assets or user accounts based solely on their physical or network location^[12] or on asset ownership, and treats authentication and authorization of both subject and device as discrete functions performed before a session to an enterprise resource is established^[12].

How a Zero Trust access decision works

Access is decided per resource by dynamic policy that can weigh the observable state of client identity, application/service, and the requesting asset^[12] plus behavioral and environmental attributes, and authentication and authorization to one resource will not automatically grant access to a different resource^[12]. SP 800-207's abstract model has three parties between a subject and a resource:

• Policy enforcement point (PEP): enables, monitors, and terminates the connection.
• Policy engine: makes the grant, deny, or revoke decision; SP 800-207 says it makes and logs the decision^[12].
• Policy administrator (PA): carries out the decision by telling the PEP to open or shut down the session.

The policy engine and policy administrator together form the policy decision point (PDP). In SP 800-207's typical scenario the request is forwarded to the policy administrator^[12], which forwards the request to the policy engine for evaluation^[12] and, if the request is authorized, configures the path to the resource: the PA configures the PEP to allow the session to start^[12], which is the bullet's telling the PEP to open the session and the step the figure below labels "tells PEP to act". For an analyst, the policy engine's decision log records whether a session was allowed or denied, but explaining why may require the policy and its inputs; a device sitting on the corporate network or connected through the VPN is not, by itself, a reason.

Zero Trust Network Access (ZTNA)

ZTNA applies Zero Trust to access to particular applications. CISA describes ZTNA as protecting identified on-premises and cloud-based internal private applications^[13] with granular, context-aware access controls that leverage identity, device, application, data, and network context. On this page ZTNA means Zero Trust Network Access, the access capability described above.

Secure access service edge (SASE)

CISA defines SASE as a technology framework that combines network capabilities with security functions^[13]: networking tools such as software-defined wide area networking (SD-WAN), routing, and bandwidth optimization, combined with security tools such as a secure web gateway (SWG), a cloud access security broker (CASB), ZTNA, and a next-generation firewall (NGFW). The terms therefore nest rather than compete: Zero Trust is the set of access principles, ZTNA is one access capability that applies them, and SASE is a combined service that can include ZTNA and, in CISA's words, support the implementation of zero trust architectures^[13]. Because SASE relies on cloud-based enforcement points^[13], the records of a remote user's web and application access may sit with the SASE service rather than at an on-premises gateway.

Takeaway: in a Zero Trust architecture, network location alone grants no trust; the per-request policy decision and its log show whether access was approved, while the policy and its inputs help explain why.

A hybrid cloud links separate cloud environments, and for an analyst it means one intrusion can cross from one environment to another without passing the device you usually watch. NIST SP 800-145^[14], NIST's definition of cloud computing, defines a hybrid cloud as a composition of two or more distinct cloud infrastructures (private, community, or public)^[14] that remain unique entities but are bound together by technology that enables data and application portability. In that composition a private cloud may exist on or off premises^[14] and a public cloud exists on the premises of the cloud provider^[14], so a hybrid environment can join an organization's on-premises private cloud with a provider's public cloud.

Hybrid cloud and ZTNA describe different things

Hybrid cloud describes where connected resources run; ZTNA, from the Zero Trust section above, describes how access to resources is controlled. The labels are independent: a hybrid environment may or may not use ZTNA, and ZTNA can protect applications in a single environment. When a scenario lists both, it is telling you two separate facts about the architecture.

Investigations cross the boundary

Hybrid environments usually link identity as well as networks. MITRE ATT&CK describes adversaries who log into cloud services using Valid Accounts that are synchronized with or federated to on-premises user identities^[1] and then perform management actions or access cloud-hosted resources. An intrusion can therefore begin on premises and continue in the cloud, or the reverse, and a user reaching a cloud service directly may never pass through the on-premises internet gateway. Correlate on-premises logs, cloud logs (including the control-plane audit log), and identity provider records instead of treating one perimeter device's view as the complete record of access.

Takeaway: in a hybrid environment, follow the identity and the data across every connected environment; do not assume one gateway provides the complete record.

Network segmentation limits which systems a compromised host can reach, and the permitted paths between segments are the baseline against which an analyst judges cross-zone traffic. CISA's microsegmentation guidance^[15] describes network segmentation as dividing a network into distinct segments, each acting as its own network, used to limit access to devices, data and applications and restrict communications between networks^[15]. Microsegmentation, the finer-grained form, lists among its benefits reducing the surface for lateral movement of adversaries that have breached networks^[15], lateral movement meaning an intruder's spread from the first compromised system to others.

• Expected or not. Traffic between two zones that policy says should never communicate is a finding by itself, even before you know its content.
• Blast radius. The allowed paths out of a compromised host's segment help estimate potential lateral movement and shape the scope of the response.
• Bypass paths. The CISA guidance advises understanding how it can be bypassed by an adversary, so that the bypass method can be monitored^[15] if it cannot be blocked.

Segmentation needs enforcement. Placing assets on unpublished or unusual addresses hides them but does not restrict communication, so it is not segmentation.

Takeaway: segmentation enforces limits on communication, and the allowed paths help you identify expected traffic and estimate potential lateral movement while accounting for bypass paths.

Suppose a policy lets a user open a record from a managed laptop at 10:00 but denies the same user from an unmanaged phone at 02:00: the OWASP Authorization Cheat Sheet^[16] notes that attribute-based authorization can incorporate environmental and other dynamic attributes, such as time of day, type of device used, and geographic location^[16], so one authenticated identity can receive two answers. Authorization decides what an authenticated identity may do, and several principles shape that decision.

Least privilege

The OWASP Authorization Cheat Sheet^[16] describes least privilege as assigning users only the minimum privileges necessary to complete their job^[16]. It follows the work, not the seniority: two analysts at the same grade may need access to different systems. Permissions also accumulate as people change roles, which is why CISA's red-team advisory A Tale of Two SOCs^[17] recommends that organizations periodically audit standard user accounts and minimize privileged access^[17].

Deny by default

OWASP explains that an application cannot remain neutral^[16] when no access control rule matches a request, and that it should be configured to deny access by default^[16], including whenever new functionality or resources are exposed. The opposite design, allowing everything not explicitly forbidden, turns every gap in the rule set into access, including resources added after the rules were written.

RBAC and ABAC

The two common authorization models take different inputs. OWASP describes role-based access control (RBAC) as a model in which access is granted or denied based upon the roles assigned to a user^[16], and attribute-based access control (ABAC), quoting NIST SP 800-162, as granting or denying requests based on assigned attributes of the subject, assigned attributes of the object, environment conditions^[16], and policies written over those attributes. To explain a decision, inspect the inputs the model used: role assignments for RBAC, and the evaluated subject, resource, action, and environment attributes for ABAC. An ABAC decision can therefore change while the user's job role stays the same, whenever the policy evaluates attributes such as device and time.

Privileged access management (PAM)

PAM adds controls around high-impact administrative access, such as controlled use of privileged credentials and monitoring of privileged activity. CISA recommends that organizations consider using a privileged access management (PAM) solution to manage access to privileged accounts and resources^[17], notes that PAM solutions can log and alert usage to detect unusual activity^[17], and describes just-in-time access, which provisions privileged access when needed^[17] for a set timeframe instead of leaving standing administrator rights. PAM is the relevant control family when the concern is accountability for and restriction of administrative operations; ordinary user connectivity to an application is a network access question, as in the ZTNA discussion above.

Takeaway: grant what the work requires, deny what no rule allows, explain decisions by the model's inputs, and put administrative power behind PAM.

Authentication establishes who or what is making a request, and the method recorded in an access event tells you exactly what was proven, which matters when you decide what an attacker must have held. NIST SP 800-63-4^[18], NIST's digital identity guidelines, defines three authentication factor types: something you know (e.g., a password)^[18], something you have (e.g., a device containing a cryptographic key), and something you are (e.g., a fingerprint or other biometric characteristic).

What each credential method proves

Method in the record	What was proven	What it does not show
Password	Knowledge of a secret value	Which device was used
Certificate-based client authentication	Control of the private key that matches a validated certificate	That anyone typed the account password
Bearer token	Possession of the token	That the password or any private key was presented

A password is a secret value the user memorized or recorded, and NIST SP 800-63B-4^[19] notes that passwords are not phishing-resistant^[19]. Certificate-based authentication is cryptographic authentication, accomplished by proving the possession and control of a cryptographic key via an authentication protocol^[19]; the certificate itself is public, so holding a copy of it proves nothing, and the private key is what counts. A bearer token works differently again: RFC 6750^[20] defines it as a token that any party in possession of the token (a "bearer") can use^[20], without proving possession of cryptographic key material. A session opened with a stolen token therefore need not involve the account password at all.

MFA counts factor types, not prompts

SP 800-63-4 states that multiple instances of the same factor still constitute single-factor authentication^[18], with the example that a user-generated PIN and a password do not constitute two factors^[18], and defines multifactor authentication (MFA) as the use of more than one distinct factor^[18]. A password plus a hardware security key is knowledge plus possession, so it is MFA; a password followed by a PIN (personal identification number) is two prompts and one factor type.

Federated single sign-on

In federated single sign-on (SSO), the application does not check the user's authenticator itself. SP 800-63-4 calls the application the relying party (RP) and says the identity provider (IdP) manages the subscriber's primary authenticators and issues assertions^[18]. NIST SP 800-63C-4^[21] describes the federation protocol as the verification of the subscriber's identity by the IdP and subsequent issuance of an assertion to the RP^[21], which establishes an authenticated session at the RP. It adds that the exact order in which that happens and which parties are involved in which steps can vary^[21], so the figure below shows one example, a sign-in started at the application, with the evidence to collect at each step where it is logged.

• Where to look. The authenticator check, including any MFA, happened at the IdP, so the application's own password-failure log can be empty for a federated sign-in. Join the IdP's sign-in and assertion records with the application's session records.
• How to join. SP 800-63C-4 builds a federated identifier from a subject identifier plus the IdP's issuer identifier, because different IdPs assign subject identifiers independently and could, therefore, potentially collide^[21]; an RP must never process the subject identifier without accounting for the IdP that issued^[21] it. Keep the issuer with the user identifier whenever you correlate.

Takeaway: read the recorded method to know what was proven, count factor types for MFA, and look to the IdP for how a federated session began.

Secrets are the credentials programs use: API keys, database passwords, SSH (Secure Shell) keys, and certificates with their private keys. The OWASP Secrets Management Cheat Sheet^[22] observes that many organizations have them hardcoded within the source code in plaintext^[22] or scattered through configuration files, and argues for centralizing the storage, provisioning, auditing, rotation and management of secrets^[22]. A secrets manager stores secrets centrally and releases them to authorized workloads at run time, so code and deployment files carry a reference instead of the credential. A private repository is not a substitute: the secret still travels with every clone and copy of the code.

Scope access and keep it attributable

Least privilege applies inside the secrets manager too. OWASP says engineers should not have access to all secrets^[22] and that the system needs fine-grained access control on each object. At a minimum, the audit trail should record who requested a secret and for what system and role^[22], whether the request was approved or rejected, and when the secret was used and by whom/what^[22]. Separate, narrowly scoped workload identities make that trail more useful for attribution. OWASP notes that when services share the same secrets^[22], identifying the source of a compromise or leak becomes challenging; an audit entry naming one identity shared by five services cannot tell you which service made a suspicious retrieval.

A leaked secret stays valid until it is invalidated

When a secret is exposed, for example committed to a repository, deleting the visible copy is cleanup, not containment, because the secret may already have been copied. OWASP says that when secrets are no longer required or potentially compromised, you must securely revoke them^[22], and that regular rotation means any stolen credentials will only work for a short time^[22]. Revoke or rotate the credential, then investigate how it was used during the exposure window, both in the secrets manager audit log and in the systems the secret unlocks.

Takeaway: keep secrets out of code, give each workload its own scoped identity so retrievals are attributable, and invalidate any exposed secret rather than just deleting it.

Encryption protects confidentiality, but what else it protects depends on the layer, mode (the cipher mode of operation, one of the various modes that can be used to allow block ciphers (such as AES) to encrypt arbitrary amounts of data^[23]), key management, and threat model, so the analyst's first question is where the data is exposed.

Key model: symmetric and asymmetric

NIST SP 800-63-4^[18] distinguishes secrets based on key pairs (i.e., asymmetric cryptographic keys)^[18] from shared secrets, including symmetric cryptographic keys, and describes an asymmetric key pair as a public key and a related private key^[18]. Symmetric encryption uses one shared secret key to encrypt and decrypt; asymmetric cryptography uses the related key pair. The key model describes the relationship between the keys, not every protection the data receives.

Confidentiality is not integrity

Encryption keeps unauthorized parties from reading data; on its own it does not detect changes or prove where data came from. The OWASP Cryptographic Storage Cheat Sheet^[23] recommends authenticated modes (authenticated encryption), which provide guarantees of the integrity and authenticity of the data, as well as confidentiality^[23], with GCM and CCM as first preferences. It warns that CTR and CBC modes do not provide any guarantees about the authenticity of the data^[23], so separate authentication must be added when they are used.

In transit, at rest, and at runtime

Encryption in transit, such as TLS (Transport Layer Security), protects data while it crosses a connection. Once a file lands at its destination, its protection depends entirely on how that destination stores it, so a transfer over TLS proves nothing about whether the exported file is encrypted on disk.

Encryption at rest protects stored data, and where it is applied decides what it stops. OWASP lists application, database, filesystem, and hardware levels and notes that hardware level encryption is effective at protecting against the physical theft of the server, but will provide no protection if an attacker is able to compromise the server remotely^[23]. The reason is that a running system has already made its storage readable to its authorized processes, so a compromised application reads the database exactly as the legitimate application does. Against that threat you need runtime access controls, such as least privilege for the application's account and monitoring of its queries, not more disk encryption.

Keep keys apart from the data

OWASP states that encryption keys should be stored in a separate location from encrypted data^[23], so that an attacker with access to only one cannot use both. An encrypted export whose unprotected, usable decryption key is accessible through the same path is protected only from people who cannot reach both.

Passwords are hashed, not encrypted

NIST SP 800-63B-4^[19] requires that passwords SHALL be salted and hashed using a suitable password hashing scheme^[19]. Verifying a password only needs to test whether a submitted password matches; nothing needs to recover the original. Reversible encryption, chosen so that support staff can read passwords back, keeps recoverable credentials with no verification benefit.

Takeaway: match the control to the exposure (connection, storage, or running system), keep keys away from the data, and hash passwords.

Data protection reduces how much sensitive data exists and controls where it may go, whatever encryption is applied to it.

Data minimization

The OWASP Cryptographic Storage Cheat Sheet^[23] puts it plainly: the best way to protect sensitive information is to not store it in the first place^[23]. Data minimization limits collection and retention to what the approved purpose needs. Where an analysis does not need direct identifiers, masking or de-identification keeps the analytic value while shrinking what an unauthorized reader could take; the log configuration section above applies the same idea to tokens and passwords. Encrypting unnecessary fields while keeping them indefinitely still exposes them to anyone whose authorized access is misused.

Data loss prevention (DLP)

NIST's glossary defines data loss prevention as a system's ability to identify, monitor, and protect data in use (e.g. endpoint actions), data in motion (e.g. network actions), and data at rest^[24] through content inspection and contextual analysis of attributes such as the originator, data object, medium, timing, recipient/destination^[24], with capabilities designed to detect and prevent the unauthorized use and transmission^[24] of protected information. The organization's data classification (its sensitivity labels and handling rules) tells DLP which data to protect and how.

For an analyst, a DLP alert matters for what it names: which protected data, which user, and which destination triggered the policy. Encryption alone does not establish that the disclosure is authorized. A spreadsheet of customer records sent over TLS to a personal webmail account is an encrypted disclosure to a destination assumed here to be unauthorized; the encryption protected the transfer from eavesdroppers, not the data from the wrong recipient.

Takeaway: keep less sensitive data, and judge a disclosure by what was sent, by whom, and to where, not by whether the channel was encrypted.

Critical infrastructure is defined by the consequences of its loss, not only by contact with the physical world. Its operation depends on operational technology (OT): NIST SP 800-82 Rev. 3^[25], NIST's guide to operational technology security, states that OT is vital to the operation of U.S. critical infrastructures^[25] and that OT encompasses a broad range of programmable systems and devices that interact with the physical environment^[25], with examples that include industrial control systems (ICS), building automation systems, transportation systems, physical access control systems^[25], among others. The three terms nest:

• OT is the umbrella category.
• ICS is SP 800-82 Rev. 3's general term that encompasses several types of control systems^[25], including SCADA systems, distributed control systems (DCS), and other configurations such as programmable logic controllers (PLCs), used in industrial sectors and critical infrastructure.
• SCADA (supervisory control and data acquisition) is one ICS type, used to control dispersed assets for which centralized data acquisition is as important as control^[25], such as pipelines, water distribution, and electrical transmission.

A DCS, by contrast, controls production within the same geographic location^[25], such as a refinery, and a PLC-based system can control a single local process. Both are ICS without being SCADA. The boxes are not exclusive, though: SP 800-82 Rev. 3 notes that PLCs are used in both SCADA and DCS systems^[25] as control components, so a PLC can sit inside either, whereas PLC-based systems, with a PLC as the primary controller, differ from SCADA and DCS^[25]; it also lists rail and other public transportation systems^[25] among SCADA's uses, so transportation systems, another OT example, can use SCADA, as the figure below shows.

The two halves of a SCADA system

SCADA systems are designed to collect field information, transfer it to a control center, and display the information to the operator^[25], so the operator can monitor or control an entire system from a central location. Typical hardware includes a control server at the control center, communications equipment, and geographically distributed field sites with remote terminal units (RTUs) or PLCs. When a command or a measurement looks abnormal, assess both halves: the central supervisory systems (control server and operator display) and the communications to the field devices that act on the process.

Takeaway: OT contains ICS, and ICS contains SCADA alongside DCS and PLC-based systems; SCADA is the one built for central supervision of dispersed field sites.

OT changes an analyst's default responses, because a security action that is routine on an office endpoint can have physical consequences. NIST SP 800-82 Rev. 3^[25] lists among OT's priorities significant risk to the health and safety of human lives, serious damage to the environment^[25], and production losses, notes that OT has different performance and reliability requirements^[25], and says security protections must maintain system integrity during normal operations as well as during cyber attacks^[25].

Coordinate before any disruptive action

Isolating an office laptop is routine; disconnecting a controller that keeps a physical process within safe limits may not be. Evaluate safety, performance, and reliability with the operational owner (the engineers responsible for the process) before applying a step that an IT playbook would run automatically.

Compensating controls when the normal control cannot run

SP 800-82 Rev. 3 notes that the lifespan of an OT system can exceed 20 years^[25], so many systems run unsupported software, and that when security controls are not supported by a legacy OT system compensating controls should be considered^[25]. Its example: anti-malware may not be available for PLCs and DCS, so a compensating control might be a firewall with a deep packet inspection capability^[25]. It also warns that host-based agents can impact the performance of the OT device^[25] and that monitoring solutions should be tested before deployment. Installing a standard endpoint agent on every controller without a compatibility review assumes IT software is safe on specialized OT; restricted network access and suitable network monitoring are the usual assessed alternatives.

Passive monitoring

Passive monitoring (SP 800-82 Rev. 3 calls it passive network scanning) inspects existing network traffic^[25]; systems that implement it do not introduce any additional traffic to the network^[25], which SP 800-82 Rev. 3 calls ideal for sensitive OT devices that may exhibit unexpected behavior when directly probed^[25]. Its limits are real: passive monitoring cannot identify devices that are not actively communicating^[25], nor inspect encrypted traffic without special provisioning. Active scans, by contrast, may cause device instability or interfere with the device process state^[25], and SP 800-82 Rev. 3 advises scheduling them during planned OT outages whenever possible. Incomplete passive visibility is a reason to plan any active discovery carefully with the operational owner, not a reason to probe without restriction.

Takeaway: in OT, safety and reliability come first, a compensating control stands in for an IT control the device cannot run, and passive monitoring is the default way to see without touching.

The scenarios below pair a record, or the absence of one, with a tempting conclusion that ignores which layer wrote it.

What the record shows	Tempting conclusion	Why it fails	Evidence to check
A cloud permission or resource changed	Check the VM's login history	Management API calls need no workload login (Cloud-native workloads)	The control-plane audit log
A source sent no events for hours	Nothing happened, close it	Missing telemetry is not observed inactivity (Log ingestion)	The collection path
Events from two systems disagree on order	Sort by SIEM arrival	Arrival reflects forwarding delay (Time synchronization)	Event time on synchronized clocks
Logs were forwarded over TLS	The logs are tamper-proof	Transport protection ends at storage (Log integrity)	Read-only storage, tamper detection, access monitoring
A server is fully patched	It is hardened	Patching does not remove unneeded services or privileges (System hardening)	The hardening baseline
A process has a system-binary name	It is legitimate	Names and locations can be imitated (System processes)	Parent, path, arguments, account
A laptop appears in the asset inventory	It is managed and compliant	Inventory identifies, it does not show current posture (Device management)	Current enrollment and compliance records
A container was compromised	It is isolated like a VM	Containers share the host kernel (Virtualization)	The host and its other containers
An API caller authenticated successfully	It may read any record	Authorization is decided per object (APIs)	Object-level authorization
A connection came from the corporate VPN	It is trusted	Zero Trust grants nothing for location (Zero Trust access)	The per-request policy decision
A password then a PIN were required	That is MFA	Both are something you know (Authentication methods)	Factor types
A federated sign-in is under investigation	Search the app's password failures	The IdP verified the authenticator (Authentication methods)	IdP sign-in and assertion records
A leaked secret was deleted from the repository	It is contained	Copies still authenticate (Secrets management)	Revoke or rotate, then review its use
A compromised app reads the encrypted database	Disk encryption stops it	The running system reads decrypted data (Encryption techniques)	Runtime access controls
Customer data went over TLS to a personal account	Encrypted, so acceptable	Encryption is not authorization to receive (Data protection)	DLP: which data, who, and where
An alert fires on a plant controller	Run the office isolation playbook	Physical safety and reliability come first (OT environments)	The operational owner, compensating controls, passive monitoring

The pattern behind every row is the question this page opened with: before accepting a conclusion, name the layer that would have recorded the action and ask what its record can and cannot prove.