aws re:invent 2016: hackproof your cloud: responding to 2016 threats (sac308)

28
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Aaron Newman, CloudCheckr November 29, 2016 SAC308 Hackproof Your Cloud Responding to 2016 Threats

Upload: amazon-web-services

Post on 06-Jan-2017

170 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Aaron Newman, CloudCheckr

November 29, 2016

SAC308

Hackproof Your CloudResponding to 2016 Threats

Page 2: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

What to expect from the session

• Reevaluate:

• Your perspective as you move to the cloud/scale up

• Intrusion detection, activity monitoring and vulnerability

assessment in AWS

• Gain a better understanding of:

• How to better leverage native AWS services

• Perimeter assessments of your VPCs

• Internal vs. external threats

• Monitoring threats

Page 3: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Changing your perspectiveMoving to the cloud = rethinking your perimeter security

How do I secure my business applications on AWS?

Rethink how you perform most security tasks:

• Network-based IPS/IDS

• Network scanning

• Penetration tests

• Vulnerability assessments

Focus on securing cloud workloads

• Not on securing the cloud

Page 4: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

In the data center

Setting up perimeter security:

• Setting up your infrastructure

• Setting up access points to the Internet

• Configuring firewall, IDS, IPS, etc. at the access points

Auditing your perimeter security:

• Gather set of IP address blocks to poke at

• Do a port scan (using tools such as Nmap)

• Determine which ports are open on the target

• Try various exploits on the open ports.

• Sniff lots of packets

Page 5: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

AWS: What’s different?

The idea of physical security morphs as

infrastructure becomes virtualized by AWS APIs.

In a new world of ephemeral, autoscaling infrastructure,

you need to adapt your security architecture to meet

both compliance and security threats.

~ Physical assets secured at the AWS Availability Zone ~

~ Must guard the AWS API ~

~ IAM access is your new physical security ~

Page 6: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

AWS foundation services

Compute Storage Database Networking

AWS global infrastructureAvailability Zones

Regions

Edge locations

Network

security

Inventory

and config

Customer applications and content

You get to define

your controls IN

the cloud

AWS takes care

of the security

OF the cloud

You

AWS and you share responsibility for security

Data

security

Access

control

AWS

Page 7: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Minimizing attack vectors

Principles don’t change

• Reduce your surface area!

• Defense-in-depth

Some attack vectors don’t change

• Application level

• User-privilege escalation, web app vulns, XSS

• Operating system vulnerabilities

• Database vulnerabilities

Some attack vectors change

• Polymorphic targets/mapping

• Reduced network sniffing

Security hardening

Configure and

manage user

privileges

Remove unused

user accounts

Close unused

open network

ports

Enforce password complexity

and policies

Remove unwanted services

Patch all known

vulnerabil-ities

Page 8: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Give me your network block

• Nmap

• Port scans

• Ping sweeps

• Etc…

Perimeter assessments in the cloudHow do I assess the perimeter of my cloud?

Let me see your configuration

• List of publicly accessible

resources

• Security groups

• Routing tables, network ACL

• VPC, subnets

• Amazon S3 buckets and

permissions

• IAM policies

OLDWORLD

NEWWORLD

Page 9: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Virtual private clouds (VPCs)

Default VPC is created in every region

VPC is composed of:

• Internet and VPN gateways – connect to the rest of the world

• 1+ subnet(s)

• Routing table – how to move traffic around the VPC

• Network ACLs – a firewall but stateless

• Security groups – host-based firewall stateful

• Resources

• Amazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache

Page 10: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)
Page 11: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Network security in a VPC

Network ACLs• Network ACLs are stateless; responses to allowed inbound

traffic are subject to the rules for outbound traffic (and vice versa).

• Rules evaluated numerical ascending

• DENY can be overridden by ALLOW, watch for INEFFECTIVE rules

Security groups• Stateful – responses to allowed inbound traffic are not subjected

to the rules for outbound traffic

• Rules are cumulative – traffic is denied unless explicitly ALLOWed

• Assigning wrong security group to an instance exposes the entire VPC

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

Page 12: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Complex connections to Amazon EC2

•Legacy capability to run outside VPCs

•Instance ID: i-001bac39

•Friendly name (implemented as a tag): ISS-V2-API1

Run inside VPCs

• For example: 172.12.6.186

• This generates a DNS name ip-172-12-6-186.us-west-2.compute.internal

• For example: 52.24.201.167

• This generates a DNS name ec2-52-24-201-167.us-west-2.compute.amazonaws.com

Given 1 or more public IP addresses

• For example: 107.20.135.132

Attached to an Elastic IP address

Amazon EC2 instances can be:

Given 1 or more private IP addresses

Page 13: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Running VA in cloud environmentsHow do I run vulnerability assessments (VA)?

Stage 1:

Gather the list of

public IPs and Elastic

IP addresses of all

resources

Do I need to scan the

private IP addresses

and instances?

Stage 2:

Scanning an AMI

Spin up a new instance, run a scan on the new instance

Mark everything based on this AMI as “scanned”

