Business In the Cloud. Mitigating Risk. Fred Pinkett VP of Product Management Security Innovation

Transcription

1 Business In the Cloud Mitigating Risk Fred Pinkett VP of Product Management Security Innovation

2 About Security Innovation Application & Crypto Security Experts 10+ years research on vulnerabilities and cryptography Hundreds of assessments on world s most dominant software applications Products, Services & Training Software & SDLC Assessment elearning & Coding Standards High-Performance Data Encryption Helping organizations Build internal application security expertise Integrate security into their development process Reduce vulnerabilities and IT/data risk

3 Security Innovation Credentials Authors of 8 Books & Guides - How To Break Software Security - How to Break Web Software - The Software Vulnerability Guide - How To Break Software - Team Development with VSTS - Improving Web Services Security - Application Architecture Guide Security Engineering Explained Our roots are in Security Education Spin-off of Florida Institute of Technology (2002) One of three universities at the time with an application testing degree program and first to introduce a minor in software security Real-world, vetted content Techniques based on assessment of the world s most dominant software: Microsoft, Amazon.com, Symantec, Orbitz.com, B&N.com, Adobe, Akamai Industry s Largest Library of elearning Courses 40+ courses and 85+ hours of total content 100,000+ users

4 Agenda Pros and Cons of Cloud Computing Security Controls & Building a Secure System Redundancy We Still Need to Think About This? The Murky Waters of Compliance Service Level Agreements Conclusion

5 Pros & Cons of Cloud Computing Early days: buy one or many very large servers Pros: You own hardware/infrastructure; you know how it works (probably) Cons: You deal with hardware failure and build for peak load (may only happen once per year); very costly, slow to react Today there are lots of *aas models Software as a Service Platform as a Service Infrastructure as a Service and security means a lot of *aas holes

6 Pros & Cons of Cloud Computing Today s Cloud: pay for space, bandwidth, processing time (similar to time-sharing servers, but exponentially bigger) Pros: pay for what you need, instant and reactive scaling, many options for "going into the cloud, no more failover headaches Cons: You have no idea where your data is; Compliance issues, New Vulnerability Classes, Trust issues Security in the Cloud: You Are Still Responsible If your organization wasn t good at security, cloud can help you improve but it is not a silver bullet. Beware a false sense of security. If you organization was good at security, cloud can bring you backwards unknowingly. Understand and deal with regressions. Best protection is the SLA and how you build/deploy applications

7 Pros & Cons of Cloud Computing - Trust Amazon Elastic Compute Cloud (EC2) Failure Case Study EC2 is a web service that allows developers to obtain and configure capacity with minimal friction Affected EC2 customers primarily were in a subset of the Amazon Elastic Block Store ( EBS ) volumes on the US East Coast caused by several root causes interacting with one another, triggered by a network configuration change while upgrading instances trying to use these affected volumes got stuck when they attempted to read or write to them. In order to restore these volumes, Amazon disabled all control in the affected Availability Zone caused high error rates and latencies for EBS calls to these APIs across the entire US East Region. Failure cascaded up the stack.

8 Agenda Pros and Cons of Cloud Computing Security Controls & Building a Secure System Redundancy We Still Need to Think About This? The Murky Waters of Compliance Service Level Agreements Conclusion

9 Cloud Security Security can be improved or reduced by going into the Cloud Need to consider things like loss of control, data flow, insight into how the cloud infrastructure is designed, etc. Mitigating risk by transferring it; but can the recipient can provide necessary protections/assurance Amalgam of IDS, Firewalls, IPS and other security controls provided by cloud vendor good, but. Miss the majority of attacks and security vulnerabilities Ineffective when applications must be internet facing The truth is that security is generally a software problem With internet applications, software becomes the perimeter Between 70-92%* of security vulnerabilities exist in the application layer * source: Gartner Group and NIST

10 Building a Secure System: Locking Down Legacy Applications External Penetration Testing Access Control Review and update Recommendations Replacement If the application cannot be secured and provides key functionality Abandonment If the application cannot be secured and the functionality can be provided by another asset Isolation if the application cannot be secured, is critical and there s no alternative asset

11 Building a Secure System Securing New Applications Software Development Process Review Introduce secure best practices where needed Modify implemented practices where needed Software Requirements and Code Reviews Inline with development, constant feedback Security testing as part of the normal test plan Penetration Testing External (Outside in) Internal (Cross network)

12 Building a Secure System Under-leveraged, Powerful Risk Techniques Attack Surface Analysis and Reduction The entire collection of entry points is known as it s Attack Surface Helps prevent vulnerabilities you don t know about yet Real measure of risk in your application: Fewer doors (entry points) there are, generally there is lower risk Big Attack Surface = Big Security Work = Big Security Problems Threat Modeling Secure software starts with identifying most critical threats and risks Based on understanding an assets value and cost of exploitation Can be done at the individual application or system level Threats are not vulnerabilities: they live forever and are attackers goal

13 Building a Secure System Security Controls Secure in Isolation If a component is isolated though failure or malicious actions it should behave appropriately Secure (Defense) in Depth Multiple layers of defense Defense at all layers of the stack (from your provider and in your application) Secure in Failure If (When!) something goes down or is compromised, there should be forensic information but not sensitive information Test your controls early and often

14 Agenda Pros and Cons of Cloud Computing Security Controls & Building a Secure System Redundancy The Murky Waters of Compliance Service Level Agreements Conclusion

15 Application Redundancy & CIA Availability is the most straightforward to achieve Think up time Although no simple task, it is much easier than protecting confidentiality and integrity Typical attacks based on bad data input in effort to choke the application Requires strict data input rules as guidelines for validation Confidentiality & Integrity Confidentiality: ensure that only intended users can access information Integrity: ensure source of data and that it has not been altered in transit Both require strong authentication that allows the system to validate a true identity and authorization

16 Redundancy: We Still Need to Think About This? Ask Amazon s Customers Those that had a secondary service provider or replicated across mutiple Amazon availability zones continued Going Cloud an Opportunity for Redundant Redundancy Across providers, provider s geographic areas, etc. If You Lose Service You Get Fees Back, Not the Business We ll talk SLA s shortly Consider Insurance

17 Redundancy: We Still Need to Think About This? Where are your points of failure? DNS Load Balancer Data Storage Components are constantly failing and in flux, we need to Understand it Plan for it Make our failure transparent to our users

18 Redundancy Netflix Chaos Monkey Case Study Netflix has its infrastructure on the Amazon cloud Has to work within the limits of what Amazon provides: a highly automated set of capabilities across an elastic and regular infrastructure Chaos Monkey ensures that individual components work independently and return something when dependencies aren t responding Script that randomly kills instances and services Brings down production servers at random points during the day when developers are around, just in case things go wrong Designing applications in the cloud means designing for failure Avoid single points of failure Distributing activity across multiple nodes in multiple data centers so that if parts of the infrastructure fail, the applications continue to run

19 Agenda Pros and Cons of Cloud Computing Security Controls & Building a Secure System Redundancy We Still Need to Think About This? The Murky Waters of Compliance Service Level Agreements Conclusion

20 The Murky Waters of Compliance PCI-DSS PCI Responsibilities for Cloud Provider annual audits to make sure they meet all service provider criteria firewalls, intrusion detection, disaster recovery, physical controls and appropriate segmentation of staff duties PCI Responsibilities for Organization using Cloud Provider Need to add their own controls and technology, including not storing card information no longer than necessary to process transaction Gray Areas The place where data is stored can only be accessed by you and servers that you control are locked down In the cloud, servers may be shared by multiple clients, and even if they are not, who controls them? Part of the transaction takes place within merchant's point-of-sale system

21 The Murky Waters of Compliance SAS 70 Tracking data flow across multiple data centers can be difficult, but do-able If there are material numbers coming from data that has been stored or in any way acted upon by a cloud vendor, there needs to be a full understanding of where the information comes in, how it gets back to the users, the controls over the processing of the data, and what happens to the data when it gets to the cloud. Bottom line: YOU are responsible for your data With SAS 70, you are building a control framework that your auditor feels is appropriate i.e. SAS 70 does not talk about encryption, but you can make encryption part of your audit framework, and SAS 70 will show you are doing it.

22 The Murky Waters of Compliance HIPAA HIPAA Responsibilities for Cloud Provider warrant to customers that they are in a HIPAA-compliant environment, that the environment is secure both physically and logically, that the data is protected, and that controls are in place protect patient data HIPAA Responsibilities for Organization using Cloud Provider Ensure that the data is handled properly Although encryption is not required, if there is none, there must be mitigating controls (i.e. physical security to prevent unauthorized access) Personal data sent over public networks must be encrypted Log access and validate who has access to network Some companies strip out all protected health care information before uploading data the cloud to ensure compliance

23 The Murky Waters of Compliance GLBA Not built with security in mind; assumes data in controlled by the enterprise You are responsible for your providers Companies assume the risk for data loss no matter whereit is stored All the requirements apply to you, cannot be passed through Some things change How data is stored, accessed, transmitted Some things don t Logging/Auditing is still required Encryption can help or hurt Architecture has to be thought out in detail

24 The Murky Waters of Compliance Privacy and Disclosure Laws If your customer s data is disclosed, you have to notify You bear the cost You bear the hit to your reputation You can blame this on the provider, but that s a nuance lost on the customer Example marketing provider hacked I got notifications from several companies.

25 Agenda Pros and Cons of Cloud Computing Security Controls & Building a Secure System Redundancy We Still Need to Think About This? The Murky Waters of Compliance Service Level Agreements Conclusion

26 Service Level Agreements (SLAs) Read them like your business depends on it (hint: it does) Many exceptions and nebulous wording. Not responsible for events.caused by a third party.outside of our reasonable control (Amazon) Back to Amazon EC2 Failure Case Study Primary failure was in a component they didn't promise to be available (elastic storage) The Companies that knew this piece might fail, and accounted for it had no interruption in service EC2 has no guarantee for VM uptime Bottom line: limited recourse; lawyers need to get involved

27 Service Level Agreements (SLAs) Security Innovation Case Study We depend on a hosted LMS Provider Risk Moved from self-hosted system to cloud provider Business features and maintenance costs main driver We require that they let us conduct our own security testing Vulnerabilities are analyzed and traced back to damage potential If high risk/impact, push back on the vendor or consider removing offline If low risk/impact, implement mitigating controls We put these clauses in the contract We are currently working through several vulns with the cloud provider

28 Conclusion Cloud Computing has nice security and feature advantages, but beware of. How it impacts Compliance The false sense of security that comes with cloud provisioning What is in your SLA Amazon customers got 10 days fees back Your Applications are your line of defense in the Cloud They need to hardened and self-defending Well designed applications with small attack surface can protect against vulnerabilities that you don t know about or are introduced within a cloud environment

29 Questions? Thank You Fred Pinkett VP of Product Management