These are the slides that I used to introduce my birds of a feather session at fwd:cloudsec in 2022. They're brief by design.

1. Gabe Schuyler (@gabe_sky)
fwd:cloudsec birds of a feather
July, 2022
"Shifting right"
discussing policy as code
(or: how I learned to stop worrying and trust my devs)
Hi there, I'm Gabe. I'd initially proposed a whole talk on this, but I
didn't really have enough content -- which the organizers aptly pointed
out -- so rather than accept a half-assed presentation, they invited me
to do a birds of a feather session. Perfect!
The Chatham House rule
"Under the Chatham House rule, anyone who
comes to a meeting is free to use information
from the discussion, but is not allowed to reveal
who made any particular comment." (Wikipedia)
• Quotable yes
• Attributable no
• Compromise of "secret" and "o
ff
the record"
Chatham House, CC BY 2.0, via Wikimedia Commons
Yeah, this is a new one to me, too. Basically, we can all have a lovely
chat, and learn from each other. We can quote each other outside the
session, but without attribution. This means you can say whatever the
heck you want, without worrying that it'll hurt your reputation or a
ff
ect
your job. It's kind of cool.
A tale of DevOps
• Initially insert Ops (governance) into Dev
• Leads to trust
• Leads to cooperation
• Leads to "borrowing" tools and methods
• Infrastructure and con
fi
guration as code ("ops as code")
So where'd this come from? Well, devops. Initially this was an e
ff
ort
to involve ops in development ... and impose rules thereon. But once
trust was established, ops started to realize that dev had valuable
tools and techniques that they could "borrow" to make ops smoother
and quicker. So they adopted them.

2. What do you mean by "policy"
• Firewall rules and ACLs
• System security con
fi
guration
• Expected API inputs and outputs
• The "allow list" for an application
Policy, put simply, is allowed behavior in an application's environment.
What network tra
ffi
c is okay. How should a system be con
fi
gured
securely. Developers already know their APIs' acceptable inputs and
outputs ... let's make that policy, too. Anything where devs say "I
need you to allow this." (And deny anything else!)
What do you mean by "as code"
• Text
fi
les
• Versioned
• Machine readable
• Human reviewable
• Automate-able
Codifying policy just means we'll put it in text
fi
les that can be read by
both humans and machines. This means we can put it in version
control along with devs' application code. In that form, humans can
do peer review on it before it's automatically applied to the
application's environment.
Value
• Readable (and Commentable)
• Automatable (ClickOps must die)
• Move at the same cadence as development
• Include "code review" before changes
• Integrate into testing and QA
• Remove unused policies from the allow list
There's plenty of value in "borrowing" developers' tools and
techniques. For one, policy is clearer and avoids error-prone and time
consuming manual work. Policy application is no longer a separate
phase before/after application deployment. And it can be validated
early in the process. As an allow list, stale rules disappear.

3. Examples
• Terraform
• Kubernetes
• Con
fi
guration Management
• Open Policy Agent
• OpenAPI speci
fi
cation
You're soaking in it. Developers already have tools for automatic
policy de
fi
nition. It's up to security to learn and understand them
enough that they can review policies in the language of developers.
Like devops' evolution, you're going to have to blur the lines a little
here. Some folks call this DevSecOps.
How do we get started?
• Talk to developers about their
fl
ow and tools
• Convert tribal knowledge to code
• Convert manual run-books to automated processes
• Transcribe existing policy into code
• Cooperate
All well and good to talk the talk ... where next? Involve developers --
don't fall into the trap of imposing security -- cooperate. Get policy
out of people's heads. Tribal knowledge is dangerous. Stop doing
manual work; ask the developers how they'd help you automate it.
What do you think?
• Versioned text
fi
les?
• Integration with CICD and QA?
• Automated policy updates?
• Examples from your experience?
• Important tools and tricks?
• Trust your developers?
• # policy-ignore:open-storage-bucket !?
?
So, what do you think? I'd love to know what's on your mind. I'll
leave this slide up here as a conversation starter, but really, anything
goes.

4. Gabe Schuyler
@gabe_sky
fwd:cloudsec -- July 2022
"Shifting right"
This slide is just here so that I don't accidentally "fall o
ff
the end" of
my slide show if I advance past the "what do you think" slide. That's
the actual ending slide. You should never show this slide.