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.

layers

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.

Contextual architecture

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 and 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.


Cyber startups: keys to success

Innovation

What makes a cyber startup successful? From my working with a number of companies, there are four key areas cyber entrepreneurs should consider:

Idea

  • Are you passionate about the idea?
  • How unique is it?
  • Can your intellectual properly be protected?

Credibility

  • Do you have genuine expertise in your domain?
  • What do people in your community think of you?
  • Do you have a strong network and business skills?

Client-focus

  • Do you know your client?
  • Do you understand their issues?
  • Do they trust you to solve them?

Learning

  • Are you focusing on the right things?
  • Are you measuring the right things?
  • Are you incorporating client feedback into the development?

The key here, as you can see, is clients. There is really no way around understanding them, pleasing them and focusing on what they want. This feedback will allow you to pivot where required. Above all, stay focused and avoid premature scaling – don’t do too much too soon.


Books and blogs for cyber startup founders

e4c506fe-hutzero-logo_04t01404t014000000

HutZero, an early-stage entrepreneur bootcamp, kindly prepared a list of books and websites recommended for aspiring cyber startup founders.

Books:
The Lean Startup, Eric Reis
Business Model Generation, Alexander Osterwalder, Yves Pigneur
The Mom Test, Rob Fitzpatrick
Lean Analytics, Alistair Croll, Benjamin Yoskovitz
To Sell Is Human, Daniel H. Pink
Start with Why, Simon Sinek
The Purple Cow, Seth Godin
Lean UX, Jeff Gothelf, Josh Seiden
Made to Stick, Chip Heath, Dan Heath
The Four Steps to the Epiphany, Steve Blank
Do More Faster: Lessons from TechStars, Brad Feld, David Cohen
Fundraising Field Guide, Carlos Espinal

Blogs:
Wired Threat Level
Dark Reading
Krebs On Security
TechCrunch Europe
The Next Web
Tech.eu
Tech City News
Buffer Blog (marketing)
Steve Blank
Fred Wilson’s Blog, A VC
Brad Feld’s Blog (Techstars)
KissMetrics Blog (marketing)
Both Sides of the Table


Helping clients in Saudi Arabia

 

I’ve recently completed an assignment for one of the largest companies in Saudi Arabia where I had the pleasure of helping my clients improve their cyber security posture. During my time there I had the opportunity to explore this beautiful country, learn about its rich history and make a few friends.

And in case you are wondering how an Arabic keyboard looks like, here you go:

jvGavCsCSG6MP5VGAobf6g_thumb_3cf0


Security in mergers and acquisitions: integration

M&A 2

This blog is the second part of the discussion of security in mergers and acquisitions (M&A). I suggest to read Part 1 first, as I’m going to build on it and talk about what happens after the deal is finally signed.

Ok, it’s time to put that champagne glass down. I have bad news: closing the deal was the easy part. Now the hard work begins.

The purpose of the integration phase is to create value. More bad news: 83% of the M&A deals did not boost the shareholder value (according to KPMG global research report) and total average returns on M&A are negative (A.T. Kearney research).

All too often the root cause of these failures lies in poor integration.

There are ample opportunities to start losing the value right at the start during the handover between the deal and integration teams.

To alleviate this, I suggest identifying key resources and preparing implementation plans early in the process. Just like having an overall acquisition strategy and plan precedes the negotiation and due diligence phases, having an approach to integration is key to success. Deliverables, due dates, milestones, information flows are all need to be defined in advance. And cyber security plays a big role here.

A newly acquired company is a prime target for cyber criminals due to the magnitude of change it’s going through during the M&A process. Lack of governance, employee turnover, security vulnerabilities and many other factors can contribute to embarrassing security breaches that affect the reputation of the combined entity.

Key cyber security risks to consider:

  • Regulatory compliance liabilities and impact (e.g. GDPR fines)
  • Theft of intellectual property (data leaks, key employees leave with all the secrets, etc.)
  • Reputational damage (unwanted media attention due to data leaks)

The focus of cyber security post-deal is on protecting the value from internal and external threats, enabling secure integration, achieving long-term security and minimising cultural impact.

This can be attained in the following ways:

  • Supporting the project team deployment (security education, secured laptops, secure remote connection, encryption, etc.)
  • Identifying and prioritising key assets, systems, people and processes
  • Assessing the security of these assets (a carefully scoped pentest might be a good idea)
  • Ensuring confidentiality, integrity and availability of these assets (backups, antivirus, firewalls, patches, etc.)
  • Establishing and controlling access
  • Supporting the rationalisation of normalisation of processes
  • Developing an approach to cyber risk management (including third-party risk)
  • Rolling out security training
  • Supporting secure migration of applications and data
  • Supporting with incident management
  • Supporting with achieving compliance with relevant laws and regulations
  • Setting up a security monitoring capability of the merged entity
  • Establishing governance
  • Developing integrated security strategy and roadmap

Different cultures, attitudes to security and varying control frameworks are among many challenges to consider. Controls are typically relaxed to allow for the integration to go faster. This is where you need to be on a look out for increased threat levels.

To address these effectively, it’s a good idea to split your efforts in two stages: interim and long-term integration.

From the cyber security perspective, during the interim phase, the aim is to assess cyber maturity across the acquired entity rather than come up with a permanent solution.

High-risk areas should be addressed first by establishing interim controls. Long-term integration efforts should be initiated in parallel, starting with development of a security strategy, governance and roadmap.

