CHAPTER 7: APPLICATION OF SECURITY ARCHITECTURE TO CLOUD COMPUTING

Chapter 6 introduced some fundamental concepts of security architecture. In this chapter we begin to apply some of these concepts to the area of Cloud computing. The use of a security architecture methodology allows organisations to approach Cloud-based deliveries with the confidence that their security concerns have been identified and appropriately managed. Rather than acting as a blocker, we can use security as a mechanism for enabling organisations to take advantage of the undoubted benefits of Cloud computing.

Security Reference Model

I shall use a Security Reference Model that I have used elsewhere to act as a framework for the discussion of approaches to securing Cloud services. This Security Reference Model (SRM) is shown in Figure 7.

image

Figure 7: Security Reference Model (SRM)

Using the terminology defined in chapter 6, the SRM shown in Figure 7 is a collection of conceptual security services. This SRM is based on a framework I derived for a real system, but has been extended and modified many times over the years to provide a more comprehensive, generic set of services. Now, there are other existing reference architectures with regard to Cloud computing, notably those provided by NIST78 and by the Cloud Security Alliance (CSA)79. As worthwhile and well-written as these existing models are, they are not sufficiently granular for the purposes of this book. In addition to the architecture provided in their guidance document, the CSA have also issued their Trusted Cloud Initiative architecture80 which is more granular in nature. However, from a personal perspective I believe that it has jumped straight to the logical level and so loses some of the flexibility provided by working at the conceptual level, and makes tracing back to underlying business requirements more problematic.

The original iteration of the security services within the SRM were derived from the examination of a set of organisational, legislative, regulatory and other requirements together with the output from a business-focussed risk assessment and guidance from a set of agreed security principles. The requirements were grouped together using areas of commonality (e.g. requirements relating to audit) to form a series of conceptual services. The output of the risk assessment exercise was used to validate the set of conceptual services, i.e. did the set of services provide an appropriate set of security barriers to mitigate the identified risks? Alterations were made to the services where they were not thought to be sufficient to mitigate the identified risks. This led to a set of conceptual services that the relevant business stakeholders were able to accept as being sufficient to meet both their business requirements and their non-functional requirements arising from the risk assessment. Significantly, this original set of services did not include all aspects of application security within its scope; as a result, the SRM has been through a number of iterations to make it more generic and to keep up with developments in the field, such as the move towards DevSecOps. The SRM now acts as a useful tool for sanity checking that the most common aspects of information assurance have been catered for in any particular design. It must be noted that not all services will be relevant to all applications – the purpose of the SRM is to help its users ensure that there is adequate coverage of those areas that are within scope.

For the rest of this book we will be using the SRM to examine potential technical and/or procedural mechanisms for delivering the conceptual services it defines in the context of an application to be delivered using Cloud services.

Security service descriptions

Figure 7 provides a useful representation of a set of conceptual security services, although the SRM would undoubtedly be more useful if there was a description of what each of the security services is there to provide. These descriptions are provided within Table 1.

Table 1: Service Descriptions

