Page 1
Security Delusions
Kelly Shortridge (@swagitda_)QCon NYC 2019
Page 3
3
“Ignorance is the parent of fear.”
― Herman Melville, Moby Dick
Page 4
4
Infosec is consistently a tech laggard –“skepticism” is seen as a strength
Page 5
5
How can you herd these frightened sheep to modern tech pastures?
Page 6
6
1. A History of Cloud Compunction
2. APIs: Infosec’s Anathema
3. The Curse of Containers
4. Cheat Codes for Dealing with This
Page 7
A History of Cloud Compunction
Page 8
8
“Cloud transformation” ruffled infosec feathers in the early 2010s
Page 9
9
“Storing data online,” shared resources, insider threat, DDoS, supply chain…
Page 10
10
The crux of cloud fear was rooted in a loss of control by the infosec team
Page 11
11
The firewall was always the center of the enterprise infosec universe
Page 14
14
Defense in Depth model: the firewall is the first line of defense
Page 15
15
Cloud + microservices represents a Copernican revolution for infosec
Page 16
16
What do surveys from yesteryear reveal about infosec’s fear of cloud tech?
Page 17
17
2012: “What is holding back cloud?”
Page 18
18
Source: Intel
57%
55%
49%
Inability to measure CSP's security measures
Lack of control over data
Lack of confidence in CSP's security capabilities
Page 19
19
“Uneasiness about adequate firewalling” = the pre-Copernican mindset
Page 20
20
2014: Cloud Multiplier effect on security
Page 21
21
Source: Ponemon
66%
64%
51%
Diminishes the ability to protect sensitive data
Makes it difficult to secure business-critical apps
Increases the likelihood of a data breach
Page 22
22
2015: 71% view cloud data security as a big red flag & 38% feared loss of control
Source: Cloud Security Alliance
Page 23
23
Endowment effect & sunk cost fallacy: “Our security is better than CSPs!”
Page 24
24
Evidence is quite scant that CSPs are breached more frequently
Page 25
25
Acceptance that CSPs have better security is only in the past few years
Page 26
26
Reality: misconfigurations are the biggest concern for cloud security
Page 27
27
Gartner: “Through 2020, 80% of cloud breaches will be due to misconfiguration … not cloud provider vulnerabilities”
Page 28
28
Using cloud-native security controls can reduce security expense by 30%
Source: McKinsey
Page 29
29
Network security blinky boxes often carry price tags of $100k - $200k
Page 30
30
So, how is infosec reacting to emerging tech today?
Page 31
APIs: Infosec’s Anathema
Page 32
32
Microservices fears: APIs + containers
Page 33
33
Horror story: microservices creates a titanic, labyrinthian attack surface
Page 34
34
Basically monolithic app risk x 10,000 = infosec’s mental model of microservices
Page 35
35
Revisionist history: as long as the perimeter is secure, the org is safe
Page 36
36
Real history: lateral movement was easy because everything else was #yolosec
Page 37
37
Public-by-default begets embedded security vs. bolt-on security – a big win
Page 38
38
2018: 51% aren’t certain the infosec team knows all APIs within the organization
Source: Ping Identity
Page 39
39
Public API fears – adds attack surface, closer to attackers, impossible to control
Page 40
40
A lie: “Formerly, local networks had only a few connections to the outside world, & securing those endpoints was sufficient.”
Page 41
41
Public API fears – provides a “roadmap” for underlying functionality of the app
Page 42
42
Reality: “Security through obscurity” is a garbage cop-out
Page 43
43
Security resilience: assume your added security controls will fail
Page 44
44
API endpoints actually raise the cost of attack – attack tools don’t work & entire vuln classes are removed
Page 45
45
Standardization begets security benefits – but isn’t a common concept in infosec
Page 46
The Curse of Containers
Page 47
47
Few in infosec realize containers aren’t just featherweight VMs
Page 48
48
2019: 94% have concerns on container security – leading 42% to delay adoption
Source: Tripwire
Page 49
49
54% acknowledge inadequate container security knowledge among teams
Source: Tripwire
Page 50
50
Source: Tripwire
52%
43%
42%
40%
Lack of visibility into container security
Inability to assess container image risk pre-deploy
Lack of tools to secure containers
Insufficient processes to handle fundamental differencesin securing containers
Page 51
51
52% want incident detection & response. 49% want isolation of pwned containers.
Source: Tripwire
Page 52
52
40% want “AI security analytics” & 22% want “blockchain” to secure containers.
Source: Tripwire
Page 53
53
We can presume at least 22% of security pros have nfi what containers are.
Page 54
54
Straw man: each container needs its own monitoring, management, & securing
Page 55
55
Standardization fear: vulns can be replicated ad infinitum
Page 56
56
Because scanning for vulns in monolithic, custom-built Java apps is easy???
Page 57
57
Rose-tinted glasses: monolithic apps = “You know exactly where the bad guys are going to try to get in”
Page 58
58
Microservices: easily mapped workflows means easier threat models
Page 59
59
Container fear: shared environments (just like with cloud previously)
Page 60
60
Should we go back to apps talking over FTP, telnet, SSH, random UDP ports, etc.?
Page 61
61
Past: get in via a running FTP service
Containers: exploit the web server
Page 62
62
Container fear: too easy for devs to use vulnerable versions of software
Page 63
63
As opposed to what – versions of Windows Server 2008 with Metasploit backdoors ready to go?
Page 64
64
Separating complex functionality into separate services is better for security
Page 65
65
Now that we’ve explored the tinfoil universe, how do we return to reality?
Page 66
Cheat Codes for Dealing with This Mess
Page 67
67
How can we evangelize real threat models & solutions in this new world?
Page 68
68
Warning: Infosec largely views DevOps as a frenemy (at best)
Page 69
69
“DevOps is like a black hole to security teams because they have no idea what DevOps is doing and have no way of ensuring security policy is enforced.”
Page 70
70
Telling someone gripped by fear to “calm down” will backfire
Page 71
71
Acknowledge there are relevant concerns for using this tech – just not the ones they believe
Page 72
72
Which concerns should you highlight? There are three critical basics:
Page 73
73
1. Don’t expose cloud storage publicly
2. Don’t use unauthenticated APIs
3. Don’t use “god mode” in containers
Page 74
74
Infosec’s job becomes validating adherence to established best practices
Page 75
75
Analogize “new security” to pre-Copernican methods to facilitate comms
Page 76
76
Example: security groups & network isolation by CSPs = firewall equivalent
Page 77
77
Amazon Inspector + AWS Trusted Advisor are great tools to start
Page 78
78
Use IAM roles for least priv or segment prod + dev through different accounts
Page 79
79
Basic API hygiene will suffice – auth, validation, & not trusting external data
Page 80
80
Example: Don’t expose API keys in the URL, only use HTTPS endpoints, etc.
Page 81
81
Validate input & content types. Explicitly define intended types & reject all others.
Page 82
82
Analogize this as a form of granular whitelisting only possible with APIs
Page 83
83
For containers, restrict access – no “god mode”, no anon access, don’t expose management dashboards, etc.
Page 84
84
Any CISO will already be familiar with the concept of “Least Privilege”
Page 85
85
Containers = antidote to the “Equifax problem” (patching procrastination)
Page 86
86
Container registries make security scanning easier & add sense of control
Page 87
87
Live migration means security can patch without impacting end users
Page 88
88
Analogy: Windows updates if Word & PPT docs were migrated to a healthy OS
Page 89
89
If misconfigs are covered, what remains for infosec teams to tackle?
Page 90
90
Codifying secure configs – modern equivalent of security policy templates
Page 91
91
Documenting threat models, starting with scenarios most damaging to the org & working back to likely vectors
Page 92
92
Focus on securing data stores – enticing to attackers & less standardized
Page 93
93
Help infosec finds database visibility & monitoring tools (e.g. Vivid Cortex)
Page 94
94
Cultivates an activity baseline for policy creation & aids in security investigation
Page 95
95
Highlight compliance – file integrity monitoring underpins most standards
Page 96
96
FIM is easier given the improved inspectability of containers
Page 97
97
(Observability isn’t a common term in infosec, but visibility is)
Page 98
98
Infosec ppl aren’t all the same – different tactics will work to build understanding
Page 99
99
Generally, infosec is more familiar with Windows than Unix, thinks in a network-centric model, & doesn’t have dev skills
Page 100
100
Patience, analogies, & proof that not all control is lost are critical ingredients
Page 102
102
Letting go of core, long-held beliefs is difficult for anyone
Page 103
103
Most of infosec’s fears of modern tech distill into fears over losing control
Page 104
104
Redirect grasping at phantasms towards control of meaningful threat mitigation
Page 105
105
Work together to codify standards so infosec can focus on securing “pets”
Page 106
106
DevOps can be the Perseus to infosec’s Andromeda
Page 107
107
Unchain infosec from their fears & bring forth a new dawn of secure & resilient software delivery performance
Page 108
108
@swagitda_
/in/kellyshortridge
[email protected]