InSpec - June 2018 at Open28.be
Download as PPTX, PDF0 likes284 views
This document discusses InSpec, an open-source testing framework for infrastructure and compliance. It can be used to test configurations and ensure security best practices are followed. InSpec uses human-readable tests and comes with built-in resources to test common infrastructure components. It can test locally or remotely on Linux, Windows, and cloud platforms. Profiles allow packaging tests for reuse across environments. InSpec integrates with DevOps tools like Chef and Test Kitchen to enable compliance testing in development workflows.
![Execute InSpec
[chef@ip-172-31-38-151 ~]$ inspec exec ./test.rb
Profile: tests from ./test.rb
Version: (not specified)
Target: local://
File /tmp
✔ should exist
✔ should be directory
✔ should be owned by "root"
✔ mode should cmp == "01777"
Test Summary: 4 successful, 0 failures, 0 skipped](https://image.slidesharecdn.com/walls-open28-180607122128/85/InSpec-June-2018-at-Open28-be-20-320.jpg)
InSpec - June 2018 at Open28.be
- 1. InSpec: Automated Tests for Compliance and Security Mandi Walls | mandi@chef.io
- 2. HI! • Mandi Walls • Technical Community Manager for Chef, EMEA • mandi@chef.io • @lnxchk • https://www.chef.io/ • https://www.inspec.io/
- 3. EVERY business is a software business We’re going to be a software company with airplanes. – CIO, Alaska Airlines
- 5. Different Sources for the Same Goals
- 7. InSpec • Human-readable language for tests related to security and compliance • Create, share, and reuse complex profiles • Extensible language - build your own rules • Command-line tools plug into your existing workflow, build, deploy • Integrates with Test Kitchen for fast feedback • Test early, test often!
- 8. Create and Consume • Complex compliance requirements can slow you down • Share information and expertise • Compliance as code leverages cross-team knowledge • InSpec is code – check into repos, publish as artifacts • Include InSpec before code checkin • Include InSpec in integration and pre-production • Continue InSpec checks in production to guard against new threats
- 9. SSH Requirement • If your security team sends you a directive: SSH supports two different protocol versions. The original version, SSHv1, was subject to a number of security issues. All systems must use SSHv2 instead to avoid these issues.
- 10. Checking and Fixing • Identify the file and file location on your platforms • What setting to change Do we check it first or just push a new one everywhere? • What’s the plan for the OS images? Rebuild? Remediate at instantiation? • Do you test before pushing changes?
- 11. Lifecycle – How Often Do You Check Security? • Single big scan, report mailed out with a “due date”? Considered done, not checked again • Yearly or twice-yearly massive scans with remediation firedrills? Common audit cycles, large projects around fixing found issues • Part of the software development lifecycle? “To the left” Regularly part of what is included in builds Photo: https://www.flickr.com/photos/tarn-aveyron/2124972713/
- 12. Check that sshd_config describe sshd_config do impact 1.0 title 'SSH Version 2' desc <<-EOF SSH supports two different protocol versions. The original version, SSHv1, was subject to a number of security issues. Please use SSHv2 instead to avoid these. EOF its('Protocol') { should cmp 2 } end
- 13. Resources • InSpec includes built-in resources for common services, system files, and configurations • Built-in resources work on several platforms of Linux. There are also Windows-specifics • A resource has characteristics that can be verified for your requirements, and Matchers that work with those characteristics
- 14. Sample Resources • System resources: directory, file, user, group, crontab, service, package • Specific services: apache, nginx, rabbitmq, postgresql, IIS • Programming language components: gem, npm, powershell • Network services: port, http, sshd • Cloud resources: AWS, Azure • https://www.inspec.io/docs/reference/resources/
- 15. Characteristic Tests • it { should exist } – files, directories, groups • it { should be_installed } – packages • it { should be_enabled } – services • its('max_log_file') { should cmp 6 } – rotate auditd logs • its('exit_status') { should eq 0 } – run any arbitrary checks
- 16. Run InSpec • InSpec is command line Installs on your workstation as a ruby gem or as part of the ChefDK • Can be run locally, test the machine it is executing on • Or remotely InSpec will log into the target and run the tests for you • Also a REPL https://www.inspec.io/docs/reference/shell/
- 17. Create a Basic Test • Basic test to make sure /tmp is a directory • It also should be owned by root • And its mode should be 01777 – open to all (plus sticky bit!)
- 18. test.rb describe file("/tmp") do it { should exist } it { should be_directory } it { should be_owned_by 'root' } its('mode') { should cmp '01777' } end
- 19. Test Any Target inspec exec test.rb inspec exec test.rb -i ~/.aws/mandi_eu.pem -t ssh://ec2- user@54.152.7.203 inspec exec test.rb -t winrm://Admin@192.168.1.2 --password super inspec exec test.rb -t docker://3dda08e75838
- 20. Execute InSpec [chef@ip-172-31-38-151 ~]$ inspec exec ./test.rb Profile: tests from ./test.rb Version: (not specified) Target: local:// File /tmp ✔ should exist ✔ should be directory ✔ should be owned by "root" ✔ mode should cmp == "01777" Test Summary: 4 successful, 0 failures, 0 skipped
- 21. Execute in Build Pipelines • InSpec runs with failed tests return a non-zero return code • Passing tests have 0 return code Profile Summary: 0 successful, 1 failures, 0 skipped $ echo $? 1 Profile Summary: 1 successful, 0 failures, 0 skipped $ echo $? 0
- 22. Profiles • InSpec profiles allow you to package and share sets of InSpec tests for your organization or for a specific application set • Each profile can have multiple test files included • Flexible! Create your own profiles for specific software you use Use included matcher libraries or write your own – they live in the profile • https://dev-sec.io/
- 23. Sample Profile: linux-baseline control 'os-02' do impact 1.0 title 'Check owner and permissions for /etc/shadow' desc 'Check periodically the owner and permissions for /etc/shadow' describe file('/etc/shadow') do it { should exist } it { should be_file } it { should be_owned_by 'root' } its('group') { should eq shadow_group } it { should_not be_executable } it { should be_writable.by('owner') } ...
- 24. Skipping Individual Controls include_controls 'linux-baseline' do skip_control 'os-10’ skip_control 'os-08’ skip_control ‘package-08' skip_control 'sysctl-14' end
- 25. Fast Feedback with Test Kitchen • Test Kitchen is a tool for your team to create fast-feedback loops for development • Add InSpec tests to TK so that any change can also be certified with the security profile before it is pushed to source code repository • More info at http://kitchen.ci/
- 26. Include InSpec in Your Workflow • Infrastructure developers rely on InSpec profiles while working on configurations, use InSpec profiles as guidance for new configs • Application developers InSpec profiles to ensure new features don’t violate security requirements • Security and compliance personnel work with all teams to create profiles meet requirements • Build, Integration, Test environments built to meet InSpec requirements • Production systems checked regularly to manage drift, ensure against new threats
- 27. Resources • https://inspec.io • https://github.com/chef-training/workshops/ • http://www.anniehedgie.com/inspec-basics-1 • http://blog.johnray.io/chef-inspec-and-dirty-cow • https://blog.chef.io/2017/05/23/inspec-launches-support-cloud-platform- assessments/ • https://github.com/lnxchk/inspec_fivemins
Editor's Notes
- #6: Compliance requirements are often set out in flat documents. Sometimes PDFs, sometimes other formats, but they have a tendency to be a huge list of characteristics and checkboxes to be investigated and potentially remediated. Security tools may be somewhat more flexible, encoded into a set of shell scripts that check and verify the systems after they are built. But what if it was easy to build these checks into the workflow while the systems are being built and applications installed.
- #7: For the purposes of compliance, we actually wanted a common language, in code, that would allow all audiences – compliance, security, and devops – to collaborate on. And this code will then act on systems. This is whyInSpec was developed.
- #10: This directive is fairly common; it’s included in the security benchmarks published by CIS for a number of Linux and Unix systems that include SSH as a connection protocol. Many modern versions of these operating systems have version 2 as the default but include legacy support for version 1. It’s still a good idea to ensure that your systems are set to only use version 2.
- #12: For bits like the ssh configuration that are considered more infrastructure than application, these practices are common, changes are periodically rolled into the source images for new hosts (or containers) and the old configurations are eventually purged from production. It’s a herd-immunity approach. But what happens if the thing to be tested is affected by a continuously developed application? Like run time configurations for java, or your databases. Can you count on every team to always know all of the requirements?
- #22: Plug InSpec into whatever command set you are already using