Service Name Level Service Description
Secure Development 0 Responsible for delivery of a secure codebase for the Cloud-based application.
Coding Standards 1 Responsible for providing developers with the guidance needed to produce secure code.
Code Review 1 Responsible for peer or automated review of the code produced by developers against the coding standards.
Repository 1 Responsible for secure storage of code.
Automate 1 Responsible for automation of development activities.
Build 1 Responsible for build of code.
Secrets Management 1 Responsible for secure creation, storage and retrieval of application secrets.
Mitigate 1 Responsible for addressing issues raised during testing activity.
Test 1 Responsible for active code testing of modules before incorporation into the main branch.
Integrity 0 Responsible for ensuring that the application runs with integrity.
Non-Repudiation 1 Responsible for ensuring that actions can be attributed to those performing the action (system, process or individual).
Content Check 1 Responsible for ensuring that the information being processed, stored or transmitted does not contain malicious content.
Snapshot 1 Responsible for providing snapshots of known good configurations (function, operating system, application, etc.).
Hosting 0 Responsible for ensuring that the physical infrastructure and operating, processing and hosting of the Cloud application are secure.
Physical Security 1 Responsible for ensuring that the physical infrastructure is in a physically secure environment.
Environmental Security 1 Responsible for ensuring that the physical infrastructure is in a physical environment suitable for IT equipment.
Storage 1 Responsible for providing data storage facilities.
Communications 1 Responsible for providing voice and data communications facilities.
Compliance 0 Responsible for ensuring that the Cloud application meets the legislative, regulatory and internal policy requirements.
Audit 1 Responsible for assurance that the application is designed, built, operated and decommissioned in line with organisational standards.
Test (C) 1 Responsible for delivering security testing requirements to ensure that the application does not contain known or easily discoverable vulnerabilities.
Regime 1 Responsible for defining the compliance regime that the application must deliver against.
Identify 2 Responsible for identifying the legislative, regulatory and internal policy requirements.
Translate 2 Responsible for translating the compliance requirements into the context of the application.
Availability 0 Responsible for ensuring that the application is available when required.
Business Continuity (BC) 1 Responsible for ensuring that the business functions provided by the application can continue in the event of the application itself not being available.
BC Planning 2 Responsible for designing the mechanisms needed to provide adequate levels of necessary business services in the event of a BC invocation.
BC Implement 2 Responsible for delivery of the requirements of the BC plan.
BC Test 2 Responsible for testing that the BC plan is effective.
Disaster Recovery (DR) 1 Responsible for ensuring that IT services can be brought back online within a reasonable timescale after a disaster.
DR Planning 2 Responsible for designing the mechanisms needed to bring back agreed levels of IT service (RPO) within an agreed time frame (RTO).
DR Implement 2 Responsible for delivery of the requirements of the DR plan.
DR Test 2 Responsible for testing that the DR plan is effective.
Resilience 1 Responsible for ensuring that the service is available as expected.
Copy 2 Responsible for replication of data (including infrastructure as code) across zones, sites or geographies.
Reliability and Chaos 2 Responsible for active testing of resilience through controlled ‘failure’ of components.
Evergreen 2 Responsible for ensuring currency of environment.
Content Distribution 2 Responsible for ensuring content is made available from a variety of locations.
DoS Prevention 2 Responsible for protection of a service from (distributed) denial of service attacks.
Cryptography 0 Responsible for delivery of any cryptographic services needed to operate or manage the application.
Encryption 1 Responsible for delivery of encryption services.
Key Management 1 Responsible for ensuring that encryption keys are appropriately managed.
Access Management 0 Responsible for ensuring that only authorised access to data and resources is permitted.
Identity Management 1 Responsible for ensuring that identities are managed securely.
Registration 2 Responsible for ensuring that identities are only created upon appropriate presentation of valid authorised credentials.
Provisioning 2 Responsible for creation and status amendment of identities and associated credentials.
Privilege Management 2 Responsible for ensuring that identities can be assigned the privileges necessary for their function.
Directory 2 Responsible for storing identity and privilege information.
Validate 1 Responsible for checking that access requests are valid.
Authenticate 2 Responsible for checking that the presented credentials match those associated with the claimed identity.
Authorise 2 Responsible for checking whether the authenticated identity is authorised to perform the requested action.
Federate 1 Responsible for trust infrastructures between federated identity partners.
Policy (AM) 1 Responsible for providing the policy information required for the other identity management services to operate.
Filter 1 Responsible for enforcing the access control decisions provided by the validate services.
Security Governance 0 Responsible for providing an appropriate governance framework and associated standards.
Security Management 1 Responsible for providing appropriate security management capabilities.
Assurance 2 Responsible for ensuring that services are designed in line with organisational security standards.
Architecture and Design 3 Responsible for providing architecture and design security assurance.
Procedures 3 Responsible for providing security assurance of operating procedures.
Policy (SM) 2 Responsible for production of organisational security policies.
Policy Research 3 Responsible for incorporation of latest compliance, technology and business developments into policy.
Policy Design 3 Responsible for production of organisational security policies.
Disseminate 2 Responsible for dissemination of organisational security policies.
Enforce 2 Responsible for providing the organisational functions to enforce the provisions of the security policies.
Risk Management 1 Responsible for ensuring services are designed, built, operated and decommissioned in line with the relevant risk appetite.
Threat Model 2 Identifies the threat sources and threat actors relevant to the service.
Classify 2 Ensures that information assets are classified according to organisational policies.
Inform 2 Responsible for involving all relevant stakeholders in risk management.
Assess 2 Responsible for assessment of the risks associated with the service in scope.
Treat 2 Responsible for development of the approaches to manage each identified risk.
Accredit 2 Responsible for judging whether a system can be accredited for operation.
Personnel Security 1 Responsible for managing the risk that staff may present to the security of the service or data.
Vetting 2 Responsible for validating the identity and references of a candidate. Includes conducting any other pre-employment checks in line with policy (e.g. criminal record and financial checks).
Discipline 2 Responsible for disciplining any breaches of security policy.
Training 2 Responsible for providing employees with the training necessary to fulfil their duties in a secure manner.
Coordinate 1 Responsible for coordination of the security services within the architecture.
Ownership 1 Responsible for allocation of the ownership of security responsibilities.
Privacy 1 Responsible for addressing matters relating to privacy.
Impact Assess 2 Responsible for completion of privacy impact assessment.
Consent Management 2 Responsible for management of data subject consent status.
Data Sanitisation 2 Responsible for sanitisation of data from tokenisation to anonymisation.
Security Operations 0 Responsible for secure operation of the service.
Monitoring 1 Responsible for monitoring of the output and performance of the security services.
Log 2 Responsible for logging of predefined security event information.
Analyse 2 Responsible for analysis of the logged security information, e.g. to highlight potential security incidents.
Event Management 2 Responsible for management of events (e.g. ignore, escalate or report).
Report 2 Responsible for production of regular reports or other exports of information from the monitoring service.
Threat Hunting 2 Responsible for active identification of threats operating within the environment.
Administration 1 Responsible for secure system administration.
Secure Channel 2 Responsible for secure transit of management traffic.
Decommission 2 Responsible for secure decommissioning of services.
Manage 2 Responsible for system administration.
Dispose 2 Responsible for secure disposal of hardware.
Deploy 2 Responsible for secure deployment of services.
Orchestrate 2 Responsible for orchestration of services or functions.
Change Management 1 Provides security input into the change management process.
Problem Management 1 Provides security input into the problem management process.
Vulnerability Management 1 Responsible for the active identification and management of security vulnerabilities.
Threat Intelligence 1 Responsible for the identification of threats to the organisation or service.
Incident Management 1 Responsible for the management of security incidents.
Respond 2 Responsible for formation of the initial response team.
Investigate 2 Responsible for investigation of the security incident.
Action 2 Responsible for deciding and enacting the appropriate course of action.
Close 2 Responsible for closure of the security incident, including documentation of any lessons learned.
Exercise 2 Responsible for active testing of incident response processes.
Asset Management 1 Responsible for management of the IT assets associated with the service.
Catalogue 2 Documents the IT assets associated with the service.
Configuration Management 2 Provides a managed approach to the recording of IT asset configuration.
License 2 Responsible for ensuring that all IT services are appropriately licensed.
Rights Management 2 Enables control of usage of information within or outside the service.
Data Loss Prevention 2 Prevents unauthorised export of information from the service.
Integration 0 Responsible for integration of security controls in hybrid environments.
CASB 1 Brokers security controls across multiple Cloud environments.
API 1 Provides API interfaces to security functionality.
Cloud Workload Protection 1 Provides a portable wrap of security protection to Cloud workloads.

