AWS Security & Compliance Day

Thank you for attending AWS Security & Compliance Day On the 18 th of June, 2015 at 60 Holborn Viaduct London EC1A 2FD United Kingdom This deck contains four presentations that took place on the day As well as information for our next AWS Security and Compliance Day 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Content Slide 4 Introduction: AWS Security and Compliance in the Public Sector Dob Todorov, Regional Technology Officer, Public Sector Solutions Architecture Principle Architect Security and Compliance, EMEA AWS Slide 21 Toolset for Cloud Security Principles on AWS Dave Walker, Specialised Solutions Architect Security/Compliance, AWS Slide 62 Cloud Security Guidance from CESG for G-Cloud and AWS Security Paavan Mistry, EMEA Security Assurance, AWS Rob Whitmore, WWPS Solutions Architect, AWS Slide 99 Amazon Web Services Smart Citizen Services Chis Hayman, Enterprise Account Manager, AWS

Introduction: AWS Security and Compliance in the Public Sector Dob Todorov Regional Technology Officer, Public Sector Solutions Architecture Principle Architect Security and Compliance, EMEA 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Electric Power Generation in the 19 th Century

Modern Electric Power Generation & Distribution

IT Security in the 20 th Century

Modern IT Security Cloud Security

The Economics of Cloud Security

Cost of Security on Premises / Hosted Facility Technology (Physical Security, Infrastructure, Power, Networking) Processes (standards, procedures, guidelines, assurance, compliance) People (hire, upskill, compensate, train, manage) CapEx OpEx

Security and Business Value Security as a Feature : Qualitative measure: either secure or insecure No added end user value Objective Reality: Small or shrinking budgets Threat vectors and agents rising in number and sophistication Challenge: How do we justify the cost of security?

Cost of Security in the Cloud Infrastructure secure & compliant at no extra cost CapEx OpEx Technology (Physical Security, Infrastructure, Power, Networking) Processes (standards, procedures, guidelines, assurance, compliance) People (hire, upskill, compensate, train, manage) - - - - - -

Advanced Persistent Threats and Cloud

Infrastructure Attack (Layer 3 / 4) Examples Asymmetric attacks that use amplification & rely upon depletion of limited resources SYN Flood UDP (NTP) Amplification Flood SYN SYN/ACK Attacker 192.0.2.1 Victim 198.51.100.4 ACK src=198.51.100.4 dst=203.0.113.32 NTP DNS SNMP SSDP Connection Table X Reflectors (NTP servers) 203.0.113.32

Architecture for HTTP Flood Elastic resources cannot be depleted. users WAF web app server CloudFront Edge Location ELB Auto Scaling ELB Auto Scaling security group security group security group security group DDoS DMZ public subnet WAF / Proxy private subnet frontend servers private subnet

The UK Public Sector Landscape

Central Government

Local and Regional Government

Education and Research

Non-for-profit Organisations & Non-government Organisations (NPO/NGO)

Toolset for Cloud Security Principles on AWS Dave Walker Specialised Solutions Architect Security/Compliance Amazon Web Services UK Ltd 18 th June 2015 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Agenda Principle 2: Key Management for Encryption at Rest Principle 3: Separation between Consumers Principle 5: Operational Security Principles 9 and 10: Secure Consumer Management, Identity and Authentication Principle 13: Audit Information Provision to Consumers

Principle 2: Key Management for Encryption at Rest

CloudHSM Tamper-Proof and Tamper-Evident Destroys its stored keys if under attack FIPS 140-2 Level 2 certified Base position is to be a Keystore Can also be used to timestamp documents You can send data for encrypt / decrypt Needs to be backed-up (ideally to HSM on customer premises) Can be (and should) be combined in HA clusters Is NOT a key management system but can work with some third-party ones Communicates via: PKCS#11 JCE Some applications need a plugin

CloudHSM Integration with S3, EBS, EC2 S3 Integration using SafeNet KeySecure on EC2 White paper at http://www2.safenet-inc.com/awsguides/safenetkmip_amazons3_integrationguide.pdf EBS and EC2 Use SafeNet KeySecure (6.1.2 or later) on EC2, backed by CloudHSM, for key management Install SafeNet ProtectV Manager on EC2 (c1.medium / m1.medium) Install ProtectV Client on EC2 instances Use ProtectV for EBS volume encryption (ext3, ext4, swap) Supported platforms: RHEL 5.8, 6.2, 6.3 CentOS 6.2 Microsoft Windows 2008, 2012 Encrypt full EBS-backed EC2 instances, including root volumes

