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
1.7.1.1. Reputable
1.7.1.2. Accurate
1.7.2. Security attributes
1.7.2.1. Integrity
1.7.2.2. Authentication
1.7.3. User attributes
1.7.3.1. Accessible
1.7.3.2. Accurate
1.7.3.3. Reliable
1.7.4. Regulatory attributes
1.7.4.1. Admissible
1.7.4.2. Compliant
1.7.4.3. 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
2.4.1.1. Set of elements under a single policy authority and complies with a higher authority
2.4.2. Superdomain
2.4.2.1. A domain that contains one or more compliant subdomains
2.4.3. Peer domain
2.4.3.1. Domains that share a common superdomain policy
2.4.4. Logical domain
2.4.4.1. Logical classification/department/line of business
2.4.4.2. Convert the enterprise policy to a more granular one that can be understood locally
2.4.4.3. Can have multiple physical domain
2.4.5. Physical domain
2.4.5.1. Set of physical elements
2.4.5.2. Can have multiple logical domains
2.4.5.3. Serve the needs of the logical domain
2.4.6. Isolated domain
2.4.6.1. Enforces its own self-contained policy
2.4.6.2. Boundary must be explicit
2.4.6.3. Trust is constant in the domain
2.4.6.4. Has no inter-domain associations
2.4.7. Independent domain
2.4.7.1. Enforces its own self-contained policy
2.4.7.2. Boundary must be explicit
2.4.7.3. Trust is constant in the domain
2.4.7.4. Trust between domains is not constant
2.4.7.5. Has gateway for inter-domain associations
2.4.7.6. Physical access control contains many cells that have their own parameters
2.4.8. Honeycomb domain
2.4.8.1. Contains many cells that have their own parameter
2.4.8.2. Each cell has independent access policy
2.4.9. Combined domain
2.4.9.1. Combines independent/isolated domain with honeycomb domain
2.4.9.2. Strength-in depth provision
2.4.9.3. Resolves variable trust and binary gateway issues
2.4.9.4. Common in classified systems requiring clearance
2.4.10. Multi-tiered domain
2.4.10.1. Layered model of domains
2.4.10.2. New policy at each boundry
2.5. Communication
2.5.1. Inter-domain policy associations
2.5.1.1. Simple
2.5.1.1.1. Interactions between two independent domains or a superdomain and a subdomain
2.5.1.2. Complex
2.5.1.2.1. Via trusted third party domain
2.5.1.2.2. 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
3.1.1.1. Accurate representation of conceptual attribute at each layer
3.1.2. Horizontal security consitency
3.1.3. Process layers
3.1.3.1. Meta-process
3.1.3.1.1. Contextual layer
3.1.3.2. Strategic view of process
3.1.3.2.1. Conceptual layer
3.1.3.3. Information flows and transformations
3.1.3.3.1. Logical layer
3.1.3.4. Data flows and system interaction
3.1.3.4.1. Physical layer
3.1.3.5. Protocols and step sequences
3.1.3.5.1. Component layer
3.2. Security services generally represented using SOA model
3.3. Information types
3.3.1. Static
3.3.1.1. No changes in short term
3.3.2. Dynamic
3.3.2.1. Changes in short term
3.4. Service types
3.4.1. Implicit
3.4.1.1. Services in the same domain
3.4.1.2. Subtypes
3.4.1.2.1. Primary
3.4.1.2.2. Secondary
3.4.2. Explicit
3.4.2.1. 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
3.6.3.1. Processing layer
3.6.3.1.1. Antivirus & other security controls, local user authentication, local services, backups and change controls
3.6.3.2. Information transfer layer
3.6.3.2.1. Network
3.6.3.3. Data Management Subsystem
3.6.3.4. 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
4.1.1.1. One who is trusted
4.1.1.2. Ex: customer
4.1.2. Relying party
4.1.2.1. One who is relying on the trust
4.1.2.2. Ex: vendor
4.2. Types
4.2.1. One-way trust
4.2.1.1. Unidirectional trust relationship
4.2.1.2. One party trusts the other
4.2.2. Two-way trust
4.2.2.1. Bidirectional trust relationship
4.2.2.2. Both parties trust each other
4.2.3. Transitive trust
4.2.3.1. Also known as pass-through trust
4.2.3.2. Uses a trusted third party
4.2.3.3. Third party performs the registration
4.2.3.4. Can be one-way or two-way
4.2.3.5. 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
5.1.1.1. Develop business strategy
5.1.1.2. Set goals, objectives and expectations
5.1.1.3. Set performance targets, risk appetite
5.1.1.4. Set policy to meet objectives and targets
5.1.2. Design
5.1.2.1. Design process
5.1.2.2. Design systems
5.1.2.3. Design staffing model
5.1.2.4. Design controls and enablers
5.1.3. Implement
5.1.3.1. Establish process
5.1.3.2. Implement systems
5.1.3.3. Appoint and train people
5.1.3.4. Establish controls and enablers
5.1.4. Manage & Measure
5.1.4.1. Manage processes and operations
5.1.4.2. Manage people and systems
5.1.4.3. Monitor KRIs and KPIs
5.2. RACI model
5.2.1. Model
5.2.1.1. Responsible
5.2.1.1.1. Who is responsible for the activity
5.2.1.2. Accountable
5.2.1.2.1. Who is accountable for the activity
5.2.1.3. Consulted
5.2.1.3.1. Whose opinion is sought
5.2.1.4. Informed
5.2.1.4.1. 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
5.2.5.1. 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
5.3.3.1. asset
5.3.3.2. liability
5.3.3.2.1. cannot be deligated
5.3.3.3. impact
5.3.4. Owner
5.3.4.1. Sets goals, risk appetite and performance targets
5.3.4.2. Accountable for performance of assets in the domain
5.3.5. Trustee
5.3.5.1. Also called steward
5.3.5.2. Responsible for performance of assets in the domain
5.3.5.3. Can set policy on behalf of domain authority or owner
5.3.6. Custodian
5.3.6.1. Policy authority not delegated
5.3.6.2. Responsible for performance of assets in the domain
5.3.6.3. Complies with policies already set
5.3.7. Compliance role
5.3.7.1. To check and report on policy compliance and risk appetite
5.3.7.2. Reports to the owner of the domain
5.3.8. Audit role
5.3.8.1. Appointed by thesuperdomain
5.3.8.2. Responsible for auditing performance of assets in a subdomain
5.3.8.3. 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
7.5.1.1. Long-term goals and plans
7.5.1.2. Have no end
7.5.2. Tactical goals - Defined in Logical, Physical and Component layers
7.5.2.1. Medium-term goals and plans
7.5.2.2. Address an immediate problems
7.5.3. Operational goals - Defined in Operations layer
7.5.3.1. Day-to-day goals and plans
7.5.3.2. Based on business processes containing repetitive procedures