At Conjur, we feel that the security aspects of Firewall, Application Auth, Networking, and Physical Infrastructure are well-understood and well-addressed in cloud.
DevOps speeds innovation and delivers business value through faster feature deployment and more stable application deployments which provide those businesses with DevOps methodologies in place a strong competitive edge.
However, there is a simple problem with DevOps that concerns the business.
To business people, coded infrastructure and DevOps workflows are magic. They can’t see it but it makes stuff happen. Stuff that is important to them, like delivering features faster, more stable applications and better uptime and scaling with the business.
Chris’ history with DevOps
IGM + Security
But that runs contrary to the goals of compliance, security and auditing which is to increase transparency around those applications and infrastructures that are considered vital and high-risk to the business. So at one level the business is asking you to go faster and do more with less, and the countervailing force is that there is a desire for transparency to protect the business.
Next slide = alignment and learning governance needs (relationships)
But when you can get the business and deveops to align, then everyone can wrap their minds around the new goal which is actually a reproducable process that is compliance and secure.
Learning governance stakeholders language, concerns, backgrounds, needs
A modular pipeline can have its parts swapped out at will. A robust security setup needs to be able to accommodate continuous pipeline improvements, swapping out modules as business and operation needs change
Demonstrate to your auditor that all code changes are checked, tested, tracked, and then released into production.
That you can create a complete history of the (recent) past and current structure of your entire environment.
Access controls for people and system accounts exist and are well documented, logged and auditable and that you have remediation plans in place in case of an “event”
Separation of Duties and Least Priviiege
* Your user management is tied directly to Chef
The Chef server loses some collaborative functions
Separation of Concerns
More complicated scenarios quickly become tangled
different rights for different environments, e.g., dev team can ssh into dev but not prod, but ops has both
hard to implement least privilege, for access to specific roles you have to set attributes directly on them
CRUD on users requires a cookbook update -> release cycle* separate Chef servers/orgs needed for each environment if you want to test your changes before hitting prod* Requires access to Chef server to test cookbooks dependent on user databags* Completely separate from how to manage secrets, have to write your own bridge
No report or audit
No single point of configuration - layers and layers of roles and attributes; default + override, etc
Enterprise directory integration
SSH access management is completely separate from secrets or app/service auth or anything else
chef-vault+IAM: http://sysadvent.blogspot.com/2013/12/day-19-automating-iam-credentials-with.html (Dec 2013)on chef-vault: http://jtimberman.housepub.org/blog/2013/09/10/managing-secrets-with-chef-vault/ (Sep 2013)
problems* until a Chef node completes its first run, it cannot use secrets (invisible to search until then)* you end up with unencrypted files in your repos that have to be gitignored - how are they shared or backed up?* you have to create ‘sets’ of secrets - for each new permutation you need a different set - a Chef node query is mapped to one set* admin setup is all or nothing - all users you select in your query can fetch/update/delete secrets* adding/removing hosts and users requires that the Chef query is re-run* how this works for development is unclear - gitignoring files, adding switches to cookbooks if using vagrant/kitchen, mocking out node attributes - this is a result of being completely dependent on Chef search
Noah’s overview: https://coderanger.net/chef-secrets/ (Aug 2014)Data bags vs resources: https://coderanger.net/data-bags/ (Feb 2014)
Chef Analytics
Separate from Chef Server so that allows for Chef Analytics to be managed and monitored outside the working Chef System
Write rules that trigger on events or event sequences of events
Send emails, log messages or AMQP messages based upon rules etc.
These are both very useful tools, but they are only part of a larger picture. Chef Analytics will tell you what has changed in Chef, but what about the compliance of your underlying infrastructure and applications?
Guardrail isn’t tied to Chef and covers everything changing on your server/instance but finding out who made a change requires reverse-engineering.
What’s missing?* Secrets management audit - who has access, who is fetching and updating? A clear view.
audit of permissions changes - eg temporary privilege escalation, changes to group membership* SSH logins/sudo calls
logout of the container is the first step…
Really get to know the compliance group
I had Gene Kim’s, “Visible Ops” books almost permanently on-hand and referred to them often.
Data bags & bootstrapping ← need to document
List every activity performed with the tool and declare the impact of the activity. This will dictate the rigor of the change control process.
List roles and responsibilities associated with Chef
e.g., Chef Manager, Chef Administrator, Customer
Provide specific classifications of impact (e.g., high, medium and low risk) with associated change tracking processes (e.g., file change control ticket)
HINT: Create a “maintenance” activity with a change tracking process of “none”
Example activities: “Create/Modify/Update Cookbooks in Chef Server” or “Bootstrap (add)/Remove Node”
Always look to manage scope and be aware of which systems are particularly sensitive (read: important) and which systems are managed by other groups
Declare which products and systems are “in scope”
Explicitly declare what is “out of scope”
Map high level features and activities to workflows and activities within your organization
Automated processes, where everything happens in a traceable and auditable manner (driven out of assets managed in source control) provide great flexibility and insulation within the change control process. You can declare, “change tickets must be filed for all medium risk updates unless performed via source control driven automation (list your org’s specifics).” Statements like the former within your documentation provide huge flexibility and leverage. As you update your automation and expand its scope, you should be able to file fewer and fewer change control tickets.
Validating Chef
Document how the product will be deployed within your organization
Describe
Incident and problem management. Hopefully, simply map this to pre-existing incident management documentation
Backup and restore management
Service and support
Leverage existing processes and documentation wherever possible. use whole, other processes completely or make only minor tweaks to existing tools and processes
Think creatively: Source control commit and accompanying data (e.g., message, diff and author) is a change control ticket or Chef cookbook is an installation document (that happens to be executable). Framing mechanisms in these terms allows you to map modern devops tools and processes on top of outdated change control and governance processes and documentation. It eases compliance group’s concerns because you are making incremental changes rather than throwing everything out and starting over