Architecting Cyber Security?

March 2017

Cyber Security is a controversial field. It is difficult to measure performance or demonstrate value. It is therefore considered later and relegated to a few add-on fixes when all design decisions have been made. Typical arguments are;

  • Security hinders the business process rather than helping - just focusing upon "security" rather than real business value?
  • Security tries to deliver controls in isolation without clear understanding of service context, priorities, risks or opportunities?
  • Security leads to increased complexity and cost of delivery and support?
Traditional approaches to Security often contribute to these arguments when;
  • Security (process & technology) design is isolated into domains (or control sets) and incapable of being integrated together (tactical approach).
  • Security and business strategy is loosely coupled (i.e. weak traceability / justification of security investments for business value).
  • Checklist / compliance approach - just checking the links (security controls) in the chain exist but do not test that the links actually fit together to form a secure chain.
Architectural approach to Security will resolve above by bringing disconnected pieces together within a structured framework that breaks down the complexity into modular blocks of simplified views. This is achieved by layering techniques and modular representations of security capabilities and reference solutions managed in an organised repository altogether.

A successful Security Architecture Practice should be tailored to;
  • create the holistic view of cyber security for the Enterprise (with Architecture Repository),
  • break down complexity into apparent simplicity by layering & abstraction,
  • describe and present capabilities consistently within a structure,
  • maintain the integrity of design (security view),
  • bring project streams together and set direction for design decisions,
  • guide to resolve conflicting objectives & priorities,
  • support compliance (regulatory &enterprise security standards) assessments naturally with robust solution references.
I described a model below for Security Architecture and suggested methods to tailor its content as per the Enterprise Architecture practice of an organisation.

The Reference Model

The Security Architecture Landscape is founded by a Reference Model that delivers a taxonomy for concepts and a common vocabulary for security capabilities altogether.

The Reference Model provides the bird's eye view and a simple method to classify cyber security capabilities and their relations. Each module in the Architecture Landscape represents a Security Domain (e.g. Access Control) that bundles similar security functions or capabilities together. Relationships between Security Domains are shown at the highest level of abstraction and with respect to the asset to be protected (i.e. the information system). 

Business context, libraries of information security controls and standards are also shown as part of the Reference Model as they drive the security capabilities to be described, managed and presented. They are typically formed of;

  • Business Security Requirements and Opportunities.
  • Enterprise IT Technical Security Controls.
  • Enterprise Security Policies & Standards.
  • Other Legislative & Regulatory Standards as appropriate.

Security Domains shown in the Reference Model above are defined later in this article.
Developing Content for the Architecture Repository; The Content Model

The agile way of developing architectures compel simple descriptions of capabilities and solutions that can be consumed easily. The Content Model for the referenced Security Architecture is tailored accordingly as per below principles;
  • Form consistent & brief structure for content development,
  • Hide complexity and promote reuse by layering & abstraction,
  • Trace capabilities for business justification and completeness.

My model develops content (Security Building Blocks) within two abstraction layers in the Architecture Repository;

Conceptual (Reference) Architecture is described for each Security Domain (service group) to provide a frame of conceptual reference (e.g. Access Control Conceptual Architecture). This is the highest level of abstraction for the Security Domain, with core concepts, functions and relations described in order to facilitate design / integration efforts.

