Modern digital technology underpins the shift that enables businesses to implement new processes, scale quickly and serve customers in a whole new way.
Historically, organisations would invest in their own IT infrastructure to support their business objectives and the IT department’s role would be focused on keeping the ‘lights on’.
To minimise the chance of failure of the equipment, engineers traditionally introduced an element of redundancy in the architecture. That redundancy could manifest itself on many levels. For example, it could be a redundant datacentre, which is kept as a ‘hot’ or ‘warm’ site with a complete set of hardware and software ready to take the workload in case of the failure of a primary datacentre. Components of the datacentre, like power and cooling, can also be redundant to increase the resiliency.
On a lesser scale, within a single datacentre, networking infrastructure elements can be redundant. It is not uncommon to procure two firewalls instead of just one to configure them to balance the load or just to have a second one as a backup. Power and utilities companies still stock up on critical industrial control equipment to be able to quickly react to a failed component.
The majority of effort, however, went into protecting the data storage. Magnetic disks were assembled in RAIDs to reduce the chances of data loss in case of failure and backups were relegated to magnetic tapes to preserve less time-sensitive data and stored in separate physical locations.
Depending on specific business objectives or compliance requirements, organisations had to heavily invest in these architectures. One-off investments were, however, only one side of the story. On-going maintenance, regular tests and periodic upgrades were also required to keep these components operational. Labour, electricity, insurance and other costs were adding to the final bill. Moreover, if a company was operating in a regulated space, for example if they processed payments and cardholder data then external audits, certification and attestation were also required.
With the advent of cloud computing, companies were able to abstract away a lot of this complexity and let someone else handle the building and operation of datacentres and dealing with compliance issues relating to physical security.
The need for the business resilience, however, did not go away.
Cloud providers can offer options that far exceed (at comparable costs) the traditional infrastructure; but only if configured appropriately.
One example of this is the use of ‘zones’ of availability, where your resources can be deployed across physically separate datacentres. In this scenario, your service can be balanced across these availability zones and can remain running even if one of the ‘zones’ goes down. If you build your own infrastructure for this, you would have to build one datacentre in each zone and . You better have a solid business case for this.
It is important to keep this in mind when deciding to move to the cloud from the traditional infrastructure. Simply lifting and shifting your applications to the cloud may, in fact. These applications are unlikely to have been developed to work in the cloud and take advantage of these additional resiliency options. Therefore, I advise against such migration in favour of re-architecting.
Cloud Service Provider SLAs should also be considered. Compensation might be offered for failure to meet these, but it’s your job to check how this compares to the traditional “5 nines” of a availability in a traditional datacentre.
You should also be aware of the many differences between cloud service models.
When procuring a SaaS, for example, your ability to manage resilience is significantly reduced. In this case you are relying completely on your provider to keep the service up and running, potentially raising the provider outage concern. . Even with the data, however, your options are limited without a second application on-hand to process that data which may also require data transformation. Study the historical performance and pick your SaaS provider carefully.
IaaS gives you more options to design an architecture for your application, but with this great freedom comes great responsibility. The provider is responsible for fewer layers of the overall stack when it comes to IaaS, so you must design and maintain a lot of it yourself. When doing so, assume failure rather than thinking of it as a (remote) possibility. Availability Zones are helpful, but not always sufficient. What scenarios require consideration of the use of a separate geographical region? The European Banking Authority recommendations on Exit and Continuity can be an interesting example to look at from a testing and deliverability perspective.
Be mindful of characteristics of SaaS that also affect PaaS from a redundancy perspective. For example, if you’re using a proprietary PaaS then you can’t just lift and shift your data and code.
Above all, when designing for resiliency, take a risk-based approach. Not all your assets have the same criticality. , know your RPO and RTO. Remember that SaaS can be built on top of AWS or Azure, exposing you to supply chain risks.
Even when assuming the worst, you may not have to keep every single service running should the worst actually happen. For one thing, it’s too expensive – just ask your business stakeholders. The very worst time to be defining your approach to resilience is in the middle of an incident, closely followed by shortly after an incident. As with other elements of security in the cloud, resilience should “shift left” and be addressed as early in the delivery cycle as possible. As the Scout movement is fond of saying – “be prepared”.
Image by Berkeley Lab.
ArchiMate modelling language is one of the The Open Group enterprise architecture standards. It is aligned with TOGAF and aims to help architects (and other interested parties) understand the impact of design choices and changes.
Here I would like to build on the foundation we’ve laid while discussing SABSA architecture and design case study and share and example of using the Archi tool to model security architecture using SABSA framework.
Let’s say ACME Corp asked us to help them with their security architecture. Where do we start?
As described in my previous blog, let’s establish Contextual Architecture.
Using Archi, I select Principles (can be found in Motivation section) for attributes and define composition relationship between elements (e.g. ACME Corp is composed of Cost-effective, Reputable and many other attributes that hopefully define the business).
Here and below I’ll be using a simplified example just to illustrate a point – you will have many more attributes in practice.
From reading company annual reports and talking to business stakeholders we can start identifying business drivers of ACME Corp. We can them map these business drivers to attributes. Below is an illustration of mapping a business driver Generate revenue (Driver element) to the attribute Cost-effective using Influence relation, as business drivers influence attributes.
On the Conceptual architecture level we need to start defining lower level attributes. For example, Cost-effective is composed (Composition relation) of Available and Business-driven
Remember that you can provide definitions of your attributes in the element’s properties (Main section). In this example I’m defining Available as Service should be uninterrupted. You are also encouraged to establish a measurement approach for each attribute. You can see above that Uptime is the main KPI for availability. It’s a hard measure where we monitor the percentage of time system is available compared to what is specified in the SLA.
Logical level provides an insight into what capabilities enable the attributes. In the example below, Available is realised (Realsisation relation) by Backup capability which in turn is comprised of Synchronous and Asynchronous backup capabilities (Composition relation).
Archi tool allows us to model SABSA Physical Architecture view by describing services, events, processes, interfaces, functions and other elements of the TOGAF Technology layer.
Below is a simplified example of describing the Asynchronous backup capability.
Asynchronous backup is being realised by Backup manager application service (reaalisation relation). Backup store is a data object that is being accessed by the Backup manager (access relation).
You can be quite detailed here and that’s where Archi tool can add a lot of value. But to keep things simple, I’m going to leave it at that. You can decompose elements into services and function, group them together and even go lower describing actual technology solutions on SABSA Component architecture level.
The real question is: what do you do with all of this?
My answer is simple: visualise.
Archi let’s you switch into the Visualiser mode and create graphs bringing all your hard work together. Playing with depth (6 in the example above) you can analyse the architecture and ensure traceability: you can see and, more importantly, demonstrate to your business stakeholders how a particular technology solution contributes to the overall business objective.
In addition, the Validator allows you to see the elements that are orphaned, i.e. not related to any other element. You then have the ability to rectify this and introduce a relationship or discontinue the capability (otherwise, why are you paying for something that is not in use?).
If you followed the steps above, the tool, despite being free, actually does a lot of the heavy lifting for you and automatically adjusts the models and graphs if changes to the architecture are introduced.
Now it’s your turn to try out Archi for SABSA architecture. Good luck!
Telling stories is one of the best ways to get your ideas across, especially when your audience is not technical. Therefore, as an architect, you might want to communicate in a way that can be easily understood by others.
TOGAF, for example, encourages enterprise architects to develop Business Scenarios. But what if you want to represent your concepts visually? The solution might lie in using a modelling language that meets this requirement.
ArchiMate is an open standard for such a language that supports enterprise architects in the documenting and analysing of architecture. Full alignment with aforementioned TOGAF is an added bonus.
The ArchiMate mimics constructs of the English language i.e. it has a subject, an object and a verb that refer to active, passive and behavior (action) aspects respectively. It employs these constructs to model business architecture.
To illustrate this, let’s model a specific business process using ArchiMate. Similarly to the example described in one of the whitepapers, let’s consider a stock trader registering an order on the exchange as part of the overall Place Order process.
Thinking back to the English language parallel, what does this sentence tell us? In other words, who is doing what to what?
In this scenario, a Trader (subject) places (verb) the order (object).
The diagram below illustrates how this might look like when modelled in ArchiMate.
‘Trader’, being an active element is modelled as Business Role, ‘Place Order’ as a behavior (action) element is represented as Business Process and the passive ‘Order’ itself is modelled as Business Object.
The relationship between elements carry meaning in ArchiMate too. In our example, Assign relation is used to model the ‘Trader’ performing the ‘Place Order’ action. Contrary, the interaction between ‘Place Order’ and ‘Order’ is modelled using Access relation to illustrate that the the Business Process creates the Business Object.
To put all of this into practice, you can use the Archi modelling toolkit. It’s free, open-source and support multiple platforms.
In fact, I used it to illustrate the scenario above, but it can do much more. For example, I talk about modelling SABSA architecture using ArchiMate in my other blog.
When building a house you would not consider starting the planning, and certainly not the build itself, without the guidance of an architect. Throughout this process you would use a number of experts such as plumbers, electricians and carpenters. If each individual expert was given a blank piece of paper to design and implement their aspect of the property with no collaboration with the other specialists and no architectural blueprint, then it’s likely the house would be difficult and costly to maintain, look unattractive and not be easy to live in. It’s highly probable that the installation of such aspects would not be in time with each other, therefore causing problems at a later stage when, for example, the plastering has been completed before the wiring is complete.
This analogy can be applied to security architecture, with many companies implementing different systems at different times with little consideration of how other experts will implement their ideas, often without realising they are doing it. This, like the house build, will impact on the overarching effectiveness of the security strategy and will in turn impact employees, clients and the success of the company.
For both of the above, an understanding of the baseline requirements, how these may change in the future and overall framework is essential for a successful project. Over time, building regulations and practices have evolved to help the house building process and we see the same in the security domain; with industry standards being developed and shared to help overcome some of these challenges.
The approach I use when helping clients with their security architecture is outlined below.
I begin by understanding the business, gathering requirements and analysing risks. Defining current and target states leads to assessing the gaps between them and developing the roadmap that aims to close these gaps.
I prefer to start the security architecture development cycle from the top by defining security strategy and outlining how lower levels of the architecture support it, linking them to business objectives. But this approach is adjusted based on the specific needs.
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.
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.
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:
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.
The next step would be to highlight or define relationships between attributes on each level:
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:
|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:
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.
From the Trust Modelling perspective, the relationship will look like this:
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:
Let’s overlay applicable attributes over process flows to understand requirements for security:
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.
With security attributes applied (the direction of orange arrows define the expectation of a particular attribute being met):
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.
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:
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.
I’ve recently passed my AWS Certified Solutions Architect – Associate exam. In this blog I would like to share some preparation tips that would help you ace it.
Not only practice makes perfect, some hands-on experience is also a prerequisite for the exam. So there is really no way around that! But what if you didn’t have a chance to use your skills on a real-world project yet? No problem! AWS gives you a opportunity to learn how their cloud components work through AWS Free Tier. For one year, you can use Amazon EC2 , Amazon S3, Amazon RDS, AWS IoT and many more free of charge,
You want more guidance? Qwiklabs developed a set of labs that specifically designed to help you prepare for this exam. For a small price, you can complete exercises without even requiring an AWS account or signing up for Free Tier.
I recommend studying AWS Whitepapers to broaden your technical understanding. If you are short on time, focus on these:
- Overview of Amazon Web Services
- Architecting for the Cloud: AWS Best Practices
- How AWS Pricing Works
- Compare AWS Support Plans
AWS developed a freecself-paced Cloud Practitioner Essential course, to help you develop an overall understanding of the AWS Cloud. You will learn basic cloud concepts and AWS services, security, architecture, pricing, and support.
There is also a YouTube channel with free introductory videos and other noteworthy material.
Exam sample questions can help you check your knowledge and highlight areas requiring more study.
Remember, the best preparation for the exam is practical experience: AWS recommend 1+ years of hands-on experience with their technologies.
When you’re ready, go ahead and schedule an exam here.
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: