SABSA Implementation(Part II)_ver1-0
Download as PPTX, PDF9 likes3,978 views
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
SABSA Implementation(Part II)_ver1-0
- 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
- 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