BuildStuff.LT 2018 InSpec Workshop

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

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

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

Shared Goals, Different Languages

InSpec
• Human-readable
• Test security and compliance
• Create, share, and reuse profiles
• Extend for your applications and systems
• Plug into your existing workflows / build servers
• Fast feedback with Test Kitchen

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?

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.

What To Do?
• Locate configuration file
• Locate correct setting
• Schedule a fix and restart
• Who fixes OS images?
• Do you need to test new settings?

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

Resources
• Resources examine common services, system files, and
configurations
See http://inspec.io/docs/reference/resources/ for the current list!
• Various Linux distros, plus Windows
• Check the characteristics of the resource (e.g., file size, owner)
• InSpec libraries are Matchers for testing and verifying
characteristics

• Resources include where the item is and how to look at it
• Included parsers do the work for you
• Similar to Ruby testing language rSpec, meant to be human
readable

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 }

SSH Configuration
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
The Resource – built in
InSpec will find this in the fil

Run It
• 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/

Using InSpec
User: chef
Pass: BuildStuff2018
What you need to replicate on your own:
This version is built using CentOS 7.4
Your user needs to have full sudo access
Install git
Install ChefDK from https://downloads.chef.io/chefdk/

Find It!
• http://inspec.io/
• Open Source, but cool stuff in the server
• Looks like other "spec" testing languages
• ChefDK or separate from https://downloads.chef.io
• It's already installed on your test host
$ inspec --version
3.0.12
Your version of InSpec is out of date! The latest
version is 3.0.52.

Create a Basic Test – test.rb
• Let’s write a 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!)
• Let’s check out the docs for the “file” resource for InSpec

File Resources in InSpec
• https://www.inspec.io/docs/reference/resources/file/
• We want:
Directory
Owner
Mode
describe file(‘path’) do
it { should MATCHER ‘value’ }
end

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
describe file('/tmp/') do
it { should exist }
its('type') { should eq :directory }
it { should_not be_file }
its('owner') { should eq 'root' }
its('mode') { should cmp '01777' }
end

Test Any Target
inspec exec test.rb
inspec exec test.rb -i ~/.aws/cert.pem -t ssh://ec2-
user@192.168.1.2
inspec exec test.rb -t winrm://Admin@192.168.1.2 --password
super
inspec exec test.rb -t docker://3dda08e75838

Execute InSpec
[chef@host ~]$ 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

Failures
• InSpec runs with failed tests return a non-zero return code
Profile Summary: 0 successful, 1 failures, 0 skipped
[chef@ip-172-31-29-25 ~]$ echo $?
1
[chef@ip-172-31-29-25 ~]$
• Passing tests have 0 return code
Profile Summary: 1 successful, 0 failures, 0 skipped
[chef@ip-172-31-29-25 ~]$ echo $?
0
[chef@ip-172-31-29-25 ~]$

Security Rule: set ssh login banner
• When logging into any machine your organization, display a notification:
"Welcome to MyCorp. This is a secure system and all activities are logged.
Authorized users only."
• The file /etc/ssh/sshd_banner
• We want it to exist and have the above content

$ vi banner.rb
describe file('/etc/ssh/sshd_banner') do
it { should exist }
its('content') { should match /Authorized users only/ }
end

$ sudo inspec exec banner.rb
Profile: tests from banner.rb (tests from banner.rb)
Target: local://
File /etc/ssh/sshd_banner
× should exist
expected File /etc/ssh/sshd_banner to exist
× content should match /Authorized users only/
expected nil to match /Authorized users only/

Test-driven Development
• We created the test first
• We know the feature we need does not exist on the machine
• Now we can create the sshd_banner file and re-run our test
• This helps us check our assumptions about the state of the system
• Create the banner file and run inspec again

$ sudo vi /etc/ssh/sshd_banner
Welcome to MyCorp.
This is a secure system and all activities are logged.
Authorized users only.

Target: local://
✔ should exist
✔ content should match /Authorized users only/

$ vi banner.rb
...
describe file('/etc/ssh/sshd_config') do
its('content') { should match /^Banner /etc/ssh/sshd_banner/ }
end

Target: local://
✔ should exist
File /etc/ssh/sshd_config
× content should match /^Banner /etc/ssh/sshd_banner/
expected "#t$OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp
$nn# This is the sshd server system...oncvsn#tX11Forwarding
non#tAllowTcpForwarding non#tPermitTTY non#tForceCommand cvs servern" to
match /$Banner /etc/ssh/sshd_banner/
Need sudo this time!

$ sudo vi /etc/ssh/sshd_config
Find the line for the banner:
# no default banner path
#Banner none
Change to:
# add default banner path
Banner /etc/ssh/sshd_banner

Target: local://
✔ should exist
File /etc/ssh/sshd_config
✔ content should match /^Banner /etc/ssh/sshd_banner/

Add in the Description and Impact
• Now that we know our tests are working, add info for other users
• Determine the impact of this requirement:
0.0 < 0.01 – Information only
0.01 < 0.4 – LOW impact
0.4 < 0.7 – MEDIUM impact
0.7 < 0.9 – HIGH impact
0.9 – 1.0 – CRITICAL impact
• Add a description of the controls