Integration Patterns are described for common problem areas to deliver re-usable & abstracted reference solutions and blueprints (e.g. Customer Portal User Access Control, Border Protection in VendorX IaaS Cloud).
Conceptual (Reference) Architecture
Integration Pattern
Logical description of Security Domain.
Abstracted (“generalized for reuse”) view of a solution.
Guides to describe integration patterns.
Guides to implement specific solutions.
Design view of security principles / policies / standards.
Design view of IT system(s).
Contained within a single domain (e.g. access control)
May float around conceptual Security Domains.
Building blocks formed of logical security services.
Building blocks include physical system components or technologies.
One may argue how to describe Integration Patterns when a service is packaged and delivered by a partner (external) organisation that hides the technologies and processes involved. This is perfectly in line with the architecture approach as per the abstraction principle. Here, the scope of service (i.e. the utility) with its warranty attributes (SLAs) are typically defined and presented as per the Content Model structure.
Traceability of Building Blocks
Ideally, any building block described in the Architecture Repository is associated with the next specialized and abstracted layer of building block for completeness of business requirements and justification of chosen components. Below diagram shows five specialization / abstraction layers as per the SABSA framework (
My Content Model involves two abstraction layers only (Conceptual Architecture and Integration Pattern), spreading across the three layers of the SABSA model (conceptual, logical, physical). This is deliberately chosen as a pragmatic model to build and manage brief architecture descriptions within agile organisations.
Business & IT Strategy is considered as the layer above Conceptual Architecture and I consider this area to be worked as per the existing tools and practices of the organisation, such as the Enterprise (Business) Architecture or the Business / IT Strategy Planning Practice.
Security Domains - Definitions
This final section defines the Security Domains shown in the Reference Model diagram above.

1. Access Control

Integrated services to regulate and mediate access to information assets;
• Non-runtime administration functions for provisioning, maintaining and decommissioning identities, credentials and their attributes (permissions), such as group memberships or roles, within the identity life cycle,
• Runtime processing of access requests by validating identities (authentication) and ruling their rights of access (authorization),
• Enforcing access to resource systems and logging access events.

2. Communication Security

Data protection services when it is in motion across networks;
• Classifying network domains and establishing secure channels between domains,
• Preventing unauthorized disclosure of data when it traverses between domains (encryption),
• Ensuring timely and accurate delivery of data between systems (integrity, availability).

3. Application Security

Integrated services for secure development, delivery and maintenance of software applications;
• Risk assessment and threat modeling for application services,
• Secure code development and analysis,
• Security testing of application (static & dynamic testing, vulnerability scanning and penetration testing),
• Mitigation of security vulnerabilities in application software.

4. Data Security

Data classification and labelling concepts, descriptions and guidance for protection;
• Classifying and labelling data,
• Determining security services (Security Domains) pertinent to data classification levels,
• Determining legal/regulatory factors for Data and Information (e.g. GDPR, PCI DSS).

5. Platform Security

Integrated services for protection of data and application hosting platforms (compute and storage);
• Secure build and configuration of platforms (physical & virtual),
• Security testing of platforms (vulnerability testing and pre-production penetration testing),
• Secure configuration and access control for management consoles,
• Remediation of security vulnerabilities in platform software (patch management).

6. Border Protection

Integrated services to protect boundaries of infrastructure, networks and host systems from external security threats;
• Firewall Services,
• Malware Protection Services,
• Intrusion Detection & Prevention,
• Denial of Service Protection,
• Data Leak Control.

7. Security Operations

Operational services for systems monitoring, reporting, vulnerability and threat management;
• Backup / Restore (within context of cyber security),
• Vulnerability & Threat Management (reporting),
• Penetration Testing (when service in operation),
• Security Event Management,
• Security Monitoring.

8. Security Incident Management

Specialized form of incident response services following a reported security incident;
• Containing the impact of incident,
• Processes and activities for incident communication,
• Systems and data recovery,
• Forensics investigation.
Conclusion & Summary
Architecture in our context is all about describing and presenting services / capabilities altogether within a structure built on modular components, therefore complexity of changes can be managed, redundancy of services can be eliminated, and decisions can be made quickly and consistently, by tracing and justifying technology services as per business context.
I defined a structure in this article; delivering modularity with defined service groups, and ensuring traceability with abstracted service descriptions (content) within two layers (Conceptual Architecture  & Integration Pattern). Layering will also help to manage complexity of the heterogeneous technology landscape. I considered the content in these layers are owned by the Enterprise Security Architecture practice that embraces a pragmatic model for agile organisations.
A higher layer above Conceptual Architecture could be the Business Security Architecture layer in order to connect the cyber / IT Security Architecture to the business context. I excluded this in my model as this should be better tailored as per the Enterprise Architecture practice of the organisation. SABSA also provides powerful methods for Business Security Architecture  (e.g. business attribute profiling) and will perfectly fit this model for end-to-end traceability and justification.
Lower layers below Integration Patterns comprise system specific design & engineering content as appropriate - not typically delivered by Enterprise / Security Architecture. Integration Patterns are expected to provide design & implementation guidance to lower layers for consistent engineering and delivery of services (bottom-up flows are also possible, such as an engineering team developing a reference solution that forms a pattern for reuse by others).