CHAPTER 6: INTRODUCTION TO SECURITY ARCHITECTURE
Chapter 6 introduces the concepts of security architecture, drawing on well-established enterprise architecture methodologies to derive logical services that deliver consistent levels of security regardless of the technologies used to implement those services. One of the main advantages of adopting this approach is the complete traceability from business requirement to technical component. This allows the business to understand how their risks are managed and the consequences of any move to Cloud-based services.
What is security architecture?
The international software architecture standard ISO/IEC 4201071 defines architecture as:
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
Architecture can, therefore, be thought of as an abstract view of a system (including organisations and enterprises) in terms of its component parts and how these parts interact with themselves and the outside world.
By slightly adapting the ISO/IEC 42010 words we can think of security architecture as:
The fundamental security organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
In essence, security architecture should provide a holistic view of the security controls relevant to the enterprise or solution. Furthermore, the architecture should demonstrate how these controls are adequate to meet the underlying requirements and identified risks. Conversely, the security architecture should also be able to demonstrate:
•Where requirements or risks are not being adequately managed; and
•Where controls may have been implemented but do not demonstrably meet a documented requirement or manage an identified risk.
Finally, a fully formed security architecture should be able to identify the physical security components in place in an organisation, thereby identifying duplicate security services and driving the consolidation of such services, as well as reducing ongoing expenditure. The goal of the security architecture should be to enable, and not hamper, the needs of the business.
Figure 4: Security architecture process
Figure 4 shows how a security architecture process can be implemented. This process is applicable at either individual solution or enterprise levels. For the solution architecture, I would expect any existing enterprise architecture (including security aspects) to form a further element of the ‘context’ layer at the top of the figure. This element is dotted within the diagram to reflect the fact that an enterprise security architecture may not be present, particularly if deriving such a beast is the aim of the exercise.
The importance of the context layer cannot be overstated. A security architecture must reflect the organisation in terms of supporting its goals, structures, activities and acknowledging the risk appetite of the business. A security architecture that attempts to enforce an overly risk averse approach on a fairly relaxed business will fail. A security architecture that ignores existing governance structures and which is derived in an ivory tower will fail. A security architecture that blocks all attempts by the business to meet their stated goals will fail, spectacularly. A security architecture must demonstrate how it fits within an organisation and help the business to meet its needs to stand a chance of success.
This is not to say that a security architecture cannot attempt to improve upon existing governance structures or seek to educate key stakeholders with a view to altering risk appetites. However, to do so it must include suitable mechanisms for managing such change rather than simply wishing that the context were different. We will explore different security governance approaches and their applicability in the agile and Cloud environments later in this book (chapter 8); failures in governance underlaid a number of the failed enterprise-wide Cloud adoptions that I have encountered over the years.
Once the security architect is fully versed in the context, the next stage is to ensure that there is an agreed set of business requirements that the organisation is looking to fulfil via the system under consideration. These requirements should also include the key non-functional requirements around service levels (e.g. availability) and hosting. Similarly, the architect should ensure that a risk assessment of the service has been conducted. Both the requirements and the risk assessment must be informed by the context and, crucially, the set of requirements and identified risks must be agreed by the business. This agreement is critical to achieving successful adoption of the security architecture. Business agreement of the capabilities the security architecture must provide and of the risks that it must mitigate helps to smooth adoption of the security architecture by design teams and, in due course, by the end user population.
Once a set of requirements and risks has been agreed, it is then time for the security architect to use their skills and experience to derive a set of architectural services capable of meeting the needs of the organisation.
The process described in Figure 4 could be viewed as being somewhat old-fashioned and tethered to a ‘Waterfall model’ of project delivery. This is certainly not the case; for example, Figure 5 illustrates a number of options for using the various steps described to support more iterative and agile ways of working.
Figure 5: Security architecture process – Agile
Different organisations will choose different styles of iteration; indeed, an individual global enterprise may choose a number of different styles of iteration across different parts of their business. The global analyst firm Gartner has suggested a bimodal72 approach towards the organisation and delivery of enterprise IT, with Mode 1 relating to areas that are more predictable and well-understood and more straightforward to transform. Mode 2 is intended to service the need for more exploratory and experimental activities targeting delivery in areas of uncertainty. The bimodal approach has achieved some traction within enterprise environments. Enterprises considering the bimodal approach may also wish to be aware of the Pioneers, Settlers and Town Planners (PST) model73 suggested by Simon Wardley; this seeks to address the potential ‘missing middle’ between the two extremes of the bimodal approach whilst trying to avoid the stigma that can arise when working in a Mode 1 environment. Whether adopting bimodal, PST or other flexible organisational structures, it is vital that the security architecture approach is adapted to meet the need(s) of the organisation.
Let us look more closely at the four different iteration options shown in Figure 5. In Option 1, the entire solution is being delivered via an iterative approach. This is the option to use for a true ‘scrum-based’ approach to solution delivery; in this case, product owners are embedded within the delivery team to provide the context information that the rest of the team requires. When dealing with enterprise security architecture, organisations may wish to consider the more discrete iterations labelled 2, 3 and 4. This would allow the enterprise to continually keep their ‘conceptual architecture’ up to date via Iteration 2, but it would also decouple the delivery of both the ‘logical’ (iteration 3) and ‘physical’ (iteration 4) elements of the architecture. The decoupling of the logical and physical elements is particularly relevant in a Cloud-based agile environment – DevSecOps teams may choose to update the physical components delivering security capability on a regular basis (iteration 4) so long as they maintain alignment with the wider enterprise security architecture.
What is a service?
What do I mean by the term ‘architectural service’?
I will be adopting some of the thinking associated with service-oriented architecture (SOA) to drive the security architecture processes used in this book. In line with the wider SOA approach, I use ‘architectural service’ to describe a self-contained set of discrete and repeatable functionality. These chunks of functionality can then be coordinated (or orchestrated in the SOA terminology) to deliver flexible capabilities. To put this into a security context, you could consider a security monitoring capability being provided through an orchestrated set of services including logging, analysis, reporting and event management services.
Now, unfortunately, I cannot pretend to have invented the idea of security architecture, solution architecture or enterprise architecture. Example enterprise architecture frameworks include the Zachman Framework74 and The Open Group Architecture Framework (TOGAF)75 amongst others. In the security space we have the well-respected Sherwood Applied Business Security Architecture (SABSA)76. The Open Group and the SABSA Institute have worked together to document how the security aspects of the TOGAF methodology can be bolstered through adoption of SABSA. The methodology I use in this book does not draw directly on any of the processes defined within the aforementioned publications; rather it draws upon their shared underlying philosophies such as their aim of increasing the alignment of technical IT delivery with the needs of the business stakeholders. Don't worry if you either don't agree with the SOA philosophy or do not have great experience with any of the aforementioned approaches – you will still find some value in the contents of this book.
Architectural layers
I have adopted the layers of abstraction defined within Capgemini's Integrated Architecture Framework (IAF)77 for use within this book. I have already stressed the importance of agreeing the wider organisational and regulatory context of the architecture work; this effort is represented within the contextual layer sitting at the top of the architectural layers shown in Figure 6.
Figure 6: IAF layers
A particular strength of the IAF approach is its ability to use the conceptual, logical and physical layers (as shown in Figure 6) to represent an easily understood route from defined business requirement through to defined technical solution.
Conceptual – the what
The conceptual layer of an architecture defines what services are necessary to deliver the outcomes expressed within business strategies, drivers, goals. These services must also be defined in line with agreed architecture principles and other elements described by the context. In the case of a conceptual security architecture, I usually define a set of security services that can be traced back to agreed business requirements and which aim to mitigate the risks identified by an agreed risk assessment. As an example of a conceptual security service, let us describe a requirement to limit access to resources to those with authorisation. In order to prevent unauthorised access to resources, there must be some kind of a filter in place. At the conceptual layer then, we can define a filter service that only allows authorised access to resources. Note that we have not defined what the protected resources are (e.g. networks, operating systems, applications, specific information objects, etc.) or how the filter service should work; we have only defined what the filter service must do.
Logical – the how
The logical layer describes how to deliver the conceptual services needed through the derivation of a set of independent logical services and the interactions (contracts) between these services. These logical services remain product-agnostic and simply define how the overall architecture should work to meet the needs of the business.
In the case of a logical security architecture, I map these logical security services on to the conceptual services so as to ensure that traceability is maintained. Revisiting the example of the conceptual filter service, we must now consider how a filter service could work. For this derivation, we'd need to know the resources to be protected and the threats to guard against. At a high level let's assume that we'd need a logical network filter (to protect against network attacks), a logical operating system filter (to protect against unauthorised use of OS commands) and a logical database filter (to protect against unauthorised access to data). It's clear at this point that we also need a whole set of identity management and authorisation services to provide the filter service with the necessary information as to the access rights of users to services and data, but I'll keep our example simple for now! Note that these logical security services remain product-neutral – we know how these services should work and the protection that they should provide, but we have not defined the products used to implement them.
Physical – the with what
The physical layer is the layer at which we concern ourselves with the products, processes and application components needed to implement our security services. The logical layer provides us with a set of functional requirements, non-functional requirements, service levels and interface requirements; the physical layer defines physical components able to meet those requirements. In the Cloud world, ‘physical’ can also mean virtualised appliances; it does not necessarily mean physical hardware, just the actual instantiation of a logical security control.
For example, if our logical layer includes a network filter that must be able to deliver enterprise-class performance, we could consider delivering that logical service using a Fortinet Fortigate 6300F firewall.
These physical components can then be mapped on to the logical services, which are mapped to the conceptual services which are, in turn, mapped on to the underlying business requirements and risks. This approach enables architects to provide complete traceability from the business requirements through to the physical component.
The other main point to note is that it is only at the physical layer that we concern ourselves with actual specific technologies. So, from a Cloud perspective, the conceptual security architecture should be the same regardless of whether the business service is being implemented on-premises or on-Cloud – the goals and aims for the service are independent of the method of IT delivery. The logical layer will also often be independent of physical delivery, subject to consideration of the technical feasibility of delivery! What this means is that the Cloud security architect can then concentrate on finding suitable technical means to deliver the necessary security services (to the levels defined at the logical layer) using appropriate Cloud-relevant components.
Advantages of security architecture
What advantages are offered by following a security architecture approach like the one outlined in this chapter?
Improved traceability from business requirements to security solutions
The security services within an enterprise security architecture are derived from a set of agreed business requirements and the output from an agreed risk analysis. This enables complete traceability between the business requirements (and/or risks) and the security services. Traceability can then be continued through to the physical security product (or process) that implements the architectural security service. This provides an organisation with complete traceability end-to-end from the initial business requirements to the implemented solution. Such traceability is extremely valuable for managing change and for the purposes of internal, and external, audit.
Improved sponsorship and governance
Sponsorship from senior business stakeholders is essential to the success of any piece of architecture work, including enterprise security architecture. Such sponsorship encourages participation from the wider organisation and helps to enforce implementation. Sufficient executive sponsorship and ownership of Cloud strategy is essential for the success of an enterprise Cloud adoption. A failure to have adequate ownership and the associated governance increases the risk of an uncontrolled and/or inconsistent adoption of Cloud services, including the risk of Shadow IT. I am aware of one global organisation in which the failure to adequately assign the ownership and governance of Cloud strategy led to a significant problem with Shadow IT: at one point they discovered that over 6000 SaaS applications were in active use instead of the around 400 applications that they believed were authorised and catalogued in their asset management system. As discussed earlier, organisations can adopt a variety of different approaches towards IT delivery (e.g. bimodal), including the delegation and distribution of control to business units. However, the key to success is to make sure that the delegation and distribution of control are performed in an informed manner, with the threat of a suitably empowered executive ready to intervene should such controls not be adopted in line with expectations. Even where control is delegated, an enterprise may wish to set a few fundamental principles to guide behaviours. For example, enterprises may wish to use principles like a SaaS-First approach; to ensure, as a principle, that all tooling be API-enabled; to prefer Cloud provider native tooling to third party tooling; or to adopt the principle that agility and capability should be preferred to portability. These principles are merely examples, and organisations should define principles suitable for their own needs; the aim of these suggestions is to provide a set of common guardrails rather than a list of definitive solutions.
Improved project success rate
Reuse of security architecture patterns reduces the amount of design work required per project and acts as an accelerator reducing the overall cost of development. In addition, if an organisation reuses existing physical components then there is less risk of unexpected problems with unfamiliar technologies delaying project implementation. The development of a set of pre-approved infrastructure templates and CI/CD pipeline tooling for reuse allows security teams to focus on and address project-specific concerns.
Reduced risk of breaches of compliance requirements
An enterprise security architecture should incorporate the compliance requirements (legal, regulatory and internal) within the context. This enables the organisation to derive a holistic approach to information security. As the compliance requirements are embedded within the architecture, they flow through into individual solution delivery (Cloud or on-premises) alongside the other business requirements.
Ensures security is embedded at the earliest stage of development
A common problem with project delivery is the late incorporation of security requirements into the project development lifecycle and the lack of integration of security architecture with delivery processes of other architecture domains such as application, information and technology. This can often lead to expensive design changes and the shoe-horning of inappropriate security products into the solution. Through enterprise security architecture, attendant governance processes and the adoption of DevSecOps approaches, the organisation can ensure that security requirements are considered early in the design lifecycle alongside any potential reuse of existing security services.
Reduced operational expenditure by consolidation of services
The building of shared security services reduces the complexity and diversity of the technical security products implemented by the organisation. Why manage five different firewall products when two or three would provide the diversity and security required? Why sustain three different identity directories and four different authentication mechanisms? Enterprise security architecture enables the identification of ‘champion’ products, or at least reusable services, and elimination of the ones that provide little or no value to the organisation, reducing the overall cost of management of the security service. The identification and monitoring of relevant metrics can help to demonstrate the improved cost-effectiveness.
Increased agility of the business to react to new or increased threats as a result of new business strategies or requirements
A fully traceable enterprise security architecture provides organisations with excellent situational awareness including a comprehensive understanding of the true threats, vulnerabilities and risks to which they are exposed and the controls that have been implemented to manage those risks. This understanding enables businesses to consider new approaches to IT delivery (or delivery of new IT services) in full knowledge of the real risks, impact and cost that they currently face. The enterprise security approach enables lingering fears relating to the security of Cloud services to be countered through a reasoned, business-focused approach to risk management.
This chapter has introduced some fundamental concepts regarding security architecture. The next chapter takes these concepts and begins to apply them to the security of Cloud computing.
71 www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50508.
72 www.gartner.com/it-glossary/bimodal/.
73 https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html.
74 www.zachman.com/about-the-zachman-framework.
77 https://agilearchitect.azurewebsites.net/useful_material/iaf/.