I’ve undoubtedly said this many times, so but I thought I would express this again so that anyone can understand. Lets put this simply. I wont put much detail in this post. There are lots of approaches we can take do applying security architecture design but that’s not really the subject here. I am not saying modelling is the only approach to take, there are other approaches that have pros and cons. I am saying a good architecture model can make life much easier.

The real basics of architecture…

Architecture is essentially about building architecture building blocks. Different elements of architecture are connected to each other. one block can contain other blocks, but essentially it boils down to elements being connected to each other by relationships. ISO42010 actually has a diagram in it that looks a little like the one above.

There are many different types of elements in architecture and they can be modelled in PowerPoint just as I have done above, but drawing boxes in PowerPoint is just as bad as just writing about this stuff in a Word Document – its very nice and pretty, but you cannot easily understand the bigger picture when you have diagrams buried in different documents, and changing an element in one document does not automatically change it in another. For that we need something better – an architecture model. Then we can save thousands of hours and autogenerate architecture, as our model begins to fill. But to do that, we need to all understand in a common way what all these types of elements mean.

You can see above some standard elements and standard relationships in ArchiMate – An industry standard recognised language with a very specific definition & syntax. Professionals across the world can read the notation above and it means something – An actor (Bob) is assigned to a process (Documenting) – its being served by an application Component (SharePoint), and there’s a device that’s really important to making that happen.(Yes, I could have made SharePoint System software)

How does security fit in?

There are a couple of common issues, starting with the fact we often don’t have a fully relational model, like I showed above. Having the model enables you to do security by design in a far simpler way which is more comprehensive.

The second problem you can see above. I’ve seen many architects focus primarily in designing in the application and technology layers. They forget about things like the business layer, people, and process. Anyone who has ever spent any time working with security can tell you that issues can happen with the people, with the process, just as easily as with the technology or application layers, so we need to model them to understand how they connect together. A system is not only elements SharePoint & Hyper-V – Elements Bob and Documenting are just as important. We can also represent motivation, strategy, including things like requirements and goals as elements, but I didn’t here to keep things simple. Take a look at this:

I put in some basic examples of some vulnerabilities in our system above (in red) – I don’t need much detail to start to see issues, and when we see them we can manage them. All I did was look at the elements and their relationship and started to think about what would happen if the other elements either failed or were delayed.

If architects had not documented elements, Its very possible I could miss vulnerabilities and risks. These elements would be related to other elements in the bigger design of an organization. A single security architect cannot secure a whole system unless architects have been working to document that system in a way that is standard and reusable.

We are working hard to fix the vulnerabilities

When there is a security incident all eyes are on a security team to fix things. In organizations with weak architecture this means pulling in a team of people from all over the place to work through the problems. This often makes leadership happy, but is a temporary fix. Architects are normally responsible for maintaining an architecture and changes to it. If we do not have architects working with a common model and maintaining architecture change control, a few things may happen:

  • We do not fix the underlaying cause. For example, The actor Bob, does not understand the process of Documenting and makes a mistake. The band-aid fix is to tell him he is wrong and move on. but what happens if Bob changes after 6 months due to a reorganization? If we have not established a proper control, the next person may make the same mistake & the issue reoccurs.
  • We do not design think in terms of control. Fixing a problem is one thing but we need to make sure those problems don’t happen again. we need to think how do we want to measure the control we have, how will we track that measurement, and what we want to happen if a similar thing occurs. If we don’t do all these things, then issues can reoccur. In the example above even if we train Bob, Changing Bob for Edwina would undo the work if we didn’t think it through. Its possible if Bob doesn’t use the process so often he could even forget, these are all scenarios we would want to consider in a design, the energy we put into it needs to be proportionate to the risk.
  • We don’t document things properly. This comes back to bite us later on. we can end up spending hundreds or even thousands of man hours trying to figure out why we did something, or trying to work out how the systems are now. Its very hard for leadership to make informed decisions on things when we cannot see the full impact. Many times i have been in meetings that have gone on several hours with 5-10 people just becuase we cannot trust documentation.
  • We do not understand the impact of our decisions. If we do not fully understand the connections between elements something can get missed. For example – we should be mapping motivation to our model. Imagine an incident has happened – Hyper-V was accidently shut down because Bob dropped his coffee on it, and a new server needed to be built. its conceivable that the team dealing with the incident may think we can solve this by placing the application on Windows Azure. It would stop the problem. But what if the reason that the server was under bobs desk in the first place was because Suzy, Bobs predecessor knew there was a legal compliance reason for keeping the files in country? If it was covered in design the team thinking of changing Hyper-V would see this, and change plans accordingly. This is much better than an auditor or customer discovering the documentation in the wrong country, and penalties and reputation damage being incurred.

But we are compliant to ISO27k, so we are on top of this….

I very commonly see people thinking that because they have compliance they have control of vulnerability. This is often not so. Ever wonder why an organization with ISO27k, CSA star certification, or other certifications can still have a significant number of security incidents?

Its often because of a failure in applying the requirements or controls to the architecture that the organization has. Its because the elements and relationships are not fully defined or are missing, so the people applying the standards do not apply them everywhere they are needed, and there’s no easy way to see that, because the architecture is sometimes distributed in many documents, which are not all updated or connected.

Any good security consultant can tell you the basics of what you may need in an organization, but it really needs a good architect to apply that level of control. Its also important to note that you do not only need to apply controls specific to standards, but also controls specific to your business.

Summing it up

To effectively secure an architecture design, we need to be applying our security principles in every stage of the design, and need to be analysing the design as it happens. This requires security architecture skills, but it also requires that the other architects pull their weight and effectively design the systems using industry standards, so that onboarding new resources can happen easily.

As well as the vulnerabilities we see above, a good architect would be seeing more vulnerabilities when applying architecture and security architecture principles to the motivation layer design as well. Its a topic for another day, but when you design a system the requirements you need to design against are not only coming from the customer – we get them from analysing and working with standards and different stakeholders. I hope this blog helps someone, somewhere describe to their leadership why a security architect cannot fix the world alone.

Threats come in from every direction and do not respect organization boundaries or stay within the technology layers, which is why its more important than ever in the cloud enabled world that we are on top of architecture design. There is always an architecture, its really about how much control we have over it. To have the best control over risk and security we need to understand how everything interacts, and a relatively easy way of doing that is to work with a common architecture model.