AWS Pop-up Loft London Series

1. Cloud Security Guidance
from CESG and AWS
Paavan Mistry – EMEA Security Assurance
@98pm

2. Security is the foundation
Physical
Security
Network
Security
Platform
Security
People &
Procedures
Familiar security model
Validated by security experts
Collaboration on Enhancements
Every Customer Benefits

3. AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure
Regions
Availability
Zones Edge
Locations
Client-side Data
Encryption
Server-side Data
Encryption
Network Traffic
Protection
Platform, Applications, Identity & Access Management
Operating System, Network, & Firewall Configuration
Customer applications & contentCustomers
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

4. UK Government Security Programs
Cloud Security
Principles
(14 Principles)
Cyber Essentials
Scheme

5. Cyber Essentials Scheme

6. 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.

7. 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.

8. Cloud Security Principles

9. Background and context
• Change from GPMS to GSCP
• Publication of Cloud Security
Principles
• Buyer ownership of risks associated
with OFFICIAL workloads
InformedRisk
Assessments
• Shift from central accreditation model for IL2/IL3

10. 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)

11. 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

12. 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

13. Principle 2 – Asset protection and resilience
• Physical location
• Physical resilience and availability
AZ
AZ
AZ AZ AZ
Transit
Transit

14. 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

15. 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

16. Principle 2 – Asset protection and resilience
• Equipment disposal
– Techniques per DoD 5220.22-M (“National Industrial Security
Program Operating Manual “)

17. 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).

18. 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)

19. 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.

20. Build everything on a constantly improving security baseline
AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure
Regions
Availability
Zones Edge
Locations
GxP
ISO 13485
AS9100
ISO/TS 16949
AWS is
responsible for
the security OF
the Cloud

21. 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.

22. 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

23. 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

24. 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.

25. 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

26. 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.

27. 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

28. 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.

29. 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)

30. 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

31. Principle 9 – Secure consumer management
• IAM (Identity and Access
Management)
– Granular control to
AWS resources
– Least privilege role based
access
– Delegated API access

32. 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.

33. 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)

34. 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.

35. 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

36. 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.

37. 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

38. 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.

39. 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

40. 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.

41. 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

42. 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/

43. LONDON

44. LONDON
©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
AWS Security & Compliance Day