Security 

SABSA

SABSA is a model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives. The primary characteristic of the SABSA model is that everything must be derived from an analysis of the business requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited.

The process analyses the business requirements at the outset, and creates a chain of traceability through the strategy and concept, design, implementation, and ongoing manage and measure phases of the lifecycle to ensure that the business mandate is preserved. Framework tools created from practical experience further support the whole methodology.

The model is layered, with the top layer being the business requirements definition stage. At each lower layer a new level of abstraction and detail is developed, going through the definition of the conceptual architecture, logical services architecture, physical infrastructure architecture and finally at the lowest layer, the selection of technologies and products (component architecture).

The SABSA model itself is generic and can be the starting point for any organisation, but by going through the process of analysis and decision-making implied by its structure, it becomes specific to the enterprise, and is finally highly customised to a unique business model. It becomes in reality the enterprise security architecture, and it is central to the success of a strategic program of information security management within the organisation.

Material here is sourced from the SABSA home pages.

The SABSA Matrix uses the same six questions that are used in the Zachman Framework:

The six vertical architectural elements map to all six horizontal layers for 6 x 6 matrix of cells, which represents the whole model for the enterprise security architecture. Addressing the issues for each of these cells provides for a complete security architecture. The process of developing an enterprise security architecture is a process of populating all of the thirty-six cells.

Contextual

The Business View - Contextual Security Architecture

In the SABSA Model this business view is called the contextual security architecture . It is a description of the business context in which a secure systems must be designed, built and operated.

The contextual architecture is concerned with:

• What
  The business, its assets to be protected (brand, reputation, etc.) and the business needs forinformation security (security as a business enabler, secure electronic business, operational continuity and stability, compliance with the law, etc.).
• Why
  The business risks expressed in terms of assets, goals, success factors and the threats, impacts and vulnerabilities that put these at risk, driving the need for business security (brand protection, fraud prevention, loss prevention, legal obligations, business continuity, etc.).
• How
  The business processes that require security (business interactions and transactions, business communications, etc.).
• Who
  The organisational aspects of business security (management structures, supply chain structures,out-sourcing relationships, strategic partnerships).
• Where
  The business geography and location-related aspects of business security (the global village market place, distributed corporate sites, remote working, etc.).
• When
  The business time-dependencies and time-related aspects of business security in terms of both performance and sequence (business transaction throughput, lifetimes and deadlines, just-in-time operations, time-to-market, etc.).

Conceptual

The architect's view is the overall concept by which the business requirements of the enterprise may be met.This layer of the SABSA Model is the conceptual architecture.

It defines principles and fundamental concepts that guide the selection and organisation of the logical and physical elements at the lower layers of abstraction.When describing the enterprise security architecture, this is the place to describe the security concepts and principles that will be used. These include:

• What
  What is to be protected, expressed in the SABSA Model in terms of Business Attributes. They provide the primary tool by which business requirements can be captured in a normalised form.
• Why
  The protection importantance in terms of control objectives.Control objectives are derived directly from an analysis of business operational risks and are a conceptualisation of business motivation for security.
• How
  How to achieve the protection, in terms of high-level technical and management securitystrategies.These strategies set out the conceptual layered framework for integrating individual tactical elements at thelower levels, ensuring that these fit together in a meaningful way to fulfil the overall strategic goals of thebusiness. Such strategies include: the strategy for applications security; the network security strategy; the public key infrastructure (PKI) strategy; the role-based access control (RBAC) strategy; and so on. For every major area of the business requirements identified in the contextual security architecture, there will bea security strategy (or group of strategies) that supports it.
• Who
  Who is involved in security management, in terms of entity relationship models, and the trust frameworkwithin which entities interact with one another.The important trust concepts are concerned with the various policy authorities that govern trust within adomain, the policies that set to govern behaviour of entities in each of those domains, and the inter-domain trust relationships.
• Where
  Where to achieve the protection conceptualised in terms of security domains.The important concepts here are security domains (both logical and physical), domain boundaries and security associations.
• When
  Where the protection relevant, in terms of both points in time and periods of time.The important concepts are lifetimes and expiry deadlines (of keys, certificates, passwords, sessions, etc.), and the use of trusted time for time-stamping and time-sensitive business transactions. Also important are time-related performance criteria - how quickly things must happen.

