This document provides an overview of conceptual security architecture using the SABSA framework. It describes key concepts like security architecture, enterprise frameworks, control objectives, multi-layered security strategies, security entity models, security domains, and security lifetimes and deadlines. The goal is to conceptualize security at a high level to address business risks and requirements through control objectives and a multi-layered approach using concepts like entities, domains, and relationships of trust.

1. CONCEPTUAL SECURITY
ARCHITECTURE

2. SECURITY ARCHITECTURE ?
• Security architecture is a unified security design that addresses the
necessities and potential risks involved in a certain scenario or
environment. It also specifies when and where to apply security
controls.

3. EXAMPLE:-
• Traditionally, security architecture consists of some preventive,
detective and corrective controls that are implemented to protect
the enterprise infrastructure and applications.

4. ENTERPRISE FRAMEWORKS
 SABSA
 Sherwood Applied Business Security Architecture
 TOGAF
 The Open Group Architecture Framework

5. SABSA OVERVIEW
• Five layer framework that answers the why, how, who, where and
when for security architecture.
• Five layers are Contextual Architecture, Conceptual Architecture,
Logical Architecture, Physical Architecture and Component
Architecture.
• A sixth layer is added for Service Management Architecture and is
synonymous with Operational Security Architecture.

6. SABSA (SHERWOOD APPLIED BUSINESS SECURITY
ARCHITECTURE)

7. (SABSA) FRAMEWORK –FULLY QUALIFIED

8. CONCEPTUAL SECURITY ARCHITECTURE
• This layer provides the overall concept by which the business requirements
of the enterprise may be met. The following information needs to be obtained:
• what needs to be protected;
• why protection is important and
• how it will be achieved;
• who will be involved in security management; physical and logical security
domains; time management framework as related to security.

9. BUSINESS ATTRIBUTE PROFILE
• This section explains in detail how this Business Attributes Profile is used as the
key tool for conceptualizing the business assets that need protection in an
information security architecture.
• The Business Attribute Profile is the complete set of Business Attributes that
you believe represents your business, mapped to business drivers and business
risks, and with a measurement approach for producing metrics and specific
performance targets defined for each one.

10. • This profile is a powerful tool that allows any unique business to be translated
into common terminology and normalized. The profile selects only those Business
Attributes that apply to this specific business (creating new attributes if there are
found to be gaps). The taxonomy provides a checklist of possible attributes. The
Business Analysts can decide whether or not a given attribute should be included
in this specific profile. The senior executives will usually need to sign off on the
overall Business Attributes Profile.

11. • The Business Attributes Profile is an important conceptualization of the real business
and forms a core part of the conceptual security architecture.
• It also allows the selection of metrics that are used to set performance targets as an
integral part of the Business Attributes Profile that can later be measured to answer
the question: ‘Did we hit the target?’ This too is at the choice of the business analysts,
using either the suggested measurement approaches in the detailed definitions of the
attributes, or creating new measurement approaches if this seems more appropriate.
Once again, the performance targets usually need to be signed off at senior
executive level.

12. CONTROL OBJECTIVES
• This section explains in detail how the control objectives are used as the key tool
for conceptualizing the mitigation strategy to address the identified business
risks.
• A control objective is a statement of a desired result or purpose to be achieved
by implementing controls within a particular business activity. Controls are
implemented through policies, organizational structures, processes, practices and
procedures, and through technical systems.

13. • A control objective can be stated in response to specific business requirements
for control, or it can be a generic ‘good practice’ statement that should be
applied to all businesses.
• The control objectives form an interface between the contextual and conceptual
layer.

14. • There are several sources of generic ‘good practice’ control objectives
There are several sources of generic ‘good practice’ control objectives
such as:
 ISO/IEC 17799: ‘A Code of Practice for Information Security Management’2;
 ISO/IEC 21827: ‘Systems Security Engineering Capability Maturity Model’3;
 CobiTTM: ‘Control Objectives for Information and related Technology’4;
 ISF’s5 ‘Standard for Good Practice’6;

15. SECURITY STRATEGIES AND ARCHITECTURAL
LAYERING
• There are many security strategies that you can adopt and many ways in which
you can layer your security architecture. This section examines some of these
possibilities in some detail, at a conceptual level.
• Security architecture is not the same as software architecture.

16. MULTI-LAYERED SECURITY
Increased effectiveness is achieved by multiple layers of security of different types

17. • The primary reason for this multi-layered approach is to ensure that there is no
single point of failure in the security measures. If one measure fails to stop a
security incident, then there are others that do the job in a different way. The
multiple layers provide a reasonable level of assurance that there are multiple
ways of preventing security breaches. This is a fundamental principle that is
strongly recommended that you adopt in your security architecture.

18. SECURITY STRATEGIES INCLUDES:-
• Authentication, Authorization and Audit Strategy
• Security Service Management Strategy
• System Assurance Strategy

19. SECURITY ENTITY MODEL AND TRUST FRAMEWORK
 Security Entities
 A security entity is something or someone that can take actions in a business environment.
These actions need to be controlled through authorization processes and through technical
and procedural controls that enforce the authorizations. Security entities are of several
types:
 Individual personal entities (people);
 Corporate entities (organizations or organizational units, whether legally recognized as
entities or not);
 Application or system entities – automated processes that act on behalf of personal or
corporate entities.

20. • Security Entity Naming
 Each security entity must be identified with a globally unique name to ensure that
there will never be confusion about which entity is being referenced.
• Security Entity Relationships
 Security entity relationships are characterized by the information flows that represent
the relationship.

21.  There are three major types of entity relationship that you must
consider:
a. Unilateral relationships – in which one entity broadcasts or publishes
information and other entities may receive it at their choice;
b. Bilateral relationships – in which two entities make a specific contract
(either formal or informal) to transact business and exchange information;
c. Multilateral relationships – in which a number of entities participate in a
group relationship under an agreed set of rules.

22. • Understanding and Modelling Trust
• Trust in the merchant-customer relationship

23. SECURITY DOMAIN MODEL
• Security Domains
 A security domain is a set of security elements subject to a common security
policy defined and enforced by a single security policy authority. The
activities of a security domain involve one or more elements from that
security domain, and possibly elements of other security domains.
 A security element may be a security entity or a security object.

24. • Trust in Domains
 Trusted entities in a domain
 Conditional and unconditional trust Conditional and unconditional trust
 Trust is not necessarily two way or transitive
• Secure Interaction Between Domains
• To be able to exchange information between domains the domain policy
authorities must agree a set of security policy rules governing this interaction –
known as secure interaction rules

25. SECURITY LIFETIMES AND DEADLINES
• This section explains in detail the main lifetime and deadline concepts that you need
to consider.
• Registration Lifetimes
 Each registered entity is registered for a fixed period of time, after which the registration
expires and must be renewed.
• Certification Lifetimes
 A registered entity can be issued with a set of digital certificates with which to
authenticate messages and exchange encryption keys. These digital certificates also have
fixed lifetime, after which the certificate expires and cannot be used.