Proportionality and risk-based approach is key here when integrating the acquired company into your governance structure and control framework. Focus on what matters most and prioritise security controls to protect the value and avoid backlash.

Don’t forget that people would need to still be able to carry out their duties with minimal disruption, but it’s a good idea to establish who needs access to what and why.

Some things can be outside of your control, like losing key employees after deal completion due to inadequate incentive structure. While it might not be your job to design the right retention mechanisms, it’s your responsibility to protect intellectual property, as mentioned above.

Above all, cyber security efforts during the integration process should be joined up with other functions and stakeholder groups. Work closely with the Legal team to minimise potential impact of compliance-related risks, engage Procurement for third-party risk management and align with the executive team to establish the right security culture.


Security in mergers and acquisitions: conducting due diligence

M&A 1

Recently I’ve had an opportunity to support a number of high-profile mergers and acquisitions (M&A) from the cyber security perspective. Although, due to the confidentiality of these projects I won’t be able to share any details, I would like to talk about some learnings and common approaches that might be useful.

The focus of this blog will be on the due diligence process and the role of security in it. It’s written from the buyer’s perspective, but insight into this thought process can be useful if you’re selling too.

Acquiring firms usually seek to fill the gaps in their capabilities (e.g. new technologies) in line with their strategy or to find overlaps allowing for cost reductions through greater consolidation.

Due diligence during M&A is rarely simple, quick or 100% accurate. It aims to reduce risk for both parties involved in the transaction and identify value creation opportunities. Although it might feel brief due to the business pressures, no amount of time will allow you to detect all the threats and identify every risk facing the business.

The main questions you would like to have clarity on from the security perspective are: “What security measures does the company have in place?” and “Are these the right measures?”

Sometimes, it feels like an art rather than a science.  But there are ways to reduce the uncertainty surrounding this process.

Jason Weinstein, former Deputy Assistant Attorney General, U.S. Department of Justice, once said: “When you buy a company, you’re buying their data, and you could be buying their data-security problems.”

Security teams, however, are not always welcome during M&A activities. Why? For one thing, it takes time and costs money to involve them. They may also scare or annoy employees of the target company and can be perceived as slowing things down or, worse still, hampering the deal.

So even when security gets involved, it’s usually quite late in the process with a few days left before the deal needs to be finalised.

To make matters worse, access to the target company is often restricted and the best you can get is a (partially) filled questionnaire. Your security-related questions form a part a broader pre-deal survey, so it’s a good idea to put some thinking what you should ask and why.

A number of subject matter experts in the deal team are all scrambling for limited available time and priority is sometimes given to understanding financials, legal aspects or broader IT strategy, rather than security specifically. Cyber risks, however, should form a core part of the process.

To alleviate some of the challenges outlined above, it helps if the value of the security involvement is clearly articulated (yes, it’s your job to do that). In short, it brings additional expertise to the table, protects the negotiating position and informs senior executives about potential risks, providing recommendations on mitigating them.

To save time, I’ve developed a high-level assessment template that covers all the possible areas of interest from the cyber security perspective and helps identify key assets, systems, processes and employees, but I would never send it as is. You need to do your homework and learn as much about the company and its culture as you can using the information in the public domain.

There are paid-for services out there but Google often does the job, as many OSINT experts would argue. Assuming, of course, you know how to use it! Open source intelligence and research skills at this stage are more useful than ever. Checking the dark web to see if target’s confidential information is being sold by cybercriminals can be useful too.

After the initial research, you can now tailor the questionnaire to verify your initial thoughts. Don’t be shy to ask for evidence if you want to see their policies or latest pentest reports: there are usually secure data rooms set up to share these kinds of documents.

The aim here is to understand the target company risk profile and make the deal team aware of the potential risks and opportunities. You can go one step further and quantify the risk, as this would help inform the value of the deal, potentially reducing the asking price to account for remediation activities during the post-deal phases. Despite the number of unknowns (believe me, it’s normal) it is also a good practice to provide recommendations.

It’s helpful to group your recommendations into three broad categories:

  1.  Risks that should be addressed before the deal can be signed (red flags)
  2.  Items that should be included in the contract (conditions on signing the deal)
  3. Post-deal activities as part of a 30-60-90 day plan that helps prioritise risks mitigation actions

Ask the target to disclose any known security flaws, issues and incidents. It’s probably also a good idea to reserve some funds for the remediation activities post deal. It shouldn’t be all negative; identify value creating opportunities too, if you can.

If you’re a seller, you can increase your marketability by assessing your own assets, discovering your own vulnerabilities and addressing these. Establishing processes to demonstrate compliance is a bonus. But don’t just focus on the current state, think about how your assets are going to stay so post-deal.

Congratulations! You successfully supported the business in making the right decision about this company. But the role of cyber security doesn’t end here. If the board decides to go ahead and the agreement is reached, we are moving into the post-deal stage.

Now, we need to ensure a smooth and secure integration.


I’ve been shortlisted for Security Serious Unsung Hero award

https-cdn.evbuc.comimages34832967976773616111original

I’ve been nominated for a Security Serious Unsung Hero award in the Best Educator category. This will be awarded to a professor, lecturer or teacher who leads by example to inspire and motivate the next generation of cyber security professionals. I’m humbled to be considered. Thank you!

Join me at the event.