The document discusses implementation approaches for SABSA security architectures. It notes that SABSA does not define a specific implementation layer. Implementations are more likely to be a series of separate projects guided by the architecture and funded by business initiatives. The Service Management layer of SABSA defines how to manage and incorporate change across other layers through strategy, tactics, and operations. Performance management concepts are also discussed for defining business-driven targets.

1. SABSA Implementation
Generic Approach
PART VI

2. TIME & PERFORMANCE
MANAGEMENT CONCEPTS

3. Scope: Strategy & Planning Phase -
Time

4. Lifecycle Alignment – Demming to SABSA

5. Architecture Strategy & Planning Phase

6. Architecture Design Phase

7. Implementation Phase & Approach
• Implementation is an important part of the lifecycle but the
SABSA Matrix does not define a specific implementation
layer
– No need to re-invent Prince2 or PMI etc.
• Notoriously difficult to gain business support and budget
for pure infrastructure projects
• Rare that a major strategic enterprise-wide security
architecture is implemented as a single project
• More likely (and more sensible) is that the architecture
provides a blue-print and a road-map that guides a whole
series of separate implementation projects, each of which
is driven by a specific business initiative and funded by a
budget associated with that initiative

8. Manage & Measure Phase – Lifecycle Overlay
• SABSA Architecture traceably abstracts from pure
Business Context to:
– Pure technical deployment in the Component layer
– Pure management in the Service Management layer
• The Service Management layer defines all aspects
of security management and constructs the
means to manage and incorporate change by
being presented vertically across the other layers:
– Strategy (Context & Concept Layers)
– Tactics (Logical, Physical, & Component Layers)
– Operations (Security Service Management Matrix)

9. Manage & Measure Phase – SSM Matrix

10. SABSA Development Process

11. SABSA Risk Management Process Overview

12. Risk Management and the SABSA Matrix

13. SABSA Risk Management Activities

14. SABSA Lifecycle Domain Risk Perspectives

15. Process Improvement Framework –
SABSA Maturity Profile (SMP)
• Coordinates SABSA process information from all parts of the business
– Demonstrates due diligence to senior management, auditors and regulators
• Based on Capability Maturity Modelling (CMM) concepts
– Qualitative measurement technique for maturity of processes
– Six domains mapped onto the SABSA Matrix
– Consistent, objective 5-point maturity scale
• Identifies, measures and reports compliance practices
– Against the SABSA framework, model and processes
– Provides a gap analysis to drive a SABSA improvement programme
• Can be implemented through a web-enabled tool for
– Ease of use, wide involvement, quick responses
• Regular use tracks progress and measures changes
– Benchmarking against target maturity

16. SABSA Maturity Profile Process Areas
SMP Process Areas and SMP Process Activities
• Each of the six SMP domains is decomposed into six
SMP Process Areas
• These SMP Process Areas map onto the six cells of the
row of the SABSA
• Matrix corresponding to the particular SMP domain
• The SMP Process Activities are then derived by
overlaying the SABSA
• Service Management Matrix onto the SMP Process
Areas

17. SMP Maturity Levels

18. SMP Generic Practices

19. Performance Management Framework
Defining Business-driven Performance Targets

20. Architecture Measurement Categories
• Completeness
– Do we have all of the
components?
– Do they form an integrated
system?
• Assurance
– Does the system run
smoothly?
– Are we assured that it is
properly assembled?
– Is the system fit-for-purpose?
• Compliance
– Do we maintain the system?
– Do we follow the architecture
roadmap
– Do we comply with the rules?
• Performance
– Is the system properly tuned?
– Do the components work
together?
– Do we operate the system
correctly?
• Justification & significance
– Does the system have
business value?

21. Measurement Approaches
• High level statements of the approach to
obtaining a measurement
• Appropriate to the business need
• In the language of the intended audience
• Culturally specific

22. Measurement Guidelines
• Measurement should be a repeatable process
(for comparison & prediction)
• Measurement should have a clear
communications role
• Tracking performance
• Assigning resources
• Measurement should yield quantifiable metrics
(percentage, average, numbers, values, etc.)

23. Metrics Guidelines
• Data used to calculate metrics should be readily
obtainable
• Metrics may (should) be calculated
independently of parties with vested interest
• The type of metric used may change in line with
the maturity of the security process e.g. when
you are highly compliant, consider changing from
conformance measure to significance measure
• Performance metric / trend should be tested
prior to going ‘live’
• Expectations management is key

24. Types of Metric
• Soft Metrics
– Usually qualitative
– Subjective
– Open to interpretation and opinion (usually of the
authority setting the target or of an official
compliance agent such as a regulator or auditor)
• Hard Metrics
– Usually quantitative
– Objective
– Fixed, not open to opinion or interpretation

25. Types of Metric
• Descriptive
– Describes the current-state of the object / attribute
being measured
• Comparative
– Describes the current-state of the object / attribute
being measured in comparison with a similar object /
attribute relating to a different place and/or time
• Predictive
– Describes the current-state of the object / attribute
being measured in relation to its trend in order to
project and predict afuture state

26. Conceptual Measures & Metrics Framework

27. SABSA Vitality Framework

28. END OF PART VI