Giter VIP home page Giter VIP logo

canonical-ubuntu-18.04-lts-server-cis-baseline's Issues

C-1.1.23 is failing when it should not be

I have a failing test for control 1.1.23: Disable USB Storage.

  ×  C-1.1.23: Disable USB Storage (1 failed)
     ✔  Kernel Module usb-storage is expected not to be loaded
     ×  Kernel Module usb-storage is expected to be disabled
     expected `Kernel Module usb-storage.disabled?` to be truthy, got false

However, the 'check' commands indicate that this should not fail:

~ $ modprobe -n -v usb-storage
install /bin/true
~ $ lsmod | grep usb-storage

The other disabled module checks are working as expected. Could this have to do with the fact that there is a hyphen in the name of the module? Looking at the disabled? check, it seems that it runs modprobe --showconfig, which returns the following line (among others):

install usb_storage /bin/true

Note the _, instead of the - that the docs for this control mention (and the official CIS Benchmark PDF also uses - when discussing this control). Are the - and _ interchangeable here? Should the inspec kernel_module constructor use the _ form?

Control naming convention

Please use this unique prefix name for controls: "ubuntu-18.04-server-cis-"

For example:
Change: control "C-1.1.1.1" do
To: control "ubuntu-18.04-server-cis-1.1.1.1" do

add a docker image build, harden and test into our PR and workflow process

We would like to enhance the profile to be 'container aware' by using the `virtualization resource so that for the tests that need to be NA ( aka impact 0 ) or the testing process changes when ubuntu is run in a container vs a VM or EC2 - our profile should be able to accommodate for that and properly document and report it in the testing results.

add 'development, testing and contributing' section that describes and explains the kitchen.ci testing

# Testing with Kitchen

## Dependencies

- Ruby 2.3.0 or later
- [Virtualbox](https://www.virtualbox.org)
- [Vagrant](https://www.vagrantup.com)

#### _Notes to Windows Users_

1. An installation of ChefDK may generate conflicts when combined with the
   installed kitchen gems. **Recommend NOT installing ChefDK before testing
   with this repo.**

2. If you run into errors when running `bundle install`, use the following
   commands to install gems:

- `gem install kitchen-puppet`
- `gem install librarian-puppet`
- `gem install kitchen-vagrant`

3. If the tests are not found when running `kitchen verify`, open
   `.kitchen.yml` and consult `inspec_tests` under the `suites` section.

4) You may also experience an error when running `kitchen converge` where a
   folder is unable to be created due to the length of the path. In this case,
   you may need to edit a registry key as explained
   [here](https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/).

## Setting up your box

1. Clone the repo via `git clone -b dev https://github.com/simp/inspec_profiles.git`
2. cd to `inspec_profiles`
3. Run `bundle install`
4. Run `kitchen list` - you should see the following choice:
   - `default-centos-7`
5. Run `kitchen converge default-centos-7`
6. Run `kitchen list` - your should see your host with status "converged"

## Validating your box

**Note:** Once the open issues are resolved in InSpec and kitchen-inspec these
steps will not really be needed but for now we have to do a few things a bit
more manually. Once resolved fully, you will only need to run `kitchen verify (machine name)` and everything will be taken care of.

### In the 'inspec_profiles' dir ( manually )

1. cd `.kitchen/`
2. vi default-centos-7.yml
3. copy the `ssh_key:` value for later
4. note the mapped port value ( usually `2222`) and use in the next step

### In the 'inspec_profiles' dir

1. On the terminal: `export SSH_KEY=(value from before)`
2. cd to `inspec_profiles`

   - (optional) run an `inspec check`, and
     ensure there are no errors in the baseline.

3. run: `inspec exec -i $SSH_KEY -t ssh://[email protected]:2222 ( or the port mapped from step '4' above )`
   - (optional) `inspec exec controls/V-#####
   - -i \$SSH_KEY -t
     ssh://[email protected]:2222` to just test a single control
   - (optional) `inspec exec -i $SSH_KEY --controls=V-#####,V-##### -t ssh://[email protected]:2222` to just test a
     small set of controls

# Hardening Development

Included in this repository are testing scripts which allow you to run the profile using Vagrant or EC2 VMs. You can choose which environment your VMs are run in by passing the appropriate test-kitchen `yml` file to your `KITCHEN_LOCAL_YAML` environment variable. All of the commands below use the `kitchen.vagrant.yml` file as an example, however a `kitchen.ec2.yaml` is also available in the repository and can be substituted below to run the tests in EC2.

- Making Changes and Testing

  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen converge (machine name)` - runs any changes to your hardening scripts
  - run `kitchen verify (machine name)` - runs the inspec tests

- Starting Clean:
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen destroy (machine name)` kitchen will drop your box and you can start clean
- Going through the entire process ( create, build, configure, verify, destroy )
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen test (machine name)` or to test all defined machines `kitchen test`
- Just running the validation scripts
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen verify (machine name)`
- just run one or more controls in the validation
  - edit the .kitchen.yml file in the `controls:` section add the `control id(s)` to the list

add cicd testing to our PR process and repo

https://github.com/florianutz/Ubuntu1804-CIS

seems to be a fairly well-maintained ansible-playbook but I am open to suggestions.

https://github.com/mitre/canonical-ubuntu-18.04-lts-stig-baseline

The STIG ubuntu GitHub Workflows and kitchen ci configuration can be reused but switching out for the CIS Ansible Playbook. The kitchen.yml, vagrant.yml, thresholds, will need minimal adjustment.

To test locally, set KITCHEN_LOCAL_YAML to your vagrant.yml file.

Thoughts on using `skip`

When running inspec tests, the results show the number of passed, skipped, and failed tests. At least from my perspective, I view failures as something that should never happen (ie, a build should not be allowed to proceed if a test fails) and skipped tests should be reviewed. For example, accepted risks might use skips (with a comment pointing to some documentation about the accepted risk, mitigations, etc). Or an unimplemented test might use a skip to indicate that this control exists, but we don't know if it is passing or failing.

On the other hand, I notice a lot of controls here use skip with controls that say something like "If X is used, then it must be properly configured", in the case where "X" is not used. (Eg. 2.2.1.3.)

What are your thoughts on changing controls like 2.2.1.3 to pass when the package they are concerned with is not in use, and adding skips to unimplemented controls (eg 3.6)?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.