Table 1 describes each of the different services included within the SRM. The Level column simply refers to a level of granularity – lower level services can be grouped together to provide the higher level services. For example, in order to provide a secure development service, it is necessary to consider aspects such as coding standards, code review, automation, repository, secrets management and unit testing. As stated previously, the SRM is a generic model; experienced security architects are likely to offer different approaches towards delivery of the top level services based on their own experiences and expertise. The SRM is a useful tool; however, I am not positioning it as the holy grail of information assurance!

Service levels and contracts

In our discussions of the SRM so far, there has been no real indication of how the services interact to form a cohesive security solution. Furthermore, there has been no description of how the generic conceptual services can be moulded to provide solutions that are appropriate to a specific purpose or situation. I use a service oriented approach to architecture whereby the security services are as decoupled as possible. This means that each service can be altered without affecting the operation of the relying services – provided that the interfaces presented to other services remains commonly understood. In order to make a security service useable, it must provide an interface that consuming services can access. The mechanism for defining the operation of each of the security services is that of a service contract, as described within the Open Group TOGAF methodology. A template TOGAF-style service contract is shown in Table 2.

Table 2: Service Contract

Attribute Type Attribute Description
General Reference Unique identifier of the contract.
General Name Descriptive name of the relevant service.
General Description Description of the service concerned.
General Source Origin of the contract artefact, e.g. document or requirement.
General Owner Owner of the artefact: the individual or governance body that provides authoritative validation of the details of the contract.
General Version Version of the contract.
Business RACI Lists those who are:

