Developing a Rugged DevOps Approach to Cloud Security

DT3
Session
6/9/16 1:30 PM

Developing a Rugged DevOps Approach
to Cloud Security

Presented by:

Tim Prendergast
Evident.io

Brought to you by:

350 Corporate Way, Suite 400, Orange Park, FL 32073
888---268---8770 ·· 904---278---0524 - info@techwell.com - http://www.techwell.com/

Tim Prendergast
Evident.io

Co-founder and CEO of Evident.io Tim Prendergast (@Auxome) is a passionate
security practitioner who seeks to help others avoid the pain he endured when
leading Adobe's initiative to adopt the cloud at a massive level. After more than
fifteen years of building, operating, and securing services in AWS, including eight
years in AWS security and three years building the Adobe AWS infrastructure,
Tim has set out to make security approachable and repeatable for organizations
of all sizes by creating the first security company focused solely on programmatic
infrastructures in the cloud. Tim previously led technology teams at Adobe,
Ingenuity, Ticketmaster, and McAfee.

Copyright © 2015 evident.io1
DEVELOPING A RUGGED DEVOPS
APPROACH TO CLOUD SECURITY
Tim Prendergast (@auxome)
9
“Through 2020, 80% of cloud breaches will be
due to customer misconfiguration,
mismanaged credentials or insider theft, not
cloud provider vulnerabilities.”
Published: 15 April 2015 
How much responsibility do we have?

AGREEING ON TERMINOLOGY
What is “the Cloud”? 
Programmatic infrastructure and services
evolved for dynamic use.
How can I get some “DevOps”? 
Engineers building and managing things  
smarter, faster, and with more automation.

How can I get some “DevOps”? 
Engineers building and managing things  
smarter, faster, and with more automation.
SPRINKLE ON SOME “RUGGED”?
Rugged DevOps
• Authored for RSA 2015
• Aggregation of philosophy from:
Gene Kim, Damon Edwards, Rich
Mogull, Josh Corman, James
Wicket, and that Tim Prendergast
weirdo
• Free download from: https://
evident.io/resources/rugged-devops/

WHY DO WE NEED TO GET RUGGED?
DevOps Security
The Pit
of Despair
THESE THINGS BELONG TOGETHER
&
&
&
&
&

BAD GUYS HAVE ADVANTAGES
• We have budgets, they have #winnings
• We have finite project cycles, they have a lifetime
• We have to sleep, they do not (as much)
• There are thousands of them, and often less than 3 or 4 of us.
• We cannot afford to hyper focus on any particular area…
Context Switching is the enemy of Security
THE CONTINUOUSLY DELIVERING ATTACKER
Attacker
IPv4 Space
of AWS
IPv4 Space
of GCE
IPv4 Space
of Azure
SCAN IDENTIFY COMPROMISE
Vulnerable
Instance
Misconfigured
Storage
Weak LB
Ciphers
“FREE
CANDY”
Drop rootkit, exfiltrate data,
deploy bot, proceed to SCAN
Dump data, locate high-value
data targets, sink hooks
Traffic interception/redirection,
decryption, and manipulation
Deploy batch jobs, mine bitcoin,
setup botnet/SCAN nodes, set
phishing campaign, exploit identity
relationships, etc…

THE EASY WIN
Sometimes people accidentally give away their keys via code,
SCM, and even support tickets.
THERE ARE TEN RUGGED CORE PRINCIPALS
Attackers are Automated, so we must be, too.

UNDERMINING CONTINUOUS ATTACKS
IDENTIFY COMPROMISESCAN
|____| |____|
Time (t) Time (t)
__________________________________
| |
Attack Lifecycle
REACTION TIME (DEFENDER CYCLE)
|____| |____|
Time (t) Time (t)
Post-vulnerability Defense Window
|_________________|

PROACTION (?!) TIME
|____| |____|
Time (t) Time (t)
|_________________|
|__________|
Proactive Security
… AND THE REMAINDER
|____| |____|
Time (t) Time (t)
|_________________|
|__________|
Proactive Security
|—————>
Game Over

ANYONE DOING SAT PREP?
Minutes (>, <, =) Weeks
ANYONE DOING SAT PREP?
Minutes < Weeks

THE REAL EQUATION ISSUE
Minutes < Weeks(Attackers) (Defenders)
RUGGED DEVOPS IS EQUALIZING
|____| |____|
Time (t) Time (t)
Proactive Security Posture Mgmt
|_________________|
|__________|
Preventative Measure
|—————>
Automated
Incident Response

OWNERSHIP IS SHARED
|____| |____|
Time (t) Time (t)
(Ops)
|_________________|
|__________|
(Dev)
|—————>
Automated
Incident Response
(Security)
AND NEW BONDS ARE FORMED
|____| |____|
Time (t) Time (t)
(DevSecOps)
|_________________|
|__________|
(DevSecOps)
|—————>
Automated
Incident Response
(DevSecOps)

TIMING IS EVERYTHING
TTD
TTR
TTC
TTE
=
=
=
=
Time to Detect
Time to Respond
Time to Contain
Time to Expunge
Think biological
Automate for (Acceleration + Force-Multiplication)

TEAMS, NOT SILOS
DevOps + Security
TEAMS, NOT SILOS
DevSecOps
Handoffs Fail. Collaborations win.

• Don’t give up if you don’t get everything at first
• Mutual goals and respect = mutual wins.
• Be at the design table early, and often.
SAY WHAT?
If you cannot articulate your security requirements,
you cannot create security as code.

SECURITY CLARITY IS NECESSITY
PCI DSS Req 3.5.1: Restrict access to cryptographic keys to the fewest
number of custodians necessary.
Translation: We never want more than 2 custodians with access to keys used
for encrypting sensitive data. If there are more than two, we need
to know (organization-wide) to prevent abuse or malicious access.
THIS LEADS TO SECURITY-AS-CODE
{
"Sid": “PCI DSS 3.5.1 - Control Key Access”,
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::0123456789:user/Custodian1",
"arn:aws:iam::0123456789:role/Custodian2"
]},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
configure do |c|
c.deep_inspection = [:alias_name, :alias_arn,
:target_key_id, :description, :creation_date,
:key_state, :deletion_date, :key_policies]
c.unique_identifier = [:alias_name]
end
def perform(aws)
key_aliases = aws.kms.list_aliases.aliases
key_aliases.each do |key_alias|
key_policies = aws.kms.list_key_policies({key_id:key_alias})
@custodians = key_policies.principal
custodians.each do |users|
{HERE'S THE FUN STUFF}

… AND THAT LEADS TO AUTOMATED TESTING
Code
Check-in
Unit Tests
Functional
Tests
Security
Tests
Environment
Promotion
Yes/
No
CONTINUOUS BEHAVIOR IS THE KEY
• Now you not only can continuously measure security posture
• … But you can:
• Proactively stop undesired risk from being promoted to prod
• Take automated mitigation steps against malicious changes
• Ensure corporate and regulatory policy conformity
• Obtain situational awareness of your dynamic environments

OPEN YOUR TECHNOLOGY TO THE ORG
The broader discussion is more valuable
than closed-door one(s)
THANK YOU
PS - We’re Hiring!

Developing a Rugged DevOps Approach to Cloud Security

More Related Content

What's hot

Viewers also liked

Similar to Developing a Rugged DevOps Approach to Cloud Security

More from TechWell

Recently uploaded

Developing a Rugged DevOps Approach to Cloud Security