Stage 3:

What about when an

instance “drifts” from

original AMI?

Someone can

reconfigure settings,

install new software

In an elastic, ephemeral, automatically scaling environment

clouds can have tens of thousands of instances

Page 14: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Patching strategies for operating systems

“No patch” strategy

• Stay away from patching live systems

• Focus on patching templates/AMIs

• Deliver patches by redeploying workloads

• Dependent on adopting pure cloud architectures

Look at AWS OS templates

Systematic workload reprovisioning

• Based on high-assurance repositories

• Effective battling advanced persistent threats

Page 15: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

What are we missing?

Don’t assume attacks only happen against Amazon EC2

Over 80 different AWS services

• IAM authentication is centralized

• But services have unique authorization/access controls

You will have 100s of AWS accounts

We need a complete inventory

• All publicly accessible endpoints and resources

Security breaches can happen with a single weak link

Page 16: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Amazon RDS (Amazon Relational Database Service)

Only port Amazon RDS listens on is the database port • AWS limits access to database ports only

Publicly accessible option• Not a good idea, but if you do this

• Make sure you use security groups to restrict source IP address

• Make sure you have latest patches applied

Secure your database snapshots• Keys to the kingdom if someone can get a copy

• Encrypt your snapshots with KMS keys

• Brute-force passwords, restore to their own account

Page 17: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Amazon S3 (Amazon Simple Storage Service)

Up to 1,000 buckets in an account

Location

• Within a region, across Multi-AZs, not housed in a VPC

• Can’t sit between client and storage

Security

• Access control through IAM policies, bucket policies, ACLs, and query string authentication

• Server-side encryption, HTTPS support

• Server-access logs (does not integrate with AWS CloudTrail)

Don’t grant FULL_CONTROL, WRITE_ACP, WRITE bucket permissions to everyone EVER!

Create an inventory of your sensitive data

Page 18: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Amazon SQS (Amazon Simple Queue Service)

Where does SQS live?

• Within a region, not within a VPC

• Uses a URL such as: https://sqs.us-east-1.amazonaws.com/123456789012/MySQS

Page 19: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Amazon SNS (Amazon Simple Notification Service)

Amazon SNS does not live inside your VPC

Permissions based on topic policies:

Page 20: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Using AWS CloudTrail

An AWS service that records each time the AWS API is called

• Currently supports most AWS services

• http://docs.aws.amazon.com/awscloudtrail/latest/userguide/dochistory.html

Conveniently everything in AWS goes through the API

• Even actions in the AWS Management Console go through the API

AWS CloudTrail writes files into an Amazon S3 bucket

• Near real-time (every five minutes)

• Files are in JSON format

Get started at http://aws.amazon.com/cloudtrail/

Page 21: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Using Amazon CloudWatch Logs

Simple method of monitoring operating system logs• Ship Windows event logs and syslogs to Amazon CloudWatch

Integration from CloudTrail into CloudWatch Logs system logs• With alerting capabilities

Types of use-case:• Account login failure, account login success, new local account creation,

excessive login failure (configurable)

• Unauthorized Windows admin logon, Windows account lockout attempt,

Windows computer account changes

• Windows audit policy changes, Windows event log cleared

• Account locked out, changes to system or audit log

Get started at:

http://docs.aws.amazon.com/AmazonCloudWatch/latest/

DeveloperGuide/WhatIsCloudWatchLogs.html

Page 22: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Using Amazon VPC Flow Logs

An AWS service that records each time packets enter or leave a VPC

• http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html

Security team comes to you and says:

• We need logs going to instance 1-0123456 from

IP address ranges 52.205.16.0 - 52.205.31.255

Monitor for DENY connections

• Gives you both security group and network ACL denies

Announcement:https://aws.amazon.com/about-aws/whats-new/2015/06/

aws-launches-amazon-vpc-flow-logs/

Page 23: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Tools for configuring AWS security and cost

Generic tools fall short

Purpose-built, not cloud-washed

• Make sure tools don’t fall over in the cloud

• Tools have to understand dynamic, ephemeral IPs

Need a deep understanding of AWS

• What does this means

• Context is important

• Actionable intelligence

Page 24: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Leveraging AWS data – AWS CloudTrail, AWS Config, VPC

Flow Logs, Amazon CloudWatch Logs, DBR, and more metrics

Providing complete transparency – into 1 or across 1000s

of AWS accounts

Automating security, configuration, and activity monitoring

and alerting

Continuous monitoring of configurations, resources and

permissions

Active optimization, sophisticated allocation, and simplified

invoicing for enterprise cloud cost management

Monitoring, reporting, and optimization Enterprise security and cost management from CloudCheckr

Page 25: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Questions?

Page 26: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Thank you!

Aaron Newman

CEO & Founder of CloudCheckr

[email protected]

www.cloudcheckr.com

Page 27: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Remember to complete

your evaluations!

Page 28: AWS re:Invent 2016: Hackproof Your Cloud: Responding to 2016 Threats (SAC308)

Related sessions

http://www.quantum.com/