Look Ma No Hands: Automating Security the RightScale way. Patrick McClory Solutions Architect, RightScale

Transcription

1 1 Look Ma No Hands: Automating Security the RightScale way Patrick McClory Solutions Architect, RightScale

2 2 # Biggest real risks to data in the cloud? The same things as when your data were not in the cloud. Poor application security leading to Injection Poor system configurations, leading to system compromised Poor application configuration leading to application compromise Poor user habits leading to compromised credentials, that are then used to access data 2012 Verizon Data Breach Report

3 3 # Industry Group Breakdown 2012 Verizon Data Breach Report

4 4 # Reasons for Malicious Activity 2012 Verizon Data Breach Report

5 5 # Top 10 Threats 2012 Verizon Data Breach Report

6 6 # Creating a list of solid recommendations gets progressively more difficult every year we publish this report. Think about it; our findings shift and evolve over time but rarely are they completely new or unexpected. Why would it be any different for recommendations based on those findings? Sure, we could wing it and prattle off a lengthy list of to-dos to meet a quota but we figure you can get that elsewhere Verizon Data Breach Report

7 7 # 2012 Verizon Data Breach Report

8 8 # Common data exposure vectors in the cloud Data is typically exposed in the following three states: In Transit At Rest In Process

9 9 # We must protect data In Transit Why? Risk You do not want the bad guys to see or modify your data You can t guarantee the path your data will take You may have regulatory or contractual requirements to do so Sniffing along the path Modification of existing data Injection of new data Map of Internet Traffic Common Solutions Application Transport (SSL & TLS) VPN (SSL, IPSEC, PPTP, L2TP) App level data encryption (custom)

10 10 # We must protect data At Rest Why? Same as previous: You do not want unauthorized Disclosure Modification Injection Risks Intrusion into Instance/Guest exposes data on its filesystem Cloud provider access to ephemeral storage (e.g., EBS, SWIFT) Cloud provider access to other storage options (e.g., S3, CloudFiles) Common Solutions Protection offered by running operating system (Access Control Lists) *Encryption (and Key Management)* SLA and Policies/Processes of the Cloud provider

11 11 # We must protect data while In Process Why? Same as previous: You do not want unauthorized Risk Disclosure Modification Injection Data is in clear in the memory of the Instance Privileged users on a system can read memory Hypervisor has access to instance memory Common Solutions Protect the system that is processing Protect the hypervisor running the Instance Limit administrative users

12 12 # Philosophy and musings Let's take "cloud" out of it for a moment Just Good Enough Security Figure out what Secure is for you Best Practice is a red herring Standard Practice is something to consider

13 13 # 2012 Verizon Data Breach Report

14 14 # What is security automation? When I use a word, it means just what I choose it to meanneither more nor less. Humpty Dumpty So for our purposes today, automating security is about: Building instances that meet your definition of security Identifying vulnerabilities on running instances Patching those vulnerabilities

15 15 # Some Compliance References Baseline Requirements HIPAA: 45 CFR (a)(4)* ISO 27001: A , A PCI: 6.4 NIST SP800-53: CM-2, SA-2, SA-4 Vulnerability and Patch Management HIPAA: 45 CFR (a)(1)(i)(ii)(a) & (B), (5)(i)(ii)(B) ISO 27001: A , A , A PCI: 2.2, 6.1, 6.2, 6.3.2, 6.4.5, 6.5.X, 6.6, 11.2 NIST SP800-53: CM-3, CM-4, CP-10, RA-5, SA-7, SI-1, SI-2, SI-5

16 16 # Building instances that are secure Starts with application design You need to know what the systems will do, so you can build them accordingly Think about: What requirements for data in transit? What requirements for data at rest? What requirements for data in process? What services will be exposed to untrusted parties? What services will be exposed to trusted parties? What services are only used internally?

