Logical Layer
What security does, expressed as reusable logical services operating on information rather than data: services realise control objectives; mechanisms and sub-mechanisms define the workflows that implement them. (SABSA logical layer.)
Breaking Down Each Concept
Each concept below sets out what it is, exactly what an architect needs to do to establish it well, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Security Service
What it is: a logical service that delivers specific functionality to satisfy business-driven security requirements — operating on information rather than raw data, abstracted from implementation detail, and reusable across solutions.
What you need to do:
- Define the service by its interface — what it takes in, what it produces, what performance it guarantees — independent of which mechanism or product eventually implements it.
- Trace every service to the control objective it realises and, through it, to the business attributes it ultimately serves.
- Design the service to operate on information, not raw data, so it can be reused across solutions without being rewritten for each one.
- Keep the service self-contained. A service that only works when a specific product is present is not really abstracted at the logical layer.
- Name the service in business-recognisable terms wherever practical — "Authentication & Authorisation Service" — so non-architects can still follow the traceability chain.
Inputs: the control objective the service must realise, the business attributes it serves, existing service definitions if this is a refinement.
Outputs: a defined, reusable logical service, ready to be decomposed into the mechanisms that implement it.
Watch for: a "service" that is really just a product name with a service label attached. If swapping the vendor would mean rewriting the service definition, it was never at the logical layer.
2. Logical Mechanism
What it is: the logical process or workflow required to implement one or more security services — the sequence of tasks, decision points and information transformations, specified independently of the physical hosts that will execute it.
What you need to do:
- Define the mechanism as a logical workflow — the sequence of tasks, decision points and information transformations the service needs — before choosing what will execute them.
- Keep the mechanism technology-agnostic. It specifies what must happen; the physical layer decides where.
- Give the mechanism clearly defined inputs, outputs and performance criteria so it can be tested independently of its eventual physical implementation.
- Decompose the mechanism into sub-mechanisms only where a genuinely distinct, separately testable piece of workflow exists.
- Trace the mechanism back to the service it implements. A mechanism with no parent service is workflow without a purpose.
Inputs: the security service it implements, the process and decision logic the service actually requires.
Outputs: a defined logical workflow, ready to be realised by physical mechanisms and systems.
Watch for: a mechanism specified in terms of a particular tool's screens or configuration. That has jumped ahead to the physical layer before the logical workflow was actually settled.
3. Logical Sub-Mechanism
What it is: a finer-grained logical component of a broader mechanism, encapsulating a specific subset of the workflow — such as approval checks, data sanitisation, or audit log formatting.
What you need to do:
- Break the parent mechanism down only where a single, focused process element genuinely needs separate definition.
- Define clear inputs and outputs for the sub-mechanism so it can be composed or reordered within the parent mechanism without rework.
- Keep sub-mechanisms mapped back to specific control requirements, so audit and testing can trace a finding to an exact piece of workflow.
- Resist decomposing every mechanism to the same depth. Sub-mechanisms are for genuine complexity, not for the sake of a tidy-looking diagram.
Inputs: the parent logical mechanism and the specific workflow step it needs to isolate.
Outputs: a composable, testable logical sub-mechanism, ready to be realised by a physical sub-mechanism.
Watch for: sub-mechanisms that duplicate each other with minor variations — usually a sign the parent mechanism itself needs re-examining rather than further decomposition.