inspec 2.1.81 → 2.1.83

data/bin/inspec

@@ -1,12 +1,12 @@
-#!/usr/bin/env ruby
-# encoding: utf-8
-# Copyright 2015 Dominik Richter
-# author: Dominik Richter
-# author: Christoph Hartmann
-
-Encoding.default_external = Encoding::UTF_8
-Encoding.default_internal = Encoding::UTF_8
-
-require_relative '../lib/inspec'
-require_relative '../lib/inspec/cli'
-Inspec::InspecCLI.start(ARGV)
+#!/usr/bin/env ruby
+# encoding: utf-8
+# Copyright 2015 Dominik Richter
+# author: Dominik Richter
+# author: Christoph Hartmann
+
+Encoding.default_external = Encoding::UTF_8
+Encoding.default_internal = Encoding::UTF_8
+
+require_relative '../lib/inspec'
+require_relative '../lib/inspec/cli'
+Inspec::InspecCLI.start(ARGV)

data/docs/.gitignore

@@ -1,2 +1,2 @@
-resources.md
-cli.md
+resources.md
+cli.md

data/docs/README.md

@@ -1,40 +1,41 @@
-# InSpec documentation
-
-This is the home of the InSpec documentation. This documentation provides an introduction to this mechanism and shows how to write custom tests.
-
-The goal of this folder is for any community member to clone these docs, make the changes, check if they are valid, and contribute to the project.
-
-## How to build docs
-
-We build docs by:
-
-1. Auto-generating docs from code
-2. Transforming markdown+snippets in this folder into pure markdown in `www/source/docs`
-3. Rendering them to the website via instructions in `www/`
-
-For development, you **only need step 1**!
-
-**1 Generate docs**
-
-To generate all docs run:
-
-```
-bundle exec rake docs
-```
-
-You can run tasks individually. For a list of tasks run:
-
-```
-bundle exec rake --tasks docs
-```
-
-## Stability Index
-
-Every available InSpec resource will indicate its stability. As InSpec matures, certain parts are more reliable than others. Brand new features are likely to be redesigned and marked as such.
-
-The stability indices are as follows:
-
-* `Stability: Deprecated` - This features will be removed in future versions, because its known for being problematic. Do not rely on it.
-* `Stability: Experimental` - New features may change or are removed in future versions
-* `Stability: Stable` - API is well established and proofed. Maintaining compatibility is a high priority
-* `Stability: Locked` - Only security and performance fixes are allowed
+# InSpec documentation
+
+This is the home of the InSpec documentation. This documentation provides an introduction to this mechanism and shows how to write custom tests.
+
+The goal of this folder is for any community member to clone these docs, make the changes, check if they are valid, and contribute to the project.
+
+## How to build docs
+
+We build docs by:
+
+1. Auto-generating docs from code
+2. Transforming markdown+snippets in this folder into pure markdown in `www/source/docs`
+3. Rendering them to the website via instructions in `www/`
+
+For development, you **only need step 1**!
+
+**1 Generate docs**
+
+To generate all docs run:
+
+```
+bundle exec rake docs
+```
+
+You can run tasks individually. For a list of tasks run:
+
+```
+bundle exec rake --tasks docs
+```
+
+## Stability Index
+
+Every available InSpec resource will indicate its stability. As InSpec matures, certain parts are more reliable than others. Brand new features are likely to be redesigned and marked as such.
+
+The stability indices are as follows:
+
+* `Stability: Deprecated` - This features will be removed in future versions, because its known for being problematic. Do not rely on it.
+* `Stability: Experimental` - New features may change or are removed in future versions
+* `Stability: Stable` - API is well established and proofed. Maintaining compatibility is a high priority
+* `Stability: Locked` - Only security and performance fixes are allowed
+

data/docs/dev/control-eval.md

