AWS Security & Compliance Day

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

LONDON

AWS Security & Compliance Day

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

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 Government Day on the 8

^th

of December,

2015.

Content

Slide 4 Introduction: AWS Security and Compliance in the Public Sector

Dob Todorov, Public Sector Solutions Architecture Principle Architect

Security and Compliance, EMEA AWS

Slide 21 Toolset for Cloud Security Principles on AWS

Dave Walker, AWS

Slide 62 Cloud Security Guidance from CESG for G-Cloud and AWS Security

Paavan Mistry, AWS

Rob Whitmore, WWPS Solutions Architect, AWS

Slide 99 Amazon Web Services Smart Citizen Services

Chis Hayman, AWS

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

Amazon Web Services

Smart Citizen Services

Chris Hayman

18

^th

June 2015

About Amazon Web Services

…get into cloud computing?

How did Amazon…

Administration

& Security Access

Control Identity

Management

Key Management

& Storage

Monitoring

& Logs Resource &

Usage Auditing

Platform Services

Analytics App Services Developer Tools & Operations Mobile Services

Data Pipelines Data Warehouse Hadoop

Real-time Streaming Data

Application Lifecycle Management

Containers Deployment

DevOps

Event-driven Computing Resource Templates

Identity

Mobile Analytics

Push Notifications Sync

App Streaming

Email Queuing &

Notifications

Search Transcoding

Workflow

Core Services CDN

Compute

(VMs, Auto-scaling

& Load Balancing)

Databases

(Relational, NoSQL, Caching)

Networking

(VPC, DX, DNS)

Storage

(Object, Block and Archival)

Infrastructure Availability

Zones

Points of Presence Regions

Enterprise Applications Business

Email Sharing &

Collaboration Virtual

Desktop

Technical &

Business Support Account

Management Partner

Ecosystem Professional

Services

Security &

Pricing Reports Solutions

Architects

Support Training &

Certification

Service Breadth & Depth

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

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

Customers

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

Authorize access

Analyze User Behavior

Store and share media

Synchronize data

AWS Mobile SDK

Amazon Mobile Analytics

Deliver media

Amazon Cognito (Sync)

AWS Identity and Access Management

Amazon Cognito

(Identity Broker) ^{Amazon S3} Transfer Manager

Amazon CloudFront (Device Detection)

Store shared data

Amazon DynamoDB (Object Mapper)

Stream real-time data

Amazon Kinesis (Recorder)

Run Business Logic

AWS Lambda

Send push notifications

Amazon SNS Mobile Push

Your Mobile

App

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

effective to efficiently analyze all your data using your

existing business intelligence tools

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

Introduction: AWS Security and Compliance in the Public Sector

Dob Todorov

The Economics of Cloud Security

Cost of Security on Premises / Hosted Facility

CapEx OpEx

Technology

(Physical Security, Infrastructure, Power, Networking)

£££££ £££

Processes

(standards, procedures, guidelines, assurance, compliance)

£££ ££

People

(hire, upskill, compensate,

train, manage)

££ ££££

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

CapEx OpEx

Technology

(Physical Security, Infrastructure, Power, Networking)

- -

Processes

(standards, procedures, guidelines, assurance, compliance)

- -

People

(hire, upskill, compensate,

train, manage) - -

Infrastructure secure & compliant at no extra cost

AWS Cloud

Advanced Persistent Threats and Cloud

Connection Table

Infrastructure Attack (Layer 3 / 4) Examples

• SYN Flood ^• UDP (NTP) Amplification Flood

SYN

ACK SYN/ACK

Attacker 192.0.2.1

Victim

198.51.100.4

src=198.51.100.4 dst=203.0.113.32

NTP DNS SNMP SSDP

Reflectors (NTP servers) 203.0.113.32

X



Asymmetric attacks that use amplification & rely upon depletion of limited resources

Architecture for HTTP Flood

ELB

security group

DMZ public subnet CloudFront

Edge Location

security group

WAF / Proxy private subnet DDoS

users

WAF

Auto Scaling

ELB

security group

Auto Scaling

security group

frontend servers private subnet

web app server

Elastic resources cannot be depleted.

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

Cloud Security Guidance from CESG for G-Cloud and AWS Security

Paavan Mistry

Rob Whitmore

Background and context

• Change from GPMS to GSCP

• Publication of Cloud Security Principles

• Buyer ownership of risks associated with OFFICIAL workloads

Inf o rmed Ri s k A s s e s s m e n ts

• Shift from central accreditation model for IL2/IL3

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

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 & content

C u s to m e 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

14 Essential Principles

of the Cloud Security Guidance by CESG

The Cloud Security Guidance published by CESG lists 14 essential principles to consider when evaluating cloud services, and why these may be important to the public sector organisation.

Cloud service users should decide which of the principles are important, and

how much (if any) assurance the users require in the implementation of these

principles.

14 Essential Principles of the Cloud Security Guidance by CESG

• Principle 1 – Data in transit protection

• Principle 2 – Asset protection and resilience

• Principle 3 – Separation between consumers

• Principle 4 – Governance framework

• Principle 5 – Operational security

