This article briefly introduces the SABSA framework and its importance in the production of Security Architectures using Enterprise Architecture and TOGAF.

Figure 1 – The SABSA Framework

[Source: SABSA – (stylised version below by Steve Nimmons)]

The SABSA (Sherwood Applied Business Security Architecture) framework has evolved as a “best practice” method for delivering cohesive information security solutions to enterprises.

SABSA is a six-layer model covering all four parts of the IT lifecycle: Strategy, Design, Implementation and Management & Operations.

SABSA ensures the security needs of your enterprise are met completely and that security services are designed, delivered, and supported as an integral part of your IT Management infrastructure.

Figure 2 – The SABSA MATRIX

[source: SABSA]

Figure 3 (SABSA and the TOGAF ADM) is a useful way to compare the relationship between the two frameworks at a high level. The SABSA dimensions are principally used to guide creation of the Security Architecture and the production of security aspects of the dependent TOGAF views (Business Architecture, Information Systems Architecture and Technology Architecture).

Figure 3 – TOGAF ADM & SABSA

[Source: Steve Nimmons]

Figure 4 – High-level process for creation of Security Architecture

[Source: Steve Nimmons]

High Level Steps

• Ensure security requirements are considered at inception (including legislation such as Data Protection Act, PCI DSS etc.)
• Create a set of Enterprise Principles (across Business, Data, Application and Technology domains, with a specific focus on security principles and policies)
• Conduct a structured Risk Assessment to determine which assets require protection and the level of controls required
• Create RMADS documentation highlighting the actors, risks and countermeasures required to mitigate the risks
• Develop standard TOGAF views (Business Architecture, Data Architecture, Application Architecture and Technology Architecture), informed by the functional and non-functional requirements and Enterprise Principles. Each of these views will have security aspects
• Implement security architecture view(s) in TOGAF based on SABSA and relevant best practices (e.g. CESG GPG documentation). This set of architectural views focuses on the SABSA dimensions pictured in Figures 2 and 3 (above) and Table 1 (below)
• The Security Architecture should identify the principal Security Enforcing Functions in the architecture and cross-reference them with the countermeasures laid out in the RMADS

Table 1 – SABSA focus areas

Contextual and conceptual security is often rather glossed over, with Security Architecture ‘diving in’ at the Logical View. Application Architectures also need decent security and component architectures, in terms of understanding protocols in use, ports required, deployment options, component interactions, security contexts, resilience etc.

As with TOGAF implementation, the degree of ceremony and tailoring of SABSA should be pragmatic. Security should be proportionate, architectural modelling guided by SABSA should also be proportionate. Structured risk assessment provides the right focus. Cross-referencing between risk assessment, countermeasures in the RMADS (i.e. mitigation of risk) and the actual Security Enforcing Functions in the Security Architecture is important. Laid out well, this really helps with understanding how identified risks are dealt with in the architecture (and at which tier). This is a G-d send for penetration testing and accreditation.

Figure 1 – The Johari Window devised by Joseph Luft and Harry Ingham

The Johari Window is a model for describing personal awareness types and human interaction.

Quadrant A: encapsulates personal awareness and a wish to share information with others, for the purposes of simplicity assume this means publicly.

Quadrant B: encapsulates personal awareness of a different type. The motivations for concealment are plentiful (bad habits, competitive advantage, Machiavellianism, protection of personal interests etc.). The size of this box tends to diminish as trust relationships expand, however I contend: a) there are many types and levels of concealment implied here and b) many different levels of trust in different social circles.

Quadrant C: encapsulates weak personal awareness and misinterpretation (we assume others see us as we see ourselves, but this is not the case). This quadrant (in the context of Social Networking) provides an interesting opportunity for introspection and awareness development from social feedback, Social Network Analysis and sentiment analysis. This is a box full of brambles!

Quadrant D: Donald Rumsfeld’s infamous Known Knowns speech of 2002 sums up this quadrant.