AWS Databases and CloudHSM Redshift: When using CloudHSM Redshift gets cluster key from HSM Redshift generates a database key and encrypts it with the cluster key from the CloudHSM Redshift encrypts data with the database key Redshift supports re-encryption RDS RDS / Oracle EE can use CloudHSM to store keys as per Oracle Wallet So TDE can be HSM-backed Note that in-memory database contents (once the database has been unlocked) are cleartext RAM encryption is not something AWS has today, but it has been done in other contexts

Principle 3: Separation between Consumers

Infrastructure Storage: EBS: LUN segregation S3: Bucket policy; [other things to be put here] Compute: Xen-based hypervisor separation covered as Level 1 application in PCI-DSS Dedicated Instances (optional per instance or per VPC) No other customers on the same underlying physical server

Infrastructure Networking: No promiscuous mode, ARP spoofing No need for VLANs; VPC network segregation cfg out-of-band at Layer 2 Bespoke network card and Layer 2 switch firmware See A Day in the Life of a Billion Packets from Re:Invent 2013: https://www.youtube.com/watch?v=zd5hsl-jny4 Customer-configurable filtering: NACLs (layer 3 stateless; switch ACL-like) Security Groups (Layer 3 stateful; IPFilter-like) ELB: Session-terminating, load-balancing proxy VPC Flow logs: Send VPC, subnet or ENI Layer 3 info to CloudWatch Logs plus 3 rd -party appliances from AWS Marketplace to cover IPS / IDS / WAF etc, as an adjunct to deploying layered software on EC2 instances

Principle 5: Operational Security

Infrastructure Isolation Support and Engineering Access: EC2 network environment physically isolated from AWS internal networks Support and Services access to underlying EC2 networks limited to via bastion hosts Bastion hosts: Hardened, minimised Linux with bespoke bits Access requires separate per-engineer MFA token from their usual office MFA token, and valid Trouble Ticket All actions (command and response) logged All logs shipped near-realtime over log network to AWS Security for analysis and archive Access revoked when ticket closes Service team access segregated by service Service updates heavily automated (see CodeDeploy)

Principles 9 and 10: Secure Consumer Management, Identity and Authentication

Identity and Access Management: Authentication Console Username / passwd (enforcable complexity), optional MFA token response Signed URL (token) Multi-factor Authentication ( MFA ) Token-based authn as an adjunct to passwords RFC6238-compatible time-based one-time password Works with Gemalto tokens, software implementations If you need a different token type, look at: Federation SAML recommended for Enterprise integration Tested with OpenLDAP + Shibboleth, Active Directory Authentication happens where the user data is held so implement your own token s plug-in code on your federated on-premises directory You can pentest your own identity repo (but not ours) OAuth / OpenID available for subscriber-based authentication federation

Identity and Access Management: Authentication REST API Access Key (for identification), Secret Access Key (for request signing), optional MFA token response Temporary access key / secret access key + token, issued by STS) X.509 certificates (for SOAP API; deprecated)

2) SAML SSO SAML to AWS Management Console federation SP console Assertion Attribute SAML subject name RoleArn PrincipalArn RoleSessionName Description Required for SAML role for user entitlements role of IDP in AWS Enables user-specific auditing and access policies federation IDP X.509 certificate Bound to PrincipalArn

SAML to AWS (API) STS federation SP ST credentials RoleArn PrincipalArn ST credentials Assertion 1) authentication 2) authn, attributes 3) assertion federation IDP

Identity and Access Management: Authorisation Least Privilege Fine-grained permissions Eg EC2 instance stop, start, create, terminate; Security Group assign, rule change Permissions can be assigned by: User (where policy requires) Group (better) Role (best, where practical applicable to users and EC2 instances) Permission Grants can be constrained by: User, Group, Role (naturally!) Source IP address(es), subnet Time of day Use of MFA token Region of instances (a work in progress; works for many EC2 permissions, also applies to RDS)