•‘Responsible’;

•‘Accountable’;

•‘Consulted’; or

•‘Informed’

with respect to the operation of the contract.
Business Functional requirements Specific set of bulleted items listing exactly what activities the service performs.
Business Importance to the process Description of the criticality of this service to the business – it should be using a common set of criteria and criticality definitions.
Business Quality of information required Description of the data quality requirements with regard to information objects input to the service and the data quality requirements of the data output by the service.
Business Contract control requirements How the contract will be monitored and controlled, e.g. to ensure that it remains aligned to changing business requirements.
Business Quality of service Defines allowable failure rate for the service.
Business Service level agreement (SLA) Defines the service levels expected of the service.
Non-functional Throughput Defines the throughput that the service must be able to process, e.g. volume of transactions.
Non-functional Throughput period Defines the period of time in which the expected throughput will occur, e.g. yearly, monthly, daily, hourly, etc.
Non-functional Growth Defines the rate of expected growth in usage of the service (per a defined period, e.g. 10% over 12 months).
Non-functional Service times The times during which the service must be operational, e.g. office hours (for example, 9am to 5pm).
Non-functional Peak Profile (short term) Description of peak usage on a short-term basis, e.g. 9am to 10am each day.
Non-functional Peak Profile (long term) Description of peak usage on a long-term basis (e.g. month end, annual events, etc.).
Technical Invocation Description of how the service can be invoked, e.g. service end points for technical services.
Technical Invocation preconditions Description of the conditions that must be met in order to invoke the service, e.g. authentication requirements.
Technical Information objects Describes:

•The information objects that can be passed to the service for processing.

•The information objects output by the service.
Technical Behaviours Criteria and conditions for successful operation, including dependencies. Lists any likely child services invoked in order to fulfil the purpose.

It can be seen from Table 2 that service contracts can be used to define the activities that the service conducts, the information objects it consumes and the information objects it creates. Furthermore, Table 2 shows that the service levels and non-functional requirements are defined by the service contract. This is where the services can be customised to match each deployment situation; a service requiring 24-hour operation with zero downtime will likely require a different technical implementation than one with more relaxed requirements.