• Principle 6 – Personnel security

• Principle 7 – Secure development

• Principle 8 – Supply chain security

• Principle 9 – Secure consumer management

• Principle 10 – Identity and authentication

• Principle 11 – External interface protection

• Principle 12 – Secure service administration

• Principle 13 – Audit information provision to consumers

• Principle 14 – Secure use of the service by the consumer

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

– Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon EMR, Elastic Load

Balancing

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.

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/

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

Toolset for Cloud Security Principles on AWS

Dave Walker – Specialised Solutions Architect Security/Compliance

Amazon Web Services UK Ltd 18^th June 2015

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

• Amazon S3

– Integration using SafeNet KeySecure on EC2

– White paper at http://www2.safenet-inc.com/AWS-

guides/SafeNetKMIP_AmazonS3_IntegrationGuide.pdf

• Amazon EBS and Amazon 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

• Amazon 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

• Amazon 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:

– Amazon EBS: LUN segregation

– Amazon 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:

– Amazon 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

• 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)

SAML to AWS Management Console

console

federation IDP

2) SAML SSO

Assertion

X.509 certificate Bound to PrincipalArn

federation SP

SAML to AWS (API)

federation IDP

1) authentication

Assertion

2) authn, attributes 3) assertion

federation SP

STS

RoleArn PrincipalArn ST credentials

ST credentials

Identity and Access Management: Authorisation

• Least Privilege

– Fine-grained permissions

• Eg Amazon 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 Amazon EC2 instances)

• Permission Grants can be constrained by:

– User, Group, Role (naturally!) – Source IP address(es), subnet – Time of day

– Use of MFA token

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 UsageStar

tDate UsageEn

dDate UsageQua

ntity Currenc

yCode CostBef oreTax Cre

dits TaxAm ount TaxT

ype TotalCo st

$0.000 per GB - regional data transfer under the

monthly global free tier 01.04.14

00:00 30.04.14

23:59 0.0000067

5 USD 0.00 0.0 0.0000

00 None 0.0000 00

$0.05 per GB-month of provisioned storage - US

West (Oregon) 01.04.14

00:00 30.04.14

23:59 1.126.666.

554 USD 0.56 0.0 0.0000

00 None 0.5600 00 First 1,000,000 Amazon SNS API Requests per

month are free 01.04.14

00:00 30.04.14

23:59 10.0 USD 0.00 0.0 0.0000

00 None 0.0000 00 First 1,000,000 Amazon SQS Requests per month

are free 01.04.14

00:00 30.04.14

23:59 4153.0 USD 0.00 0.0 0.0000

00 None 0.0000 00

$0.00 per GB - EU (Ireland) data transfer from US

West (Northern California) 01.04.14

00:00 30.04.14

23:59 0.0000329

2 USD 0.00 0.0 0.0000

00 None 0.0000 00

$0.000 per GB - data transfer out under the monthly

global free tier 01.04.14

00:00 30.04.14

23:59 0.02311019 USD 0.00 0.0 0.0000

00 None 0.0000 00 First 1,000,000 Amazon SNS API Requests per

month are free 01.04.14

00:00 30.04.14

23:59 88.0 USD 0.00 0.0 0.0000

00 None 0.0000 00

$0.000 per GB - data transfer out under the monthly

global free tier 01.04.14

00:00 30.04.14

23:59 3.3E-7 USD 0.00 0.0 0.0000

00 None 0.0000 00

AWS CloudTrail

AWS 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

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

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

Continuous Change Recording

Changing Resources

AWS ^Config

History

Stream

Snapshot (ex. 2014-11-05) AWS Config

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 EBS Volumes

AWS CloudTrail Log

Amazon VPC

VPC, Subnet...

Resources

Resource Type Resource

Amazon EC2 EC2 Instance

EC2 Elastic IP (VPC only) EC2 Security Group

EC2 Network Interface

Amazon EBS EBS Volume

Amazon VPC VPCs

Network ACLs Route Table Subnet

VPN Connection Internet Gateway Customer Gateway VPN Gateway

AWS CloudTrail 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

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 How the resource is related to other resources associated with the

account

EBS volume vol-1234567 is attached to an EC2 instance i- a1b2c3d4

Current Configuration Information returned through a call to the Describe or List API of the resource

e.g. for EBS Volume

State of DeleteOnTermination flag Type of volume. For example, gp2, io1, or standard

Related Events The AWS CloudTrail events that are related to the current configuration of the resource

AWS CloudTrail event ID

Configuration Item

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

• Generated on demand, can be exported to

Amazon S3

Snapshot @ 2014-11-05, 11:30pm

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

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

Monitoring: Get consistent visibility of logs

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

Thank you for attending!

We look forward to seeing you at our next AWS Government Day On the 8

^th

of December, 2015

at 60 Holborn Viaduct | London EC1A 2FD | United Kingdom Register here

Places are Limited.

Participants will be able to engage in security deep dive sessions with AWS Security Solutions Architects within the UK Public Sector, learn about security services and implementation approaches by AWS partners, as well as hear from the AWS Security Assurance teams on current

and upcoming initiatives.