SABSA Operations

Get Started. It's Free
or sign up with your email address
SABSA Operations by Mind Map: SABSA Operations

1. Policy Architecture

1.1. Structure

1.1.1. Must address only a group, not everyone

1.1.2. Must be in a language that the group can understand

1.1.3. Should be based and prioritized on the interests of the group

1.1.4. Enterprise wide policies should cover all risk dimensions, types or categories

1.1.5. Should state what is required at that layer and avoid references to lower level details

1.2. policy Authority

1.2.1. Owner of the risk to a domain

1.2.2. Accountable for the risks and opportunities to the assets/goals/objectives

1.2.3. Delegates responsibility to the sub domains

1.2.4. Set the policy in the context of meeting the super domain policy targets

1.3. Risk Conflicts

1.3.1. Handled by the super domain policy authority

1.3.2. Super domain policy authority is responsible for the overall risk

1.3.3. Mandates that an individual cannot be at two different domain levels

1.4. Waivers and exceptions

1.4.1. Created to avoid violation

1.4.2. Based upon business case

1.4.3. Common ones move to the super domain

1.4.4. Exceptions move to the sub domains

1.5. Framework

1.5.1. Enterprise Policy Contextual Policy Business risk management policy Conceptual policy Policies for each risk strategy

1.5.2. Domain Policy Logical Policy Policies for each risk strategy Physical Policy Procedures for each risk strategy Component policy Detailed standards and rules Operational policy Implementation and operational guides

1.6. Controls

1.6.1. Complex due to various standards, regulations, frameworks, life cycles and culture

1.6.2. Use top-down approach for architectural controls

1.6.3. Use bottom-up approach for service management controls

1.7. O-ESA (Open Enterprise Security Architecture)

1.7.1. Developed by the Open Group

1.7.2. Technique-focused policy architecture

1.7.3. Logical and physical layers

2. Risk Management

2.1. R (Risk) = T (Threat) * V (Vulnerability) * I (Impact)

2.2. Risks interact with each other and must be seen holistically

2.3. Impact based approach

2.3.1. Focus on critical risks

2.3.2. Can be used to establish priorities

2.3.3. Can be expressed in business language

2.3.4. Is faster and more usable

2.4. TCOR (Total cost of risk)

2.4.1. Cost of action + Cost of inaction

2.5. Measurement

2.5.1. Severity Magnitude of impact

2.5.2. Frequency Probability of event happening

2.6. Impact

2.6.1. Positive or negative consequences of potential events on attributes

2.6.2. Positive impact Opportunity Increase in attribute performance

2.6.3. Negative impact Threat Decrease in attribute performance

2.7. KRI

2.7.1. Key Risk Indicator

2.7.2. Indicates the risk level of an attribute

2.7.3. Two boundaries Primary Threshold for performance Secondary Early warning about nearing primary threshold

2.8. Analysis

2.8.1. Goal is to measure the attribute perforrmance

2.8.2. PESTELIM Political factors Economic factors Social factors Technological factors Environmental factors Legislative factors Industry factors Military factors

2.8.3. SWOT Strenght Weaknesses Opportunities Define enablement objective need to be improved Threats Define control objectives Need to be mitigated

2.8.4. Risk Management Tools Static Risk register Risk Treatment Plan Dynamic Gives real time view of the enterprise Can help in forecasting problems before they occur Dashboards

2.8.5. Risk Management Process Communicate and Assure Strategy and Planning Design Implement Manage and Measure

2.8.6. Systematic risk Failure to meet performance at lower level Cascades upwards impacting performance in higher levels

2.8.7. Standards ISO ISO 27005 ISO 31000 ISO 31010 The Open Group FAIR (Factor Analysis of Information Risk)

3. Metrics

3.1. Measurement guidelines

3.1.1. Should be repeatable

3.1.2. Have clear communication role

3.1.3. Yield quantifiable metrics

3.2. Metrics guidelines

3.2.1. Data used should be readily optainable

3.2.2. Must be calculated independently

3.2.3. Type of metric used can change

3.3. Type of metrics

3.3.1. Softs Qualitive

3.3.2. Hard Quantitative

3.3.3. Descriptive Current state description of an object/attribute

3.3.4. Comparative Current state in comparison to a similar object/attribute

3.3.5. Predictive Current state measurement based on its rend

3.4. Validity Framework

3.4.1. Architecture framework should adopt and support dynamic business needs

3.4.2. Achieved by Architectural change management Detection of new business requirements

3.5. Process improvement framework

3.5.1. SABSA Maturity Profile (SMP)

3.5.2. Based on CMM

3.5.3. 5 point maturity scale

3.5.4. SMP levels Unreliable Informal Defined Monitored Optimised

4. Security Administration

5. Assurance Framework

5.1. SABSA Matrix and Lifecycle

5.1.1. Assurance levels 1 to 4

5.2. Assurance

5.2.1. Providing confirmation and confidence about the management of risks

5.3. Assurance role

5.3.1. Provides policy compliance testing and auditing

5.4. Activities

5.4.1. Audits, reviews and other tests

5.5. Level

5.5.1. Correlate to risk level

5.5.2. High risk levels require higher assurance services