This blog post by Chris Swan, Policy Debt, was included in the September 8, 2019 edition of DevOps Weekly (subscribe here if you haven’t already). Many of the points Chris raises are likely familiar to folks who have been working in operations, systems engineering, or DevOps for any length of time. In summary, security practices and requirements should change over time as the systems they are meant to target change. As more features are included, they need to be handled appropriately. As computational resources become more powerful and less expensive, more cryptographic solutions become more accessible. As more research is done in areas of usability, accessibility, and UX, we can see the negative impacts of policies that seemed like a good idea at the time, like changing passwords every 45 or 90 days (and then updating the password list under your keyboard – not that you would ever do that, right?).
It’s one of the reasons we have been reluctant to call anything a “best practice”. “Best” is transient, it ages and often does not maintain its first place status for very long. We need tools that are flexible and allow any of our stakeholders to make necessary changes and additions as environments evolve. Chef InSpec’s extensible platform allows you to add, delete, or update the requirements of your security policies over time, and make sure that all of your teams are using the most up-to-date versions of those policies.
One of the most powerful aspects of InSpec is the ability to share and consume policies inside of policies via InSpec Profiles. This includes not only Chef’s commercial profile offerings like those that enforce CIS standards, but also includes your policies that meet your specific site requirements. Profiles are collections of security requirements called controls that describe aspects of your system and the proper configurations they should have to meet your security requirements. Controls can be anything from user account settings, to file permissions, to ensuring that an insecure service is disabled or not installed.
We know that different teams have different skills and knowledge about your systems, so InSpec’s ability to consume profiles means that your global security team can provide profiles to secure your infrastructure platforms to their requirements. Your application architecture teams can produce profiles to secure runtime packages and platforms. Individual dev and ops and DevOps teams can add in any of their own requirements, as well as consuming the latest requirements from other teams.
InSpec profiles have a dependency feature that is similar to the feature of the same name in Chef Infra. When I create myself a new Chef InSpec profile for my project, one of the files that is created is inspec.yml. This file describes the InSpec profile, and allows me to bring in other profiles via depends. For example:
name: my-hardening title: InSpec Profile maintainer: The Authors copyright: The Authors copyright_email: you@example.com license: Apache-2.0 summary: An InSpec Compliance Profile version: 0.1.0 depends: - name: linux-baseline git: https://github.com/dev-sec/linux-baseline
This dependency capability has a number of different features, and I can consume profiles from various locations. In this example, I’m using a public profile that is stored on GitHub. I will get the updates to this profile as they are published. There’s no need to worry that my hosts will be behind or out of date with their security requirements. The profile itself can be treated as a piece of software, built and updated via a workflow similar to any other software the team might manage via GitHub or similar tooling.
I can depend on multiple profiles; depend on specific versions of profiles; and consume profiles from a variety of locations.
If profiles are available on a website that isn’t necessarily GitHub, they can be shared as tar.gz files:
depends: - name: linux-baseline url: https://github.com/dev-sec/linux-baseline/archive/master.tar.gz - name: ssh-baseline url: https://myhost.com/security-resources/ssh-baseline/master.tar.gz
For more options for publishing and consuming profiles, definitely check out the Chef InSpec Docs.
include_controls directive in my profile.
Now my infrastructure will run my controls as well as those published by my security team via the depends and include_controls settings.
Another key feature that will help your teams better manage and maintain complex requirements over a full lifecycle is the ability to leave out certain parts of a profile. Maybe my org’s baseline profile isn’t updated to an OS or runtime version my application requires; I can leave out parts of the profile and remediate them with my security team at a later date. The skip_control directive allows me to customize the depended profiles piece-by-piece, instead of abandoning a broken profile completely.
One of the examples we used in early Chef InSpec workshops included checking the sshd configuration for an old version of the SSH protocol by checking the sshd_config file on a host. In the time since we first wrote that example, most of the operating systems vendors have updated the baseline version of sshd that is included in their distributions and updating sshd_config, making our example control obsolete. We can still test sshd, but the test must change to reflect the new normal for our hosts, otherwise that test will fail or produce an outcome we can’t necessarily trust. Treating our profiles as software allows us to provide updates and release new baselines to reflect out constantly changing ecosystem.
Chef InSpec is a flexible, extensible, human-readable security focused testing language for your infrastructure. If your team is searching for a powerful and programmatic way to encode and execute your security requirements, Chef InSpec is for you.
To learn more, visit https://www.chef.io/products/chef-inspec/ and https://community.chef.io/tools/chef-inspec.