InSpec is an open source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security, and policy requirements. Using a combination of command-line and remote-execution tools, InSpec can help you keep your infrastructure aligned with security and compliance guidelines on an ongoing basis, rather than waiting for and then remediating from arduous annual audits. InSpec’s flexibility makes it a key tool choice for incorporating security into a complete continuous delivery workflow, reducing the risk of new features and releases breaking established host-based security guidelines.

1. Building Security Into Your Workflow
with InSpec
Mandi Walls | mandi@chef.io

2. HI!
• Mandi Walls
• Technical Community Manager for Chef
• mandi@chef.io
• @lnxchk

3. Who Is Chef
• Configuration Management, System Automation
• Based in Seattle, USA with offices in San Francisco, London,
and Berlin

4. EVERY business is a software business
We’re going to be a software
company with airplanes.
– CIO, Alaska Airlines

6. Motivation

8. Product Ideas and Features
Security Review
Production

10. Afterthought Scanning

11. http://mspmentor.net/msp-mentor/botched-server-install-results-214-million-hipaa-breach-fine

12. What We Have Here Is A Communications Problem

14. What Is InSpec

15. InSpec
• Human-readable specification language for tests related to
security and compliance
• Includes facilities for creating, sharing, and reusing profiles
• Extensible language so you can build your own rules for your
applications and systems
• Command-line tools for plugging into your existing workflows /
build servers
• Integrates with Test Kitchen for fast-feedback local testing by
developers

16. SSH Example
• From your security team:
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.

17. Remediation
• Identify the file and file location to check your systems
• Figure out some sort of fix
Do we check it first or just push a new one everywhere?
• What’s the plan for the currently used images?
Rebuild?
Remediate at instantiation?
• Hopefully you’re using a configuration management solution for
these types of changes?

18. Lifecycle
• When you get a mandate from security, how often is it checked?
• Single big scan, report mailed out with a “due date”?
• Yearly or twice-yearly massive scans with remediation firedrills?

19. Using InSpec

20. Find It!
• http://inspec.io/
• Open Source!
• The “spec” is a hint

21. 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

22. Resources
• Inspec includes built-in resources for common services, system
files, and configurations
See http://inspec.io/docs/reference/resources/ for the current list!
• 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

23. 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
Compliance officers don’t care
where that file is based on what
OS you’re using. It has to be
checked on all platforms. Let
InSpec figure out where it lives.

24. its.... should...
• it { should exist }
• it { should be_installed }
• it { should be_enabled }
• its('max_log_file') { should cmp 6 }
• its('exit_status') { should eq 0 }
• its('gid') { should eq 0 }

25. More Complex Built Ins
• Example: limits.conf
grantmc hard nofile 63536
^^^^^^^ ^^^^ ^^^^^^ ^^^^^
domain type item value
• Match on the categories
• its('domain') { should eq ['type', 'item', 'value'] }
• its('ftp') { should eq ['hard', 'nproc', '0'] }

26. Run It
• InSpec is command line
Installs 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

27. 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

28. Failures
• InSpec runs with failed tests return a non-zero return code
Profile Summary: 0 successful, 1 failures, 0 skipped
$ echo $?
1
$
• Passing tests have 0 return code
Profile Summary: 1 successful, 0 failures, 0 skipped
$ echo $?
0
$

29. Test Kitchen
• InSpec also runs as an included tester in TK
verifier:
name: inspec

30. But What About ServerSpec?
• ServerSpec is awesome!
• InSpec is a superset of ServerSpec’s features, with a different
audience – compliance officers
• There’s more about the evolution of InSpec on our blog:
https://blog.chef.io/2015/11/04/the-road-to-inspec/

31. Introducing Profiles

32. Profiles
• InSpec profiles allow you to package and share sets of InSpec
tests for your organization or for a specific application set
• Built around “controls” that can be audited against specific
requirements
• Each profile can have multiple test files included
• Depend on other profiles outside the current working set
• Publish profiles as a shared resource to be included in local
work
• More at: https://www.inspec.io/docs/reference/profiles/

33. Profiles
$ inspec init profile companyprofile_01
Create new profile at /home/chef/companyprofile_01
* Create directory libraries
* Create directory controls
* Create file controls/example.rb
* Create file inspec.yml
* Create file README.md
Add more InSpec test files to the
controls directory

34. Profile Commands
inspec check companyprofile_01/
inspec exec companyprofile_01/

35. Profile Controls
control 'os-04' do
impact 1.0
title 'Dot in PATH variable'
desc 'Do not include the current working directory in PATH
variable. This makes it easier for an attacker to gain extensive
rigths by executing a Trojan program'
describe os_env('PATH') do
its('split') { should_not include('') }
its('split') { should_not include('.') }
end
end

36. Example – Basic Hardening
• Centos 7.2 host
• Test Kitchen
• os-hardening cookbook from https://supermarket.chef.io
• /dev-sec/linux-baseline InSpec profile from
https://supermarket.chef.io

37. The Cookbook and the InSpec Profile Work Together
suites:
- name: default
run_list:
- recipe[osdc-inspec-talk::default]
- recipe[os-hardening]
verifier:
inspec_tests:
- test/smoke/default
- https://github.com/dev-sec/linux-baseline
attributes:

38. What’s in the os-hardening Cookbook

39. Run kitchen test Without Hardening
Profile Summary: 25 successful, 25 failures, 1 skipped
Test Summary: 77 successful, 39 failures, 3 skipped
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>> Verify failed on instance <default-centos-72>. Please
see .kitchen/logs/default-centos-72.log for more details
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

40. Run kitchen test With Hardening
Profile Summary: 50 successful, 0 failures, 1 skipped
Test Summary: 116 successful, 0 failures, 3 skipped
Finished verifying <default-centos-72> (0m11.07s).
-----> Destroying <default-centos-72>...
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
Vagrant instance <default-centos-72> destroyed.
Finished destroying <default-centos-72> (0m4.97s).
Finished testing <default-centos-72> (2m37.89s).
-----> Kitchen is finished. (2m39.44s)

41. What’s in the linux-baseline Profile
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') }
...

42. Over Time
Build a Comprehensive Set of Checks for Your Systems
Run Them Every Time Someone Needs to Make a Change
Make it EASY for Everyone to Use

43. Resources
• https://inspec.io
• https://github.com/chef-training/workshops/
• https://blog.chef.io/2017/05/15/detecting-wannacry-exploit-
inspec/
• http://www.anniehedgie.com/inspec-basics-1
• http://blog.johnray.io/chef-inspec-and-dirty-cow
• https://github.com/lnxchk/inspec_fivemins.git