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

2. Certified AWS Solutions Arch - Associate
About Me
Sr. Principal Consultant / BSIMM Ops Synopsys Software Integrity Group
Certified AWS Solutions Arch - Associate
Former: Director Assessment 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
define architecture
identify assets
ID attack surface
enumerate attackers
enumerate attacks
MATRIX: (attacks * threats * positions*...)
validate "controls" against list
improve architecture
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. How much is enough?? Trace Matrix Position Attacks Control Residual
Asset
Risk
Auth'd Users
External, Internal
OWASP #1-10
ESAPI
Zero Day App
App, Runtime
App Data, Network Intrusion
Unauthed Users
External
OS Attacks against Server
Firewall, Patching
Unpatched, Zero Day
Runtime Environment
Data, Network Intrusion
Unauthed Users, Internal
Corporate
[ NONE ]
OS Admin Users
[ recurse ]
Campus Training
MiTM attacks, OS Attacks
[ unanticpated abuse ]
Priv User
Misuse of Server
Background Check
Data, Horizontal to Other Systems
DB Admin
Misuse of DB ops Access
Database
Data
SAN Admin
Misuse of Storage Access
[ unanticipated abuse ]
Storage Device
How much is enough??

6. network / segmentation
Threat Modeling Libraries: Curating Re-usable Inputs for common architectures and components
Management Plane
attacker profiles
threat perspectives
top N attacks lists
intelligence
standard controls
app
container / os
Compute / data
network / segmentation
physical / datacenter

7. Risk management as things move into the cloud..
Good news
Cloud services will generally be "better" than “we” were at things like patching & segmentation
Design level remediation is faster
You can opt into the level of shared responsibility you want
Bad news
You will never know how things truly work
We've seen mistakes
We've seen arrogance
Amplified “ambiguity” between developers, cloud engineers, and cloud providers

8. Threat Modeling Cloud Management plane!!!! app container / os
Compute / data
network / segmentation
physical / datacenter
app
OS Virtualization & Container
Logical Compute Isolation / Data Controls
Logical Network Separation / network transport considerations..
Physical?

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.