Most companies value speed over security, which has traditionally been a blocker in delivering software. But with more and more breaches and vulnerabilities reported (Shellshock and Heartbleed to name a just few) it's more important than ever that security gets integrated into the operations process. Here are the top four ways to balance DevOps workflows while maintaining a pragmatic view on security.

1. 4 Steps to Integrate
DevOps Workflows With
Cloud Security Practices
By Pete Cheslock
Senior Director, Ops and Support at Threat Stack

2. Introductions
Pete Cheslock
Senior Director, Ops and Support
As the head of Threat Stack’s operations and support teams, Pete is focused on
delivering the highest level of service, reliability, and customer satisfaction to Threat
Stack’s growing user base. An industry veteran with over 15 years’ experience in
DevOps, Pete understands the challenges and issues faced by security, development
and operations professionals everyday and how Threat Stack can help.
You can find Pete on Twitter @PeteCheslock.

3. One of the biggest themes I’ve observed throughout
my career is:
Companies value speed over security.

4. …yet this approach has traditionally been
a blocker in delivering software.

5. Recently, however, with more and more
breaches and vulnerabilities reported
(i.e. Shellshock and Heartbleed),
it’s important now more than ever that
security gets integrated INTO
the operations process.

6. Here are the
4 Ways to Balance DevOps
Workflows With
Pragmatic Security:

7. 1. Recognize that tools enabling
DevOps also introduce new threats
and attack surfaces!

8. •Vagrant
•Packer
•Docker
•Chef
•Puppet
•Salt
•Ansible
•etc., etc.
Many apps have entered the
modern-day Ops toolbelt:

9. The problem that many of these tools
solve is the ability for engineers to:
• Manage more systems
• With more control
• And consistency
…than ever before!

10. With Ops Engineers now representing their
infrastructure as code, they can deploy
changes with much higher velocity and
much less risk than ever before.

11. And since their infrastructure is now
represented in source control, they can use
software engineering methodologies to
test their code, and can do so much
earlier in the Dev process.

12. With Docker and OSv, and the maturity
around orchestrating containers and
processes with tools like Kubernetes,
Mesos and others…
Ops Engineers can maintain a platform
that enables Software Engineers to ship
changes quickly and effectively.

13. The wall that existed between
Engineering and Operations is
now broken down!
Both sides are embracing change
and pushing updates frequently.

14. However, we’re now faced
with a new wall.
It exists between Security
and the rest of the technical
organization.

15. Fortunately, there are collaborative
ways to overcome this wall…

16. 2. Mitigate risk
while still moving fast

17. This is the classic “DevOps”
conversation all over again…

18. Developers want frequent change and/
or are being pushed forward for change by
the Product team…
…yet Operations teams want stability
and changes to their system could
introduce instability.

19. Now, both Dev and Ops teams are
enabling each other to ship
effectively using many of these
new tools to assist them.
Unfortunately, Security teams
have been left behind…

20. The ideal state is:
Security teams using and creating new tools
that enable them to insert security and risk control
in the same pipelines that Engineering and Operations
are using to deploy their changes.

21. (FYI: This is a BIG problem I’m excited
Threat Stack is solving
for Dev, Ops and Security teams)

22. For example…
If Ops teams use Chef to continually
update their systems at scale, Security
teams should be writing cookbooks
that setup and enforce security policies.

23. Or…
If Engineering is using Jenkins to
continuously integrate their code, Security
teams should add additional tooling into the
build pipeline to monitor for risk and threats.

24. 3. Let developers and others
have safe access to production

25. A practice I’ve seen work well is to put
the engineers on call for the specific
applications they own.

26. For example…
The Web team has a pager rotation and gets
alerts when there are issues with the web
servers.
The Search team gets alerts when search
clusters are OOMing.

27. But this can present a frightening reality
to Security teams who now have to
deal with both frequent changes to
the code AND an endless group of
people who have access to systems.

28. Trust but Verify
I’ve taken this approach when it comes to access control and
have implemented tools including:
• auditd
• OSSEC
• centralized logging

29. This helps ensure compliance, BUT:
•These tools are cumbersome to setup and configure.
•You don’t want them to come in the way of progress OR
performance.
This is why carefully increasing ownership works well among
teams.

30. 4. Build a system that will allow you
to regularly push to production with
security checks in place

31. The same CI tools (i.e. Jenkins) that Engineering
has been using to continuously integrate their
feature branches are the same tools Operations
can use to manage and deploy code (whether
or not this is the ideal solution).

32. Security teams should work to
integrate security tooling direction
into the automation pipelines to
allow for quick feedback loops
that Engineering and Operations
have become used to.

33. Building in
automation
+
Taking advantage of virtualized
cloud infrastructure
+
A workflow that empowers developers
to push code continuously
=
Companies can move fast when deploying and
managing apps with less overhead.

34. In a wrap…

35. As DevOps has evolved into a
mainstream philosophy, we’ve heard
more DevOps conversations on security-
related topics than ever before.
This process is the next logical step.

36. That means it’s more important than ever that
there is a unified understanding of the ways
to balance new DevOps workflows with
evolving cloud security practices.

37. To see how we’re enabling teams to integrate
these workflows:
Sign up: http://threatstack.com/
signup
Stay in touch: @ThreatStack