Auto-Scaling WebApplication Securityinthe Cloud Stephen Coty Chief Security Evangelist
Cloud Environments 101
Spring 2013 Report Key Findings Higher attack frequency in enterprise data centersthan in cloud deployments Web applications are among Top 3 attackvectorsin both enterprise and cloud environments Threats levels areconsistent across industriesand verticals Full Report Available atalrt.co/spring2013csr 1,800+Customers Environments 2 Yearsof Threat Data Published 150k+Security Incidents Analyzed
Threats in the Cloud are Increasing With Adoption Increase in attack frequency Brute force attacks and vulnerability scansarenow occurring at near-equivalent rates in both cloud and onpremisesenvironments Malware/Botnet is increasing year over year Traditional on-premises threats are moving to the cloud Majority of cloud incidents were related to web application attacks, brute force attacks, and vulnerability scans
Spring 2014 Report Cloudenvironments saw significant increases with brute force attacks climbing from 30% to 44% of customers, and vulnerability scans increasing from 27% to 44% Malware/botnet attacks, historically the most common attacks in the on-premises datacenter, are on the rise in CHPenvironments
Cloud Provider Selection Criteria
Security in the Cloud is a Shared Responsibility Apps Cloud Service Provider Responsibility Networks Software and virtual patching Access management Application level attack monitoring Configuration management Hosts Secure coding and best practices Hardened hypervisor System image library Root access for customer Access management Customer Patch management Configuration hardening Responsibility Security monitoring Log analysis Logical network segmentation Network threat detection Security monitoring Perimeter security services External DDoS, spoofing, and scanning prevented Foundation Services Compute Storage DB Network
OWASP Top 10 Attacks Still Highly Pervasive
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 legitimate browser WAF sql injection reverse reverse proxy proxy traffic www server
What Makes a WAF Work? Negative Security Positive Security Filter known attacks All requests allowed by default, unless explicitly denied Providesimmediatebaselinesecurity Dynamic analysis of web application Allow wanted transactions Everything else is denied Implicit security against new or unknownattacks(zero DayAttacks) Necessary fundamental model that provides Flexible adaptive model that enhances security rule-based protection beyond well-knownthreats
Auto Scaling Principles Designed for failure Loosely coupled Horizontally scaled Fastbootstrap Health/loadconditions as scalingtriggers web tier is easiest to scale but good design decisions are essential Independent components Asstateless as possible Minimal interactions
Common Web Tier Auto Scaling Tools ELB AutoScalinggroups Health monitoring CloudWatch Bootstrapping/configuration automation CloudFormation Chef/Puppet/Cfengine
WhyAuto-Scaling a WAF is Difficult WAF Appliances significantcapitalinvestment AWS semantics difficultto maintain &tune invasivedeployment model Unable to auto-scale using common No native support for ELB andcloudwatch CDN WAFs Learned data not easily shared across appliances onesizefitsall latency limitedprotection Management and processing planes are too tightly coupled
Approach to Auto Scaling Web Security Worker Worker Browser Alert Logic Designed from the ground-up for ELB integration Decoupled management and data processing planes S3/EBS used to maintain configuration/state data and logs ELB - Public Worker Worker WSM Worker ELB - Public WSM Master Assumes VPC deployments Native support for auto-scaling driven bycloudwatchmetrics ELB - Internal Worker Worker Web server S3/EBS
Deployment for Auto Scaling and HighAvailability 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 ELB Master External interface for WSM Master Management and monitoring (https andssh) ELB Worker SSL Termination Load balances web traffic to worker AS group S3 Bucket Persists configuration data NAT Instances Required for S3 access from private subnets WSM Master Acts as management node for configuration Queues and transports logs, stats from workers 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 ELB Transports logs, stats to master queue
Web Traffic Flow Browser clients connect to worker ELB Traffic is load balanced to WAF appliances WAF appliances connect to backend ELB
Auto Scaling Options Auto Scaling Group Master min-size 1 max-size 1 Uses ELB health check to ensure an instance is up Will recreate itself from configuration data in S3 Auto Scaling Group Worker min-size 2 recommended for availability max-size TBD Uses Auto Scaling policyto scale on demand
Default Auto-Scaling Parameters Defaults set incloudformationtemplates 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 S3 Worker instances retrieve configuration Redundancy Configuration also transmitted to Alert Logic
Logs and Statistics Collection Log Data Queued on Master for transport Statistics Data Queued on Master for transport Aggregated for all workers before transport Security Provider Data stored for search, correlation, alerting, and reporting 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 incloudformationtemplates User configurable and tunable for specific requirements
Deployment Process InitialWAFstack created viacloudformationtemplate s 1 2 Traffic gradually redirected after a testing period
Sizing Examples Master Instance Max Workers Throughput Worker Instance Per Master Throughput PerWorker 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 TestWAFStack withcloudformation Basic testing stack in twoavailability Zones VPC Internet Gateway 2 public subnets 2 private subnets Public ELB for test backend web servers 2 NAT instances 2 web server instances Additional AWS components are created (not pictured): VPC gateway attachment Security groups Network ACL Routes and route tables Launch configuration and auto scalinggroup Cloudwatchalarms Auto scaling policies
AWS Console 3 1 2
Command Line Example Usecfn-create-stackto start creation. $cfn-create-stack test-backend --template-filewsm-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 usecfn-describe-stack-eventsalong with watch to view the stack creation. $watchcfn-describe-stack-eventstest-backend Every2.0s:cfn-describe-stack-events test-backendmonaug 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.144ZCREATE_COMPLETE Once complete,cfn-describe-stackswill 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 Managervpc=vpc-591b9337;elbBackend=test-back-elbBacke-17N275T20CGQ9-1608750954.us-east1.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=rtbe71b9389;routeTableNAT2=rtb-e71b9389;subnetPublic1=subnet-fd1b9393;subnetPublic2=subnet-e21b938c 2013-08-12T13:21:51.116Z
BaseWSM Stack Ready
Additional examples Multiple front end ELBs used to terminate SSL connections for separate web applications. VPC VPC Availability Availability Zone Zone 1 1 Availability Availability Zone Zone 2 2 ELB ELB Master Master Master Master Subnet Subnet WAF WAF Master Master ELB ELB Workers Workers Private Private Subnet Subnet Private Private Subnet Subnet WAF WAF Worker Worker WAF WAF Worker Worker Application Application 1 1 Application Application 1 1 Application Application 2 2 Application Application 3 3 Application Application 2 2 Application Application 3 3
Thank You Q&A Email:scoty@alertlogic.com Twitter: @StephenCoty Blog:www.alertlogic.com/resources/blog