the end of security as we know it - shannon lietz
TRANSCRIPT
1
The End of Security as We Know It …
Shannon Lietz Intuit
2 Copyright © DevSecOps Foundation 2015-2016
• Over two decades of Tech & Security
• Passionate Security Evangelist; Not a Vendor
• Clean-up Crew for some of the Industry’s Biggest Breaches
• Practitioner & Culture Hacker
Who am I?
3 Copyright © DevSecOps Foundation 2015-2016
• DevOps• Public Cloud • Agile• Scrum• Lean• Low-Code• No-Code• No Ops• More Ops• Sec Ops• Everything Ops• …
What’s Happening in the World?
https://www.google.com/trends/
4 Copyright © DevSecOps Foundation 2015-2016
Who’s doing Enterprise DevOps?
…
5 Copyright © DevSecOps Foundation 2015-2016
What’s the business benefit?
Business strategy is achieved with the collaboration of all departments and providers in service to the customer who requires better, faster, cheaper,
secure products and services.
6 Copyright © DevSecOps Foundation 2015-2016
What Hinders Enterprise DevOps…
1. Manual processes & meeting culture2. Point in time assessments3. Friction for friction’s sake4. Contextual misunderstandings5. Decisions being made outside of value creation6. Late constraints and requirements7. Big commitments, big teams, and big failures 8. Fear of failure, lack of learning 9. Lack of inspiration10. Management and political interference (approvals, exceptions)...
7 Copyright © DevSecOps Foundation 2015-2016
“THIS IS THE ENDOF SECURITY ASWE KNOW IT ...” - Josh Corman
8 Copyright © DevSecOps Foundation 2015-2016
The Secure Software Supply Chain Gating processes are not Deming-likeSecurity is a design constraintDecisions made by engineering teams
Hard to avoid business catastrophes by applying one-size-fits-all strategies Security defects is more like a security “recall”
design build deploy operate
How do I secure my app?
What component is secure enough?
How do I secure secrets for the
app?
Is my app getting attacked? How?
Typical gates for security
checks & balances
Mistakes and drift often happen after design and build phases that
result in weaknesses and potentially exploits
Most costly mistakesHappen during design
Faster security feedback loop
9 Copyright © DevSecOps Foundation 2015-2016
From a traditional supply chain
When will you solve my problem?!! Can we discuss my feedback?
10 Copyright © DevSecOps Foundation 2015-2016
To a customer-centric supply chain
Awesome!When can I bring my kids with me?Does it come in Red?
Can this be motorizedto go faster and for longer trips?
Better than walking, for sure …but not by much...
Security must shift left with a science mindset
11 Copyright © DevSecOps Foundation 2015-2016
Migrating Security to the Left where it can get built-in
design build deploy operate
How do I secure my app?
What component is secure enough?
How do I secure secrets for the
app?
Is my app getting attacked? How?
Typical gates for security
checks & balances
Mistakes and drift often happen after design and build phases that
result in weaknesses and potentially exploits
Most costly mistakesHappen during design
Faster security feedback loop
Security is a Design Constraint
12 Copyright © DevSecOps Foundation 2015-2016
Security is a design constraint…
13 Copyright © DevSecOps Foundation 2015-2016
The Security Feedback Loop
THE FEEDBACK HIGHWAY
Customer
Feedback
Attacke
rActi
vity
Production
Monitorin
g
PRODUCT SCRUM TEAM
System
RegressionCICD
BuildUnit
Tests
THE INTEL HIGHWAY
SECURITY TESTING & DATA PLATFORMSECURITY TEAM SECURITY COMMUNITY
14 Copyright © DevSecOps Foundation 2015-2016
The Art of DevSecOps
DevSecOps
Security Engineering
Experiment, Automate, Test
Security Operations
Hunt, Detect, Contain
Compliance Operations
Respond, Manage, Train
Security Science
Learn, Measure, Forecast
15 Copyright © DevSecOps Foundation 2015-2016
Your reality is changing...
Internet
Clou
d Pr
ovid
er N
etw
ork
Clou
d Pr
ovid
er N
etw
ork
Clou
d Pr
ovid
er N
etw
ork
Clou
d Pr
ovid
er N
etw
ork
Data
Cen
ter
Data
Cen
ter
Clou
d Pr
ovid
er N
etw
ork
16 Copyright © DevSecOps Foundation 2015-2016
Attacks are changing…
API KEY EXPOSURE ->
8 HRS
DEFAULT CONFIGS ->
24 HRS
SECURITY GROUPS ->
24 HRS
ESCALATION OF PRIVS ->
5 D
KNOWN VULN ->
8 HRS
17 Copyright © DevSecOps Foundation 2015-2016
Security Events are Spreading out…
18 Copyright © DevSecOps Foundation 2015-2016
Monitor & Inspect Everything
insightssecuritysciencesecurity
tools & data
Cloud accounts
S3
Glacier
EC2
CloudTrail
ingestion
threat intel
SPEED MATTERS
security feedback loop continuous response
Your job is changing…
19 Copyright © DevSecOps Foundation 2015-2016
Security Decisions & Processes are changing…
20 Copyright © DevSecOps Foundation 2015-2016
Security Controls are changing…
SecurityMonitoring
21 Copyright © DevSecOps Foundation 2015-2016
What’s this look like in practice?
Etc… Etc... Etc...
22 Copyright © DevSecOps Foundation 2015-2016
Account Sharding is a new control!
Splitting cloud workloads into many accounts has a benefit.Accounts should contain less than 100% of a cloud workload.Works well with APIs; works dismal with forklifts.What is your appetite for risk?
Cloud WorkloadTemplates
Clou
d Pr
ovid
er N
etw
ork
33 % 33 % 33 %
Clou
d Ac
coun
t
Clou
d Ac
coun
t
Clou
d Ac
coun
t
attacker
23 Copyright © DevSecOps Foundation 2015-2016
Long live APIs…
Everything in the cloud should be an API, even Security…Protocols that are not cloudy should not span across environments.If you wouldn’t put it on the Internet then you should put an API and Authentication in front of it:
MessagingDatabasesFile TransfersLogging
Clou
d Pr
ovid
er N
etw
ork
Tested machine image…Tested instances...Tested roles...Tested passwords...
New instance created…Instance 12345 changed…User ABC accessed Instance 12345...
B
User Routing
Data Replication
ApplicationGateway
File Transfers
Log Sharing
Messaging
My API
24 Copyright © DevSecOps Foundation 2015-2016
Host-Based Controls
Shared Responsibility and Cloud require host-based controls.Instrumentation is everything!Fine-grained controls require more scrutiny and bigger big data analysis.Agents & Outbound Reporting to an API are critical Cl
oud
Prov
ider
Net
wor
k
InstanceInstance
Tested machine image…Tested instances...Tested roles...Tested passwords...
New instance created…Instance 12345 changed…User ABC accessed Instance 12345...
B
25 Copyright © DevSecOps Foundation 2015-2016
10 DAYS
Don’t Hug Your Instances…
Research suggests that you should replace your instances at least every 10 days, and that may not be often enough.Use Blue/Green or Red/Black deployments to reduce security issues by baking in patching.Make sure to keep a snapshot for forensic and compliance purposes.Use config management automation to make changes part of the stack.Refresh routinely; refresh often!
26 Copyright © DevSecOps Foundation 2015-2016
• Paper-resident policies do not stand up to constant cloud evolution and lessons learned.
• Translation from paper to code can lead to mistakes.
• Traditional security policies do not 1:1 translate to Full Stack deployments.
Code can solve the great divide…
Data
Cen
ter
Clou
d Pr
ovid
er
Net
wor
k
• LOCK YOUR DOORS• BADGE IN• AUTHORIZED PERSONNEL ONLY• BACKGROUND CHECKS
• CHOOSE STRONG PASSWORDS• USE MFA• ROTATE API CREDENTIALS• CROSS-ACCOUNT ACCESS
EVERYTHING AS CODE
Page 3 of 433
27 Copyright © DevSecOps Foundation 2015-2016
But the change could be worth it…This could be your mean time to recovery (MTTR)
MTT
R
Days… 6 months
28 Copyright © DevSecOps Foundation 2015-2016
Still not convinced? We’ve actually been talking about it for a long time…
https://www.kpmg.com/BE/en/IssuesAndInsights/ArticlesPublications/Documents/Transforming-Internal-Audit.pdf
29 Copyright © DevSecOps Foundation 2015-2016
DevSecOps Today…
https://www.google.com/trends/
30 Copyright © DevSecOps Foundation 2015-2016
• devsecops.org• @devsecops on Twitter• DevSecOps on LinkedIn• DevSecOps on Github• RuggedSoftware.org• Compliance at Velocity
Join Us !!!Spread the word!!!
Get Involved & Join the Community