Actually, this is about the things a Cloud Evangelist DOESN'T say and correlates the experience, belief systems and issues of developers and security folks. It's a plea to have devs evangelize to and enroll security in their efforts as it relates to security of their platforms...
Spring Boot vs Quarkus the ultimate battle - DevoxxUK
Shit My Cloud Evangelist Says...Just Not To My CSO
1. Sh*t my cloud evangelist
says...
...Just not to my CSO
2. About @Beaker:
✤ I’m an a*hole with a blog (rationalsurvivability.com)
✤ Global Chief Security Architect for a company who
provides networking & security widgets to SP’s &
Enterprises
✤ Love Cloud & particularly fond of those that do my
bidding in a manner commensurate with my OCD-driven
need to manage outcomes in a reasonably predictable
way
3. About @Beaker:
✤ I’m an a*hole with a blog (rationalsurvivability.com)
✤ Global Chief Security Architect for a company who
provides networking & security widgets to SP’s &
Enterprises
✤ Love Cloud & particularly fond of those that do my
bidding in a manner commensurate with my OCD-driven
need to manage outcomes in a reasonably predictable
way
<< @SMCES
6. Developer Priorities* VS Security Priorities
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
7. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
8. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
9. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
3. Usability 3. Uptime
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
10. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
3. Usability 3. Uptime
4. Uptime 4. Performance
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
11. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
3. Usability 3. Uptime
4. Uptime 4. Performance
5. Maintainability 5. Functions and features as
specified or envisioned
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
12. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
3. Usability 3. Uptime
4. Uptime 4. Performance
5. Maintainability 5. Functions and features as
specified or envisioned
6. Security 6. Usability/Maintainability
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
13. Developer Priorities* VS Security Priorities
1. Functions and features as 1. Security
specified or envisioned
2. Performance 2. Compliance
3. Usability 3. Uptime
4. Uptime 4. Performance
5. Maintainability 5. Functions and features as
specified or envisioned
6. Security 6. Usability/Maintainability
*Mark Curphey - The Great Security Divide - Part 1 & John Wilander - Security People vs Developers
15. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
16. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
✤ The Golden Rule: Design for fail ✤ Security is penalized severely for failure & is
expected never to fail (even though it does)
17. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
✤ The Golden Rule: Design for fail ✤ Security is penalized severely for failure & is
expected never to fail (even though it does)
✤ Cloud is more agile, costs less and delivers more ✤ Cloud encourages bypassing controls, promotes
value, more quickly & flexibly and without capital reckless operations and will ultimately cost more
costs to clean up the mess
18. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
✤ The Golden Rule: Design for fail ✤ Security is penalized severely for failure & is
expected never to fail (even though it does)
✤ Cloud is more agile, costs less and delivers more ✤ Cloud encourages bypassing controls, promotes
value, more quickly & flexibly and without capital reckless operations and will ultimately cost more
costs to clean up the mess
✤ The only “True Cloud” is Public, pay-per use, ✤ Private Clouds, extending in limited fashion to
multi-tenant platforms. All else are “False Public clouds will provide a controllable, hybrid
Clouds” architecture we can secure
19. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
✤ The Golden Rule: Design for fail ✤ Security is penalized severely for failure & is
expected never to fail (even though it does)
✤ Cloud is more agile, costs less and delivers more ✤ Cloud encourages bypassing controls, promotes
value, more quickly & flexibly and without capital reckless operations and will ultimately cost more
costs to clean up the mess
✤ The only “True Cloud” is Public, pay-per use, ✤ Private Clouds, extending in limited fashion to
multi-tenant platforms. All else are “False Public clouds will provide a controllable, hybrid
Clouds” architecture we can secure
✤ Legacy IT organizational hierarchy and siloed ✤ Compliance will have the last laugh when you
operations is dead. Long live Shadow IT and bypass security and bad things happen;
DevOps...or NoOps Separation of Duties & Least Privilege
20. @SMCES... VS ...SECURITY
✤ Cloud is more secure; security is more integrated ✤ Cloud is less secure because developers can’t
and it’s everyone’s responsibility detect & prevent basic threats, let alone complex,
adaptive and emerging adversaries; See OWASP
Top 10 vs APT
✤ The Golden Rule: Design for fail ✤ Security is penalized severely for failure & is
expected never to fail (even though it does)
✤ Cloud is more agile, costs less and delivers more ✤ Cloud encourages bypassing controls, promotes
value, more quickly & flexibly and without capital reckless operations and will ultimately cost more
costs to clean up the mess
✤ The only “True Cloud” is Public, pay-per use, ✤ Private Clouds, extending in limited fashion to
multi-tenant platforms. All else are “False Public clouds will provide a controllable, hybrid
Clouds” architecture we can secure
✤ Legacy IT organizational hierarchy and siloed ✤ Compliance will have the last laugh when you
operations is dead. Long live Shadow IT and bypass security and bad things happen;
DevOps...or NoOps Separation of Duties & Least Privilege
✤ Automation enables simplicity, scalability, agility, ✤ Abstraction yields “simplexity” and complex
resiliency and better security; Availability is the System Failures due to automation in security will
priority be catastrophic; Fail CLOSED
23. What’s Missing?
✤ Instrumentation that is inclusive of security
✤ Intelligence and context shared between infrastructure and
applistructure layers
24. What’s Missing?
✤ Instrumentation that is inclusive of security
✤ Intelligence and context shared between infrastructure and
applistructure layers
✤ Maturity of “automation mechanics” and frameworks
25. What’s Missing?
✤ Instrumentation that is inclusive of security
✤ Intelligence and context shared between infrastructure and
applistructure layers
✤ Maturity of “automation mechanics” and frameworks
✤ Standard interfaces, precise syntactical representation of elemental
security constructs < We need the “EC2 API” of Security
26. What’s Missing?
✤ Instrumentation that is inclusive of security
✤ Intelligence and context shared between infrastructure and
applistructure layers
✤ Maturity of “automation mechanics” and frameworks
✤ Standard interfaces, precise syntactical representation of elemental
security constructs < We need the “EC2 API” of Security
✤ An operational methodology that ensures a common understanding
of outcomes & “Agile” culture in general
27. What’s Missing?
✤ Instrumentation that is inclusive of security
✤ Intelligence and context shared between infrastructure and
applistructure layers
✤ Maturity of “automation mechanics” and frameworks
✤ Standard interfaces, precise syntactical representation of elemental
security constructs < We need the “EC2 API” of Security
✤ An operational methodology that ensures a common understanding
of outcomes & “Agile” culture in general
✤ Sanitary Application Security Practices
29. “Information Security” Sucks
Figu
re 21
. Hac
king
meth
ods b
y per
cent
Expl
oitat of br
ion o each
f es w
defa
ult o ithin
r gue Hack
ssab ing
le cr
eden
Use tials
of st
olen
login
cred
Brut entia 9%
Expl e for ls
oitat ce an
ion o d dic
f bac tiona
kdoo ry at
r or c tack
omm s
and a
Expl nd co 55%
oitat ntrol
ion o chan 40%
f ins nel +#
uffic 14%
ient 29%
auth –
no lo entica 51%
(e.g.,
gin r t
equirion 25%
ed) 6% –#
SQL 3% 29%
injec
tion
Rem 3%–
ote fi
le inclu
sion 1% 14%
Abus
e of
func 6%
tiona <1%
lity #
Unkn 3%
VGhhbmsgeW91IGZvciBwYXJ0aWNpcGF0aW5nIGluIHRoZSAyMDEyIFZlcml6b24gREJJUiBDb3Zl own
4%
#
ciBDaGFsbGVuZ2UuCldlIGhvcGUgeW91IGVuam95IHRoaXMgY2hhbGxlbmdlIGFzIG11Y2ggYXMg
d2UgaGF2ZSBlbmpveWVkIGNyZWF0aW5nIGl0LiAgCgoKVGhlcmUgb25jZSB3YXMgYSBsYWR5IGZy
b20gTmFudHVja2V0LApXaXRoIHRleHQgc28gd2lkZSB3ZSBjb3VsZCBncm9rIGl0Lgp3ZSBjaG9w
cGVkIGFuZCBzbGljZWQgaXQgYWxsIGRheSBsb25nLApPbmx5IHRvIGZpbmQgc2hlIHdhc27igJl0
IGFsbCB3cm9uZy4KCldpdGggc2tpbGwgYW5kIGVhc2Ugd2UgYmF0dGxlZCB0aGlzIGZpZ2h0LApF
king
eGNlcHQgc2hlIHdhcyBub3QgdG90YWxseSByaWdodC4KVHdpc3RpbmcgYW5kIHR1cm5pbmcgd2Ug
Hac
a2VwdCBvbiBzdHJvbmcsCldlIHNob3VsZCBoYXZlIGJlZW4gc2luZ2luZyBhbGwgYWxvbmc6CgpN
hin
wit
YXJ5IGhhZCBhIGxpdHRsZSBsYW1iLApsaXR0bGUgbGFtYiwgbGl0dGxlIGxhbWIsCk1hcnkgaGFk
es 31%
IGEgbGl0dGxlIGxhbWIsCndob3NlIGZsZWVjZSB3YXMgd2hpdGUgYXMgc25vdy4KCkFuZCBldmVy
ch
eXdoZXJlIHRoYXQgTWFyeSB3ZW50LApNYXJ5IHdlbnQsIE1hcnkgd2VudCwKYW5kIGV2ZXJ5d2hl
rea wn
of b
cmUgdGhhdCBNYXJ5IHdlbnQsCnRoZSBsYW1iIHdhcyBzdXJlIHRvIGdvLgoKSXQgZm9sbG93ZWQg
nt kno
aGVyIHRvIHNjaG9vbCBvbmUgZGF5CnNjaG9vbCBvbmUgZGF5LCBzY2hvb2wgb25lIGRheSwKSXQg
rce Un
Zm9sbG93ZWQgaGVyIHRvIHNjaG9vbCBvbmUgZGF5LAp3aGljaCB3YXMgYWdhaW5zdCB0aGUgcnVs
y pe
ZXMuCgpJdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheSwKbGF1Z2ggYW5kIHBsYXks
rs b ion
IGxhdWdoIGFuZCBwbGF5LAppdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheQp0byBz
vec
to icat All O
ZWUgYSBsYW1iIGF0IHNjaG9vbC4KCkFuZCBzbyB0aGUgdGVhY2hlciB0dXJuZWQgaXQgb3V0LAp0
ppl rgs
ing ba
dXJuZWQgaXQgb3V0LCB0dXJuZWQgaXQgb3V0LApBbmQgc28gdGhlIHRlYWNoZXIgdHVybmVkIGl0
ck r We
IG91dCwKYnV0IHN0aWxsIGl0IGxpbmdlcmVkIG5lYXIsCgpBbmQgd2FpdGVkIHBhdGllbnRseSBh
. Ha or o l
Ym91dCwKcGF0aWVudGx5IGFib3V0LCBwYXRpZW50bHkgYWJvdXQsCkFuZCB3OGVkIHBhdGllbnRs
2 2 kdo nne Larg
ure Bac ol cha
eSBhYm91dAp0aWxsIE1hcnkgZGlkIGFwcGVhci4KCiJXaHkgZG9lcyB0aGUgbGFtYiBsb3ZlIE1h
Fig er O
cnkgc28/IgpMb3ZlIE1hcnkgc28/IExvdmUgTWFyeSBzbz8KIldoeSBkb2VzIHRoZSBsYW1iIGxv
/ tr rgs
con
dmUgTWFyeSBzbywiCnRoZSBlYWdlciBjaGlsZHJlbiBjcnkuCgoiV2h5LCBNYXJ5IGxvdmVzIHRo
ess
acc es
ZSBsYW1iLCB5b3Uga25vdy4iClRoZSBsYW1iLCB5b3Uga25vdywgdGhlIGxhbWIsIHlvdSBrbm93
ote servic
LAoiV2h5LCBNYXJ5IGxvdmVzIHRoZSBsYW1iLCB5b3Uga25vdywiCnRoZSB0ZWFjaGVyIGRpZCBy
Remktop
ZXBseS4KJHAK
4%
des
–
10%
25%
17%
+
88% s
Org
54% ger
Lar
rgs
34% All
O
20%
30. “Information Security” Sucks
Figu
re 21
. Hac
king
meth
ods b
y per
cent
Expl
oitat of br
ion o each
f es w
defa
ult o ithin
r gue Hack
ssab ing
le cr
eden
Use tials
of st
olen
login
cred
Brut entia 9%
Expl e for ls
oitat ce an
ion o d dic
f bac tiona
kdoo ry at
r or c tack
omm s
and a
Expl nd co 55%
oitat ntrol
ion o chan 40%
f ins nel +#
uffic 14%
ient 29%
auth –
no lo entica 51%
(e.g.,
gin r t
equirion 25%
ed) 6% –#
SQL 3% 29%
injec
tion
Rem 3%–
ote fi
le inclu
sion 1% 14%
Abus
e of
func 6%
tiona <1%
lity #
Unkn 3%
VGhhbmsgeW91IGZvciBwYXJ0aWNpcGF0aW5nIGluIHRoZSAyMDEyIFZlcml6b24gREJJUiBDb3Zl own
4%
#
ciBDaGFsbGVuZ2UuCldlIGhvcGUgeW91IGVuam95IHRoaXMgY2hhbGxlbmdlIGFzIG11Y2ggYXMg
d2UgaGF2ZSBlbmpveWVkIGNyZWF0aW5nIGl0LiAgCgoKVGhlcmUgb25jZSB3YXMgYSBsYWR5IGZy
b20gTmFudHVja2V0LApXaXRoIHRleHQgc28gd2lkZSB3ZSBjb3VsZCBncm9rIGl0Lgp3ZSBjaG9w
cGVkIGFuZCBzbGljZWQgaXQgYWxsIGRheSBsb25nLApPbmx5IHRvIGZpbmQgc2hlIHdhc27igJl0
IGFsbCB3cm9uZy4KCldpdGggc2tpbGwgYW5kIGVhc2Ugd2UgYmF0dGxlZCB0aGlzIGZpZ2h0LApF
king
eGNlcHQgc2hlIHdhcyBub3QgdG90YWxseSByaWdodC4KVHdpc3RpbmcgYW5kIHR1cm5pbmcgd2Ug
Hac
a2VwdCBvbiBzdHJvbmcsCldlIHNob3VsZCBoYXZlIGJlZW4gc2luZ2luZyBhbGwgYWxvbmc6CgpN
hin
wit
YXJ5IGhhZCBhIGxpdHRsZSBsYW1iLApsaXR0bGUgbGFtYiwgbGl0dGxlIGxhbWIsCk1hcnkgaGFk
es 31%
IGEgbGl0dGxlIGxhbWIsCndob3NlIGZsZWVjZSB3YXMgd2hpdGUgYXMgc25vdy4KCkFuZCBldmVy
ch
eXdoZXJlIHRoYXQgTWFyeSB3ZW50LApNYXJ5IHdlbnQsIE1hcnkgd2VudCwKYW5kIGV2ZXJ5d2hl
rea wn
of b
cmUgdGhhdCBNYXJ5IHdlbnQsCnRoZSBsYW1iIHdhcyBzdXJlIHRvIGdvLgoKSXQgZm9sbG93ZWQg
nt kno
aGVyIHRvIHNjaG9vbCBvbmUgZGF5CnNjaG9vbCBvbmUgZGF5LCBzY2hvb2wgb25lIGRheSwKSXQg
rce Un
Zm9sbG93ZWQgaGVyIHRvIHNjaG9vbCBvbmUgZGF5LAp3aGljaCB3YXMgYWdhaW5zdCB0aGUgcnVs
y pe
ZXMuCgpJdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheSwKbGF1Z2ggYW5kIHBsYXks
rs b ion
IGxhdWdoIGFuZCBwbGF5LAppdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheQp0byBz
vec
to icat All O
ZWUgYSBsYW1iIGF0IHNjaG9vbC4KCkFuZCBzbyB0aGUgdGVhY2hlciB0dXJuZWQgaXQgb3V0LAp0
ppl rgs
ing ba
dXJuZWQgaXQgb3V0LCB0dXJuZWQgaXQgb3V0LApBbmQgc28gdGhlIHRlYWNoZXIgdHVybmVkIGl0
ck r We
IG91dCwKYnV0IHN0aWxsIGl0IGxpbmdlcmVkIG5lYXIsCgpBbmQgd2FpdGVkIHBhdGllbnRseSBh
. Ha or o l
Ym91dCwKcGF0aWVudGx5IGFib3V0LCBwYXRpZW50bHkgYWJvdXQsCkFuZCB3OGVkIHBhdGllbnRs
2 2 kdo nne Larg
ure Bac ol cha
eSBhYm91dAp0aWxsIE1hcnkgZGlkIGFwcGVhci4KCiJXaHkgZG9lcyB0aGUgbGFtYiBsb3ZlIE1h
Fig er O
cnkgc28/IgpMb3ZlIE1hcnkgc28/IExvdmUgTWFyeSBzbz8KIldoeSBkb2VzIHRoZSBsYW1iIGxv
/ tr rgs
con
dmUgTWFyeSBzbywiCnRoZSBlYWdlciBjaGlsZHJlbiBjcnkuCgoiV2h5LCBNYXJ5IGxvdmVzIHRo
ess
acc es
ZSBsYW1iLCB5b3Uga25vdy4iClRoZSBsYW1iLCB5b3Uga25vdywgdGhlIGxhbWIsIHlvdSBrbm93
ote servic
LAoiV2h5LCBNYXJ5IGxvdmVzIHRoZSBsYW1iLCB5b3Uga25vdywiCnRoZSB0ZWFjaGVyIGRpZCBy
Remktop
ZXBseS4KJHAK
4%
des
–
10%
25%
17%
+
88% s
Org
54% ger
Lar
rgs
34% All
O
20%
31. “Information Security” Sucks
Figu
re 21
. Hac
king
meth
ods b
y per
cent
Expl
oitat of br
ion o each
f es w
defa
ult o ithin
r gue Hack
ssab ing
le cr
eden
Use tials
of st
olen
login
cred
Brut entia 9%
Expl e for ls
oitat ce an
ion o d dic
f bac tiona
kdoo ry at
r or c tack
omm s
and a
Expl nd co 55%
oitat ntrol
ion o chan 40%
f ins nel +#
uffic 14%
ient 29%
auth –
no lo entica 51%
(e.g.,
gin r t
equirion 25%
ed) 6% –#
SQL 3% 29%
injec
tion
Rem 3%–
ote fi
le inclu
sion 1% 14%
Abus
e of
func 6%
tiona <1%
lity #
Unkn 3%
VGhhbmsgeW91IGZvciBwYXJ0aWNpcGF0aW5nIGluIHRoZSAyMDEyIFZlcml6b24gREJJUiBDb3Zl own
4%
#
ciBDaGFsbGVuZ2UuCldlIGhvcGUgeW91IGVuam95IHRoaXMgY2hhbGxlbmdlIGFzIG11Y2ggYXMg
d2UgaGF2ZSBlbmpveWVkIGNyZWF0aW5nIGl0LiAgCgoKVGhlcmUgb25jZSB3YXMgYSBsYWR5IGZy
b20gTmFudHVja2V0LApXaXRoIHRleHQgc28gd2lkZSB3ZSBjb3VsZCBncm9rIGl0Lgp3ZSBjaG9w
cGVkIGFuZCBzbGljZWQgaXQgYWxsIGRheSBsb25nLApPbmx5IHRvIGZpbmQgc2hlIHdhc27igJl0
IGFsbCB3cm9uZy4KCldpdGggc2tpbGwgYW5kIGVhc2Ugd2UgYmF0dGxlZCB0aGlzIGZpZ2h0LApF
king
eGNlcHQgc2hlIHdhcyBub3QgdG90YWxseSByaWdodC4KVHdpc3RpbmcgYW5kIHR1cm5pbmcgd2Ug
Hac
a2VwdCBvbiBzdHJvbmcsCldlIHNob3VsZCBoYXZlIGJlZW4gc2luZ2luZyBhbGwgYWxvbmc6CgpN
hin
wit
YXJ5IGhhZCBhIGxpdHRsZSBsYW1iLApsaXR0bGUgbGFtYiwgbGl0dGxlIGxhbWIsCk1hcnkgaGFk
es 31%
IGEgbGl0dGxlIGxhbWIsCndob3NlIGZsZWVjZSB3YXMgd2hpdGUgYXMgc25vdy4KCkFuZCBldmVy
ch
eXdoZXJlIHRoYXQgTWFyeSB3ZW50LApNYXJ5IHdlbnQsIE1hcnkgd2VudCwKYW5kIGV2ZXJ5d2hl
rea wn
of b
cmUgdGhhdCBNYXJ5IHdlbnQsCnRoZSBsYW1iIHdhcyBzdXJlIHRvIGdvLgoKSXQgZm9sbG93ZWQg
nt kno
aGVyIHRvIHNjaG9vbCBvbmUgZGF5CnNjaG9vbCBvbmUgZGF5LCBzY2hvb2wgb25lIGRheSwKSXQg
rce Un
Zm9sbG93ZWQgaGVyIHRvIHNjaG9vbCBvbmUgZGF5LAp3aGljaCB3YXMgYWdhaW5zdCB0aGUgcnVs
y pe
ZXMuCgpJdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheSwKbGF1Z2ggYW5kIHBsYXks
rs b ion
IGxhdWdoIGFuZCBwbGF5LAppdCBtYWRlIHRoZSBjaGlsZHJlbiBsYXVnaCBhbmQgcGxheQp0byBz
vec
to icat All O
ZWUgYSBsYW1iIGF0IHNjaG9vbC4KCkFuZCBzbyB0aGUgdGVhY2hlciB0dXJuZWQgaXQgb3V0LAp0
ppl rgs
ing ba
dXJuZWQgaXQgb3V0LCB0dXJuZWQgaXQgb3V0LApBbmQgc28gdGhlIHRlYWNoZXIgdHVybmVkIGl0
ck r We
IG91dCwKYnV0IHN0aWxsIGl0IGxpbmdlcmVkIG5lYXIsCgpBbmQgd2FpdGVkIHBhdGllbnRseSBh
. Ha or o l
Ym91dCwKcGF0aWVudGx5IGFib3V0LCBwYXRpZW50bHkgYWJvdXQsCkFuZCB3OGVkIHBhdGllbnRs
2 2 kdo nne Larg
ure Bac ol cha
eSBhYm91dAp0aWxsIE1hcnkgZGlkIGFwcGVhci4KCiJXaHkgZG9lcyB0aGUgbGFtYiBsb3ZlIE1h
Fig er O
cnkgc28/IgpMb3ZlIE1hcnkgc28/IExvdmUgTWFyeSBzbz8KIldoeSBkb2VzIHRoZSBsYW1iIGxv
/ tr rgs
con
dmUgTWFyeSBzbywiCnRoZSBlYWdlciBjaGlsZHJlbiBjcnkuCgoiV2h5LCBNYXJ5IGxvdmVzIHRo
ess
acc es
ZSBsYW1iLCB5b3Uga25vdy4iClRoZSBsYW1iLCB5b3Uga25vdywgdGhlIGxhbWIsIHlvdSBrbm93
ote servic
LAoiV2h5LCBNYXJ5IGxvdmVzIHRoZSBsYW1iLCB5b3Uga25vdywiCnRoZSB0ZWFjaGVyIGRpZCBy
Remktop
ZXBseS4KJHAK
4%
des
–
10%
25%
17%
+
88% s
Org
54% ger
Lar
rgs
34% All
O
20%
33. API Security Sucks Harder
✤ Most Security Drones can’t spell XML
✤ ...they rarely use SOAP
✤ ...they don’t get REST
✤ SSL and Firewalls: the breakfast of champions
35. Fool! You Fell Victim To One Of
the Classic Blunders!
✤ Never Get Involved In
a Cloud War In Asia
36. Fool! You Fell Victim To One Of
the Classic Blunders!
✤ Never Get Involved In
a Cloud War In Asia
✤ Never Go In Against a
Dutchman When APIs
Are On the Line!
37. Fool! You Fell Victim To One Of
the Classic Blunders!
✤ Never Get Involved In
a Cloud War In Asia
✤ Never Go In Against a
Dutchman When APIs
Are On the Line!
38. Fool! You Fell Victim To One Of
the Classic Blunders!
✤ Never Get Involved In
a Cloud War In Asia
✤ Never Go In Against a
Dutchman When APIs
Are On the Line!
* You Can Order Iocaine Powder On Amazon - Free Shipping With Prime!
39. Sh*T My Cloud Evangelist Fails to say...
CE
NS
OR
ED
As illustrated by George’s
7 Dirty Words
49. Scalability
✤ Distributed Networked System problems are tough; Distributed
Networked System Security problems are tougher
50. Scalability
✤ Distributed Networked System problems are tough; Distributed
Networked System Security problems are tougher
✤ “Traditional” security doesn’t scale across distributed software-driven
architecture; policies disconnected from workloads...more complicated
as we go from IaaS > PaaS
51. Scalability
✤ Distributed Networked System problems are tough; Distributed
Networked System Security problems are tougher
✤ “Traditional” security doesn’t scale across distributed software-driven
architecture; policies disconnected from workloads...more complicated
as we go from IaaS > PaaS
✤ Unfortunate reconciliation of Metcalfe’s Law vs. Moore's Law vs. HD
Moore’s Law (Casual Attacker power grows at the rate of Metasploit)
52. Scalability
✤ Distributed Networked System problems are tough; Distributed
Networked System Security problems are tougher
✤ “Traditional” security doesn’t scale across distributed software-driven
architecture; policies disconnected from workloads...more complicated
as we go from IaaS > PaaS
✤ Unfortunate reconciliation of Metcalfe’s Law vs. Moore's Law vs. HD
Moore’s Law (Casual Attacker power grows at the rate of Metasploit)
✤ Security is not programmatic & leveragable automation across
heterogenous systems in security is LULZ
54. Security@Scale
✤ It doesn’t. The MeatCloud giveth, the MeatCloud
taketh away...
55. Security@Scale
✤ It doesn’t. The MeatCloud giveth, the MeatCloud
taketh away...
✤ Beyond Gb/s, Connections/s, flows, etc., security
requires the notion of context, policy, and potentially
state...eventual consistency doesn’t work with
security
56. Security@Scale
✤ It doesn’t. The MeatCloud giveth, the MeatCloud
taketh away...
✤ Beyond Gb/s, Connections/s, flows, etc., security
requires the notion of context, policy, and potentially
state...eventual consistency doesn’t work with
security
✤ The Self-Defending {network | application} is
complicated simultaneously with the concepts of
“data gravity” and mobility
62. Portability
✤ If we don’t have consistency in standards/formats for
workloads & stack insertion, we’re not going to have
consistency in security; Lack of consistent telemetry
63. Portability
✤ If we don’t have consistency in standards/formats for
workloads & stack insertion, we’re not going to have
consistency in security; Lack of consistent telemetry
✤ Inconsistent policies and network topologies make security
service, topology & device-specific...flatter means
responses to “network” attacks must be dealt with by the
application...or not
64. Portability
✤ If we don’t have consistency in standards/formats for
workloads & stack insertion, we’re not going to have
consistency in security; Lack of consistent telemetry
✤ Inconsistent policies and network topologies make security
service, topology & device-specific...flatter means
responses to “network” attacks must be dealt with by the
application...or not
✤ Abstraction has become a distraction
65. Portability
✤ Dude, Where’s My IOS ACL
5-Tuple!?
Working with VMware vShield REST API in perl. Richard Park, Sourcefire
66. Portability
✤ ...or this:
AWS Security : A Practitioner’s Perspective. Jason Chan, Netflix
68. Fungibility
✤ Fundamentally, we need reusable and programmatic
security design patterns; Controls today are CLI/GUI based
69. Fungibility
✤ Fundamentally, we need reusable and programmatic
security design patterns; Controls today are CLI/GUI based
✤ Few are API-driven or feature capabilities for
orchestration, provisioning as the workloads they protect
70. Fungibility
✤ Fundamentally, we need reusable and programmatic
security design patterns; Controls today are CLI/GUI based
✤ Few are API-driven or feature capabilities for
orchestration, provisioning as the workloads they protect
✤ Each level of “the stack” means security controls can’t be
reused and are “slice” specific (more on this in a minute)
71. Fungibility
✤ Fundamentally, we need reusable and programmatic
security design patterns; Controls today are CLI/GUI based
✤ Few are API-driven or feature capabilities for
orchestration, provisioning as the workloads they protect
✤ Each level of “the stack” means security controls can’t be
reused and are “slice” specific (more on this in a minute)
✤ If we’re having trouble digesting IaaS, guess what PaaS
does to the conversation?
72. Fungibility
✤ Fundamentally, we need reusable and programmatic
security design patterns; Controls today are CLI/GUI based
✤ Few are API-driven or feature capabilities for
orchestration, provisioning as the workloads they protect
✤ Each level of “the stack” means security controls can’t be
reused and are “slice” specific (more on this in a minute)
✤ If we’re having trouble digesting IaaS, guess what PaaS
does to the conversation?
74. The Hamster Sine Wave of Pain...*
The Security Hamster Sine Wave of Pain
Network
Centricity
Control Deployment/Investment Focus
User
Centricity
Information
Centricity
Application
Centricity
Host
Centricity
Time
* With Apologies to Andy Jaquith & His Hamster...
75. The Hamster Sine Wave of Pain...*
The Security Hamster Sine Wave of Pain
Network
Centricity
Control Deployment/Investment Focus
User
Centricity
Information
Centricity
Cloud
Application
Centricity
Host
Centricity
Time
* With Apologies to Andy Jaquith & His Hamster...
76. The Hamster Sine Wave of Pain...*
The Security Hamster Sine Wave of Pain
We Are Here
Network
Centricity
Control Deployment/Investment Focus
User
Centricity
Information
Centricity
Cloud
Application
Centricity
Host
Centricity
Time
* With Apologies to Andy Jaquith & His Hamster...
77. The Hamster Sine Wave of Pain...*
The Security Hamster Sine Wave of Pain
We Are Here
Network
Centricity
Control Deployment/Investment Focus
User
Centricity
Information
Centricity
Cloud
Application
Centricity
Host
Centricity
Deployment Is Here
Time
* With Apologies to Andy Jaquith & His Hamster...
80. Compliance
✤ Security != Compliance and “security” doesn’t matter
✤ Regulatory compliance and frameworks don’t address
emerging/disruptive innovation quickly enough - or at
all
81. Compliance
✤ Security != Compliance and “security” doesn’t matter
✤ Regulatory compliance and frameworks don’t address
emerging/disruptive innovation quickly enough - or at
all
✤ How do we demonstrate compliance against
measurements that don’t exist?
82. Compliance
✤ Security != Compliance and “security” doesn’t matter
✤ Regulatory compliance and frameworks don’t address
emerging/disruptive innovation quickly enough - or at
all
✤ How do we demonstrate compliance against
measurements that don’t exist?
✤ Lack of automation for gathering audit/compliance
artifacts
84. Mapping the Model to the Metal
Cloud Model
Presentation Presentation
Modality Platform
APIs
Applications
Data Metadata Content
Integration & Middleware
APIs
Core Connectivity & Delivery
Software as a Service (SaaS)
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Abstraction
Hardware
Facilities
85. Mapping the Model to the Metal
Cloud Model
Presentation Presentation
Modality Platform
APIs
Security Control Model
Applications SDLC, Binary Analysis,
Applications Scanners, WebApp Firewalls,
Transactional Sec.
Data Metadata Content
DLP, CMF, Database Activity
Information Monitoring, Encryption
Integration & Middleware
GRC, IAM, VA/VM, Patch
Management Management, Config.
Management, Monitoring
APIs
Core Connectivity & Delivery NIDS/NIPS, Firewalls, DPI,
Software as a Service (SaaS)
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Network Anti-DDoS, QoS, DNSSEC
Abstraction
Trusted Computing Hardware & Software RoT & API’s
Host-based Firewalls, HIDS/
Hardware HIPS, Integrity & File/log
Compute & Storage
Management, Encryption,
Masking
Physical Plant Security, CCTV,
Facilities Physical Guards
86. Mapping the Model to the Metal
Cloud Model
Presentation Presentation
Modality Platform
APIs
Security Control Model
Applications SDLC, Binary Analysis,
Applications Scanners, WebApp Firewalls,
Transactional Sec. Compliance Model
Data Metadata Content
Information
DLP, CMF, Database Activity PCI
Monitoring, Encryption
Integration & Middleware Firewalls
GRC, IAM, VA/VM, Patch Code Review
Management, Config. WAF
Management Encryption
Management, Monitoring
APIs
Unique User IDs
Anti-Virus
Monitoring/IDS/IPS
Patch/Vulnerability MgMt
Physical Access Control
Core Connectivity & Delivery NIDS/NIPS, Firewalls, DPI,
Software as a Service (SaaS)
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Two-Factor Authentication...
Network Anti-DDoS, QoS, DNSSEC
Abstraction
Hardware & Software RoT & API’s
Trusted Computing
HIPAA
Host-based Firewalls, HIDS/
HIPS, Integrity & File/log
Hardware Compute & Storage
Management, Encryption,
ISO
Masking
Facilities Physical
Physical Plant Security, CCTV, COBIT
Guards