Identity and Access Management: Subtleties Mandatory Access Control Achievable using cross-account sharing, eg: Create an S3 bucket in an account designated for Audit (Apply versioning and MFA Delete on it, naturally more on this shortly) Share it write-only with your Production account, for use by CloudTrail, Config, CloudWatch Logs The bucket policy are invisible and immutable to all users in the Production account, even root! Managed Policies For when you don t necessarily want to write the JSON policy yourself and how to give someone privilege in IAM, without allowing them to rewrite their own account profile

Principle 13: Audit Information Provision to Consumers

Detailed Billing Billing Information logged Daily in S3 Also Visible in the Billing Console Alarms can be set on Billing Info to Alert on Unexpected Activity

Sample Records ItemDescription $0.000 per GB - regional data transfer under the monthly global free tier $0.05 per GB-month of provisioned storage - US West (Oregon) First 1,000,000 Amazon SNS API Requests per month are free First 1,000,000 Amazon SQS Requests per month are free $0.00 per GB - EU (Ireland) data transfer from US West (Northern California) $0.000 per GB - data transfer out under the monthly global free tier First 1,000,000 Amazon SNS API Requests per month are free $0.000 per GB - data transfer out under the monthly global free tier UsageStar UsageEn UsageQua Currenc CostBef Cre tdate ddate ntity ycode oretax dits 01.04.14 30.04.140.0000067 00:00 23:595 USD 0.00 0.0 01.04.14 30.04.14 1.126.666. 00:00 23:59 554 USD 0.56 0.0 01.04.14 30.04.14 00:00 23:5910.0 USD 0.00 0.0 01.04.14 30.04.14 00:00 23:594153.0 USD 0.00 0.0 01.04.14 30.04.140.0000329 00:00 23:592 USD 0.00 0.0 01.04.14 30.04.14 00:00 23:590.02311019 USD 0.00 0.0 01.04.14 30.04.14 00:00 23:5988.0 USD 0.00 0.0 01.04.14 30.04.14 00:00 23:593.3E-7 USD 0.00 0.0 TaxAm TaxT TotalCo ount ype st 0.0000 0.0000 00 None 00 0.0000 0.5600 00 None 00 0.0000 0.0000 00 None 00 0.0000 0.0000 00 None 00 0.0000 0.0000 00 None 00 0.0000 0.0000 00 None 00 0.0000 0.0000 00 None 00 0.0000 0.0000 00 None 00

AWS CloudTrail CloudTrail can help you achieve many tasks Security analysis Track changes to AWS resources, for example VPC security groups and NACLs Compliance log and understand AWS API call history Prove that you did not: Use the wrong region Use services you don t want Troubleshoot operational issues quickly identify the most recent changes to your environment

AWS CloudTrail logs can be delivered cross-account CloudTrail can help you achieve many tasks Accounts can send their trails to a central account Central account can then do analytics Central account can: Redistribute the trails Grant access to the trails Filter and reformat Trails (to meet privacy requirements)

AWS Config AWS Config is a fully managed service that provides you with an inventory of your AWS resources, lets you audit the resource configuration history and notifies you of resource configuration changes.

Am I safe? Properly configured resources are critical to security AWS Config enables you to continuously monitor the configurations of your resources at AWS API level, and evaluate these configurations for potential security weaknesses

Where is the evidence? Many compliance audits require access to the state of your systems at arbitrary times (i.e. PCI, HIPAA) A complete inventory of all resources and their configuration attributes at AWS API level is available for any point in time

What will this change affect? When your resources are created, updated, or deleted, these configuration changes can be streamed to Amazon SNS Relationships between resources are understood, so that you can proactively assess change impact

What changed? It is critical to be able to quickly answer What has changed? You can quickly identify the recent configuration changes to your resources by using the console or by building custom integrations with the regularly exported resource history files

What resources exist? AWS Config will discover the resources that exist in your account A complete inventory of all resources and their configuration attributes is maintained Available via console or export in JSON to Amazon S3

Resource A resource is an AWS object you can create, update or delete on AWS Examples include Amazon EC2 instances, Security Groups, Network ACLs, VPCs and subnets Amazon EC2 Instance, ENI... Amazon VPC VPC, Subnet... Amazon EBS Volumes AWS CloudTrail Log

Resources Resource Type Amazon EC2 Amazon EBS Amazon VPC AWS CloudTrail Resource EC2 Instance EC2 Elastic IP (VPC only) EC2 Security Group EC2 Network Interface EBS Volume VPCs Network ACLs Route Table Subnet VPN Connection Internet Gateway Customer Gateway VPN Gateway Trail

