Chapter 3 — Operating systems and identities

Chapter 3 — Operating systems and identities

Lesson map

Lesson 03 published. Map, example, EX009.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["3.1 Name the layers before joining them"]
  N2["3.2 Synthetic host/identity/application bundle"]
  N3["3.3 A timeline with uncertainty and hypothesis branc"]
  N4["3.4 Worked join audit"]
  N5["3.5 Safe next actions and verification design"]
  N6["3.6 Identifier scope, lifetime and fan-out"]
  N7["3.7 Paper decision lab: approval is not attribution"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX009"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["3.1 Name the layers before joining them"]
  N2["3.2 Synthetic host/identity/application bundle"]
  N3["3.3 A timeline with uncertainty and hypothesis branc"]
  N4["3.4 Worked join audit"]
  N5["3.5 Safe next actions and verification design"]
  N6["3.6 Identifier scope, lifetime and fan-out"]
  N7["3.7 Paper decision lab: approval is not attribution"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX009"]

[Learning outcomes and connection]
    |
    v
[3.1 Name the layers before joining them]
    |
    v
[3.2 Synthetic host/identity/application bundle]
    |
    v
[3.3 A timeline with uncertainty and hypothesis branc]
    |
    v
[3.4 Worked join audit]
    |
    v
[3.5 Safe next actions and verification design]
    |
    v
[3.6 Identifier scope, lifetime and fan-out]
    |
    v
[3.7 Paper decision lab: approval is not attribution]
    |
    v
[Worked example] --> [Exercise EX009]

Learning outcomes and connection

The learner will distinguish a host process, an operating-system account, an identity principal, a session and a human; reconstruct only supported joins across host, IdP and application records; and specify a safe collection request when a join key is missing. Chapter 2 left the API-path explanation open. This chapter asks whether identity and host records narrow an observed reservation change without turning a service account into a person. NIST SP 800-61 Rev. 3 informs coordinated response, while NIST SP 800-86 provides forensic vocabulary from 2006; current OS/vendor collection details require separate verification.

3.1 Name the layers before joining them

A process is an executing program instance in a host namespace, identified locally by fields such as PID, start time and executable path. A PID can be reused after exit and is meaningless without host and time. An OS account supplies local privilege context for a process, but a daemon's account is not necessarily the user who initiated a request. An identity principal is an entity represented to an IdP or application; it may be a human, service or workload identity. A session is a particular authenticated context with an identifier and lifetime; a service principal can have many sessions. A human actor is a person whose actions require independent attribution evidence. These categories overlap but are not interchangeable.

An application may log a principal label but omit the session ID. A host may log a process owned by a service account but omit the IdP token used on an outbound request. Nearby timestamps and the same account string make a hypothesis, not a cryptographic or semantic join. To claim a direct join, ask the producer whether two records share an identifier with the same meaning and whether the logs cover the relevant route. A shared identity can be used by a legitimate scheduler and an emergency operator; a label alone cannot distinguish them. Blank actor means the producer did not provide a value, not that an anonymous attacker has been identified.

The response decision also has a service dependency. In the Chapter 1 graph, the worker and api both depend on idp; a broad principal disablement could stop approved scheduled work. A scoped read-only request for status and source coverage is safer than an unsupervised account action. A later containment proposal must include target session/principal, approving roles, expected legitimate service effect, verification and rollback. This chapter performs only a paper and offline analysis.

3.2 Synthetic host/identity/application bundle

The following records are fictional LLR data. They are supplied as snippets, not certified complete exports. All event times are source-reported UTC; the custodian has not supplied clock-offset measurements or original-object digests. No record contains personal information.

A01 is not the same request as Chapter 2's r-201: its request ID is r-202, and this chapter's bundle asks a distinct question about a reservation change, not the earlier /rooms 503. Both may belong to the same synthetic service, but no supplied producer links them. CH01 shows that R42 lies outside the visible approval record, not that a person acted maliciously. The next bounded request should ask the application owner whether r-202 carried an IdP session/actor mapping in a restricted server-side source and ask the change owner whether a valid R42 addendum exists. A trustworthy negative response requires coverage and version information, not just a search screenshot.

3.3 A timeline with uncertainty and hypothesis branches

At 11:58:00, I01 reports an IdP success. Four seconds later, H01 reports a process start on the named runner. At 12:00:03 A01 reports a change; one second later I02 reports a denied attempt. Because source clocks and collection paths are not verified, do not infer a four-second causal chain or treat I02 as proof that the A01 request failed. Three hypotheses remain plausible in the supplied evidence: H1, the approved worker was misconfigured to touch R42; H2, an unapproved operator or different task used the shared principal; H3, a change/addendum record is missing from the supplied calendar. A fourth option is an API audit error. Each has a falsifiable discriminator: a complete signed job manifest and request-ID map for H1; approved operator/session-to-request records for H2; versioned change ledger for H3; and an authoritative R42 state/audit reconciliation for the logging-error option. The provided snippets do not settle any branch.

At this point a technical analyst should preserve the snippets and request narrow source metadata: source object ID, producer, query, interval, collector, time basis, field definitions and digest of the copy actually received. A digest helps detect byte changes between copies; it does not prove completeness, correct collection or truth. If identity logs expire sooner than the calendar, prioritize a permitted preservation request with an owner and time limit, but do not silently expand it to all staff sign-ins. NIST SP 800-92 discusses log-management processes at a high level; real retention and access must be confirmed with the actual system owners.

3.4 Worked join audit

Draw four nodes: I01/sid-88, H01/runner-02:PID420, A01/r-202, CH01/R40-R41. I01 and H01 share a client/host label runner-02, but no session ID in H01. I01 and A01 share principal label svc-reserve, but A01 lacks a session ID. A01 and CH01 refer to different reservation sets, so CH01 is evidence of an approval-scope tension. The graph has dotted candidate edges, not validated direct joins. Do not turn the dotted I01–A01 edge into a solid arrow because the times are close. An extra record keyed by r-202 and a producer-validated sid-88 mapping could change that conclusion; so could an approved R42 addendum. Until then, the claim is “an R42 change was recorded under a shared principal outside the visible change scope.”

Offline check: paste the dictionary into Python 3 or reason about it on paper. It has no environment access. A blank value is deliberately represented as an empty string. The code tests only whether a literal matching session key exists; it cannot validate source semantics.

idp = {"principal": "svc-reserve", "session": "sid-88", "client": "runner-02"}
api = {"principal": "svc-reserve", "session": "", "request": "r-202"}
same_principal = idp["principal"] == api["principal"]
direct_session_join = bool(api["session"]) and idp["session"] == api["session"]
print("same principal label:", same_principal)
print("direct session join:", direct_session_join)

Expected lines: same principal label: True and direct session join: False. In a separate synthetic variant, set api["session"] = "sid-88"; the second line becomes True as a string comparison. Even that variant would require proof that the two producers use the same session namespace and the copied records are authentic before it supports a case conclusion. Restore the original fixture for the main LLR analysis. The test guards against a common automation bug: treating an empty session field as if it matched any successful session for the same principal.

3.5 Safe next actions and verification design

At the current checkpoint, preserve the raw snippets and a derived timeline separately; ask the identity custodian for a scoped session-to-request mapping if one exists and the application/change owners for R42 state and approval scope. The decision record should have explicit fields: source IDs; request window; custodian; permission; expected field; what a no-result means; collection receipt; remaining uncertainty. A read-only check must still respect data minimization and access control. If an owner later considers restriction, compare one session, one task and whole-principal options against the Chapter 1 dependency graph. The record needs an expiry, operator, service-health check and rollback owner before approval; this manuscript provides no actual operator procedure or credentials.

Verification should include both security and legitimate-function conditions. For example, if a narrow task pause is approved, a positive check asks whether the task stopped issuing out-of-scope R42 changes; a negative/business check asks whether approved R40/R41 work still functions. A failure to see R42 changes in a short sample is not proof that the path cannot recur; record coverage and next observation. Those checks belong to later containment chapters and a separately authorized lab. Here the learner designs them without touching a service.

3.6 Identifier scope, lifetime and fan-out

An identifier becomes useful only after its namespace, lifetime and cardinality are known. PID 420 is local to one host and execution interval and may be reused. A principal can outlive many sessions; a session can issue many requests; a request ID may be regenerated at a gateway; a reservation ID can be changed by several requests. A one-to-many relationship cannot be inferred as one-to-one simply because one sample shows only one row. A rigorous mapping claim has the shape “producer X reports field A in record Y corresponds to field B in record Z under rule R for interval T.” Without R, draw a dotted candidate edge.

For I01/H01/A01, use a join ledger with five columns: candidate edge, literal overlap, producer semantics, collection coverage and decision consequence. I01→H01 shares runner-02 and nearby time, but H01 has no session field. I01→A01 shares the svc-reserve label, but A01 has a blank session. H01→A01 has no request key. The immediate consequence is a bounded mapping request, not attribution of R42 to the worker. I02's denial belongs to a separate sid-89; it does not reverse I01's successful sid-88 or A01's change record.

In a separate hypothetical L3-V branch, imagine the application custodian supplies a producer-validated r-202→sid-88 mapping with an identified source object and covered time window. That would strengthen the I01→A01 session-level edge. It would not prove H01's process used sid-88, that the change was approved, or that a named person initiated it. If the mapping were instead assembled in an unversioned spreadsheet without original-object references, state the weaker provenance. Do not import L3-V into the main case; A01's supplied session field remains blank. This staged branch helps a learner identify exactly which uncertainty one new source can remove.

3.7 Paper decision lab: approval is not attribution

Consider a proposed broad disablement of svc-reserve because R42 is outside CH01's visible approval. The proposed control targets a principal, but the suspicious observation is a reservation change under a label. A broad restriction might stop the worker and an API dependency together. Compare a verified single-task pause, a single-session restriction and principal revocation. For each, specify target, approver, duration, rollback owner, positive security test and legitimate-work test. Also ask whether the control covers the hypothesized route: a task pause fails if another task used the principal; a session restriction fails if an actor can create a fresh session.

Outcome A, a hypothetical new approval ledger and producer-validated request map, shows a valid R42 addendum and maps r-202 to the approved job. The visible scope tension is resolved for this one request; keep the record and do not invent malicious intent. Outcome B shows a complete approval ledger with no R42 authorization, while the application source still lacks a session map. The business-approval concern strengthens, but actor attribution remains unresolved. Escalate a bounded preservation and control decision to the owners. The correct output distinguishes approval status, request provenance and human attribution. These are three questions, not three names for the same conclusion.

Before Chapter 4, state the data-handling consequence: a missing session value must not be filled from the nearest timestamp; a reused request ID needs a namespace check; a rejected line stays in the rejection inventory. This is why the identity memo must carry raw-source references and explicit unknowns, even when the likely next action feels obvious.

Common errors and limits

• Reading svc-reserve as a person's name or an intruder identity. It is a principal label shared by several possible workflows.
• Matching H01 PID 420 to a later process without host and start-time scope. PIDs can be reused.
• Claiming I02's denied attempt negates I01's earlier success or A01's application record.
• Treating a blank A01 session field as a wildcard join or evidence of deliberately hidden identity.
• Treating CH01's missing R42 approval as proof no approval exists anywhere; ask for a versioned, bounded ledger check.

Exercises — subject 3

EX009 — Entity separation. Objective: prevent false attribution. Inputs: I01, H01, A01, I02. Draw a five-column matrix for host process, OS account, IdP principal, session and human, and fill only supported fields. State one identifier needed for each proposed join. Evidence: matrix with empty/unknown cells retained. Rubric: 2 = distinguishes all five and no human attribution; 1 = four categories with one ambiguity; 0 = labels the service account as a person.

EX010 — Timeline and alternatives. Objective: preserve time and source limits. Inputs: I01–I02, H01, A01, CH01. Produce four timed event rows plus a separate change-scope row, then H1–H3 with one supporting item and one discriminator each. Evidence: source-linked Markdown. Rubric: 2 = no causal join from proximity and R42 scope tension stated; 1 = useful timeline with weak discriminator; 0 = claims actor or intent.

EX011 — Join-check lab. Objective: reproduce a bounded parser inference. Run §3.4's code or calculate its booleans by hand, then run the separate api["session"]="sid-88" variant. Report exact two-line outputs for both and the extra producer-semantic check needed before a real direct join. Evidence: original and variant transcript. Rubric: 2 = outputs and source-authenticity caveat; 1 = outputs only; 0 = main case recorded as a direct join.

EX012 — Collection and control proposal. Objective: connect evidence request to a reversible choice. Inputs: A01/CH01 and the Chapter 1 graph. Write a 150–200-word plan for a scoped r-202 mapping request, a versioned R42 approval check, and a proposed task-versus-principal restriction comparison. Name custodians, expiry/retention question, approved-change role, positive/negative verification and rollback owner. Evidence: paper request with blank execution fields. Rubric: 2 = exact scope and separate authorization/verification; 1 = plausible but missing one owner or negative check; 0 = directs an unapproved real change.

Subject synthesis

Host, identity and application records answer different questions. A shared label and close timestamps are starting points for an investigation, not a validated session-to-request edge or a human identity. Chapter 4 adds schema and parser checks so later source comparisons do not quietly discard malformed or ambiguous records.

Continue studying — chapter 03 of 18

← Chapter 02 · Course chapter index · Chapter 04 →

Continue to the next authored lesson.