A Prophetic View

Just under two years ago I wrote a somewhat prophetic article concerning Privacy and Social Networks in which I argued for the need for additional privacy controls and multiple walled gardens within social networks. Facebook lists were a crude approximation, but Goolge+ Circles now excel at delivering the concept. A sister post in February 2010 discussed Social Search and the Integrity of the Social Graph, concluding that Google was heading (with purpose) into the Social Networking space.

What I said back in January 2010:

Visualisation of Social Network privacy controls is poor. The granularity of access controls is too coarse. My solution would be creation of (either my privacy “Onion model”) or perhaps more simply a ‘radar’ or quadrant model on which connections could be placed within ‘trust zones’ (by dragging and dropping them onto the appropriate region). Configuration is half the battle, and visualisation of the resultant privacy controls effect is essential. This is where current controls are weakest. I also want multiple walled gardens to play with (where I could segregate user groups) and ensure no (uncontrolled) information leakage between…

A trust and privacy ‘radar’ would be equally interesting, with those closest to the centre having the greater trust relationship and access to more personal data.

The Johari Window and Google+ Circles

Figure 2 – The Google+ Circle Model

I have a number of Circles within Google+: Friends, Family, Acquaintances, Scientific Community, Social Media, Politics, Techies etc. There is also a ‘Public category’ which maps neatly onto Quadrant A of the Johari Window.

Quadrant B maps neatly to the different circles (Friends, Family etc.). This creates controlled separation, where I can isolate various topic discussions. This helps prevent Family members from being bored by discussions about Social Network Analysis or Social Psychology! Equally it saves Scientific Community colleagues reading my latest views on the European Union. There is a great deal more depth to this than simple ‘separation of interests.’ Despite what we may think, as multi-dimensional beings, we do not necessarily want everyone in cyberspace or our social sphere having a complete 360 degree view of our personality, interests or social connections.

Quadrant C could make for a ‘fun’ social network game – tell me something about myself that I don’t know, but you do know. Play at your own risk!

Quadrant D is ripe for Reality Mining as long as there is a digital footprint.

The Johari Window provides an interesting thinking framework on which to base an approach to online privacy protection and information sharing across social groups.

Extending the Johari Window for Privacy and Reputation Protection

I propose an extension to the Johari Window (as depicted in Figure 3). As information flows into a Circle we lose control of it. We must assume that we have chosen Circle members well and that each member will understand (and abide) by our privacy wishes in respect of that information. The obvious drawback however is that there is no adequate meta-data associated with the shared information to indicate to Circle members what is ‘allowable’. Perhaps Google will introduce ‘Circle Contracts’ to stipulate between parties what is acceptable!

Adding an A+ box (Figure 3) recognises that there will be information which I am happy to be disclosed by people acting as relays between Circles with no restrictions.

Box B+ recognises information disclosed to certain Circles must stay within that Circle or may be selectively disclosed to other Circles (not under my ownership) which meet certain membership/privacy criteria. There is currently however no way to express this (or manage disclosure across ‘logically chained Walled Gardens’).

Box C+ recognises that there is information about myself of which I am unaware, and would be happy about being disclosed. If it is information which may be publicly disclosed, it fits within box A. If it requires restriction per ‘Walled Garden’ or Circle, it fits within box B.

Box C++ recognises that there is information about myself of which am I unaware, and would be unhappy about being disclosed. This box is ripe for Reputation Protection.

Boxes C+ and C++ are interesting as I would be theoretically unaware of my privacy requirements until the information is disclosed (of course heuristics could be employed).

Boxes B, B+, C, C+ and C++ all have potential for information leakage. As Circles and Networks are highly interconnected, chances are the information could reach parties which you would rather not see it.

Extending the Johari Window and applying this thinking technique to online privacy within Social Networks is useful in terms of surfacing complexity and also challenging personal views of requirements for information management.

Figure 3 – Extending the Johari Window

[source: Steve Nimmons]