Kyle Harper, Lead Engineering Manager, CernerWatch Session » Session Description »
Are you challenged to demonstrate security compliance with strict security controls? Are your systems unexpectedly failing security audits due to your inability to routinely assess your posture? By auditing compliance through agile software delivery, one can reduce the toil of demonstrating an aggressive security posture at scale. InSpec, a compliance as code tool, enables organizations to quickly and frequently produce compliance artifacts while providing a framework for iterative continuous improvement.
In this talk, we will share our journey and challenges encountered leveraging compliance as code to validate system compliance in a federal space. We will share first-hand experience and lessons learned with successfully meeting these challenges. Whether you are a software developer, security professional, or in operations, all can benefit from these concepts.
- Interpret Security Technical Implementation Guides (STIGs) into well-defined InSpec.
- Collaborate on InSpec controls to unite and articulate your organization’s desired security posture.
- Learn methods to inject more contextual information into your InSpec results.
- Prepare auditors for this new philosophical approach.
- Create orchestration pipelines to execute InSpec at mass scale.
- Learn techniques for converting InSpec results into auditor required specific formats.
Learn from the shared experiences of an engineering manager responsible for the creation of InSpec profiles leveraged to audit systems with stringent federal security requirements.
Lance Albertson, Director, OSU Open Source LabWatch Session » Session Description »
Multi-node testing with Kitchen has long been a requested feature, however it’s outside of the scope of Kitchen. Multi-node testing is useful for testing complex services such as replicated database servers, Ceph clusters and OpenStack to name a few.
Some examples of how this is useful:
- Test to ensure your replicated database servers can fail over properly
- Test an upgrade between versions of Ceph or Openstack where doing this in an “All-in-One” might have differences with multiple nodes interacting
- Ensure all components can communicate properly with firewalls
At the OSUOSL, we developed a method for doing this using a combination of Kitchen, Terraform, InSpec and OpenStack (however any public cloud supported by Terraform will also work).
This session will cover the following topics:
- Why this is important and the problem we’re trying to solve
- Discuss what tools we used
- How you can replicate this for your environment
- Recorded demo using a real-world example
Annie Hedgpeth, Senior Cloud Automation Engineer, 10th MagnitudeWatch Session » Session Description »
For those that have longed for a simpler test-driven approach to Terraform development, come and see how I’ve made my team’s lives easier by using Test Kitchen for Terraform and how I can validate my deployments with InSpec. This will be a beginner’s guide, but all skillsets are welcome to contribute to the conversation!
We’ll discuss the different use cases for Terraform testing, such as:
- Test Driven Development (TDD)
- Integration Testing and CI/CD
- Compliance, shifting security left
- Production provisioning validation
As we know, good testing doesn’t just solve CI/CD problems; it solves culture problems. I will seek to convince you of why you need to invest in a good Terraform testing strategy early and how you might have bought into a myth that makes you think you have velocity when you don’t (are you running in wet cement).
And if you’re late to the game and have existing infrastructure with no tests, that’s okay, too. Let’s talk about how you can reduce stress by adding in some testing now. It’s not too late.
It takes an IT village to do DevOps, so let’s talk about moving security and sanity left with InSpec and Terraform. So many use cases, and so little time. You’ll leave this talk ready to implement at least one of them.
Tal Klein, CMO, RezilionWatch Session » Session Description »
What if we took a fresh approach to security that treated developers as intelligent human beings capable of making good decisions? The reality is that the lines between immutability and security and becoming more blurry every day. This quick talk explores an approach for using code, recipes and cookbooks to define security policies and ensure that what goes into production as well as what’s running in production achieves the developers’ desired state. We call it: Desired State Enforcement with Chef and Rezilion.