Date post: | 15-Jul-2015 |
Category: |
Documents |
Upload: | maganathin-marcus-veeraragaloo |
View: | 510 times |
Download: | 10 times |
SABSA Implementation
Generic Approach
PART I
Architecture Supports Strategy
• Every morning in Africa, a Gazelle wakes up.
• It knows it must run faster than the fastest lion…….or it will be killed.
• Every morning in Africa, a Lion wakes up. It knows it must run faster than the slowest Gazelle …….or it will die of starvation.
• Is it better to be a Lion or a Gazelle?
Business View – Survival StrategyWhen the sun comes up in Africa, it doesn’t matter what shape you are:
If you want to survive, what matters is that you’d better be running!
Layer Mapping for Traceability
BUSINESS CONTEXT AND REQUIREMENTS
Scope: Strategy & Planning Phase -Assets
Scope: Strategy & Planning Phase -Assets
Business Driver Development
BAP with KPI’s and KRI’s
Business Driven Architecture
• Being business-driven means never losing site of the organisation’s goals, objectives, success factors and targets, and ensuring that the security strategy demonstrably supports, enhances and protects them
• The contextual architecture captures and presents the full set of relevant requirements for the scope of the assignment– Including conflicts in business strategy, risks & priorities– At this stage we are confirming that they are complete and
we understand them– The conceptual layer will later resolve these conflicts by
delivering an appropriate, measurable security strategy
Credible Abstraction is Key
• Meaningful traceability is enabled by credible abstraction from business context (assets, goals & objectives) to a business security context
• Traceability therefore starts by delivering two slightly different sets of requirements:
Business Attributes
• An Attribute is a conceptual abstraction of a real business requirement (the goals, objectives, drivers, targets, and assets confirmed as part of the business contextual architecture)
• The Attributes Profiling technique enables any unique set of business requirements to be engineered as a standardized and re-usable set of specifications
• The Attributes are modeled into a normalized language that articulates requirements and measures performance in a way that is instinctive to all stakeholders
Attributes Profiling Rules & Features
• Attributes can be tangible or intangible• Each attribute requires a meaningful name and detailed definition
customised specifically for a particular organisation• Each attribute requires a measurement approach and metric to be
defined during the SABSA Strategy & Planning phase to set performance targets for security
• Attributes must be validated (and preferably created) by senior management & the business stake-holders by report, interview or facilitated workshop
• The performance targets are then used as the basis for reporting and/or SLAs in the SABSA Manage & Measure phase
• Powerful requirements engineering technique• Populates the vital ‘missing link’ between business requirements
and technology / process design
Two-way Traceability – Drivers to Attributes
Two-way Traceability – Attributes to Drivers
Sample of Business Drivers
Driver # Business Drivers
BD1Protecting the reputation of the Organization, ensuring that it is perceived as competent in its sector
BD2Providing support to the claims made by the Organization about its competence to carry out its intended functions
BD3
Protecting the trust that exists in business relationships and propagating that trust across remote electronic business communications links and distributed information systems
BD4Maintaining the confidence of other key parties in their relationships with the Organization
BD5 Maintaining the operational capability of the Organization’s systems
BD6Maintaining the continuity of service delivery, including the ability to meet the requirements of service level agreements where these exist
BD7 Maintaining the accuracy of information
BD8 Maintaining the ability to govern
Sample Taxonomy of ICT Attributes
BUSINESS CONTEXT AND REQUIREMENTS
Implementation Approach
Business AttributesBusiness
Attributes
User AttributesManagement
Attributes
Risk Management
Attributes
Legal/Regulatory Attributes
Technical Strategy
Attributes
Operational Attributes
Business Strategy
Attributes
Business Attribute Business Attribute Definition Suggested Measurement Approach Metric Type
User Attributes
Accessible Information to which the user is entitled to gain access should be easily found and accessed by that user.
Search tree depth necessary to find the information Soft
Accurate
The information provided to users should be accurate within a range that has been preagreed upon as being applicable to the service being delivered.
Acceptance testing on key data to demonstrate compliance with design rules Hard
AnonymousFor certain specialized types of service, the anonymity of the user should be protected.
Rigorous proof of system functionality Red team review
HardSoft
Consistent
The way in which log-in, navigation, and target services are presented to the user should be consistent across different times, locations, and channels of access.
Conformance with design style guides Red team review
Soft
Current
Information provided to users should be current and kept up to date, within a range that has been pre-agreed upon as being applicable for the service being delivered.
Refresh rates at the data source and replication of source and replication of refreshed data to the destination.
Hard
Attribute ProfileBusiness
Attributes
User AttributesManagement
Attributes
Risk Management
Attributes
Legal/Regulatory Attributes
Technical Strategy
Attributes
Operational Attributes
Business Strategy
Attributes
Business Attribute
Business Driver Business Attribute Definition Measurement Approach Metric
Performance Target
User Attributes
Accessible 5
Information to which the user is entitled to gain access should be easily found and accessed by that user.
Search tree depth necessary to find the information
Soft
Accurate 7
The information provided to users should be accurate within a range that has been preagreed upon as being applicable to the service being delivered.
Acceptance testing on key data to demonstrate compliance with design rules Hard
Anonymous 4
For certain specialized types of service, the anonymity of the user should be protected.
Rigorous proof of system functionality Red team review
HardSoft
Consistent 23, 41
The way in which log-in, navigation, and target services are presented to the user should be consistent across different times, locations, and channels of access.
Conformance with design style guides Red team review
Soft
Current 7
Information provided to users should be current and kept up to date, within a range that has been preagreed upon as being applicable for the service being delivered.
Refresh rates at the data source and replication of source and replication of refreshed data to the destination.
Hard
RISK AND OPPORTUNITY FRAMEWORK
Scope: Strategy & Planning Phase -Motivation
Scope: Strategy & Planning Phase -Motivation
Business Risk Assessment
Risk Analysis on Business Attributes
Aims, Characteristics & Benefits
• Achieve an appropriate balance between realizing opportunities for gains while minimising losses
• Establish an appropriate infrastructure and culture and apply a logical and systematic method
• Embed into the organisation's philosophy, practices and business• processes• Early warnings & fewer surprises• Economic & efficient exploitation of opportunities• Improved planning through provision of information for decision-
making• Accountability assurance & governance
• Extract from ISO 31000 (formerly AS/NZS 4360)
SABSA Operational Risk Opportunities
• In a sense no-one ‘chooses’ to take operational risk in the same way that they ‘choose’ to take financial risk of strategic risk
• Operational risk is generally seen as being all downside risk• Operational risk is perceived as ‘things that can go wrong’• Despite this negative view, operational risk-taking is needed
to realise business opportunities, either financial or strategic
• In the SABSA world operational risk can also be an upside risk
• Business enablement is achieved through excellence in operational processes, people and technical systems
• SABSA is a framework for achieving this excellence
SABSA Risk & Opportunity Model
SABSA Approach to Impact• Impact is expressed as positive or negative consequences of potential
events upon Attributes
• Negative impact expressed as
• Reduction in Attribute performance
• Failure to meet Attribute performance target
• Positive impact expressed as
• Increase in Attribute performance
• Increase in Attribute performance threshold to higher target
SABSA Controls & Enablers Derivation
RISK AND OPPORTUNITY
Implementation Approach
Sample Implementation - Risk
Business Attribute
Business Driver Risk (Impact Based) Security Controls
Architecture Controls Management Activity Controls
Deter
Avo
id
Preven
t
Detect
Re-act
Reco
ver
Co
nfid
entiality
Integrity
Availab
ility
Vo
ice
Data
Vid
eo
System
Info
rmatio
n
User Attributes
Accessible 5
Information to which the user is entitled to gain access should be easily found and accessed by that user.
Accurate 7
Acceptance testing on key data to demonstrate compliance with design rules
Anonymous 4Rigorous proof of system functionality
Consistent 23, 41Conformance with design style guides
Current 7
Refresh rates at the data source and replication of source and replication of refreshed data to the destination.
Sample Implementation - Enablement
Business Attribute
Business Driver
Opportunities (Aligned to Inf. Sec. Strategy) Enablement
Architecture Enablers Management Activity Enablers
Postu
re
Reco
ver
Matu
rity
Entren
ch
Co
mp
liance
Co
nfid
entiality
Integrity
Availab
ility
User Attributes
Accessible 5Search tree depth necessary to find the information
Accurate 7Acceptance testing on key data to demonstrate compliance with design rules
Anonymous 4
Rigorous proof of system functionality Red team review
Consistent23, 41
Conformance with design style guides Red team review
Current 7
Refresh rates at the data source and replication of source and replication of refreshed data to the destination.
END OF PART I