SABSA Architecture and Design Case Study

Let’s talk about applying the SABSA framework to design an architecture that would solve a specific business problem.  In this blog post I’ll be using a fictitious example of a public sector entity aiming to roll-out an accommodation booking service for tourists visiting the country.

To ensure that security meets the needs of the business we’re going to go through the layers of the SABSA architecture from top to bottom.

Business View Contextual Architecture
Architect’s View Conceptual Architecture
Designer’s View Logical Architecture
Builder’s View Physical Architecture
Tradesman’s View Component Architecture

Contextual architecture

Start by reading your company’s business strategy, goals and values, have a look at the annual report. Getting the business level attributes from these documents should be straightforward. There’s no need to invent anything new – business stakeholders have  already defined what’s important to them.

Every single word in these documents has been reviewed and changed potentially hundreds of times. Therefore, there’s usually a good level of buy-in on the vision. Simply use the same language for your business level attributes.

After analysing the strategy of my fictitious public sector client I’m going to settle for the following attributes: Stable, Respected, Trusted, Reputable, Sustainable, Competitive. Detailed definitions for these attributes are agreed with the business stakeholders.

Conceptual architecture

Next step is to link these to the broader objectives for technology. Your CIO or CTO might be able to assist with these. In my example, the Technology department has already done the hard job of translating high-level business requirements into a set of IT objectives. Your task is just distill these into attributes:

 

Objectives

Now it’s up to you to define security attributes based on the Technology and Infrastructure attributes above. The examples might be attributes like Available, Confidential, Access-Controlled and so on.

Requirements tractability

The next step would be to highlight or define relationships between attributes on each level:

Attributes

These attributes show how security supports the business and allows for two-way tracebility of requirements. It can be used for risk management, assurance and architecture projects.

Back to our case study. Let’s consider a specific example of developing a hotel booking application for a public sector client we’ve started out with. To simplify the scenario, we will limit the application functionality requirements to the following list:

ID Name Purpose
P001 Register Accommodation Enable the registration of temporary accommodations available
P002 Update Availability Enable accommodation managers to update availability status
P003 Search Availability Allow international travellers to search and identify available accommodation
P004 Book Accommodation Allow international travellers to book accommodation
P005 Link to other departments Allow international travellers to link to other departments and agencies such as the immigration or security services (re-direct)

And here is how the process map would look like:

Process map

There are a number of stakeholders involved within the government serving international travellers’ requests. Tourists can access Immigration Services to get information on visa requirements and Security Services for safety advice. The application itself is owned by the Ministry of Tourism which acts as the “face” of this interaction and provides access to Tourist Board approved options. External accommodation (e.g. hotel chains) register and update their offers on the government’s website.

The infrastructure is outsourced to an external cloud service provider and there are mobile applications available, but these details are irrelevant for the current abstraction level.

Trust modelling

From the Trust Modelling perspective, the relationship will look like this:

Trust

Subdomain policy is derived from, and compliant with, super domain but has specialised local interpretation authorised by super domain authority. The government bodies act as Policy Authorities (PA) owning the overall risk of the interaction.

At this stage we might want to re-visit some of the attributes we defined previously to potentially narrow them down to only the ones applicable to the process flows in scope. We will focus on making sure the transactions are trusted:

New attributes

Let’s overlay applicable attributes over process flows to understand requirements for security:

Flows and attributes

Logical Architecture

Now it’s time to go down a level and step into more detailed Designer’s View. Remember requirement “P004 – Book Accommodation” I’ve mentioned above? Below is the information flow for this transaction. In most cases, someone else would’ve drawn these for you.

Flow 1

With security attributes applied (the direction of orange arrows define the expectation of a particular attribute being met):

Flow 2

These are the exact attributes we identified as relevant for this transaction on the business process map above. It’s ok if you uncover additional security attributes at this stage. If that’s the case, feel free to add them retrospectively to your business process map at the Conceptual Architecture level.

Physical architecture

After the exercise above is completed for each interaction, it’s time to go down to the Physical Architecture level and define specific security services for each attribute for every transaction:

Security services

Component architecture

At the Component Architecture level, it’s important to define solution-specific mechanisms, components & activities for each security service above. Here is a simplified example for confidentiality and integrity protection for data at rest and in-transit:

Service Physical mechanism Component brands, tools, products or technical standards Service Management activities required to manage the solution through-life
Message confidentiality protection Message encryption IPSec VPN Key management, Configuration Management, Change management
Stored data confidentiality protection Data encryption AES 256 Disk Encryption Key management, Configuration Management, Change management
Message integrity protection Checksum SHA 256 Hash Key management, Configuration Management, Change management
Stored data integrity protection Checksum SHA 256 Hash Key management, Configuration Management, Change management

As you can see, every specific security mechanism and component is now directly and traceable linked to business requirements. And that’s one of the ways you demonstrate the value of security using the SABSA framework.

Advertisements

Early Stage Cybersecurity Accelerator Programme

HutZero

A few weeks ago I learnt that my application to attend the HutZero cyber entrepreneur bootcamp had been successful.  I am excited to start the programme next week and will keep you posted!

Whether you are just finishing your studies on cyber security, or have worked in the corporate world for a number of years, HutZero supports individuals at the very start of their entrepreneurial journey.


Interview with the ISSA Journal

Snip20170902_2

I’ve been interviewed by Geordie B Stewart for the ISSA Journal.

Read the rest of this entry »


Cybersecurity Canon: The Psychology of Information Security

 

Big-Canon-Banner.png

My book has been nominated for the Cybersecurity Cannon, a list of must-read books for all cybersecurity practitioners.

Review by Guest Contributor Nicola Burr, Cybersecurity Consultant

Read the rest of this entry »


The Psychology of Information Security book reviews

51enjkmw1ll-_sx322_bo1204203200_

I wrote about my book  in the previous post. Here I would like to share what others have to say about it.

So often information security is viewed as a technical discipline – a world of firewalls, anti-virus software, access controls and encryption. An opaque and enigmatic discipline which defies understanding, with a priesthood who often protect their profession with complex concepts, language and most of all secrecy.

Leron takes a practical, pragmatic and no-holds barred approach to demystifying the topic. He reminds us that ultimately security depends on people – and that we all act in what we see as our rational self-interest – sometimes ill-informed, ill-judged, even downright perverse.

No approach to security can ever succeed without considering people – and as a profession we need to look beyond our computers to understand the business, the culture of the organisation – and most of all, how we can create a security environment which helps people feel free to actually do their job.
David Ferbrache OBE, FBCS
Technical Director, Cyber Security
KPMG UK

This is an easy-to-read, accessible and simple introduction to information security.  The style is straightforward, and calls on a range of anecdotes to help the reader through what is often a complicated and hard to penetrate subject.  Leron approaches the subject from a psychological angle and will be appealing to both those of a non-technical and a technical background.
Dr David King
Visiting Fellow of Kellogg College
University of Oxford

Read the rest of this entry »


Presenting on cyber security at UCL

ucldark_0.jpg

The UCLU Technology Society invited me to deliver a talk on information security to UCL students. Together with my colleague, I discussed various aspects of information security focusing on both technical and non-technical topics.

We talked about Advanced Persistent Threats and common misconceptions people have about them. When referring to protection measures, I emphasised the importance of considering human aspects of security. I described typical causes of a poor security culture in companies, along with providing some recommendations on improving it.

I concluded the evening with a discussion on managing and communicating the necessary changes within the organisation and the skills required to successfully do that.


Cyber Wargaming Workshop

ID-10071890

I was recently asked to develop a two-day tabletop cyber wargaming exercise. Here’s the agenda.
Please get in touch if you would like to know more.

Day 1
Introduction
Course Objectives
Module 1: What is Business Wargaming?
How Does Business Wargaming Work?

  •         Teams
  •         Interaction
  •         Moves

Module 2 Cyber Fundamentals

  •         Practical Risk Management
  •         Problems with risk management
  •         Human aspects of security
  •         Conversion of physical and information security
  •         Attacker types and motivations
  •         Security Incident management
  •         Security incident handling and response
  •         Crisis management and business continuity
  •         Cyber security trends to consider

Module 3: Introducing a Case Study

  •         Company and organisational structure
  •         Processes and architecture
  •         Issues

Module 4 Case study exercises

  •         Case study exercise 1: Risk Management
  •         Case study exercise 2: Infrastructure and Application Security

Day 2
Introducing a wagaming scenario
Roles and responsibilities
Simulated exercise to stress response capabilities
The scenario will be testing:

  •         How organisations responded from a business perspective
  •         How organisations responded to the attacks technically
  •         How affected organisations were by the scenario
  •         How they shared information amongst relevant parties

Feedback to the participants
Course wrap up

Image courtesy zirconicusso / FreeDigitalPhotos.net