Relationships Bi-directional map of dependencies automatically assigned Change to a resource propagates to create Configuration Items for related resources

Relationships Resource Relationship Related Resource CustomerGateway is attached to VPN Connection Elastic IP (EIP) is attached to Network Interface is attached to Instance Instance contains Network Interface is attached to ElasticIP (EIP) is contained in Route Table is associated with Security Group is contained in Subnet is attached to Volume is contained in Virtual Private Cloud (VPC) InternetGateway is attached to Virtual Private Cloud (VPC)...

Configuration Item All AWS API configuration attributes for a given resource at a given point in time, captured on every configuration change

Configuration Item Component Description Contains Metadata Information about this configuration item Version ID, Configuration item ID, Time when the configuration item was captured, State ID indicating the ordering of the configuration items of a resource, MD5Hash, etc. Common Attributes Resource attributes Resource ID, tags, Resource type. Amazon Resource Name (ARN) Availability Zone, etc. Relationships Current Configuration Related Events How the resource is related to other resources associated with the account Information returned through a call to the Describe or List API of the resource The AWS CloudTrail events that are related to the current configuration of the resource EBS volume vol-1234567 is attached to an EC2 instance i- a1b2c3d4 e.g. for EBS Volume State of DeleteOnTermination flag Type of volume. For example, gp2, io1, or standard AWS CloudTrail event ID

Configuration Stream Stream of CIs for all changes in an account Contains configuration attributes that changed Available in console and Amazon SNS for programmatic processing

Configuration Snapshot Collection of CIs for all resources at given point-in-time Snapshot @ 2014-11-05, 11:30pm Generated on demand, can be exported to Amazon S3 Snapshot @ 2014-11-12, 2:30pm

Configuration History Collection of CIs for a given resource over a period of time Available through console and delivered to Amazon S3 for programmatic processing

Monitoring: Get consistent visibility of logs Full visibility of your AWS environment CloudTrail will record access to API calls and save logs in your S3 buckets, no matter how those API calls were made Who did what and when and from where (IP address) CloudTrail support for many AWS services and growing - includes EC2, EBS, VPC, RDS, IAM and RedShift Easily Aggregate all instance log information CloudWatch Logs agent scrapes files from EC2 instances and sends them to S3 Also enables alerting with SNS on strings of interest, just like regular CloudWatch CloudWatch Logs used as delivery mechanism for Flow Logging Out of the box integration with log analysis tools from AWS partners including Splunk, AlertLogic and SumoLogic

Toolset for Cloud Security Principles on AWS Dave Walker Specialised Solutions Architect Security/Compliance Amazon Web Services UK Ltd 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Cloud Security Guidance from CESG for G-Cloud and AWS Security Paavan Mistry EMEA Security Assurance Rob Whitmore WWPS Solutions Architect 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

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

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

Customers Security & compliance is a shared responsibility Customer applications & content Platform, Applications, Identity & Access Management Operating System, Network, & Firewall Configuration Client-side Data Encryption AWS Foundation Services Compute Storage Database Networking AWS Global Infrastructure Server-side Data Encryption Availability Zones Regions Network Traffic Protection Edge Locations Customers have their choice of security configurations IN the Cloud AWS is responsible for the security OF the Cloud

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 Transit AZ AZ AZ AZ 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 GxP ISO 13485 AS9100 ISO/TS 16949 AWS Foundation Services Compute Storage Database Networking AWS Global Infrastructure Availability Zones Regions Edge Locations 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 nondisclosure 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/

About How did Amazon Amazon Web Services Deep experience in building and operating global web scale systems get into cloud computing?

Service Breadth & Depth Support Professional Services Partner Ecosystem Training & Certification Solutions Architects Account Management Security & Pricing Reports Technical & Business Support Virtual Desktop Sharing & Collaboration Business Email Enterprise Applications Analytics App Services Developer Tools & Operations Mobile Services Hadoop Queuing & Notifications Transcoding Deployment Resource Templates Identity Real-time Streaming Data Workflow Email DevOps Containers Sync Data Warehouse Data Pipelines App Streaming Search Application Lifecycle Management Event-driven Computing Mobile Analytics Push Notifications Platform Services Identity Management Access Control Resource & Usage Auditing Key Management & Storage Monitoring & Logs Administration & Security Compute (VMs, Auto-scaling & Load Balancing) Storage (Object, Block and Archival) CDN Databases (Relational, NoSQL, Caching) Networking (VPC, DX, DNS) Core Services Regions Availability Zones Points of Presence Infrastructure

