Cloud Security Guidancefrom CESG and AWS

Paavan Mistry – EMEA Security Assurance@98pm

Security is the foundation

Physical

Security

Network

Security

Platform

Security

People &

Procedures

Familiar security modelValidated by security experts

Collaboration on EnhancementsEvery Customer Benefits

AWS Foundation Services

Compute Storage Database Networking

AWS Global

InfrastructureRegions

Availability

Zones Edge

Locations

Client-side Data

Encryption

Server-side Data

EncryptionNetwork Traffic

Protection

Platform, Applications, Identity & Access Management

Operating System, Network, & Firewall Configuration

Customer applications & contentC

usto

me

rs

Security & compliance is a shared responsibility

Customers have

their choice of

security

configurations IN

the Cloud

AWS is

responsible for

the security OF

the Cloud

UK Government Security Programs

Cloud Security

Principles

(14 Principles)

Cyber Essentials

Scheme

Cyber Essentials Scheme

Cyber Essentails Plus – AWS

• Cyber Essentials Plus is a UK Government-backed,

industry-supported certification scheme introduced in

2014 to help organisations demonstrate security

against common cyber attacks.

• The ‘Plus’ scheme benefits from independent testing

and validation compared to the baseline ‘Cyber

Essentials’ scheme that is self-attested.

Cyber Essentails Plus – AWS (contd.)

• Increases confidence in security and compliance for AWS UK

public and private sector customers

• Enables the AWS customers and partners in discussions on cyber

security and government requirements.

• Demonstrates AWS alignment with guidance from the UK

government regulators and organisations like CESG and CREST.

Cloud Security Principles

Background and context

• Change from GPMS to GSCP

• Publication of Cloud Security

Principles

• Buyer ownership of risks associated

with OFFICIAL workloads

Info

rme

d R

isk

Assessm

ents

• Shift from central accreditation model for IL2/IL3

Principle 1 – Data in transit protection

• Description: Consumer data transiting networks should be adequately protected against tampering (integrity) and eavesdropping (confidentiality). This should be achieved via a combination of:

– network protection (denying your attacker access to intercept data)

– encryption (denying your attacker the ability to read data)

• Implementation Objectives: Consumers should be sufficiently confident that:

– Data in transit is protected between the consumer’s end user device and the service

– Data in transit is protected internally within the service

– Data in transit is protected between the service and other services (e.g. where APIs are exposed)

Principle 1 – Data in transit protection

• API protection– TLS protected API endpoints (server authentication)

– Control plane, resource management

• Customer network protection– VPC (optionally accessible only via VPN)

– TLS at the instance layer

– API call signing

– Overlay networking

• AWS services encryption– S3, RDS, DynamoDB, EMR, ELB

Principle 2 – Asset protection and resilience

• Description: Consumer data, and the assets storing or processing it,

should be protected against physical tampering, loss, damage or seizure.

The aspects to consider comprise:

Physical location and legal jurisdiction

Data centre security

Data at rest protection

Data sanitisation

Equipment disposal

Physical resilience and availability

Principle 2 – Asset protection and resilience

• Physical location

• Physical resilience and availability

AZ

AZ

AZ AZ AZ

Transit

Transit

Principle 2 – Asset protection and resilience

• Data Centre Security– Significant experience in building, operating and securing data

centres at scale

– Strict access controls

– Security staff, video surveillance and intrusion detection systems

– Multi-factor authentication to data centre floors

• Data at rest– A range of encryption options

Principle 2 – Asset protection and resilience

• Data sanitisation– Wiping prior to use mandatory (EBS)

– Supplement with your own techniques to meet specific

standards

– RDS database instances marked for deletion are deleted by an

automated sweeper

Principle 2 – Asset protection and resilience

• Equipment disposal– Techniques per DoD 5220.22-M (“National Industrial Security

Program Operating Manual “)

Principle 3 – Separation between consumers

• Description: Separation between different consumers of the service prevents one malicious or compromised consumer from affecting the service or data of another.

– Some of the important characteristics which affect the strength and implementation of the separation controls are:

– the service model (e.g. IaaS, PaaS, SaaS) of the cloud service

– the deployment model (e.g. public, private or community cloud) of the cloud service

– the level of assurance available in the implementation of separation controls

• Implementation Objectives: Consumers should:– understand the types of consumer they share the service or platform with

– have confidence that the service provides sufficient separation of their data and service from other consumers of the service

– have confidence that their management of the service is kept separate from other consumers (covered separately as part of Principle 9).

Principle 3 – Separation between consumers

• Defence in depth– Host OS, Instance OS, Firewalls, signed API calls

• Packet “sniffing” by other tenants– Prevents instances running in promiscuous mode receiving traffic

for other instances

• No access to raw disk– Proprietary virtualisation layer (automatic erasing prior to use)

– Encryption options (traditional filesystem options or AWS managed)

• Dedicated instances (single tenancy option)

Principle 4 – Governance framework

• Description: The service provider should have a security governance framework that coordinates and directs their overall approach to the management of the service and information within it.

– When procuring a cloud service, ensure that the supplier has a suitable security governance framework in place . Regardless of any technical controls deployed by the supplier, controls will be fundamentally undermined if operating outside an effective risk management and governance regime.

– A clearly identified, and named, board representative (or a person with the direct delegated authority) who is responsible for the security of the cloud service.

– A documented framework for security governance, with policies governing key aspects of information security relating to the service.

– Security and information security as part of the service provider’s financial and operational risk reporting mechanisms.

– Processes to identify and ensure compliance with applicable legal and regulatory requirements relating to the service.

• Implementation Objectives: The consumer should have sufficient confidence that the governance framework and processes in place for the service are appropriate for their intended use of it.

Build everything on a constantly improving security baseline

AWS Foundation Services

Compute Storage Database Networking

AWS Global

InfrastructureRegions

Availability

Zones Edge

Locations

GxP

ISO 13485

AS9100

ISO/TS 16949

AWS is

responsible for

the security OF

the Cloud

Principle 5 – Operational security

• Description: The service provider should have processes and procedures in place to ensure the operational security of the service. The service will need to be operated and managed securely in order to impede, detect or prevent attacks against it. The aspects to consider comprise:

– Configuration and change management - ensuring that changes to the system do not unexpectedly alter security properties and have been properly tested and authorised

– Vulnerability management - ensuring that security issues in constituent components are identified and mitigated

– Protective monitoring - taking measures to detect attacks and unauthorised activity on the service

– Incident management - ensuring the service can respond to incidents and recover a secure available service

• Implementation Objectives: Good operational security should not require complex, bureaucratic, time consuming or expensive processes. In conjunction with good development practices (see Principle 7) it is possible to combine agile and responsive development with appropriate security controls.

Principle 5 – Operational security

• Systematic approach to managing change– Review: peer reviews of the technical aspects of a change

– Test: formal testing (including TLA+)

– Approved: appropriate oversight

• Phased deployments– AZ and Region

– Closely monitored

Principle 5 – Operational security

• Vulnerability management– Continual testing regime

– Regular independent assessment

– Documented approach to customer pen tests

• Protective Monitoring– Extensive measuring of key operational and security metrics

– Amazon incident response team

• Incident management– Formal, documented incident response policy and programme

– Activation and notification, Recovery, Reconstitution phases

Principle 6 – Personnel security

• Description: Service provider staff should be subject to personnel security

screening and security education for their role.

– Personnel within a cloud service provider with access to consumer data and systems need

to be trustworthy. Service providers need to make clear how they screen and manage

personnel within any privileged roles. Personnel in those roles should understand their

responsibilities and receive regular security training. More thorough screening, supported by

adequate training, reduces the likelihood of accidental or malicious compromise of consumer

data by service provider personnel.

• Implementation Objectives: Consumers should be content with the level of security

screening conducted on service provider staff with access to their information or with ability to

affect their service.

Principle 6 – Personnel security

• Background checks– criminal background checks as permitted by applicable law

– pre-employment screening practices for employees commensurate with the employee’s position and level of access to AWS facilities