Logical

In business computing and data communications, this design process is calledsystems engineering . It involves the identification and specification of the logical architectural elements of an overall system.

This view models the business as asystem , withsystem components that are themselves sub-systems .It shows the major architectural security elements in terms of logicalsecurity services , and describes the logical flow of control and the relationships between these logical elements. It is therefore also known as thelogical security architecture .In terms of architectural decomposition down through the layers, the logical security architecture should reflectand represent all of the major security strategies in the conceptual security architecture. At this logical level,everything from the higher layers is transformed into a series of logical abstractions.The logical security architecture is concerned with:

• What
  Business information is a logical representation of the real business. It is this business informationthat needs to be secured.
• Why
  Specifying the security policy requirements (high-level security policy, registration authority policy,certification authority policy, physical domain policies, logical domain policies, etc.) for securing business information.
• How
  Specifying the logical security services (entity authentication, confidentiality protection, integrityprotection, non-repudiation, system assurance, etc.) and how they fit together as common re-usable building blocks into a complex security system that meets the overall business requirements.
• Who
  Specifying the entities (users, security administrators, auditors, etc.) and their inter-relationships,attributes, authorised roles and privilege profiles in the form of a schema.
• Where
  Specifying the security domains and inter-domain relationships (logical security domains, physicalsecurity domains, security associations).
• When
  Specifying the security processing cycle (registration, certification, login, session management,etc.).

Physical

The designer produces a set of logical abstractions that describe the system to be built. These need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components. The logical security services are now expressed in terms of the physical security mechanisms that will be used to deliver these services. In total, the physical security architecture is concerned with:

• What
  Specifying the business data model and the security-related data structures (tables, messages,pointers, certificates, signatures, etc.)
• Why
  Specifying rules that drive logical decision-making within the system (conditions, practices,procedures and actions).
• How
  Specifying security mechanisms (encryption, access control, digital signatures, virus scanning, etc.) and the physical servers upon which these mechanisms will be hosted.
• Who
  Specifying the people dependency in the form of the users, the applications that they use and thesecurity user interface (screen formats and user interactions).
• Where
  Specifying security technology infrastructure (physical layout of the hardware, software and communications lines).
• When
  Specifying the time-dependency in the form of execution control structures (sequences, events,lifetimes and time intervals).

Component

In the construction of information systems the builder needs to assemble and install a series of products from specialist vendors, with integratiors to join these products together during an implementation of the design.

Each of the installers and integrators is the equivalent of a tradesman, working with specialist products and system components that are are hardware-related, software-related and service oriented. Hence this layer of the architectural model is called the component security architecture.

The component architecture is concerned with:

• What
  ICT components such as ICT products, including data repositories and processors.
• Why
  The risk management-related tools and products such as risk analysis tools, risk registers, risk monitoring and reporting tools.
• How
  Process tools and standards (tools and protocols for process delivery - both hardware and software).
• Who
  Personnel management tools and products (identities, job descriptions, roles, functions, actions and access control lists).
• Where
  Locator tools and standards (nodes, addresses, and other locators).
• When
  Step timings and sequencing tools (time schedules, clocks, timers and interrupts).

Operational

Operational architecture is concerned with systems operations work. Here the focus of attention is only on the security-related parts of that work. The operational security architecture is concerned with:

• What
  Assuring the operational continuity of the business systems and information processing, andmaintaining the security of operational business data and information (confidentiality, integrity, availability, auditability and accountability).
• Why
  To manage operational risks and hence to minimise operational failures and disruptions.
• How
  Performing specialised security-related operations (user security administration, system securityadministration, data back-ups, security monitoring, emergency response procedures, etc.).
• Who
  Providing operational support for the security-related needs of all users and their applications (business users, operators, administrators, etc.).
• Where
  Maintaining the system integrity and security of all operational platforms and networks (by applying operational security standards and auditing the configuration against these standards).
• When
  Scheduling and executing a timetable of security-related operations.However there is another dimension to the operational security architecture, its vertical relationship with the other five layers of the model. Thus the operational security architecture needs to be interpreted in detail at each of the other five layers.

Operational security issues arise at each and every one of the other five layers. Operational security has a meaning in the context of each of these other layers.