$ vi banner.rb
control 'mycorp-sshd-01' do
impact 1.0
desc 'Require a warning message to be displayed notifying ssh users of the
ownership of the system.'
describe file('/etc/ssh/sshd_banner') do
it { should exist }
its('content') { should match /Authorized users only/ }
end
describe file('/etc/ssh/sshd_config') do
its('content') { should match /^Banner /etc/ssh/sshd_banner/ }
end
end

Different output: reporters
$ sudo inspec exec banner.rb --reporter json
$ sudo inspec exec banner.rb --reporter html
$ sudo inspec exec banner.rb --reporter documentation

Profiles
• InSpec profiles allow you to package and share sets of InSpec
tests for your organization or for a specific application set
• Profiles are made up of controls
• Controls are made up of resources and tests, with priority and
metadata
Name your controls based on what they do or link them to a written doc
• Each profile can have multiple test files included and many
controls

Hardening with InSpec
• Centos 7 host
• os-hardening cookbook from https://supermarket.chef.io
• /dev-sec/linux-baseline InSpec profile from https://github.com/dev-
sec/linux-baseline

What’s in the linux-baseline Profile on https://dev-sec.io
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') }
...

Use the Profile
$ git clone https://github.com/dev-sec/linux-baseline
...
$ sudo inspec exec linux-baseline
Profile Summary: 26 successful controls, 27 control failures, 1
control skipped
$

What’s in the os-hardening Cookbook

Use Chef to Fix the Issues
• We've detected some issues, now we will correct them using Chef
• We'll create a Policyfile for this system that will consume other resources
• No Chef Server needed for this method
• All required Chef resources will be downloaded from Chef's open source
community site, https://supermarket.chef.io/

$ vi Policyfile.rb
name 'server-hardening'
default_source :supermarket
run_list 'os-hardening::default'
• This process will create a collection of Chef cookbooks to fix the issues that
caused InSpec to fail
• We won't need to connect to a Chef server for this method, all the
cookbooks will be downloaded locally

Run Commands
chef install Policyfile.rb
chef export Policyfile.rb harden
cd harden
sudo chef-client -z
Starting Chef Client, version 14.6.47
Using policy 'server-hardening' at revision '…'
resolving cookbooks for run list: ["os-hardening::default@3.1.0 (193f7ad)"]
Synchronizing Cookbooks:
- sysctl (1.0.5)
- ohai (5.2.5)
- os-hardening (3.1.0)
...
Chef Client finished, 141/206 resources updated in 47 seconds

Rerun the Tests
$ cd ~
$ sudo inspec exec linux-baseline/
...
Profile Summary: 52 successful controls, 1 control failure, 1
control skipped
Test Summary: 124 successful, 1 failure, 1 skipped

Auditd
× package-08: Install auditd (1 failed)
✔ System Package audit should be installed
✔ Audit Daemon Config log_file should cmp == "/var/log/audit/audit.log"
✔ Audit Daemon Config log_format should cmp == "raw"
✔ Audit Daemon Config flush should match /^INCREMENTAL|INCREMENTAL_ASYNC$/
× Audit Daemon Config max_log_file_action should cmp == "keep_logs"
expected: "keep_logs"
got: ROTATE
(compared using `cmp` matcher)

What’s Still Failing?
• Find the controls that aren’t passing
• Decide if you want to fix them or forget them
• We'll build a new profile to wrap around linux-baseline
And exclude the failing test

Building New Profiles
$ inspec init profile my_hardening
Create new profile at /home/chef/my_hardening
* Create file README.md
* Create directory controls
* Create file controls/example.rb
* Create file inspec.yml
* Create directory libraries
This is a new InSpec profile, vs the new Chef cookbook we created earlier.

Including Profiles
$ vi my_hardening/inspec.yml
name: my_hardening
title: InSpec Profile
...
version: 0.1.0
depends:
- name: linux-baseline
path: ../linux-baseline

Profile Dependencies
• InSpec will find or retrieve the included profile
• You can choose to use all of the profile or pick a few controls
• You can also exclude controls that don't meet your needs
• Create a new control file to manage the other profile's controls

Skipping Individual Controls
$ vi my_hardening/controls/my.rb
include_controls 'linux-baseline' do
skip_control 'package-08'
end
We want to run all of the controls from linux-baseline except package-08
• You can also remove the file my_hardening/controls/example.rb if you want
to

Rerun the InSpec Profile
$ sudo inspec exec my_hardening/
...
Profile Summary: 53 successful controls, 0 control failures, 1
control skipped

Additional Features
• Use InSpec to test resources in the Cloud – Azure, AWS, GCP
describe aws_s3_bucket('test_bucket') do
it { should_not be_public }
end
• Industry-standard profiles such as CIS available via commercial solutions

Test Kitchen
• InSpec also runs as a test suite in 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/

InSpec and Chef's Automate
• InSpec profiles are a component of Chef's Automate server, providing a
GUI and metrics collection about compliance across your estate
• Additional industry-standard profiles are also available commercially via
Automate

Resources
• https://inspec.io
• https://dev-sec.io
• http://www.anniehedgie.com/inspec-basics-1
• http://blog.johnray.io/chef-inspec-and-dirty-cow

BuildStuff.LT 2018 InSpec Workshop

BuildStuff.LT 2018 InSpec Workshop

More Related Content

What's hot

Similar to BuildStuff.LT 2018 InSpec Workshop

More from Mandi Walls

Recently uploaded

BuildStuff.LT 2018 InSpec Workshop

Editor's Notes