Service contracts are incredibly important when defining any form of IT architecture, including security architecture. Service contracts define the levels of service provided by each security service. These service levels will often dictate the set of technical solutions that can be used to deliver each security solution. More importantly, these service levels will often enable a security architect to discount candidate security solutions that simply cannot deliver the required service levels.

I will not talk much more about service contracts in this book. Service contracts must be tailored to meet the specific needs of your application, as this book provides generic guidance it is not desirable to provide a set of service contracts for each security service. Definition of a set of appropriate service contracts, including the required granularity, is one of the critical tasks for your security architect.

Service models and the Security Reference Model

So far, we have talked a lot about the SRM but have yet to discuss its relevance in the context of Cloud computing. The remainder of this chapter uses the SRM to describe some of the differences inherent to the Cloud service models. We will take a hypothetical business application that an organisation is looking to deliver using Cloud services. The actual nature of the application is irrelevant, it simply needs to be an application that could be provided via IaaS, PaaS, SaaS or FaaS models. We will then discuss how the primary delivery responsibility for each of the security services within the SRM varies across the service models.

IaaS

Figure 8 illustrates the security responsibilities of the consumer and provider when an application is hosted upon an IaaS Cloud. Appendix A lists each of the SRM security services and provides a rationale for the assignment of primary delivery responsibility per service model.

In the following diagrams, red implies that delivery of the service is primarily the responsibility of the Cloud service provider, green implies that delivery of the service is primarily the responsibility of the Cloud consumer whilst yellow means that the delivery responsibility is split between both provider and consumer.

image

Figure 8: Security delivery responsibilities – IaaS Cloud

Figure 8 is quite clear in showing that the consumer retains primary responsibility for delivery of the vast majority of the security services within the SRM when deploying an application onto an IaaS Cloud. As should be expected, the Cloud provider has primary responsibility for those elements of service delivery relating to the physical hosting environment.

There are a number of services where the delivery responsibility is split between both service provider and consumer. The filter service is a good example of joint delivery responsibility; the provider must implement technical controls to filter network access to the underlying Cloud infrastructure, whereas the consumer is responsible for implementing appropriate filter components within their virtual network and within their application. From a security perspective, the areas of joint responsibility are those where issues are most likely to occur due to a misunderstanding about responsibility handover points. In the filter example, it is vital to ensure that all areas where a filter service is required have been catered for by either the provider or the consumer and that no gaps have been left in the overall security posture.

Availability is another example of joint delivery responsibility. The service provider will typically provide contracted levels of service availability, perhaps including transparent failover across data centres. However, the consumer must still be cognisant of availability requirements over and above the contracted requirements and ensure that the application can deliver these enhanced requirements. This may include designing in the ability to failover from one Cloud service to another in the event of a major incident at the main Cloud provider.

Note: This is a nontrivial requirement and, in general, it should only be considered where there are strong regulatory requirements that demand this level of workload portability.

PaaS

PaaS is a much more complicated scenario, as shown in Figure 9.

image

Figure 9: Security delivery responsibilities – PaaS

Given the nature of common PaaS services it should be expected that the vast majority of security services must be delivered jointly by the provider and the consumer. In this example, we are assuming that the PaaS provides a set of security APIs for the purposes of authentication and authorisation, e.g. Azure Active Directory via the Microsoft Graph API. This explains why the primary delivery responsibility for the validate services within the access management service grouping of the SRM are assigned to the provider. The consumer must call such security APIs correctly, but the coding and maintenance of these APIs are the responsibility of the provider. Consumers of PaaS services should look to those PaaS providers who can demonstrate the adoption of a secure development lifecycle.

Given what I said earlier regarding the areas of joint responsibility being the areas of most concern from a security perspective, it should not surprise you that I view PaaS as the hardest of the service models to secure. After all, almost all of the security services must be delivered jointly and the interfaces and hand-off points between provider and consumer defined and controlled.

