Auto-Scaling Web Application Security in Amazon Web Services (SEC308) | AWS re:Invent 2013


Published on

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

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Auto-Scaling Web Application Security in Amazon Web Services (SEC308) | AWS re:Invent 2013

  1. 1. 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
  2. 2. Spring 2013 Report 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 1,800+ Customers Environments 2 Years of Threat Data Published 150k+ Security Incidents Analyzed
  3. 3. Cloud Provider Selection Criteria
  4. 4. OWASP Top 10 Attacks Still Highly Pervasive Source: Whitehat Security
  5. 5. Common Web Attack Tools
  6. 6. 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 sql injection WAF reverse proxy legitimate traffic www server
  7. 7. What Makes a WAF Work? Blacklisting Whitelisting • Filter known attacks • All requests allowed by default, unless explicitly denied • Provides immediate baseline security • Dynamic analysis of web application • Allow wanted transactions • Everything else is denied • Implicit security against new or unknown attacks (Zero Day Attacks) Necessary fundamental Flexible adaptive model model that provides rulethat enhances security based protection beyond well-known threats
  8. 8. 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
  9. 9. Common Web Tier Auto Scaling Tools • Elastic Load Balancing Auto Scaling groups • Health monitoring – Amazon CloudWatch • Bootstrapping/configuration automation – AWS CloudFormation – Chef/Puppet/Cfengine
  10. 10. Why Auto-Scaling a WAF is Difficult • WAF Appliances CDN WAFs • • • • • significant capital investment difficult to maintain & tune invasive deployment model “one size fits all” latency limited protection • Native support not available for autoscaling capabilities. • “Learned” data not easily shared across appliances • Management and processing planes are too tightly coupled
  11. 11. Our Approach to Auto Scaling Web Security Worker Worker Browser Alert Logic ELB - Public ELB - Public Worker Worker WSM Worker WSM Master ELB - Internal Worker Worker Web server S3/EBS • 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
  12. 12. Deployment for Auto Scaling and High Availability in AWS VPC Amazon Web Services 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
  13. 13. Live Demo
  14. 14. Web Traffic Flow • Browser clients connect to worker load balancer • Traffic is load balanced to WSM appliances • WSM appliances connect to backend load balancer
  15. 15. 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
  16. 16. 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
  17. 17. Configuration Data Flow Web Services Configuration Data • Master instance stores data in Amazon S3 • Worker instances retrieve configuration Redundancy • Configuration also transmitted to Alert Logic
  18. 18. 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
  19. 19. Default Auto Scaling Parameters • Defaults set in AWS CloudFormation templates • User configurable and tunable for specific requirements
  20. 20. Deployment Process Initial WSM stack created via AWS CloudFormation templates 1 2 Traffic gradually redirected after a testing period
  21. 21. 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
  22. 22. Building a Test WSM Stack with AWS CloudFormation Web Services 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
  23. 23. AWS Management Console 1 2 3
  24. 24. Command Line Example Use cfn-create-stack to start creation. $ 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 You can use cfn-describe-stack-events along with watch to view the stack creation. $ watch cfn-describe-stack-events test-backend Every 2.0s: cfn-describe-stack-events test-backend 2013 STACK_EVENT STACK_EVENT STACK_EVENT STACK_EVENT STACK_EVENT test-backend test-backend test-backend test-backend test-backend test-backend eipNAT2 eipNAT1 routeNAT2 routeNAT1 Mon Aug 12 08:23:44 AWS::CloudFormation::Stack AWS::EC2::EIP AWS::EC2::EIP AWS::EC2::Route AWS::EC2::Route 2013-08-12T13:24:20.321Z 2013-08-12T13:24:17.802Z 2013-08-12T13:24:17.769Z 2013-08-12T13:24:01.615Z 2013-08-12T13:24:01.144Z CREATE_COMPLETE CREATE_COMPLETE CREATE_COMPLETE CREATE_COMPLETE CREATE_COMPLETE 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=vpc591b9337;;routeTableNAT1=rtbe71b9389;routeTableNAT2=rtb-e61b9388;paramsForWSM=vpc=vpc-591b9337;;routeTableNAT1=rtb-e71b9389;routeTableNAT2=rtb-e71b9389;subnetPublic1=subnetfd1b9393;subnetPublic2=subnet-e21b938c 2013-08-12T13:21:51.116Z
  25. 25. Base WSM Stack Ready
  26. 26. Additional examples Multiple front end load balancers used to terminate SSL connections for separate web applications. Amazon VPC Availability Zone 1 Availability Zone 2 ELB Master ELB Workers Master Subnet Private Subnet Private Subnet WSM Master WSM Worker WSM Worker Application 1 Application 1 Application 2 Application 3 Application 2 Application 3
  27. 27. Next Steps Schedule a demo
  28. 28. Please give us your feedback on this presentation SEC308 As a thank you, we will select prize winners daily for completed surveys!