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
1.5.1.1. Contextual Policy
1.5.1.1.1. Business risk management policy
1.5.1.2. Conceptual policy
1.5.1.2.1. Policies for each risk strategy
1.5.2. Domain Policy
1.5.2.1. Logical Policy
1.5.2.1.1. Policies for each risk strategy
1.5.2.2. Physical Policy
1.5.2.2.1. Procedures for each risk strategy
1.5.2.3. Component policy
1.5.2.3.1. Detailed standards and rules
1.5.2.4. Operational policy
1.5.2.4.1. 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. Metrics
2.1. Measurement guidelines
2.1.1. Should be repeatable
2.1.2. Have clear communication role
2.1.3. Yield quantifiable metrics
2.2. Metrics guidelines
2.2.1. Data used should be readily optainable
2.2.2. Must be calculated independently
2.2.3. Type of metric used can change
2.3. Type of metrics
2.3.1. Softs
2.3.1.1. Qualitive
2.3.2. Hard
2.3.2.1. Quantitative
2.3.3. Descriptive
2.3.3.1. Current state description of an object/attribute
2.3.4. Comparative
2.3.4.1. Current state in comparison to a similar object/attribute
2.3.5. Predictive
2.3.5.1. Current state measurement based on its rend
2.4. Validity Framework
2.4.1. Architecture framework should adopt and support dynamic business needs
2.4.2. Achieved by
2.4.2.1. Architectural change management
2.4.2.2. Detection of new business requirements
2.5. Process improvement framework
2.5.1. SABSA Maturity Profile (SMP)
2.5.2. Based on CMM
2.5.3. 5 point maturity scale
2.5.4. SMP levels
2.5.4.1. Unreliable
2.5.4.2. Informal
2.5.4.3. Defined
2.5.4.4. Monitored
2.5.4.5. Optimised
3. Security Administration
4. Assurance Framework
4.1. SABSA Matrix and Lifecycle
4.1.1. Assurance levels 1 to 4
4.2. Assurance
4.2.1. Providing confirmation and confidence about the management of risks
4.3. Assurance role
4.3.1. Provides policy compliance testing and auditing
4.4. Activities
4.4.1. Audits, reviews and other tests
4.5. Level
4.5.1. Correlate to risk level
4.5.2. High risk levels require higher assurance services
5. Risk Management
5.1. R (Risk) = T (Threat) * V (Vulnerability) * I (Impact)
5.2. Risks interact with each other and must be seen holistically
5.3. Impact based approach
5.3.1. Focus on critical risks
5.3.2. Can be used to establish priorities
5.3.3. Can be expressed in business language
5.3.4. Is faster and more usable
5.4. TCOR (Total cost of risk)
5.4.1. Cost of action + Cost of inaction
5.5. Measurement
5.5.1. Severity
5.5.1.1. Magnitude of impact
5.5.2. Frequency
5.5.2.1. Probability of event happening
5.6. Impact
5.6.1. Positive or negative consequences of potential events on attributes
5.6.2. Positive impact
5.6.2.1. Opportunity
5.6.2.2. Increase in attribute performance
5.6.3. Negative impact
5.6.3.1. Threat
5.6.3.2. Decrease in attribute performance
5.7. KRI
5.7.1. Key Risk Indicator
5.7.2. Indicates the risk level of an attribute
5.7.3. Two boundaries
5.7.3.1. Primary
5.7.3.1.1. Threshold for performance
5.7.3.2. Secondary
5.7.3.2.1. Early warning about nearing primary threshold
5.8. Analysis
5.8.1. Goal is to measure the attribute perforrmance
5.8.2. PESTELIM
5.8.2.1. Political factors
5.8.2.2. Economic factors
5.8.2.3. Social factors
5.8.2.4. Technological factors
5.8.2.5. Environmental factors
5.8.2.6. Legislative factors
5.8.2.7. Industry factors
5.8.2.8. Military factors
5.8.3. SWOT
5.8.3.1. Strenght
5.8.3.2. Weaknesses
5.8.3.3. Opportunities
5.8.3.3.1. Define enablement objective
5.8.3.3.2. need to be improved
5.8.3.4. Threats
5.8.3.4.1. Define control objectives
5.8.3.4.2. Need to be mitigated
5.8.4. Risk Management Tools
5.8.4.1. Static
5.8.4.1.1. Risk register
5.8.4.1.2. Risk Treatment Plan
5.8.4.2. Dynamic
5.8.4.2.1. Gives real time view of the enterprise
5.8.4.2.2. Can help in forecasting problems before they occur
5.8.4.2.3. Dashboards
5.8.5. Risk Management Process
5.8.5.1. Communicate and Assure
5.8.5.1.1. Strategy and Planning
5.8.5.1.2. Design
5.8.5.1.3. Implement
5.8.5.1.4. Manage and Measure
5.8.6. Systematic risk
5.8.6.1. Failure to meet performance at lower level
5.8.6.2. Cascades upwards impacting performance in higher levels
5.8.7. Standards
5.8.7.1. ISO
5.8.7.1.1. ISO 27005
5.8.7.1.2. ISO 31000
5.8.7.1.3. ISO 31010
5.8.7.2. The Open Group
5.8.7.2.1. FAIR (Factor Analysis of Information Risk)