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

1. Attributes

1.1. Can be domain specific

1.2. Conceptual abstraction of a real requirement

1.3. Are multi-tier

1.3.1. Distribute responsibilities downwards

1.3.2. Aggregate performance upwards

1.4. Must be measurable

1.5. Articulate performance targets relative to the targets of superdomains

1.6. Can be mapped to control objectives of various standards/regulations to achieve compliance to a number of standards/regulations

1.7. Examples

1.7.1. Business attributes Reputable Accurate

1.7.2. Security attributes Integrity Authentication

1.7.3. User attributes Accessible Accurate Reliable

1.7.4. Regulatory attributes Admissible Compliant Regulated

2. Domain Models

2.1. Security Domain

2.1.1. Set of elements subjected to a common security policy

2.1.2. Owned by a single Policy Authority

2.1.3. Can exist in multi-dimensions

2.2. Domain Registration Authority

2.2.1. Sets policy for the domain

2.2.2. Establishes identity and verifies credentials

2.3. Domain certification Authority

2.3.1. Provides chain of trust

2.3.2. Receives and certifies public keys

2.4. Types of domains

2.4.1. Subdomain Set of elements under a single policy authority and complies with a higher authority

2.4.2. Superdomain A domain that contains one or more compliant subdomains

2.4.3. Peer domain Domains that share a common superdomain policy

2.4.4. Logical domain Logical classification/department/line of business Convert the enterprise policy to a more granular one that can be understood locally Can have multiple physical domain

2.4.5. Physical domain Set of physical elements Can have multiple logical domains Serve the needs of the logical domain

2.4.6. Isolated domain Enforces its own self-contained policy Boundary must be explicit Trust is constant in the domain Has no inter-domain associations

2.4.7. Independent domain Enforces its own self-contained policy Boundary must be explicit Trust is constant in the domain Trust between domains is not constant Has gateway for inter-domain associations Physical access control contains many cells that have their own parameters

2.4.8. Honeycomb domain Contains many cells that have their own parameter Each cell has independent access policy

2.4.9. Combined domain Combines independent/isolated domain with honeycomb domain Strength-in depth provision Resolves variable trust and binary gateway issues Common in classified systems requiring clearance

2.4.10. Multi-tiered domain Layered model of domains New policy at each boundry

2.5. Communication

2.5.1. Inter-domain policy associations Simple Interactions between two independent domains or a superdomain and a subdomain Complex Via trusted third party domain Using mutually agreed policy

2.5.2. Policy authorities enforces their policy independently at the boundary/gateway

3. Service Architecture

3.1. Top-down process analysis

3.1.1. Vertical security consistency Accurate representation of conceptual attribute at each layer

3.1.2. Horizontal security consitency

3.1.3. Process layers Meta-process Contextual layer Strategic view of process Conceptual layer Information flows and transformations Logical layer Data flows and system interaction Physical layer Protocols and step sequences Component layer

3.2. Security services generally represented using SOA model

3.3. Information types

3.3.1. Static No changes in short term

3.3.2. Dynamic Changes in short term

3.4. Service types

3.4.1. Implicit Services in the same domain Subtypes Primary Secondary

3.4.2. Explicit Services that are explicitly requested from one domain to another

3.5. Service placement

3.6. Layer concept

3.6.1. Must be properly integrated and aligned

3.6.2. Trust exists by default between each layers

3.6.3. Layers Processing layer Antivirus & other security controls, local user authentication, local services, backups and change controls Information transfer layer Network Data Management Subsystem Middleware

3.7. Service management

3.7.1. Set of specialized organizational capabilities at each layer

3.7.2. Matches business requirements for controls and enablers

3.7.3. Make available the security capability and resources in a highly usable form

3.7.4. All activities in each layer need to be defined

4. Trust Concepts

4.1. Terms

4.1.1. Claimant One who is trusted Ex: customer

4.1.2. Relying party One who is relying on the trust Ex: vendor

4.2. Types

4.2.1. One-way trust Unidirectional trust relationship One party trusts the other

4.2.2. Two-way trust Bidirectional trust relationship Both parties trust each other

4.2.3. Transitive trust Also known as pass-through trust Uses a trusted third party Third party performs the registration Can be one-way or two-way Mutual authentication

4.3. Direction of trust

4.3.1. In the direction of dependancy

4.4. Strength of trust

4.4.1. Is the strength of registration process

4.5. Complex trust relationships

4.5.1. Decomposed to simple trust relationships for analysis

5. Governance Model

5.1. Steps

5.1.1. Strategy & Planning Develop business strategy Set goals, objectives and expectations Set performance targets, risk appetite Set policy to meet objectives and targets

5.1.2. Design Design process Design systems Design staffing model Design controls and enablers

5.1.3. Implement Establish process Implement systems Appoint and train people Establish controls and enablers

5.1.4. Manage & Measure Manage processes and operations Manage people and systems Monitor KRIs and KPIs

5.2. RACI model

5.2.1. Model Responsible Who is responsible for the activity Accountable Who is accountable for the activity Consulted Whose opinion is sought Informed Who are updated about the activity

5.2.2. All roles must be defined

5.2.3. Changes based on domain

5.2.4. Complexity directly proportional to the number of level in domain

5.2.5. Can be extended with additional roles Ex: Ownership, Assurance, Delegations

5.3. Ownership

5.3.1. Multi-faceted

5.3.2. Depends on the position in the governance model and domain model

5.3.3. Can be of asset liability cannot be deligated impact

5.3.4. Owner Sets goals, risk appetite and performance targets Accountable for performance of assets in the domain

5.3.5. Trustee Also called steward Responsible for performance of assets in the domain Can set policy on behalf of domain authority or owner

5.3.6. Custodian Policy authority not delegated Responsible for performance of assets in the domain Complies with policies already set

5.3.7. Compliance role To check and report on policy compliance and risk appetite Reports to the owner of the domain

5.3.8. Audit role Appointed by thesuperdomain Responsible for auditing performance of assets in a subdomain Reports to the owner of the superdomain

6. Security Associations

7. Contextual Layer

7.1. Gather business requirements

7.2. Define business drivers for security

7.3. Define business attributes

7.4. Map business drives and attributes

7.5. Types of goals

7.5.1. Strategic goals - Defined in Contextual and Conceptual layers Long-term goals and plans Have no end

7.5.2. Tactical goals - Defined in Logical, Physical and Component layers Medium-term goals and plans Address an immediate problems

7.5.3. Operational goals - Defined in Operations layer Day-to-day goals and plans Based on business processes containing repetitive procedures

8. Logical Layer

8.1. Managing security by breaking it into sub-processes