AWS History of Innovation AWS has been continually expanding its services to support virtually any cloud workload, and it now has more than 40 services. Amazon Simple DB Elastic Load Balancing Auto Scaling Amazon VPC Amazon RDS Amazon SES AWS Elastic Beanstalk AWS CloudFormation Amazon Elasticache AWS Direct Connect AWS GovCloud Amazon Elastic Transcoder AWS OpsWorks Amazon CloudHSM Amazon AppStream Amazon CloudTrail Amazon WorkSpaces Amazon Kinesis Amazon WorkMail 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 Amazon S3 Amazon SQS Amazon EC2 Amazon EBS Amazon CloudFront Amazon SNS Amazon IAM Amazon Route 53 In the last five years, AWS launched 1,203 new features and/or services for a total of 1,339 since inception in 2006. AWS Storage Gateway Amazon DynamoDB Amazon CloudSearch Amazon SWF Amazon Glacier Amazon Redshift AWS Data Pipeline Amazon ECS Amazon Lambda Amazon Config AWS CodeDeploy Amazon RDS for Aurora AWS KMS Amazon Cognito Amazon WorkDocs AWS Directory Service Amazon Mobile Analytics Mar 31, 2015

Global Footprint Everyday, AWS adds enough new server capacity to support Amazon.com when it was a $7 billion global enterprise. Over 1 million active customers across 190 countries 900+ government agencies 3,400+ educational institutions 11 regions 28 availability zones 53 edge locations Region Edge Location

Architected for Gov t Security Requirements Certifications and accreditations for workloads that matter AWS CloudTrail and AWS Config - Call logging and configuration management for governance & compliance Log, review, alarm on all user actions Browse and query database of current and previous state of cloud resources

Security is a Shared Responsibility Customers Refocus on Systems and Apps Security experts are a scarce resource! Refocus your security professional on a subset of the problem Customers Facilities Physical security Compute infrastructure Storage infrastructure Network infrastructure Virtualization layer (EC2) Hardened service endpoints Rich IAM capabilities Network configuration Security groups + = OS firewalls Operating systems Application security Proper service configuration AuthN & acct management Authorization policies More secure and compliant systems than any single entity could achieve on its own

Smart Citizen Services There is no better way to improve the lives of billions of people around the world than to improve the way cities work Michael Bloomberg former mayor of New York Goldsmith, S. and Crawford, S. The responsive city: Engaging communities through data-smart governance. Hoboken, New Jersey: John Wiley and Sons, 2014

The Interconnected City

Four AWS Services that enable Smart Citizen Services

Interconnected Smart Grids

AWS Lambda AWS Lambda is a compute service that runs your code in response to events such as image uploads, in-app activity, website clicks, or outputs from connected devices.

Mobile Services for Citizen Engagement

Authenticate users Amazon Cognito (Identity Broker) Store and share media Amazon S3 Transfer Manager Authorize access AWS Identity and Access Management Synchronize data Amazon Cognito (Sync) Analyze User Behavior Amazon Mobile Analytics Run Business Logic AWS Lambda Your Mobile App AWS Mobile SDK Deliver media Amazon CloudFront (Device Detection) Send push notifications Amazon SNS Mobile Push Store shared data Amazon DynamoDB (Object Mapper) Stream real-time data Amazon Kinesis (Recorder)

Statistical Predictions

Introducing Amazon Machine Learning Easy to use, managed machine learning service built for developers Robust, powerful machine learning technology based on Amazon s internal systems Create models using your data already stored in the AWS cloud Deploy models to production in seconds

Machine learning and smart applications Machine learning is the technology that automatically finds patterns in your data and uses them to make predictions for new data points as they become available. Your data + machine learning = smart applications

Managing the Data Deluge

Amazon Redshift Amazon Redshift is a fast, fully managed, petabyte-scale data warehouse solution that makes it simple and costeffective to efficiently analyze all your data using your existing business intelligence tools

Thank you for attending! We look forward to seeing you at our next AWS Security & Compliance Day on the 22nd of October 2015 at 60 Holborn Viaduct London EC1A 2FD United Kingdom Register here 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved