Emerging application and data protection for multi cloud

Editor's Notes

• #2: 50 minutes, 3:05 PM - 3:55 PM Personal data privacy will be the most prominent issue affecting how businesses gather, store, process, and disclose data in public cloud. Businesses have been inundated with information on what recent privacy laws like GDPR and CCPA require, but many are still trying to figure out how to comply with them on a practical level. Many companies are focusing on data privacy from the legal and security side, which are foundational, but are missing the focus on data. The good news is that these data privacy regulations compel businesses to get a handle on personal data - how they get it, where they get it from, which systems process it, where it goes internally and externally, etc. In other words, the new norms of data privacy require proactive data management, which enables organizations to extract real business value from their data, improve the customer experience, streamline internal processes, and better understand their customers. The new Verizon Data Breach Investigations Report (DBIR) provides perspectives on how Criminals simply shift their focus and adapt their tactics to locate and steal the data they find to be of most value. This session will discuss Emerging Application and Data Protection for Multi-cloud and review Differential privacy, Tokenization, Homomorphic encryption, and Privacy-preserving computation (Multi Party Computation).
• #12: The 2014 Verizon Data Breach Investigations Report concluded that enterprises are losing ground in the fight against persistent cyber-attacks. We simply cannot catch the bad guys until it is too late. This picture is not improving. Verizon concluded that less than 14% of breaches are detected by internal security tools. Detection by third party entities increased from approximately 10% to 25% during the last three years. Specifically theft of payment card information 99% of the cases that someone else told the victim they had suffered a breach. One reason is that our current approach with monitoring and intrusion detection products can't tell you what normal looks like in your own systems and SIEM technology is simply too slowly to be useful for security analytics. Big Data security analytics may help over time, but we don't have time to wait. Biggest hacks and security breaches of 2014 include eBay, Target, Sony and Microsoft, Celebrity iCloud, NSA, Heartbleed, Sony The successful attack on JP Morgan Chase surprised me most as the largest US bank lost personal information of 76 million households and it took several months to detect. 
• #31: In this section we show you how to weave security into the fabric of your DevOps framework. DevOps encourages testing in all phases of development and deployment. Better still, it easily accommodates security testing side by side with functional and regression tests. From each developer's desktop prior to check-in, to module testing, and eventually against a full application stack, both pre- and post- deployment — it is all available. Where To Test Unit Testing: Unit testing is where you check small sub-components or fragments ('units') of an application. These tests are written by programmers as they develop new functions, and commonly run by developers prior to code check-in. But these tests are intended to be long-lived, checked into the source repository along with new code, and run by every subsequent developers who contributes to that code module. For security these may straightforward — such as SQL injection against a web form — or more sophisticated attacks specific to the function under test, such as business logic attacks — all to ensure that each new bit of code correctly reflects the developers' intent. Every unit test focuses on specific pieces of code — not systems or transactions. Unit tests attempt to catch errors very early in the process, per Deming's assertion that the earlier flaws are identified, the less expensive they are to fix. In building out unit tests you will need to support. Let’s dive into the different types of testing tools available: Static Analysis: Static Application Security Testing (SAST) examines all code — or runtime binaries — to support a thorough search for common vulnerabilities. These tools are highly effective at finding flaws, even in code that has been manually reviewed. Most of these platforms have gotten much better at providing analysis that is useful for developers, not just security geeks. And many of the products are being updated to offer full functionality via APIs or build scripts. If you have a choice, select tools with APIs for integration into the DevOps process, and which don't require "code complete". We have seen a slight reduction in use of these tests, as they often take hours or days to run — in a DevOps environment that can prevent them from running inline as a gate to certification or deployment. As we mentioned in the above under 'Other', most teams are adjusting to support out-of-band — or what we are calling ‘Parallelized’ — testing for static analysis. We highly recommend keeping SAST testing inline if possible, and focus on new sections of code to reduce runtime. Dynamic Analysis: Rather than scanning code or binaries like SAST, Dynamic Application Security Testing (DAST) dynamically 'crawls' through an application's interface, testing how it reacts to various inputs. These scanners cannot see what's going on behind the scenes, but they offer valuable insight into how code behaves, and can flush out errors which other tests may not see in dynamic code paths. These tests are typically run against fully built applications, and can be destructive, so the tools often offer settings to run more aggressively in test environments. And like SAST may require some time to fully scan code, so in line tests that gate a release are often run against new code only, and full application sweeps are run ‘in parallel’. Fuzzing: At its simplest fuzz testing is essentially throwing lots of random garbage at applications, seeing whether any particular (type of) garbage causes errors. Go to any security conference — Black Hat, DefCon, RSA, or B-Sides — and you will see that most security researchers prefer fuzzing to find vulnerable code. It has become essential for identifying misbehaving code which may be exploitable. Over the last 10 years, with Agile development processes and even more with DevOps, we have a steady decline in use of fuzz testing by development and QA teams. This is because running through a large test body of possible malicious inputs takes substantial time. This is a little less of an issue with web applications because attackers don't have copies of the code, but much more problematic for applications delivered to users (including mobile apps, desktop Putting Security Into DevOps 18 applications, and automobile systems). This trend worries us — like penetration testing, periodic fuzz testing should be part of your security testing efforts. Fuzzing may be part of unit tests, or part of QA's parallel testing. Manual Code Review: Some organizations find it more than a bit scary to fully automate deployment, so they want a human to review changes before new code goes live — we understand. But there are very good security reasons for review as well. In an environment as automation-centric as DevOps, it may seem antithetical to use or endorse manual code reviews or security inspection, but manual review is still highly desirable. Manual reviews often catch obvious stuff that tests miss, and developers can miss on their first (only) pass. And developers' ability to write security unit tests varies. Whether through developer error or reviewer skill, people writing tests miss stuff which manual inspections catch. Your toolbelt should include manual code inspection — at least periodic spot checks of new code. Vulnerability Analysis: Things like Heartbleed, misconfigured databases, and Struts vulnerabilities may not be part of your application testing at all, but they all critical application stack vulnerabilities. Some people equate vulnerability testing with DAST, but there are other ways to identify vulnerabilities. In fact there are several kinds of vulnerability scans; some look settings like platform configuration, patch levels or application composition to detect known vulnerabilities. Some even use credentials to query the application for detailed information. And there are tools that actively probe an application looking for poorly implemented code, such as how user credentials are handled. Make sure you broaden you scans to include your application, your application stack, and the platforms that support it. Version Controls: One of the nice side benefits of build scripts running both QA and production infrastructure is that Dev, Ops, and QA are all in synch on the versions of code they use. But someone on your team still needs to monitor and control versions and updates for all parts of the application stack. For example, are all your gems up to date? As with vulnerability scanning, you should monitor your open source and commercial software for new vulnerabilities, and create task cards for patches to the build process. But many vulnerability analysis products don't cover all the bits and pieces that comprise an application. This can be fully automated in-house, with scripts adjusted to pull the latest version, or you can integrate third-party tools for monitoring and alerting. Either way version control should be part of your overall security monitoring program, with or without vulnerability analysis. Runtime Protection: This is a new segment of the application security market. The technical approaches are not new, but over the past couple years we have seen greater adoption of security tools embedded into applications for runtime threat protection. These tools are called by different names, including Runtime Application Self Protection (RASP) and Interactive Application Self-Testing (IAST) depending on the specific variation; essentially they provide execution path scanning, monitoring and embedded application white listing. So do the deployment models (including embedded runtime libraries, in-memory execution monitoring, and virtualized execution paths), but they all attempt to protect applications by detecting attacks in runtime behavior. These platforms can Putting Security Into DevOps 19 all be embedded into the build or runtime environment; they can all monitor or block; and they all offer adjustable enforcement, based upon the specifics of the application. While these technologies are relatively new, they fill a gap in existing application security validation and protection. Priorities and Risk Integrating security findings from application scans into bug tracking systems is not that difficult technically. Most products offer it as a built-in feature. The hard part is figuring out what to do with the data once obtained. Is a discovered security vulnerability a real risk? If it is a risk rather than a false positive, what is its priority, relative to everything else? How is this information distributed? With DevOps you need to close the loop on issues within infrastructure, as well as code. And Dev and Ops offer different possible solutions to most vulnerabilities, so the people managing security need to include operations teams as well. Patch
• #37: Protect PII Data Cross Border. Achieve Compliance while moving, outsourcing, data, EVEN between countries. Data residency issue solved. Example: A major bank performed a consolidation of all European operational data sources. This meant protecting Personally Identifiable Information (PII) in compliance with the EU Cross Border Data Protection Laws. In addition, they required access to Austrian and German customer data to be restricted to only people in each respective country. CHALLENGES The primary challenge was to protect PII – names and addresses, phone and email, policy and account numbers, birth dates, etc. – to the satisfaction of EU Cross Border Data Security requirements. This included incoming source data from various European banking entities, and existing data within those systems, which would be consolidated at the Italian HQ. RESULT Complete policy-enforced de-identification of sensitive data across all bank entities End-to-end data protection from geographically distributed bank entities to HQ All existing data secured at a granular level Achieved targeted compliance with EU Cross Border Data Security laws, Datenschutzgesetz 2000 - DSG 2000 in Austria, and Bundesdatenschutzgesetz in Germany Implemented country-specific data access restrictions Extremely high throughput of data Source
• #42: …or the issue with “rolling your own” solution Just moved the sensitive data from one area of your network to the other