Embed Size (px)
DESCRIPTION
(Presented by Alert Logic) AWS provides multiple levels of security between the physical server and facilities up to the host operating system and virtualization layer. This session covers strategies for ensuring your applications, network, and data are secure in a highly-scalable environment. In this session, you receive practical guidance for implementing scalable web application security in the AWS cloud, including: -Common techniques and tools used to provide security for auto-scaling web applications including Chef/Puppet, AWS CloudFormation, and Elastic Load Balancing. -Using auto-scaling groups and requirements for management APIs in automatically deploying web security infrastructure. -Common scaling triggers and mechanisms by which web application security infrastructure must scale to operate in lockstep with elastic web server farms. -Approach for deploying application security controls embedded directly into web applications, and considerations for PaaS cloud environments. This session is designed for an advanced audience with strong understanding of IP networking, web application security fundamentals, and experience in managing security infrastructure in a public cloud environment; however, the information covered is also of interest to intermediate attendees that set technology strategy and formulate requirements for cloud security controls.
Citation preview
Auto-Scaling Web Application Security in
Amazon Web Services
Misha Govshteyn, Chief Strategy Officer & Co-Founder, AlertLogic
Zack Fox, Architect Web Security Manager, AlertLogic
November 14, 2013
Spring 2013 Report
1,800+ Customers Environments 2 Years of Threat Data Published 150k+ Security Incidents Analyzed
Key Findings
• Higher attack frequency in enterprise data centers than in cloud deployments
• Web applications are among Top 3 attack vectors in both enterprise and cloud environments
• Threats levels are consistent across industries and verticals
Full Report Available at alrt.co/Spring2013CSR
Cloud Provider Selection Criteria
3
OWASP Top 10 Attacks Still Highly Pervasive
Source: Whitehat Security
Common Web Attack Tools
Web Application Firewall Fundamentals
• Blocks common web application attacks
– SQL injection, cross-site scripting, command insertion
• Most commonly deployed inline as a reverse proxy
in front of web servers
browser WAF reverse proxy
www
server
legitimate
traffic sql
injection
What Makes a WAF Work?
Whitelisting
• Dynamic analysis of web application
• Allow wanted transactions
• Everything else is denied
• Implicit security against new or unknown attacks (Zero Day Attacks)
Blacklisting
• Filter known attacks
• All requests allowed by default, unless explicitly denied
• Provides immediate baseline security
Flexible adaptive model
that enhances security
beyond well-known threats
Necessary fundamental
model that provides rule-
based protection
Auto Scaling Principles
• Designed for failure
– Horizontally scaled
– Fast bootstrap
– Health/load conditions
as scaling triggers
• Loosely coupled
– Independent
components
– As stateless as
possible
– Minimal interactions
web tier is easiest to scale…
but good design decisions are essential
Common Web Tier Auto Scaling Tools
• Elastic Load Balancing Auto Scaling groups
• Health monitoring
– Amazon CloudWatch
• Bootstrapping/configuration automation
– AWS CloudFormation
– Chef/Puppet/Cfengine
Why Auto-Scaling a WAF is Difficult
• Native support not
available for auto-
scaling capabilities.
• “Learned” data not
easily shared across
appliances
• Management and
processing planes are
too tightly coupled
• significant capital
investment
• difficult to maintain &
tune
• invasive deployment
model
• “one size fits all”
• latency
• limited protection
WAF
Appliances
CDN WAFs
Our Approach to Auto Scaling Web Security
• Designed from the ground-up
for Elastic Load Balancing
integration
– Decoupled management and
data processing planes
– Amazon S3/Amazon EBS used
to maintain configuration/state
data and logs
– Assumes Amazon VPC
deployments
• Native support for auto-scaling
driven by CloudWatch metrics
ELB-Public
WSMMaster
ELB-Internal
ELB-Public
WorkerWorkerWSMWorker
WorkerWorkerBrowserAlertLogic
WorkerWorker
WebserverS3/EBS
Deployment for Auto Scaling and
High Availability in AWS VPC
Overview
• 1 Master AS group with 1 master at all times
• 1 Worker AS group with 2-n workers at all times
Elastic Load Balancing Master
• External interface for WSM Master
• Management and monitoring (https and ssh)
Elastic Load Balancing Worker
• SSL Termination
• Load balances web traffic to worker AS group
Amazon S3 Bucket
• Persists configuration data
NAT Instances
• Required for Amazon S3 access from private subnets
WSM Master
• Acts as management node for configuration
• Queues and transports logs, stats from workers
Amazon EBS Log Volume
• Persists Deny Log and Stats data for master
• Attached at instance start up
WSM Worker
• Retrieves configuration on instance launch
• Protects web traffic in front of internal load balancing
• Transports logs, stats to master queue
Amazon Web Services
Live Demo
Web Traffic Flow
• Browser clients connect to
worker load balancer
• Traffic is load balanced to
WSM appliances
• WSM appliances connect to
backend load balancer
Auto Scaling Options Auto Scaling Group Master
• Min-size 1
• Max-size 1
• Uses Elastic Load Balancing health
check to ensure an instance is up
• Will recreate itself from
configuration data in Amazon S3
Auto Scaling Group Worker
• Min-size 2 recommended for
availability
• Max-size TBD
• Uses Auto Scaling policy to scale
on-demand
Default Auto Scaling Parameters
• Defaults set in AWS CloudFormation templates
• User configurable and tunable for specific requirements
Setting Default
Scale up CPU utilization threshold 80%
Scale up when CPU is above threshold for more than 120 seconds
Scale down CPU utilization threshold 50%
Scale down when CPU is below threshold for more than 600 seconds
Configuration Data Flow
Configuration Data
• Master instance stores data in
Amazon S3
• Worker instances retrieve
configuration
Redundancy
• Configuration also transmitted
to Alert Logic
Web Services
Logs and Statistics Collection
Log Data
• Queued on Master for transport
Statistics Data
• Queued on Master for transport
• Aggregated for all workers before
transport
Alert Logic
• Data stored for search, correlation,
alerting, and reporting
Amazon EBS Log Volume
• Stores log and statistics data for
master instance
• Persists queued data in case of
master instance termination
Default Auto Scaling Parameters
• Defaults set in AWS CloudFormation templates
• User configurable and tunable for specific requirements
1
Deployment Process
Initial WSM
stack created
via AWS
CloudFormation
templates Traffic gradually
redirected after
a testing period
2
Sizing Examples
Master
Instance
Max
Workers
Throughput
Per Master
Worker
Instance
Throughput
Per Worker
m1.medium 10 250mbps m1.small 13mbps
m1.large 25 1gbps c1.medium 50mbps
c1.xlarge 200mps
Small Medium Large
Capacity 25mbps 200mbps 1.2gbps
Workers (2) m1.small (4) c1.medium (6) c1.xlarge
Building a Test WSM Stack
with AWS CloudFormation Basic testing stack in two Availability
Zones
• Amazon VPC
• Internet Gateway
• 2 public subnets
• 2 private subnets
• Public load balancer for test backend
web servers
• 2 NAT instances
• 2 web server instances
Additional AWS components are created
(not pictured):
• Amazon VPC gateway attachment
• Security groups
• Network ACL
• Routes and route tables
• Launch configuration and auto scaling
group
• CloudWatch alarms
• Auto Scaling policies
Web Services
AWS Management Console
1 2 3
Command Line Example
$ cfn-create-stack test-backend --template-file wsm-test-backend-only.cloudformation.template --parameters "sshKeyName=wsm-dev"
arn:aws:cloudformation:us-east-1:355864928133:stack/test-backend/26028db0-0352-11e3-895a-500162a66ca8
Use cfn-create-stack to start creation.
$ watch cfn-describe-stack-events test-backend Every 2.0s: cfn-describe-stack-events test-backend Mon Aug 12 08:23:44 2013 STACK_EVENT test-backend test-backend AWS::CloudFormation::Stack 2013-08-12T13:24:20.321Z CREATE_COMPLETE STACK_EVENT test-backend eipNAT2 AWS::EC2::EIP 2013-08-12T13:24:17.802Z CREATE_COMPLETE STACK_EVENT test-backend eipNAT1 AWS::EC2::EIP 2013-08-12T13:24:17.769Z CREATE_COMPLETE STACK_EVENT test-backend routeNAT2 AWS::EC2::Route 2013-08-12T13:24:01.615Z CREATE_COMPLETE STACK_EVENT test-backend routeNAT1 AWS::EC2::Route 2013-08-12T13:24:01.144Z CREATE_COMPLETE
You can use cfn-describe-stack-events along with watch to view the stack creation.
Once complete, cfn-describe-stacks will return the cloud formation stack outputs.
$ cfn-describe-stacks test-backend
STACK test-backend CREATE_COMPLETE Cloud Formation for Auto Scaling Alert Logic Web Security Manager vpc=vpc-
591b9337;elbBackend=test-back-elbBacke-17N275T20CGQ9-1608750954.us-east-1.elb.amazonaws.com;routeTableNAT1=rtb-
e71b9389;routeTableNAT2=rtb-e61b9388;paramsForWSM=vpc=vpc-591b9337;elbBackend=test-back-elbBacke-17N275T20CGQ9-
1608750954.us-east-1.elb.amazonaws.com;routeTableNAT1=rtb-e71b9389;routeTableNAT2=rtb-e71b9389;subnetPublic1=subnet-
fd1b9393;subnetPublic2=subnet-e21b938c 2013-08-12T13:21:51.116Z
Base WSM Stack Ready
Additional examples
Amazon VPC
Availability Zone 1
ELB Master
Availability Zone 2
Master Subnet
WSM Master
Private Subnet
WSM Worker
Application 1
ELB Workers
Application 2 Application 3
Private Subnet
WSM Worker
Application 1
Application 2 Application 3
Multiple front end load balancers used to terminate SSL connections for separate web
applications.
Next Steps Schedule a demo
http://alrt.co/AlertAWS
aws.amazon.com/marketplace/
Please give us your feedback on this
presentation
As a thank you, we will select prize
winners daily for completed surveys!
SEC308