17 17 # More on how design affects OpSec What requirements for data in transit? How do you handle the key material for SSL/TLS or data encryption? Store it in on filesystem or in memory? What requirements for data at rest? Do you need runtime at reset security or off-line? If in a database, will/can you use the database security or do you have to do it at the application? If at the application layer, how do you manage keys? What requirements for data in process? Do you have to protect the data in memory/process? This requires some HEAVY lifting and technology choices

18 18 # More on how design affects OpSec What services will be exposed to untrusted parties? Will require diligence in patching and vulnerability management What services will be exposed to trusted parties? Likely less aggressive vulnerability management Monitoring: Trust but verify? What services are only used internally? In reality will require less diligence

19 19 # What you should have out of design Services/Applications that will be run on what instances OS types Applications to be used Network and applications Flows Ports, Protocols, and Directions Roles that are required

20 20 # Where RightScale shines RightScale can be used to ensure that poor system and application configurations are not what cause you to lose your data Use RightScale to: Require data to be transmitted securely Require data be stored securely Ensure systems are appropriately patched and configured to minimize exposures The core technologies are RightImages ServerTemplates RightScripts Repo s and Mirrors Security Motto: Build it secure, keep it secure!

21 21 # Hierarchy of assets ServerTemplate Application Server for IIS, Database Manager for MySQL RightScripts and Operational assets belong to this object Contains one or many Multi-Cloud Images MultiCloud Images Windows 2008r2 with IIS 7.5, Centos 6 Encapsulates many machine images of like configuration Provides a consistent experience across multiple cloud vendors Contains one or many Images/Machine Images Image Amazon AMI, Azure VHD, etc. Lowest level of objects. Represents one machine configuration in one cloud Occasionaly, Cloud-specific idiosyncrasies are managed at this level

22 22 # Build it Secure What Use Trusted Images Known Configurations Script the install and configuration Trusted Repository How Start with Multi-Cloud Images Build with ServerTemplates Modify with RightScripts Build from Frozen Repos

23 23 # Step 1: Standard images RightImages are the only ones we can vouch for Amazon has tons of available images, but we can t vouch for them Any RightScale Publisher would be a good choice An ISV based image is likely OK, but we typically do not vet them Work with professional services for specific cases/needs In reality, you should start with ServerTemplates (next) as they will have selected vetted images already

24 24 # Step 2: ServerTemplates Dynamic configuration Abstract role and behavior from cloud infrastructure Predictable deployment Cloud agnostic / portable Object-oriented programming for sysadmins

25 boot sequence 25 # Step 2: ServerTemplates (con t) Configuring servers through bundling images: Custom MySQL (CentOS 5.2) Custom MySQL (CentOS 5.4) MySQL (CentOS 5.4) MySQL (Ubuntu 8.10) MySQL (Ubuntu 8.10) 64bit Frontend Apache 1.3 (Ubuntu 8.10) Frontend Apache 2.0 (Ubuntu 9.10) - patched CMS v1.0 (CentOS 5.4) CMS v1.1 (CentOS 5.4) Configuring servers with ServerTemplates: Setup DNS and IPs A set Restore of configuration last backup directives that will install and configure Configure software MySQL on top of the base image Install MySQL Server Install monitoring My ASP appserver (windows 2008) My ASP.net (windows 2008) security update 1 My ASP.net (windows 2008) security update 8 SharePoint v4 (windows 2003) 32bit SharePoint v4 (windows 2003) 64bit SharePoint v4.5 (windows 2003) 64bit CentOS 5.2 CentOS 5.4 Base Image MultiCloudImage Very few and basic Ubuntu 8.10 Ubuntu 9.10 Win 2003 Win 2007

26 26 # ServerTemplates VS. Integrated approach that puts together all the parts needed to architect single & multi-server deployments

27 27 # Step 2.x: RightScripts RightScript is a mechanism to configure instances at boot time and to run additional scripts during the lifetime of an instance A RightScript is an executable piece of code that can be run on a server A RightScript consists of: A script (typically written in Bash, Ruby, Perl, PowerShell, and now Chef) A set of attachments that are downloaded from a storage location (e.g., S3) A set of packages that are installed using the system's package manager A set of input parameters that must be passed into the script On ServerTemplates Scripts or Recipe /var/cache/rightscale/