• Policy– all personnel supporting AWS systems and devices sign a non-

disclosure agreement

– Acceptable use policy

– Code of conduct and ethics

• Ongoing Information Security Training– Periodic compliance audits

Principle 7 – Secure development

• Description: Services should be designed and developed to identify and

mitigate threats to their security.– Services which are not designed securely may be vulnerable to security issues which could

compromise consumer data, cause loss of service or enable other malicious activity.

• Implementation Objectives: Consumers should be sufficiently confident that:

– New and evolving threats are reviewed and the service improved in line with them.

– Development is carried out in line with industry good practice regarding secure design,

coding, testing and deployment.

– Configuration management processes are in place to ensure the integrity of the solution

through development, testing and deployment.

Principle 7 – Secure development

• Secure software development best practices– Formal code review by AWS Security

– Threat modeling and risk assessment

– Static code analysis tools are run as a part of the standard build

process

– Recurring penetration testing

– Security risk assessment reviews begin during the design phase

and the engagement lasts through launch to ongoing operations

Principle 8 – Supply chain security

• Description: The service provider should ensure that its supply chain satisfactorily

supports all of the security principles that the service claims to implement.

– Cloud services often rely upon third party products and services. Those third parties can have an

impact on the overall security of the services. If this principle is not implemented then it is possible

that supply chain compromise can undermine the security of the service and affect the

implementation of other security principles.

• Implementation Objectives: The consumer understands and accepts:

– How their information is shared with, or accessible by, third party suppliers and their supply chains.

– How the service provider’s procurement processes place security requirements on third party

suppliers and delivery partners.

– How the service provider manages security risks from third party suppliers and delivery partners.

– How the service provider manages the conformance of their suppliers with security requirements.

– How the service provider verifies that hardware and software used in the service is genuine and

has not been tampered with.

Principle 8 – Supply chain security

• Asset tracking– AWS hardware assets are assigned an owner and tracked and

monitored by AWS personnel with proprietary inventory

management tools

• Personnel requirements– All persons working with AWS information must at a minimum,

meet the screening process for pre-employment background

checks and sign a Non-Disclosure Agreement (NDA)

Principle 9 – Secure consumer management

• Description: Consumers should be provided with the tools required to help

them securely manage their service. Management interfaces and

procedures are a vital security barrier in preventing unauthorised people

accessing and altering consumers’ resources, applications and data. The

aspects to consider comprise:

– Authentication of consumers to management interfaces and within support channels

– Separation and access control within management interfaces

Principle 9 – Secure consumer management

• IAM (Identity and Access

Management)– Granular control to

AWS resources

– Least privilege role based

access

– Delegated API access

Principle 10 – Identity and authentication

• Description: Consumer and service provider access to all service interfaces

should be constrained to authenticated and authorised individuals.

– All cloud services will have some requirement to identify and authenticate users

wishing to access service interfaces. Weak authentication or access control may

allow unauthorised changes to a consumer’s service, theft or modification of

data, or denial of service.

– It is also important that authentication occurs over secure channels. Use of

insecure channels such as email, HTTP or telephone can be more vulnerable to

interception or social engineering attacks.

• Implementation Objectives: Consumers should have sufficient confidence that

identity and authentication controls ensure users are authorised to access specific

interfaces.

Principle 10 – Identity and authentication

• Multiple options for account access– IAM

– Key management and rotation

– Temporary security credentials

– Multi-Factor Authentication

– Federation

• Host Operating System access– Rigorous access control

– Purpose-built Bastion hosts for the management plane

• Guest Operating System access– Retain control and freedom of choice (supported with best practices)

Principle 11 – External interface protection

• Description: All external or less trusted interfaces of the service should be identified and

have appropriate protections to defend against attacks through them.

– If an interface is exposed to consumers or outsiders and it is not sufficiently robust, then it could be

subverted by attackers in order to gain access to the service or data within it. If the interfaces

exposed include private interfaces (such as management interfaces) then the impact may be more

significant.

– Consumers can use different models to connect to cloud services which expose their enterprise

systems to varying levels of risk.

• Implementation Objectives: – The consumer understands how to safely connect to the service whilst minimising risk to the

consumer’s systems.

– The consumer understands what physical and logical interfaces their information is available from.

– The consumer has sufficient confidence that protections are in place to control access to their data.

– The consumer has sufficient confidence that the service can determine the identity of connecting

users and services to an appropriate level for the data or function being accessed.

Principle 11 – External interface protection

• Secure network architecture– Firewalls and boundary protection devices (rulesets and ACL’s)

– Approved by Amazon Information Security

– Polices automatically pushed

– Wide variety of automated monitoring systems

– Documentation maintained for incident handling

– Post mortems (Cause of Error – COE)

• Secure Access Points to AWS API interfaces– HTTPS redundant connections

• Choice of VPN options for VPC connectivity– AWS provide Virtual Private Gateway

– Marketplace appliances

Principle 12 – Secure service administration

• Description: The methods used by the service provider’s administrators to

manage the operational service should be designed to mitigate any risk of

exploitation that could undermine the security of the service.

– The security of a cloud service is closely tied to the security of the service provider’s

administration systems. Access to service administration systems gives an attacker high

levels of privilege and the ability to affect the security of the service. Therefore the design,

implementation and management of administration systems should reflect their higher value

to an attacker.

– A service administration network is a specialised form of enterprise network. There are a

wide range of options for how this can be designed, delivered, managed and secured. It is

expected that standard enterprise good practice be followed in the design and operation of

these systems, but at a level reflecting their higher value.

• Implementation Objectives: Consumers have sufficient confidence that

the technical approach the service provider uses to manage the service

does not put their data or service at risk.

Principle 12 – Secure service administration

• User access procedures– Adds, modifications, deletions

– Password complexity and policies

– Least privilege principle

– Periodic review

– Automatic revocation

• Management plane controls– Purpose built administration hosts (bastion hosts)

– MFA access

– Access logged and audited

– Revoked if no business need

Principle 13 – Audit information provision to

consumers

• Description: Consumers should be provided with the audit records they need to

monitor access to their service and the data held within it.

– The type of audit information available to consumers will have a direct impact on

their ability to detect and respond to inappropriate or malicious usage of their

service or data within reasonable timescales.

• Implementation Objectives: Consumers are:

– Aware of the audit information that will be provided to them, how and when it will

be made available to them, the format of the data, and the retention period

associated with it.

– Confident that the audit information available will allow them to meet their needs

for investigating misuse or incidents.

Principle 13 – Audit information provision to

consumers

• Services controlled via API’s

• CloudTrail– History of API calls (AWS Management Console, AWS SDKs,

command line tools, and higher-level AWS services)

– Enables security analysis, resource change tracking, and

compliance auditing

• Logs provided to customers through S3 buckets– Full control over onward sharing

Principle 14 – Secure use of the service by the

consumer

• Description: Consumers have certain responsibilities when using a cloud service

in order for their use of it to remain secure, and for their data to be adequately

protected.

– The security of cloud services and the data held within them can be undermined by poor use

of the service by consumers. The extent of the responsibility on the consumer for secure use

of the service will vary depending on the deployment models of the cloud service, specific

features of an individual service and the scenario in which the consumers intend to the use

the service.

• Implementation Objectives: – The consumer understands any service configuration options available to them and the

security implications of choices they make.

– The consumer understands the security requirements on their processes, uses, and

infrastructure related to the use of the service.

– The consumer can educate those administrating and using the service in how to use it safely

and securely.

Principle 14 – Secure use of the service by the

consumer

• Support and communications– Service Health Dashboard

– Account teams

– Acceptable Use Policies

– Best Practices

– Security Centre

– Training and Certification

– Premium Support

– Trusted Advisor

More information

• Contact your account team

• AWS Security Centre -

http://aws.amazon.com/security/

• AWS Compliance Centre -

http://aws.amazon.com/compliance/

• AWS Whitepapers -

http://aws.amazon.com/whitepapers/

LONDON

LONDON

©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

AWS Security & Compliance Day