Even with the PaaS model, the consumer retains primary responsibility for a small number of services; most importantly this includes the compliance service grouping. Whilst the provider may claim to provide services in line with a set of requirements such as PCI DSS, the consumer would still suffer the consequences of any breach of compliance. It remains primarily the responsibility of consumers to protect themselves from breaches of compliance, regardless of the service model.

FaaS

Figure 10 shows that the situation of FaaS is extremely similar to that of PaaS when it comes to security – this is one of the reasons why I tend to view FaaS as an evolution of PaaS rather than as a completely new model.

image

Figure 10: Security delivery responsibilities – FaaS

The main differences between the FaaS model and the PaaS model relate to the ephemeral nature of FaaS functions and their increased reliance upon Cloud provider deployment, management and orchestration mechanisms. As with PaaS, FaaS consumers remain responsible for the security of the code that they create; however, that code will typically make use of back-end services and event triggers offered by the Cloud provider. Significantly, the ephemeral nature of FaaS places more emphasis on the Cloud provider to ensure that they adequately clear down hosting environments prior to using that environment to host functions belonging to a separate customer. Whilst FaaS is very similar to PaaS, the delineation of responsibilities is, in general, somewhat cleaner in the FaaS model – the FaaS consumer is only responsible for the definition of the code to run and does not have to concern themselves with the run-time.

Note: This is not the case when the consumer chooses to use the Bring Your Own Run-time81 capability offered by some FaaS providers.

SaaS

Figure 11 shows the responsibility split for the final service model under consideration: SaaS.

image

Figure 11: Security delivery responsibilities – SaaS

With SaaS, many more of the security services are now being delivered by the provider. This includes the secure development services as the application itself is now developed (or at least tailored and operated) by the provider. You can argue whether or not the fact that more services are delivered by the provider makes SaaS more secure than PaaS or FaaS, depending upon your level of trust in the provider. I would argue that it makes SaaS intrinsically easier to secure than PaaS or FaaS, but that this does not necessarily make SaaS intrinsically more secure than PaaS or FaaS.

There are some areas of joint responsibility, even with the SaaS model. For example, the registration and privilege management services are both jointly delivered. The consumer must register their own users and must manage the privileges of their users within the application; however, both registration and privilege management must be performed using capabilities delivered by the provider.

Conclusion

The aim of this chapter was to show how security architecture methodologies can be used to enable organisations to move towards Cloud computing.

The discussion regarding the SRM has shown how security architecture can be used to identify potential areas of concern within the different service models, i.e. those areas where gaps may appear between the services delivered by the provider and those retained by the consumer.

In summary, the last two chapters have provided a high-level approach to the definition of a set of technical and procedural requirements to appropriately secure a Cloud service, based on architecture techniques. The most important components of this approach include:

•Deriving and agreeing the business and non-functional requirements relating to security;

•Performing a risk assessment of the application;

•Identifying any existing or required security principles;

•Identifying a set of conceptual security services derived from the requirements set, the risk assessment and the security principles;

•Drawing up a series of service contracts relating to the identified services;

•Elaborating the conceptual services into a series of logical services; and

•Determining appropriate technical and procedural controls to deliver the logical services, in line with the requirements of the service contracts.

This approach results in the production of a Cloud service that is demonstrably secured according to the needs of the business.

The next four chapters of this book delve into a little more detail in terms of the practical resources and mechanisms available to secure Cloud services. The services described within the SRM are explored for each of the service models and example mechanisms for delivering these services are proposed.

78 NIST Cloud Computing Security Reference Architecture https://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/CloudSecurity/NIST_Security_Reference_Architecture_2013.05.15_v1.0.pdf.

79 https://cloudsecurityalliance.org/research/working-groups/enterprise-architecture/#_overview.

80 https://cloudsecurityalliance.org/artifacts/tci-reference-architecture-v2-0/.

81 For example, https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.10.1