28 28 # Important tangent: Logging and Auditing Use ServerTemplates and RightScripts to integrate your logs into your enterprise SIEM Look to a ISV s or 3rd party SaaS SEM aggregator Not for the faint of heart!

29 29 # Step 3: Identifying vulnerabilities Out of scope of the RightScale core platform Can roll your own or use ISV s to help with this Activities Port and services scans Validate implementation meets design Nmap or typically included in Vulnerability scans Vulnerability scans SaaS services: CloudPassage*, SAINT, Rapid7, Qualys, Nessus, Build your own: SAINT, Rapid7, Qualys, Nessus, OpenVAS Application testing SaaS services are a good start: Whitehat, Vericode, HP, Manual testing is a must*: Whitehat, SystemExperts, Matasano, Aspect, * Breaks the automating part of the talk

30 30 # Step 4: Patching What Update the Operating System Update the applications Validate the configuration How You can use the same mechanism as in your enterprise *OR* Use operational RightScripts to do it for you *OR* Use a partner ISV that specializes in that service

31 31 # Patching Input form vulnerability management should drive this Apply the security updates Option 1: Apply to staging systems and run all your regression tests, then roll out Option 2: Apply directly to production systems after a cooling off period Option 3: Apply to a canary production system, wait 24 hrs, then apply en-masse Option 4: Apply directly to production systems as soon as they are released A couple points Security patches are typically well tested before released Applies well to Ubuntu, Windows, and RHEL Not so well to CentOS Upgrading the kernel is a bit touchier pvgrub is your friend

32 32 # Ubuntu Security Patching Ubuntu supports a security specific repo Need to use RightScripts attached to ServerTemplates that points security repo to latest Change the repost to point to latest sed -i "s%ubuntu_daily/.* $(lsb_release -cs)-security%ubuntu_daily/latest $(lsb_release - cs)-security%" /etc/apt/sources.list.d/rightscale.sources.list Update the list apt-get update to Update the software list Apply the updates Pin what you don t want to upgrade: /etc/apt/preferences.d/00rightscale Upgrade what you do: apt-get upgrade You need to decide if you want global updates or specific packages s

33 33 # CentOS Security Patching CentOS does not have a security specific repo Our CentOS /major repo now mirror the current is a mirror of the /5.x (i.e. latest) repo on that day Update repos to point to latest Update /etc/yum.repos.d to point to the /major version # Change /major.minor format Repo URLS to /major format sed -ri 's%centos/5.[0-9]%centos/5%' /etc/yum.repos.d/centos-*.repo # set latest or frozen date sed -ri 's/archive\/[0-9]*/archive\/latest/' /etc/yum.repos.d/centos-*.repo sed -ri 's/archive\/([0-9]* latest)/archive\/ /g' /etc/yum.repos.d/centos-*.repo Update the list yum check-update ( grep updates) Apply the updates (to specific packages)

34 34 # Security ISV s to consider (alphabetical) Centrify Account controls integration with Active Directory CloudPassage Vulnerability management Security event monitoring Firewall management TrendMicro Secure data at rest

35 35 # Recap Design it properly Build it to spec with RightImages, ServerTemplates, and RightScripts Validate configurations and identify vulnerabilities with tools Monitor with appropriate tools Patch systems ISV s are your friend!

36 36 # Crystal Ball Things that will help in the automation category NIST Security Content Automation Protocol (SCAP) Common Configuration Enumeration (CCE) Common Platform Enumeration (CPE) Common Vulnerabilities and Exposures (CVE) Common Vulnerability Scoring System (CVSS) Open Vulnerability and Assessment Language (OVAL) Extensible Configuration Checklist Description Format (XCCDF) CloudAudit (Cloud Security Alliance) Policy and attestation

37 37 # My Info patrick@rightscale.com W (mobile) Skype: patrick.mcclory.rs Twitter: patrickatrs Linked-In: Patrick McClory

38 38 # Questions? Comments?