@@ -1,62 +1,62 @@
-# What happens when a profile file is loaded
-
-## Consult with Harry Tuttle
-
-[He's not from Central Services or anything.](https://youtu.be/VRfoIyx8KfU?t=2m41s)
-
-## Tips
-
-* In the early days of InSpec / ServerSpec, controls were called "rules".  Throughout various places in the code, the word "rule" is used to mean "control".  Make the mental subsitution.
-* InSpec supports reading profiles from tarballs, local files, git repos, etc.  So, don't count on local file reading; instead it uses a special source reader to obtain the contents of the files.
-
-## The basics of the stack
-
-    #5  Inspec::Profile.collect_tests(include_list#Array) at lib/inspec/profile.rb:167
-    #4  Hash.each at lib/inspec/profile.rb:167
-    #3  block in Inspec::Profile.block in collect_tests(include_list#Array) at lib/inspec/profile.rb:170
-    #2  Inspec::ProfileContext.load_control_file(*args#Array) at lib/inspec/profile_context.rb:141
-    #1  Inspec::ProfileContext.control_eval_context at lib/inspec/profile_context.rb:58
-    #0  #<Class:Inspec::ControlEvalContext>.create(profile_context#Inspec::ProfileContext, resources_dsl#Module) at lib/inspec/control_eval_context.rb:41
-
-## A profile context is created
-
-Like many things in InSpec core, a profile context is an anonymous class. (verify)
-
-Additionally, a control_eval_context is created.  It is an instance of an anonymous class; it has a class<->relationship with its profile context.  See `lib/inspec/control_eval_context.rb`.
-
-## Each file's contents are instance eval'd against the control_eval_context
-
-### DSL methods are executed at this time
-
-So, if you have a control file with `title` in it, that will call the title method that was defined at `lib/inspec/control_eval_context.rb:60`.  Importantly, this also includes the `control` DSL keyword, and also the `describe` keyword (used for bare describes).
-
-### Each control and their block are wrapped in an anonymous class
-
-The anonymous class generator is located at `lib/inspec/control_eval_context.rb:24`.  At this point, the terminology switches from `control` to `rule`.  Each context class inherits from Inspec::Rule, which provides the constructor.
-
-The control context class also gets extended with the resource DSL, so anything in the source code for the control can use the resource DSL.  This includes all resource names, but importantly, the `describe` DSL keyword.
-
-Finally, Inspec::Rule provides the control DSL - impact, title, desc, ref, and tags.
-
-### The block is instance_eval'd against the control context class
-
-See `lib/inspec/rule.rb:50`.  We're now in two levels of instance eval'ing - the file is gradually being eval'd against the profile context anonymous class, and the current control's block is being instance eval'd against a control context anonymous class.
-
-At this stage, control-level metadata (impact, title, refs, tags, desc) are evaluated and set as instance vars on the control.
-
-Any "loose" ruby in the control is also executed at this point.
-
-And, the describe and describe.one blocks are executed.
-
-### TODO: describe blocks are *not* instance-evaled
-
-### The control is registered with the profile
-
-Using the method register_control (dynamically defined on the control eval context), we check for various skip conditions.  If none of them apply, the control is then registered with the profile context using register_rule.
-
-ProfileContext.register_rule's main job is to determine the full ID of the control (within the context of the profile) and either add it to the controls list, or (if another control with the same ID exists), merge it.  (This is where overriding happens).
-
-Note: can skip a control with:
-Inspec::Rule.set_skip_rule(control, msg)
-
+# What happens when a profile file is loaded
+
+## Consult with Harry Tuttle
+
+[He's not from Central Services or anything.](https://youtu.be/VRfoIyx8KfU?t=2m41s)
+
+## Tips
+
+* In the early days of InSpec / ServerSpec, controls were called "rules".  Throughout various places in the code, the word "rule" is used to mean "control".  Make the mental subsitution.
+* InSpec supports reading profiles from tarballs, local files, git repos, etc.  So, don't count on local file reading; instead it uses a special source reader to obtain the contents of the files.
+
+## The basics of the stack
+
+    #5  Inspec::Profile.collect_tests(include_list#Array) at lib/inspec/profile.rb:167
+    #4  Hash.each at lib/inspec/profile.rb:167
+    #3  block in Inspec::Profile.block in collect_tests(include_list#Array) at lib/inspec/profile.rb:170
+    #2  Inspec::ProfileContext.load_control_file(*args#Array) at lib/inspec/profile_context.rb:141
+    #1  Inspec::ProfileContext.control_eval_context at lib/inspec/profile_context.rb:58
+    #0  #<Class:Inspec::ControlEvalContext>.create(profile_context#Inspec::ProfileContext, resources_dsl#Module) at lib/inspec/control_eval_context.rb:41
+
+## A profile context is created
+
+Like many things in InSpec core, a profile context is an anonymous class. (verify)
+
+Additionally, a control_eval_context is created.  It is an instance of an anonymous class; it has a class<->relationship with its profile context.  See `lib/inspec/control_eval_context.rb`.
+
+## Each file's contents are instance eval'd against the control_eval_context
+
+### DSL methods are executed at this time
+
+So, if you have a control file with `title` in it, that will call the title method that was defined at `lib/inspec/control_eval_context.rb:60`.  Importantly, this also includes the `control` DSL keyword, and also the `describe` keyword (used for bare describes).
+
+### Each control and their block are wrapped in an anonymous class
+
+The anonymous class generator is located at `lib/inspec/control_eval_context.rb:24`.  At this point, the terminology switches from `control` to `rule`.  Each context class inherits from Inspec::Rule, which provides the constructor.
+
+The control context class also gets extended with the resource DSL, so anything in the source code for the control can use the resource DSL.  This includes all resource names, but importantly, the `describe` DSL keyword.
+
+Finally, Inspec::Rule provides the control DSL - impact, title, desc, ref, and tags.
+
+### The block is instance_eval'd against the control context class
+
+See `lib/inspec/rule.rb:50`.  We're now in two levels of instance eval'ing - the file is gradually being eval'd against the profile context anonymous class, and the current control's block is being instance eval'd against a control context anonymous class.
+
+At this stage, control-level metadata (impact, title, refs, tags, desc) are evaluated and set as instance vars on the control.
+
+Any "loose" ruby in the control is also executed at this point.
+
+And, the describe and describe.one blocks are executed.
+
+### TODO: describe blocks are *not* instance-evaled
+
+### The control is registered with the profile
+
+Using the method register_control (dynamically defined on the control eval context), we check for various skip conditions.  If none of them apply, the control is then registered with the profile context using register_rule.
+
+ProfileContext.register_rule's main job is to determine the full ID of the control (within the context of the profile) and either add it to the controls list, or (if another control with the same ID exists), merge it.  (This is where overriding happens).
+
+Note: can skip a control with:
+Inspec::Rule.set_skip_rule(control, msg)
+
 ## What else?

data/docs/dsl_inspec.md

@@ -1,258 +1,258 @@
----
-title: InSpec DSL
----
-
-# InSpec DSL
-
-InSpec is a run-time framework and rule language used to specify compliance, security, and policy requirements. It includes a collection of resources that help you write auditing controls quickly and easily. The syntax used by both open source and |chef compliance| auditing is the same. The open source |InSpec resource| framework is compatible with |chef compliance|.
-
-The InSpec DSL is a Ruby DSL for writing audit controls, which includes audit resources that you can invoke.
-
-The following sections describe the syntax and show some simple examples of using the InSpec resources.
-
-## Syntax
-
-The following resource tests |ssh| server configuration. For example, a simple control may described as:
-
-```ruby
-describe sshd_config do
-  its('Port') { should eq('22') }
-end
-```
-
-In various use cases like implementing IT compliance across different departments, it becomes handy to extend the control with metadata. Each control may define an additional ``impact``, ``title`` or ``desc``. An example looks like:
-
-```ruby
-control 'sshd-8' do
-  impact 0.6
-  title 'Server: Configure the service port'
-  desc '
-   Always specify which port the SSH server should listen to.
-   Prevent unexpected settings.
-  '
-  tag 'ssh','sshd','openssh-server'
-  tag cce: 'CCE-27072-8'
-  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
-
-  describe sshd_config do
-   its('Port') { should eq('22') }
-  end
-end
-```
-
-where
-
-* `'sshd-8'` is the name of the control
-* `impact`, `title`, and `desc` define metadata that fully describes the importance of the control, its purpose, with a succinct and complete description
-* `impact` is an float that measures the importance of the compliance results and must be a value between `0.0` and `1.0`. The value ranges are:
-    * `0.0 to <0.4` these are controls with minor criticality
-    * `0.4 to <0.7` these are controls with major criticality
-    * `0.7 to 1.0` these are critical controls
-* `tag` is optional meta-information with with key or key-value pairs
-* `ref` is a reference to an external document
-* `describe` is a block that contains at least one test. A `control` block must contain at least one `describe` block, but may contain as many as required
-* `sshd_config` is an InSpec resource. For the full list of InSpec resources, see InSpec resource documentation
-* `its('Port')` is the matcher; `{ should eq('22') }` is the test. A `describe` block must contain at least one matcher, but may contain as many as required
-
-
-## Advanced concepts
-
-With InSpec it is possible to check if at least one of a collection of checks is true. For example: If a setting is configured in two different locations, you may want to test if either configuration A or configuration B have been set. This is accomplished via `describe.one`. It defines a block of tests with at least one valid check.
-
-```ruby
-describe.one do
-  describe ConfigurationA do
-   its('setting_1') { should eq true }
-  end
-
-  describe ConfigurationB do
-   its('setting_2') { should eq true }
-  end
-end
-```
-
-#### Sensitive resources
-
-In some scenarios, you may be writing checks involving resources with sensitive content (e.g. a file resource). In the case of failures, it may be desired to suppress output. This can be done by adding the `:sensitive` flag to the resource definition
-
-```ruby
-describe file('/tmp/mysecretfile'), :sensitive do
-  its('content') { should contain 'secret_info' }
-end
-```
-
-## Examples
-
-The following examples show simple compliance tests using a single `control` block.
-
-## Test System Event Log
-
-The following test shows how to audit machines running Windows 2012 R2 that password complexity is enabled:
-
-```ruby
-control 'windows-account-102' do
-  impact 1.0
-  title 'Windows Password Complexity is Enabled'
-  desc 'Password must meet complexity requirement'
-  describe security_policy do
-    its('PasswordComplexity') { should eq 1 }
-  end
-end
-```
-
-## Are PostgreSQL passwords empty?
-
-The following test shows how to audit machines running PostgreSQL to ensure that passwords are not empty.
-
-```ruby
-control 'postgres-7' do
-  impact 1.0
-  title "Don't allow empty passwords"
-  describe postgres_session('user', 'pass').query("SELECT * FROM pg_shadow WHERE passwd IS NULL;") do
-   its('output') { should eq('') }
-  end
-end
-```
-
-## Are MySQL passwords in ENV?
-
-The following test shows how to audit machines running MySQL to ensure that passwords are not stored in `ENV`:
-
-```ruby
-control 'mysql-3' do
-  impact 1.0
-  title 'Do not store your MySQL password in your ENV'
-  desc '
-   Storing credentials in your ENV may easily expose
-   them to an attacker. Prevent this at all costs.
-  '
-  describe command('env') do
-   its('stdout') { should_not match(/^MYSQL_PWD=/) }
-  end
-end
-```
-
-## Is `/etc/ssh` a Directory?
-
-The following test shows how to audit machines to ensure that `/etc/ssh` is a directory:
-
-```ruby
-control 'basic-1' do
-  impact 1.0
-  title '/etc/ssh should be a directory'
-  desc '
-   In order for OpenSSH to function correctly, its
-   configuration path must be a folder.
-  '
-  describe file('/etc/ssh') do
-   it { should be_directory }
-  end
-end
-```
-
-## Is Apache running?
-
-The following test shows how to audit machines to ensure that Apache is enabled and running:
-
-```ruby
-control 'apache-1' do
-  impact 0.3
-  title 'Apache2 should be configured and running'
-  describe service(apache.service) do
-   it { should be_enabled }
-   it { should be_running }
-  end
-end
-```
-
-## Are insecure packages installed ?
-
-The following test shows how to audit machines for insecure packages:
-
-```ruby
-control 'cis-os-services-5.1.3' do
-  impact 0.7
-  title '5.1.3 Ensure rsh client is not installed'
-
-  describe package('rsh') do
-    it { should_not be_installed }
-  end
-
-  describe package('rsh-redone-client') do
-    it { should_not be_installed }
-  end
-end
-```
-
-## Test Windows Registry Keys
-
-The following test shows how to audit machines to ensure Safe DLL Search Mode is enabled:
-
-```ruby
-control 'windows-base-101' do
-  impact 1.0
-  title 'Safe DLL Search Mode is Enabled'
-  desc '
-    @link: https://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx
-  '
-  describe registry_key('HKLM\\System\\CurrentControlSet\\Control\\Session Manager') do
-    it { should exist }
-    it { should_not have_property_value('SafeDllSearchMode', :type_dword, '0') }
-  end
-end
-```
-
-## Exclude specific test
-
-This shows how to allow skipping certain tests if conditions are not met, by using `only_if`.
-In this example the test will not be performed if `redis-cli` command does not exist, because for example package on remote host was not installed.
-
-```ruby
-control 'nutcracker-connect-redis-001' do
-  impact 1.0
-  title 'Check if nutcracker can pass commands to redis'
-  desc 'execute redis-cli set key command, to check connectivity of the service'
-
-  only_if do
-    command('redis-cli').exist?
-  end
-
-  describe command('redis-cli SET test_inspec "HELLO"') do
-    its(:stdout) { should match(/OK/) }
-  end
-end
-```
-
-Mixing this with other conditionals (like checking existence of the files etc.) can help to test different test paths using InSpec. This way you can skip certain tests which would 100% fail due to the way servers are prepared, but you know that the same test suites are reused later in different circumstances by different teams.
-
-## Additional metadata for controls
-
-
-The following example illustrates various ways to add tags and references to `control`
-
-```ruby
-control 'ssh-1' do
-  impact 1.0
-
-  title 'Allow only SSH Protocol 2'
-  desc 'Only SSH protocol version 2 connections should be permitted.
-        The default setting in /etc/ssh/sshd_config is correct, and can be
-        verified by ensuring that the following line appears: Protocol 2'
-
-  tag 'production','development'
-  tag 'ssh','sshd','openssh-server'
-
-  tag cce: 'CCE-27072-8'
-  tag disa: 'RHEL-06-000227'
-
-  tag remediation: 'stig_rhel6/recipes/sshd-config.rb'
-  tag remediation: 'https://supermarket.chef.io/cookbooks/ssh-hardening'
-
-  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
-  ref 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'
-
-  describe ssh_config do
-    its ('Protocol') { should eq '2'}
-  end
-end
-```
+---
+title: InSpec DSL
+---
+
+# InSpec DSL
+
+InSpec is a run-time framework and rule language used to specify compliance, security, and policy requirements. It includes a collection of resources that help you write auditing controls quickly and easily. The syntax used by both open source and |chef compliance| auditing is the same. The open source |InSpec resource| framework is compatible with |chef compliance|.
+
+The InSpec DSL is a Ruby DSL for writing audit controls, which includes audit resources that you can invoke.
+
+The following sections describe the syntax and show some simple examples of using the InSpec resources.
+
+## Syntax
+
+The following resource tests |ssh| server configuration. For example, a simple control may described as:
+
+```ruby
+describe sshd_config do
+  its('Port') { should eq('22') }
+end
+```
+
+In various use cases like implementing IT compliance across different departments, it becomes handy to extend the control with metadata. Each control may define an additional ``impact``, ``title`` or ``desc``. An example looks like:
+
+```ruby
+control 'sshd-8' do
+  impact 0.6
+  title 'Server: Configure the service port'
+  desc '
+   Always specify which port the SSH server should listen to.
+   Prevent unexpected settings.
+  '
+  tag 'ssh','sshd','openssh-server'
+  tag cce: 'CCE-27072-8'
+  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
+
+  describe sshd_config do
+   its('Port') { should eq('22') }
+  end
+end
+```
+
+where
+
+* `'sshd-8'` is the name of the control
+* `impact`, `title`, and `desc` define metadata that fully describes the importance of the control, its purpose, with a succinct and complete description
+* `impact` is an float that measures the importance of the compliance results and must be a value between `0.0` and `1.0`. The value ranges are:
+    * `0.0 to <0.4` these are controls with minor criticality
+    * `0.4 to <0.7` these are controls with major criticality
+    * `0.7 to 1.0` these are critical controls
+* `tag` is optional meta-information with with key or key-value pairs
+* `ref` is a reference to an external document
+* `describe` is a block that contains at least one test. A `control` block must contain at least one `describe` block, but may contain as many as required
+* `sshd_config` is an InSpec resource. For the full list of InSpec resources, see InSpec resource documentation
+* `its('Port')` is the matcher; `{ should eq('22') }` is the test. A `describe` block must contain at least one matcher, but may contain as many as required
+
+
+## Advanced concepts
+
+With InSpec it is possible to check if at least one of a collection of checks is true. For example: If a setting is configured in two different locations, you may want to test if either configuration A or configuration B have been set. This is accomplished via `describe.one`. It defines a block of tests with at least one valid check.
+
+```ruby
+describe.one do
+  describe ConfigurationA do
+   its('setting_1') { should eq true }
+  end
+
+  describe ConfigurationB do
+   its('setting_2') { should eq true }
+  end
+end
+```
+
+#### Sensitive resources
+
+In some scenarios, you may be writing checks involving resources with sensitive content (e.g. a file resource). In the case of failures, it may be desired to suppress output. This can be done by adding the `:sensitive` flag to the resource definition
+
+```ruby
+describe file('/tmp/mysecretfile'), :sensitive do
+  its('content') { should contain 'secret_info' }
+end
+```
+
+## Examples
+
+The following examples show simple compliance tests using a single `control` block.
+
+## Test System Event Log
+
+The following test shows how to audit machines running Windows 2012 R2 that password complexity is enabled:
+
+```ruby
+control 'windows-account-102' do
+  impact 1.0
+  title 'Windows Password Complexity is Enabled'
+  desc 'Password must meet complexity requirement'
+  describe security_policy do
+    its('PasswordComplexity') { should eq 1 }
+  end
+end
+```
+
+## Are PostgreSQL passwords empty?
+
+The following test shows how to audit machines running PostgreSQL to ensure that passwords are not empty.
+
+```ruby
+control 'postgres-7' do
+  impact 1.0
+  title "Don't allow empty passwords"
+  describe postgres_session('user', 'pass').query("SELECT * FROM pg_shadow WHERE passwd IS NULL;") do
+   its('output') { should eq('') }
+  end
+end
+```
+
+## Are MySQL passwords in ENV?
+
+The following test shows how to audit machines running MySQL to ensure that passwords are not stored in `ENV`:
+
+```ruby
+control 'mysql-3' do
+  impact 1.0
+  title 'Do not store your MySQL password in your ENV'
+  desc '
+   Storing credentials in your ENV may easily expose
+   them to an attacker. Prevent this at all costs.
+  '
+  describe command('env') do
+   its('stdout') { should_not match(/^MYSQL_PWD=/) }
+  end
+end
+```
+
+## Is `/etc/ssh` a Directory?
+
+The following test shows how to audit machines to ensure that `/etc/ssh` is a directory:
+
+```ruby
+control 'basic-1' do
+  impact 1.0
+  title '/etc/ssh should be a directory'
+  desc '
+   In order for OpenSSH to function correctly, its
+   configuration path must be a folder.
+  '
+  describe file('/etc/ssh') do
+   it { should be_directory }
+  end
+end
+```
+
+## Is Apache running?
+
+The following test shows how to audit machines to ensure that Apache is enabled and running:
+
+```ruby
+control 'apache-1' do
+  impact 0.3
+  title 'Apache2 should be configured and running'
+  describe service(apache.service) do
+   it { should be_enabled }
+   it { should be_running }
+  end
+end
+```
+
+## Are insecure packages installed ?
+
+The following test shows how to audit machines for insecure packages:
+
+```ruby
+control 'cis-os-services-5.1.3' do
+  impact 0.7
+  title '5.1.3 Ensure rsh client is not installed'
+
+  describe package('rsh') do
+    it { should_not be_installed }
+  end
+
+  describe package('rsh-redone-client') do
+    it { should_not be_installed }
+  end
+end
+```
+
+## Test Windows Registry Keys
+
+The following test shows how to audit machines to ensure Safe DLL Search Mode is enabled:
+
+```ruby
+control 'windows-base-101' do
+  impact 1.0
+  title 'Safe DLL Search Mode is Enabled'
+  desc '
+    @link: https://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx
+  '
+  describe registry_key('HKLM\\System\\CurrentControlSet\\Control\\Session Manager') do
+    it { should exist }
+    it { should_not have_property_value('SafeDllSearchMode', :type_dword, '0') }
+  end
+end
+```
+
+## Exclude specific test
+
+This shows how to allow skipping certain tests if conditions are not met, by using `only_if`.
+In this example the test will not be performed if `redis-cli` command does not exist, because for example package on remote host was not installed.
+
+```ruby
+control 'nutcracker-connect-redis-001' do
+  impact 1.0
+  title 'Check if nutcracker can pass commands to redis'
+  desc 'execute redis-cli set key command, to check connectivity of the service'
+
+  only_if do
+    command('redis-cli').exist?
+  end
+
+  describe command('redis-cli SET test_inspec "HELLO"') do
+    its(:stdout) { should match(/OK/) }
+  end
+end
+```
+
+Mixing this with other conditionals (like checking existence of the files etc.) can help to test different test paths using InSpec. This way you can skip certain tests which would 100% fail due to the way servers are prepared, but you know that the same test suites are reused later in different circumstances by different teams.
+
+## Additional metadata for controls
+
+
+The following example illustrates various ways to add tags and references to `control`
+
+```ruby
+control 'ssh-1' do
+  impact 1.0
+
+  title 'Allow only SSH Protocol 2'
+  desc 'Only SSH protocol version 2 connections should be permitted.
+        The default setting in /etc/ssh/sshd_config is correct, and can be
+        verified by ensuring that the following line appears: Protocol 2'
+
+  tag 'production','development'
+  tag 'ssh','sshd','openssh-server'
+
+  tag cce: 'CCE-27072-8'
+  tag disa: 'RHEL-06-000227'
+
+  tag remediation: 'stig_rhel6/recipes/sshd-config.rb'
+  tag remediation: 'https://supermarket.chef.io/cookbooks/ssh-hardening'
+
+  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
+  ref 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'
+
+  describe ssh_config do
+    its ('Protocol') { should eq '2'}
+  end
+end
+```