Threat-modeling legacy Cloud Applications

1. Threat-modeling legacy Cloud Applications Kevin Nassery kevin@nassery.org @knassery on Twitter

2. About Me Sr. Principal Consultant / BSIMM Ops Director @ Synopsys Software Integrity Group Certified AWS Solutions Arch - Associate Former: Director Assessment Services @ US Bank Last 8yrs focused on Application Security; before that Infrastructure (Unix, Network) Security & Performance Engineering Free time: Chess, Amateur Radio (KE0UKR), Competition Long Range Shooter

3. Threat Modeling Workflow • Notes about scaling: • Iterative process takes several rounds • Ideally should be done as both a design and validation activity • Geometric # of scenarios: Add 5 new attacks, and your matrix gets 5x bigger • Requires special skills (system knowledge, and adversarial thinking) • Small systems can take 2-3 weeks, larger systems 5+ weeks • Developing “Threat Modeling Libraries” to combine with process is the key to both quality and efficiency

4. Example Threat Model

5. Trace Matrix How much is enough??

6. Threat Modeling Libraries: Curating Re-usable Inputs for common architectures and components Management Plane

7. Risk management as things move into the cloud..

8. Threat Modeling Cloud Management plane!!!!

9. Cloud Provider / Shared Responsibility: Notable Failures

10. Cloud Provider / Shared Responsibility: Notable Failures

11. Cloud Provider / Shared Responsibility: Notable Failures

12. A real world example: Container Security Issue (CVE-2019-5736) Late breaking news!!! Docker escape: Docker allows you to wrap an OS into a software bundle with isolated software dependency but native host execution performance. In a growing use-case scenario people are trusting container isolation as a substitute for OS virtualization (or bare-metal isolation). It is likely that this exploit, and others to-be-discovered vulnerabilities, allow code to be executed in a container to gain host root & therefore side-by-side container access. We probably DO NOT have enough information to threat model this attack on Cloud services such as Amazon ECS..

13. Let’s try.. • Could a different AWS ECS account holder who exploited this issue prior to remediation gained access to my container runtime? • Could an insider who had commit access to a subset of our enterprise docker containers used this exploit to gain access to other enterprise apps?

14. So what does the next 5 years of lift & shift look like: • Logical Architecture is the same • Transmission paths are now dependent on provider security • Physical security is an unknown, but likely much better (and has probably passed umpteen 3rd party assessments) • Other layers depend on cloud solutions architecture, for example: • EC2 or Beanstalk? • EC2 instance classes? (some are physically isolated) • Container or Server Instance, or both • Database on EC2 or AWS RDS?

15. Considerations in shared responsibility / cloud models: • Network security: Segmentation used to be “hard”, so you used fewer segments, and your app ops people probably don’t know what network least privilege works on. • Tip: Spend time here during transition to have clear definition of communication profiles, embrace hyper segmentation because it’s now free. • Transport security: You don’t ”own” the network • Tip: SSL is cheap, but Certificate Management is hard • Data at rest: You don’t ”own” the storage (from physical -> object) • Tip: The more you insulate yourself from your cloud provider the harder the key management. • Tip: The performance / availability / optimizations of Cloud DB solutions generally outweigh the security trade-offs. • Management plane: Cloud provider insiders, cloud management accounts • Tip: Beware of directory services integration with corporate networks • Server OS Images: Operating System Patching, Management • Tip: Manage the “network” as a single system, if you are using an interactive ssh session to do something, it’s probably wrong.

16. Augmenting the threat modeling process… • Consider the following in modeling “insider threats”: • Assume ”Cloud Root” users will be able to compromise almost any part of the system • Assume a “small population” of insider threats at cloud provider could compromise Application runtime memory / field level DB encryption using Cloud HSMs / encrypted storage mechanisms • Assume a bigger, ”medium sized” population of threats at cloud provider could compromise ”sniffer level access” to transport paths, Medium population of Insider threats at cloud provider + Threats to container layers supported by third parties and unencrypted storage mechanisms. • Presume any control you “can’t” understand has a decent chance of being broken by a small population of threats • Build this into your “threat modeling libraries” • Cloud provider ”threats”: ie, Management console developer; Cloud HSM engineer; Datacenter physical resource • Secondary assets for credentials & keys as ”assets” • Every “Service” you use probably has a fairly consistent threat model, build into reusable modules

17. Augmenting the threat modeling process…simple things, can be very complicated. Threat model building blocks, and ”approve” them for appropriate use cases.

18. Get a head start: • Get good at Key Management (and secure your own keys for important things) • SSL Everything, Everywhere • Use Provider Encryption integrations for data at rest where it matters (and manage your own keys where it *REALLY* matters) • Leverage free Hyper Segmentation • Manage everything through automation • Trust that providers are typically better than you at OS management, but where it *really* matters consider taking responsibility and tradeoffs • Insulate applications from software dependencies using containers, but keep those containers “Fresh” & secure • Get serious about sun-setting legacy solutions for server less / micro services / modern “cloud” native platforms.