This document discusses concepts related to policy architecture in the SABSA framework. It introduces key ideas such as: - Security domains that are subject to a common security policy set by a domain owner. - Security policy defines the security services and requirements for a domain as well as its interactions with other domains. - A layered policy architecture with each layer derived from the previous to ensure traceability from enterprise-wide to operational levels. - Examples of how a backup policy can be expressed at different layers from the logical to operational. - Inter-domain relationships where each domain authority is responsible for their risks but sets policy in the context of super domain authorities. Domains and policies can exist in multiple dimensions such as

1. SABSA Implementation
Generic Approach
PART II

2. POLICY ARCHITECTURE

3. 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

4. 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

5. 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

6. The SABSA Policy Framework

7. SABSA Policy Framework – Risk
Strategy View

8. Inter-domain Policy Relationships

9. 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

10. 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)

11. SABSA Policy Framework – Domain Model
An enterprise domain model is constructed to deliver all concepts in this section

12. END OF PART II