This document discusses principles for DevOps and security teams to collaborate effectively. It recommends building a detection network using services like AWS GuardDuty and canary tokens to monitor for anomalies. It also advocates automating configurations ruthlessly using infrastructure as code and consulting across organizational boundaries between security and engineering teams. The presenters provide examples from their company of how these principles have been applied.

1. DevOps and SecOps and Bears, oh my!
A safe way to move fast

2. 2
This is a picture of a bear

3. Agenda
5 min Our Story
10 min Building a Detection Network
10 min Automate Ruthlessly
10 min Consult Up, Down and Across
10 min Q/A
3

4. Who are we?
● We work @ Dwolla
● Information Security + Engineering leaders: we
collaborate every day
● We are hiring! (Information Security and Engineering)
dwolla.com/careers
4

5. Our Story
● We began in a hosted environment
● We chose to move to a cloud provider
● Agile software development practices and test driven
development
● The move required close collaboration between
Engineering and Information Security teams
● Path was forged based on trust, automation, detection
and continuous improvement
5

6. Why should you listen to us?
● Winning businesses utilize these practices
● It is not cost effective to pay humans to configure things
● The human emotions of stress and pressure do not change
the outcome of a computer running a program
● It’s simple to configure something once manually; it’s not
simple to do it 2000 times
○ API deployed 1200 times, 3 instances per deployment 3600
instances (one system)
6

7. This isn’t
theoretical…
...it is actually
another
picture of a
bear.
7

8. This isn’t theoretical...
8

9. This isn’t theoretical...
9

10. This isn’t theoretical...
10

11. This isn’t theoretical...
11

12. ● Your platform is a detection network
● Ruthless automation provides you scalability, availability,
and recoverability
● Your team should consult up, down, and across the
organization
12
These are principles you can apply now...

13. Building a Detection Network
Rationale: Prevention will eventually fail.
● When prevention fails, detection is imperative.
● You need alarms that should never go off.
13

14. Building a Detection Network
Rationale: Adversaries have evolved
● If employees use reports and GUIs, adversaries seek raw
data stores, CLIs and APIs.
● Adversaries seek to move inside an environment
without detection.
● Example: Lateral Movement is a key indicator of a
security event.
14

15. ● You already know a lot about yourself
○ When are customers active?
○ What network things talk to other network things?
○ Which machines talk to the internet?
● We should be alerted if something outside our normal
activity occurs
● Unexpected activity is detectable
Building a Detection Network: AWS GuardDuty
15

16. ● AWS Alerting Service based on synthesis and analysis of:
○ Network traffic flows
○ DNS traffic activity
○ AWS API/IAM usage
● Alerts for persistence, backdoors, recon/scanning,
resource consumption, cryptocurrency mining, etc.
● Very cost effective
Building a Detection Network: AWS GuardDuty
16

17. Building a Detection Network: AWS GuardDuty
17

18. Nobody should touch these instances, files, tokens. We know
this, but our adversaries don’t.
Building a Detection Network: Thinkst Canaries
18

19. Here’s a QR code canary token:
Here’s a link to a canary token: https://bit.ly/2O5w5V1
[default]
aws_access_key_id=AKIAJCPBXSIQ6RTWY7QA
aws_secret_access_key=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
19
Building a Detection Network: Thinkst Canaries

20. 20
Building a Detection Network: Thinkst Canaries

21. Automate Ruthlessly
Write code and build systems to save time.
It is a safe way to move fast.
21

22. Automate Ruthlessly: DNS Management at
Cloudflare
● You have source control, continuous integration, and
continuous delivery tools
● The metadata about maintaining a healthy codebase
can answer lot of the questions we have about
configuration (in this example, DNS).
○ Is it in production? Who made this change? Who
approved? When did we do this?
● This is release management and change advisory
board build into the core software engineering process
22

23. Automate Ruthlessly: DNS Management at
Cloudflare
● DNS is just one piece of configuration at your edge, you
also probably have
○ Certs
○ Firewall
○ Rate limiting
● What can possibly remember all the configuration we
made? Computers.
● Changes not made via code are rogue - great
signal/noise ratio.
23

24. Consult Up, Down and Across
Find out what others are building and help them
● Don’t just sit in the corner and audit
● Learn the company, how things are being used
24

25. Consult Up, Down and Across: Duo Security
● We have to protect our assets.
● Removing single factor authentication is an important
objective.
○ We seek to devalue passwords.
● Installing Duo requires a PAM configuration (Linux) or an
installer to augment the Windows Credential Provider.
25

26. Consult Up, Down and Across: Duo Security
26

27. 27

28. 28

29. Consult Up, Down and Across: Training and
Standards
● Engineering team is trained on the proper
implementation of cryptography, OWASP, etc.
● Security team is trained and expected to follow
engineering standards.
● We hold each other accountable and challenge ideas.
29

30. Consult Up, Down and Across: Not in the Corner
● Security is seated with Engineering
● Throwing problems/reports/bugs over the wall is not
acceptable
● Examples of collaboration:
○ Token protection schemes at a
whiteboard to find
performance/security balance
30

31. ● Your platform is a detection network
● Ruthless automation provides you scalability, availability,
and recoverability
● Your team should consult up, down, and across the
organization
31
Three Principles

32. Other Talks We Like
● Enterprise Security - A New Hope
● Security Automation - Duo Tech Talk
● Preventing Attacks At Scale - Dino Dai Zovi
32

33. Questions?
Thanks for coming!
We are hiring!
dwolla.com/careers
33