SABSA Implementation

Generic Approach

PART II

POLICY ARCHITECTURE

SABSA Policy Domain Concepts

• A security domain is the set of entities (logical or physical) that are subject to a common security policy

• The domain owner (most senior party vested with authority in the domain) sets the security policy for the domain and is the Policy Authority

• The Policy Authority should be the clear owner of risk in the domain

• A security policy defines what is meant by security within a security domain (what security services are required to what performance level)

• The policy also defines how the domain interacts with other domains

• The owner may delegate implementation of the security policy to a lower security authority that acts on behalf of the domain owner

• The security policy is determined by the business requirements for information management and information systems, following an assessment of the possible operational risks & opportunities

• Security policy is a statement of business requirements for security, translated into a logical structure that can be consistently applied, monitored and measured

• The security policy states what logical services are required but as far as possible avoids any reference to particular physical mechanisms that will deliver the services

• Security policy documentation exists at a number of different levels, and hence it is useful to conceive of a hierarchically layered security policy architecture

SABSA Policy Architecture Framework

• Layered policy architecture with each layer being derived from the previous layer with traceability

• Enterprise-wide policy– Contextual business-level risk management policy– Conceptual abstraction of business policy in appropriate risk strategy

views

• Domain level policy– Logical domain policy – security service requirements to manage risk

to domain– Physical interpretation of policy – security practices and procedures– Component interpretation of policy – detailed security standards and

rules– Operational interpretation of policy – instructions to execute

procedure

Layered Policy Example

• Example: Backup Policy• Policy Statement (Logical layer): In my domain all application

systems must use a backup service that backs-up full data weekly with a daily incremental back-up on other days

• Procedure (Physical layer): This is how you configure the back up Application ABC hosted on Platform PQR:– N.B. The procedure itself is a security mechanism at the Physical

Security Architecture layer, but executing the procedure is an operational activity

• Internal Standard (Component Layer): Back-up media must be of minimum quality ‘x’ in accordance with ISO yyyyy and must be retired after ‘z’ uses. Labelling and indexing standards are... etc.

• Execution Instruction (Security Service Management Layer): To execute the back-up procedure for domain PQR, use service XYZ by going to menu KLM and double-clicking the “backup” icon

The SABSA Policy Framework

SABSA Policy Framework – Risk Strategy View

Inter-domain Policy Relationships

Inter-domain Policy Relationships

Vertical Domain Hierarchy – Risk Ownership & Responsibility

• Each Policy Authority in the SABSA Policy Framework is responsible for managing risks to their own domain-level assets, goals & objectives– They are unquestionably the primary subject matter expert– They know more about risks to their domain than anyone else– They have vested interest in their own critical success factors– Therefore they issue and sign policy for their own domain

• However, they set that policy in the context of delivering to agreed service levels with their super domain authority, thus their policy must comply with, meet the needs of, and be authorised by, that super domain authority

Multi-Dimensional Policy

• Domains (and therefore policies) of many types can exist in multiple dimensions– Logical community domains by business unit and/or geography

– Logical information domains by classification

– Physical infrastructure domains (technology layer domains)

SABSA Policy Framework – Domain Model

An enterprise domain model is constructed to deliver all concepts in this section

END OF PART II