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!
I’m proud to be one of the contributors to the newly published Cyber Security: Law and Guidance book.
Although the primary focus of this book is on the cyber security laws and data protection, no discussion is complete without mentioning who all these measures aim to protect: the people.
I draw on my research and practical experience to present a case for the new approach to cyber security and data protection placing people in its core.
Check it out!
To support my firm’s corporate and social responsibility efforts, I volunteered to help NSPCC, a charity working in child protection, understand the Internet of Toys and its security and privacy implications.
I hope the efforts in this area will result in better policymaking and raise awareness among children and parents about the risks and threats posed by connected devices.
Toys are different from other connected devices not only because how they are normally used, but also who uses them.
For example, children may tell secrets to their toys, sharing particularly sensitive information with them. This, combined with often insufficient security considerations by the manufacturers, may be a cause for concern.
Apart from helping NSPCC in creating campaign materials and educating the staff on the threat landscape, we were able to suggest a high-level framework to assess the security of a connected toy, consisting of parental control, privacy and technology security considerations.
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.
Why your staff ignore security policies and what to do about it.
Dale Carnegie’s 1936 bestselling self-help book How To Win Friends And Influence People is one of those titles that sits unloved and unread on most people’s bookshelves. But dust off its cover and crack open its spine, and you’ll find lessons and anecdotes that are relevant to the challenges associated with shaping people’s behaviour when it comes to cyber security.
In one chapter, Carnegie tells the story of George B. Johnson, from Oklahoma, who worked for a local engineering company. Johnson’s role required him to ensure that other employees abide by the organisation’s health and safety policies. Among other things, he was responsible for making sure other employees wore their hard hats when working on the factory floor.
His strategy was as follows: if he spotted someone not following the company’s policy, he would approach them, admonish them, quote the regulation at them, and insist on compliance. And it worked — albeit briefly. The employee would put on their hard hat, and as soon as Johnson left the room, they would just as quickly remove it. So he tried something different: empathy. Rather than addressing them from a position of authority, Johnson spoke to his colleagues almost as though he was their friend, and expressed a genuine interest in their comfort. He wanted to know if the hats were uncomfortable to wear, and that’s why they didn’t wear them when on the job.
Instead of simply reciting the rules as chapter-and-verse, he merely mentioned it was in the best interest of the employee to wear their helmets, because they were designed to prevent workplace injuries.
This shift in approach bore fruit, and workers felt more inclined to comply with the rules. Moreover, Johnson observed that employees were less resentful of management.
The parallels between cyber security and George B. Johnson’s battle to ensure health-and-safety compliance are immediately obvious. Our jobs require us to adequately address the security risks that threaten the organisations we work for. To be successful at this, it’s important to ensure that everyone appreciates the value of security — not just engineers, developers, security specialists, and other related roles.
This isn’t easy. On one hand, failing to implement security controls can result in an organisation facing significant losses. However, badly-implemented security mechanisms can be worse: either by obstructing employee productivity or by fostering a culture where security is resented.
To ensure widespread adoption of secure behaviour, security policy and control implementations not only have to accommodate the needs of those that use them, but they also must be economically attractive to the organisation. To realise this, there are three factors we need to consider: motivation, design, and culture.
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.
This is one of these blog posts with no content. I just really wanted to share some pics from one of the coolest cities I had a privilege to live and work in for the past few months.