Security architecture: Documentation to support the process

Does your current company have a security architecture? What are its key elements?

Architecture is defined as: 'The complex or carefully designed structure of something'. You typically associate this with buildings or physical structures. But today you're going to look at it in regard to cyber security. Architecture in this context is a framework that allows controls and objectives to be delivered in a clear and consistent way. The security architect’s role is to ensure there’s an enterprise approach to mitigating risk and enforcing security controls. The practice of designing computer systems to achieve security goals.

An information security architecture defines a set of security principles. These principles are then used to define the controls that need to be implemented. These should reflect the objectives of the information security policy. Think of the role of the security architect as the conductor, while the subject matter experts – for example, in firewalls, network devices and application security – are the groups of musicians in the orchestra. 

A typical approach to security architecture is to define the security domains so that common controls can be developed to protect each domain. Developing these types of controls involves implementing new policy. For example, a new policy could require all network devices to use a particular set of permitted protocols, or the requirement to separate traffic. This would be the network teams’ responsibility to execute this on the operational level, while overseen by the security architect.

Finally, the security architecture must be fully supportive of the security strategy as these are closely related and each of these feeds into the other, so it's important for them to work together closely. The roles of security strategist and security architect often sit within the same team or can even be the same person. 

Enterprise architecture frameworks

There are several Enterprise Architecture frameworks, here you’ll look at some of them. 

Five of the most popular architecture frameworks are:

• The TOGAF® Standard, a standard of The Open Group, is a proven Enterprise Architecture methodology and framework.
• DODAF and MODAF frameworks were created by government defence entities in the United States and the United Kingdom, respectively.
• The Zachman architectural framework was created by John Zachman of IBM in the 1980’s.
• Sherwood Applied Business Security Architecture, or SABSA is a framework and methodology for enterprise security architecture and service management. It was developed independently from the Zachman Framework but has a similar structure.

The TOGAF® Standard, a standard of The Open Group, is a popular and proven Enterprise Architecture methodology and framework. It begins with Architecture principles, vision and requirements, then moving into Business architecture, Information Systems Architecture, and Technical Architecture before the final phase which is Architecture realisation. You can see an example of TOGAF in Figure 1.

Figure 1: The TOGAF (The Open Group Architecture Framework) metamodel

TOGAF related frameworks

DODAF and MODAF frameworks were created by government defence entities in the United States and the United Kingdom, respectively. The purpose of DoDAF is to define concepts and models usable in DoD’s six core processes: Joint Capabilities Integration and Development (JCIDS), Planning, Programming, Budgeting, and Execution (PPBE), Defence Acquisition System (DAS), Systems Engineering (SE), Operational Planning (OPLAN) and Capability Portfolio Management (CPM).

In MODAF, the views are divided into seven categories: 

1. Strategic views (StVs) 
2. Operational views (OVs) 
3. Service oriented views (SOVs) 
4. Systems views (SVs) 
5. Acquisition views (AcVs) 
6. Technical views (TVs) 
7. All views (AVs) 

The content framework provides a structured model of building block types, relationships and attributes which can be used informally, or as the basis for configuration of an Enterprise Architecture modelling tool. TOGAF, DODAF/MODAF are strategic frameworks. Now you’re going to see some more examples of different frameworks, which are more detailed than the strategic type. They are tactical (Zachman) and operational (SABSA) rather than strategic (TOGAF).

Zachman framework

Figure 2 shows the Zachman framework.

It lists five key areas for consideration down the left.

Across the top, it lists the key questions that need to be asked when considering any one of these areas, and below each is an answer.

The Zachman Framework is based on the idea that the same complex thing can be described for different purposes in a different way with different types of descriptions. The main goal of Zachman framework is to enable different people to observe the same thing from various perspectives.

There are six viewpoints in the six rows of the Zachman Framework:

1. Row - The Scope (Contextual) – directed to the planner.
2. Row - The Business Model (Conceptual) – directed to the owner.
3. Row - The System view point (Logical) – directed to the designer.
4. Row - The Technology viewpoint (Physical) – directed to the builder.
5. Row - The Detailed Representations viewpoint (Out of Context) – directed to the subcontractor.

The six questions which they have to answer are:

The Data aspect – What?
The Motivation aspect – Why?
The Network aspect – Where?
The Time aspect – When?
The People aspect – Who?
The Function aspect – How?

Figure 2: The Zachman framework matrix 

Contrasting TOGAF and Zachmann

As a starting conclusion: Zachman is focused on identifying the different viewpoints that might be relevant for different purposes while TOGAF is focused on the process of developing architectures. The overlap between these two is that TOGAF produces viewpoints as part of the process. Basically, the Zachman framework is used for descriptive representations of any complex models, and it does not describe any particular EA method, technique or tool.

TOGAF is one of the enterprise architecture software tools which provide a far-reaching approach to the planning, design, implementation and management use of enterprise architecture.
TOGAF defines nine phases as part of the overall process framework to develop enterprise architecture. However only the 'first' five phases can be considered an overlap with Zachman. The last four phases (E – H) are more unique to TOGAF and deal with the development of enterprise architecture change management and enterprise architecture governance.

Both the TOGAF and Zachman Framework are bringing value to the ever-evolving enterprise architecture practice. Zachman provides a simple overview of the different architecture viewpoints and what questions they answer while TOGAF gives a detailed process approach on how to develop enterprise architecture (and produce the viewpoints). These frameworks allow architects to choose their perspective and provide better results and exactly that is their greatest benefit.

SABSA

As is clear from Figure 3, the SABSA model is very similar to the Zachman model but with the addition of a new area for consideration – Operational.

Again, the main questions in relation to these are listed along the top, with the means of achieving answers for each area of consideration detailed in the column below.

SABSA (Sherwood Applied Business Security Architecture) is a framework and methodology for enterprise security architecture and service management. It was developed independently from the Zachman Framework, but has a similar structure.

The SABSA model itself is generic and can be the starting point for any organisation, but by going through the process of analysis and decision-making implied by its structure, it becomes specific to the enterprise, and is finally highly customised to a unique business model. It becomes in reality the enterprise security architecture, and it’s central to the success of a strategic program of information security management within the organisation.

SABSA is a particular example of a methodology that can be used both for IT (information technology) and OT (operational technology) environments.

A useful example to refer to is found here.

Figure 3: The SABSA Matrix 

What do you think?

What do think about the Zachman and SABSA models? 

Does the extra 'Operational' column in SABSA make it more useful? Do you think there could be any other areas for consideration? What would those be? Would they be difficult to implement? Why? 

What's next?

Having looked at Enterprise frameworks and Architecture, you're now going to look at how this affects the staff and employees at an organisation.