devsecops / bootcamp

A open contribute bootcamp to develop DevSecOps skills...

Sometimes the best way to learn a new concept is to get directly involved with it. The DevSecOps Bootcamp is developed by DevSecOps founders and practitioners, inspired by the idea that everyone is responsible for building rugged software, improving security and operating like a boss.

The DevSecOps Bootcamp is a 36 hour introduction to DevSecOps with the intention of helping the community understand DevOps + Security concepts. During the bootcamp, we will explore the professional, technical and cultural aspects involved in making security everyone's responsibility. The bootcamp is designed to provide an entry level understanding of common DevSecOps practices, processes and tools. You will learn how to support the DevSecOps transformation and increase security capabilities without the need for gating processes.

Audience

Our target audience for the DevSecOps bootcamp is:

• DevOps and IT professionals with Development, Security and/or Operations skills
• IT Security Professionals looking to transform their skills and remove gatekeeper processes
• DevOps professionals seeking to understand security
• IT Professionals seeking to understand the cultural differences of DevOps and Building Security into workloads

Prerequisites

• Previous development experience
• Familiarity with common IT concepts and technologies

Bootcamp Objectives

Individuals that attend the DevSecOps bootcamp have demonstrated:

• Knowledge of DevSecOps Fundamentals, Principles, Vocabulary, and Concepts
• Applied hands-on development, security and operational skills
• Awareness regarding cultural and organizational considerations
• Awareness of Lean, Agile, Scrum, DevOps and Rugged (Software, DevOps, etc.)
• Effectively contribute to the advancement of DevSecOps
• Understand how to safely remove gating processes
• Develop automation necessary to support DevSecOps environments
• Work with software-defined platforms that support DevOps

Curriculum

You cannot learn the right things to do until you fail a few times. The DevSecOps Bootcamp is 9 weeks with each week dedicated to a new lesson. Details: Curriculum

• Week 1: Getting Started
• Week 2: Build a Weak App
• Week 3: Attack the Weakling
• Week 4: Keeping the Weak alive
• Week 5: Build a Rugged App
• Week 6: Red for the Win!
• Week 7: Hunt the Attacker
• Week 8: A Capstone Project
• Week 9: Demos!

bootcamp's Issues

AWS STS "Invalid IPv6 URL" error (week 3 labs)

I encountered this error during the week 3 labs. This issue shows when trying to run an STS command (aws sts ...) and simply outputs "Invalid IPv6 URL". I'm not sure what the root cause of the error is, but I fixed it by doing the following.

1. removing the profile from my .aws/credentials file
2. deleting the key I was assigned via the AWS Console (in a broswer)
3. getting a new key and setting up the profile as normal using aws configure

Resetting the keys enabled me to properly use STS and other AWS commands.

Downloading Python tars via http - MiTM

Can you flip links to https for both of python packages at L20?
https://github.com/devsecops/bootcamp/blob/master/Vagrantfile#L20

create a devsecops box

We shouldn't be rebuilding and running aws, ruby, etc everytime you vagrant up.

• One option is move it to a chef cookbook first and then use packer (https://www.packer.io/intro/getting-started/build-image.html) to create a ami, vbox, vmfusion, or etc.
• Another option is to usevagrant package(https://www.vagrantup.com/docs/cli/package.html)
• Once the image is created store it in the public vagrant catalog

Getting vagrant error "Could not find the X.Org or XFree86 Window System" on my Windows machine

SYMPTOM/ISSUE

Some Windows users have experienced an issue when running vagrant up or vagrant provision or vagrant ssh.
The error message is:

...
Uncompressing VirtualBox 5.0.10 Guest Additions for Linux............
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
Starting the VirtualBox Guest Additions ...done.
Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping.
An error occurred during installation of VirtualBox Guest Additions 5.0.10. Some functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
...

DESCRIPTION

This seems to be caused by the version of vagrant plugin vagrant-vbguest on Windows.

SOLUTION

Add the following line to the top of your Vagrantfile: ENV['VBOX_INSTALL_PATH'] = ENV['VBOX_MSI_INSTALL_PATH'].

Your Vagrantfile should look something like this:

ENV['VBOX_INSTALL_PATH'] = ENV['VBOX_MSI_INSTALL_PATH']
# -*- mode: ruby -*-
# vi: set ft=ruby :

BASIC_SETUP = <<SCRIPT
  echo "######################"
  echo "# UPDATE LINUX REPOS #"
  echo "######################"
  sudo yum update -y
  echo "#############################"
  echo "# INSTALLING GIT, VIM, WGET #"
  echo "#############################"
  sudo yum install -y git vim wget xz-libs
  sudo yum groupinstall "Development Tools" -y
SCRIPT

AWS_SETUP = <<SCRIPT
  echo "##################################"
  echo "# INSTALLING PYTHON DEPENDENCIES #"
  echo "##################################"
  wget http://www.python.org/ftp/python/2.7.11/Python-2.7.11.tar.xz && wget http://www.python.org/ftp/python/3.4.3/Python-3.4.3.tar.xz
  xz -d Python-2.7.11.tar.xz && xz -d Python-3.4.3.tar.xz
  tar -xvf Python-2.7.11.tar && tar -xvf Python-3.4.3.tar
  cd /home/vagrant/Python-2.7.11/ && ./configure && make && sudo make install
  cd /home/vagrant/Python-3.4.3/ && ./configure && make && sudo make install
  echo "##################################"
  echo "######### INSTALLING PIP #########"
  echo "##################################"
  cd /home/vagrant/
  sudo yum install -y epel-release
  # curl -o- https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm > epel7.rpm
  # sudo rpm -Uvh epel7.rpm
  sudo yum update && sudo yum install -y python-pip
  sudo pip install --upgrade pip
  echo "##################################"
  echo "#### INSTALLING AWS CLI ##########"
  echo "##################################"
  sudo pip install awscli
SCRIPT

RUBY_SETUP = <<SCRIPT
  echo "##################################"
  echo "## INSTALLING RUBY DEPENDENCIES ##"
  echo "##################################"
  sudo yum install -y autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev openssl-devel readline-devel zlib-devel
  echo "##################################"
  echo "###### INSTALLING RBENV ##########"
  echo "##################################"
  git clone https://github.com/rbenv/rbenv.git /home/vagrant/.rbenv
  echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> /home/vagrant/.bash_profile
  echo "##################################"
  echo "######## RBENV INIT ##############"
  echo "##################################"
  echo 'eval "$(rbenv init -)"' >> /home/vagrant/.bash_profile
  source /home/vagrant/.bash_profile
  echo "##################################"
  echo "##### INSTALLING RUBY-BUILD ######"
  echo "##################################"
  git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
  rbenv rehash
  echo "##################################"
  echo "#### DISABLE RUBY DOCS ###########"
  echo "##################################"
  echo "gem: --no-document" >> /home/vagrant/.gemrc
  rbenv install 2.3.1
  rbenv global 2.3.1
SCRIPT

Vagrant.configure("2") do |config|
  config.vm.box = 'centos/7'

  # config.vm.provider 'virtualbox' do |v|
  #  v.memory = 2048
  #  v.cpus = 2
  # end

  # # If you have VMware Fusion installed and prefer to use VMware, uncomment the lines below and launch vagrant in the terminal with : vagrant up --provider=vmware_fusion
  # config.vm.provider 'vmware_fusion' do |v|
  #   v.vmx['memsize'] = '2048'
  #   v.vmx['numvcpus'] = '2'
  # end

  # If you want to sync the bootcamp directory between the host and guest VM, you need to install a plugin: "vagrant plugin install vagrant-vbguest"
  config.vm.synced_folder ".", "/home/vagrant/sync", type: "virtualbox" 

  config.vm.provision :shell, inline: BASIC_SETUP,  privileged: false
  config.vm.provision :shell, inline: RUBY_SETUP,   privileged: false
  config.vm.provision :shell, inline: AWS_SETUP,    privileged: false

  config.vm.network "forwarded_port", guest: 3000, host: 3000

end

Rewrite the assumer gem/CLI in golang

CLI's in GO are easier to install than their Ruby or Python counterparts. Couple that with cross-compiling for different OS types and you have advantages that are hard to dispute.

PROBLEM:
Installing and configuring Ruby, rvm/rbenv, and associated gems can be difficult for some end users. It would be nice if this was simpler.

SCOPE:
Provide equivalent functionality in a GO binary for the https://github.com/devsecops/assumer ruby code.

USE CASE:
Installation is as simple as downloading the appropriate go artifact for your operating system, un-tar'ing it, and running the binary.

Create a metasploit adapter for gauntlt

https://github.com/gauntlt/gauntlt/blob/master/lib/gauntlt/attack_adapters/

Will attempt to get into contact with Wickett.

SyntaxError

The following error is displayed after running aws config on Windows 10:

[vagrant@localhost ~]$ aws config Traceback (most recent call last): File "/usr/bin/aws", line 19, in <module> import awscli.clidriver File "/usr/lib/python2.7/site-packages/awscli/clidriver.py", line 17, in <module> import botocore.session File "/usr/lib/python2.7/site-packages/botocore/__init__.py", line 96 name = f"{name[: -len(matched)]}{sep}{matched.lower()}" ^ SyntaxError: invalid syntax

"Signature Expired" Error Message When Using AWS STS Command

When using STS to assume the control account control I experienced the following error:

A client error (SignatureDoesNotMatch) occurred when calling the AssumeRole operation: Signature expired: 20160609T184512Z is now earlier than 20160610T013008Z (20160610T014508Z - 15 min.)

This is resulting from having the local time discrepant by 15 or more minutes.

Getting error "NS_ERROR_FAILURE (0x80004005)" when running "vagrant up" or "vagrant ssh" on Windows

SYMPTOM/ISSUE

When I run vagrant up or vagrant ssh on my Windows machine, I get the following error:

...
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
Machine
Interface:
IMachine 
...

DESCRIPTION

This issue is not coming from Vagrant, but rather from VirtualBox.
Furthermore, if you try to open VirtualBox itself and open a console into your Virtual Machine, you will get the error:

VT-x/AMD-V hardware acceleration has been enabled, but is not operational. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot.

Please ensure that you have enabled VT-x/AMD-V properly in the BIOS of your host computer.

SOLUTION

This error is caused by Virtualization Technology setting being disabled in your BIOS.
To resolve this, you must:

• Know what keyboard combinations/keys will get you to the BIOS screen (e.g. HP Envy is F10).
  • If you don't know, google it (e.g. how to access bios on [insert laptop brand and model here])
• Reboot/restart your Windows machine and press the keyboard combinations/keys to access the BIOS
• Once in the BIOS screen, enable the Virtualization Technology setting
• Save and Quit

Then once your machine is rebooted, in Git Bash, go to dso_repos/bootcamp directory and run: vagrant up.

Referenced application repo no longer availible

In Week-2/labs/LAB-3.md, instructions are to grab the following repo but it does not exist.

https://github.com/godinezj/myapp.git/

Getting "There was an error when attempting to rsync a synced folder" error message on my machine

SYMPTOM/ISSUE:

When running vagrant up, I get the following error message:

There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.

DESCRIPTION:

This issue seems to happen primarily on Windows machines, but some Mac OS X users have encountered this problem.

When Vagrant initializes the virtual machine, it tries to sync the bootcamp directory on your local machine with the guest VM. Vagrant defaults to using a linux/unix utility, called rsync. This causes Vagrant to fail on some machines, especially Windows.

SOLUTION:

Instead of using the default rsync utility, Vagrant can be configured to tell VirtualBox to mount the local bootcamp directory in the guest VM.

Make sure your Vagrantfile has the following code:

# If you want to sync the bootcamp directory between the host and guest VM, you need to install a plugin: "vagrant plugin install vagrant-vbguest"
config.vm.synced_folder ".", "/home/vagrant/sync", type: "virtualbox"

If you do not see that code in your Vagrantfile, then you may have an old version of the bootcamp repository.

Please, pull the latest bootcamp repository down to your local repo and run:

vagrant plugin install vagrant-vbguest && vagrant reload

Getting "ruby: command not found" or "aws: command not found"

SYMPTOM/ISSUE

When I'm in the virtual machine and I try to run ruby -v or gem install rails or aws configure, I keep getting errors: ruby: command not found or gem: command not found or aws: command not found.

DESCRIPTION

When Vagrant is initializing the virtual machine for the first time, Vagrant first downloads a minimalist OS (in this case, CentOS 7) with essentially nothing on it but the core OS itself, then runs the scripts that are defined in the Vagrantfile, such as the BASIC_SETUP, RUBY_SETUP, and AWS_SETUP.

For some reason (potentially network latency issues), some scripts fail to run in a timely fashion (aka timeout) or fail to run at all.

SOLUTION

In your local machine terminal (if you're SSHed into the virtual machine, exit out of it), then run:

vagrant provision && vagrant ssh

This will re-run the provisioning scripts again and will SSH into the virtual machine once complete.
At this point, verify that ruby and/or aws have been installed by running:

ruby -v
aws configure

If you still get command not found error or any other errors, please open an issue with your details.

Lab 3 with vagrant up

Hi, when I perform vagrant up. I get an error with the repository.

MINGW64 ~/Desktop/dso_repos/bootcamp (master)
$ vagrant up
Bringing machine 'devsecops' up with 'virtualbox' provider...
==> devsecops: Importing base box 'centos/7'...
==> devsecops: Matching MAC address for NAT networking...
==> devsecops: Checking if box 'centos/7' version '1905.1' is up to date...
==> devsecops: Setting the name of the VM: bootcamp_devsecops_1564434099266_87107
==> devsecops: Clearing any previously set network interfaces...
==> devsecops: Preparing network interfaces based on configuration...
devsecops: Adapter 1: nat
==> devsecops: Forwarding ports...
devsecops: 3000 (guest) => 3000 (host) (adapter 1)
devsecops: 22 (guest) => 2222 (host) (adapter 1)
==> devsecops: Booting VM...
==> devsecops: Waiting for machine to boot. This may take a few minutes...
devsecops: SSH address: 127.0.0.1:2222
devsecops: SSH username: vagrant
devsecops: SSH auth method: private key
devsecops:
devsecops: Vagrant insecure key detected. Vagrant will automatically replace
devsecops: this with a newly generated keypair for better security.
devsecops:
devsecops: Inserting generated public key within guest...
devsecops: Removing insecure key from the guest if it's present...
devsecops: Key inserted! Disconnecting and reconnecting using new SSH key...
==> devsecops: Machine booted and ready!
[devsecops] No Virtualbox Guest Additions installation found.
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=<repoid> ...

 4. Disable the repository permanently, so yum won't use it by default. Yum
    will then just ignore the repository until you permanently enable it
    again or use --enablerepo for temporary usage:

        yum-config-manager --disable <repoid>
    or
        subscription-manager repos --disable=<repoid>

 5. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: extras/7/x86_64
==> devsecops: Checking for guest additions in VM...
devsecops: No guest additions were detected on the base box for this VM! Guest
devsecops: additions are required for forwarded ports, shared folders, host only
devsecops: networking, and more. If SSH fails on this machine, please install
devsecops: the guest additions and repackage the box to continue.
devsecops:
devsecops: This is not an error message; everything may continue to work properly,
devsecops: in which case you may ignore this message.
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

yum install -y centos-release

Stdout from the command:

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

Stderr from the command:

One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=<repoid> ...

 4. Disable the repository permanently, so yum won't use it by default. Yum
    will then just ignore the repository until you permanently enable it
    again or use --enablerepo for temporary usage:

        yum-config-manager --disable <repoid>
    or
        subscription-manager repos --disable=<repoid>

 5. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: extras/7/x86_64

Lab 3 content is not available

For Lab 3, 'git clone [email protected]:devsecops/bootcamp.git' returns the following error:

$ git clone [email protected]:devsecops/bootcamp.git Cloning into 'bootcamp'...
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts. [email protected]: Permission denied (publickey). fatal: Could not read from remote repository.

Assumer Error "sh: xdg-open: command not found" Week4 Lab 1

In order to fix this, I ran the command "sudo yum install xdg-utils". No confirmation on this being a proper fix though. The command fixed one error, but now the box is onto another.

Signature mismatch error while assuming roles into AWS

A client error (SignatureDoesNotMatch) occurred when calling the AssumeRole operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Below steps fixed this issue,

• Firstly verify the system clock, see if it shows a out of sync time, if yes, then reload vagrant
  $ Date
• If the issue persists, create new AWS API keys from AWS console, avoid using nano editor to copy the credentials, replace the existing one's, follow the steps mentioned in repo.

vagrant don't up

Hello.
I can't up your vagrantfile on ubuntu server 17.10 artful

I'm get

dev@ubuntu:~/dso_repos/bootcamp$ vagrant destroy
    devsecops: Are you sure you want to destroy the 'devsecops' VM? [y/N] y
==> devsecops: Forcing shutdown of VM...
==> devsecops: Destroying VM and associated drives...
dev@ubuntu:~/dso_repos/bootcamp$ nano Vagrantfile
dev@ubuntu:~/dso_repos/bootcamp$ vagrant up
Bringing machine 'devsecops' up with 'virtualbox' provider...
==> devsecops: Importing base box 'centos/7'...
==> devsecops: Matching MAC address for NAT networking...
==> devsecops: Checking if box 'centos/7' is up to date...
==> devsecops: Setting the name of the VM: bootcamp_devsecops_1512232471751_23502
==> devsecops: Clearing any previously set network interfaces...
==> devsecops: Preparing network interfaces based on configuration...
    devsecops: Adapter 1: nat
==> devsecops: Forwarding ports...
    devsecops: 3000 (guest) => 3000 (host) (adapter 1)
    devsecops: 22 (guest) => 2222 (host) (adapter 1)
==> devsecops: Booting VM...
==> devsecops: Waiting for machine to boot. This may take a few minutes...
    devsecops: SSH address: 127.0.0.1:2222
    devsecops: SSH username: vagrant
    devsecops: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Docker didn't start, also and it don't have logs.

6 Challenges Facing DevOps and Operations Teams

Previously IT infrastructure was a service published to the rest of the organization. The systems were configured and maintained by operations. If there was a new request, the request was made, and then executed by the operations team.

In the modern world of users and development the process is a bit more subjective and collaborative. This is a good thing, but shifts the dynamic and responsibilities. Development users demand more, and are adopting tools at a nearly un-manageable pace. Business users are more technically savvy, know what they want, and often will try to address challenges on their own. Additionally their productivity environment has made a major move to mobile devices, which are self-contained and hungry for enterprise-wide cloud services.

I’m sure you have heard “knowing is half the battle,” and sometimes when in the weeds, you cannot spend the time to reflect on what has happened and what is coming. Knowing what you will face will help you brace and prepare in advance. Here is the list.

1. Who owns Culture?

You have heard that DevOps is culture first. And while you know what culture means, it’s never clear who owns it. The point of naming culture is to highlight that its creation should be deliberate. It does not mean Ninjas, Rockstars, and hoodies. Culture exists no matter what, but usually it creates itself. And in DevOps you are supposed to intentionally foster collaboration, and results driven effort.

Until operations can identify how they will include culture fostering into their daily activities, there is no way to help this aspect of DevOps grow. It is a must to get to the processes and proper implementation of the tools. Infrastructure is still in operations full control, but because large organizations are creating dev silos the culture is not, and because they are supposed to be tied, this is a bit of a contradiction.

2. Everyone has a tool

These days everyone has a tool for the job. Either they used it in the past, they heard about it from a friend, or recently saw it on TechCrunch. Many of the tools are open-source, or SaaS based offerings that users can get a trial of and start using instantly. The trick for operations is to support this and still maintain awareness.

These tools can be adopted without any internal oversight, which can lead to issues down the road. First because of support down the road if the original adopter leaves, but more importantly governance. What data is stored there?

This is usually not developments concern, but operations are expected to know.

Balancing tool delegation, which needs to happen, and tool management is something that needs to be addressed early on. This is where the concept of Shared Services comes in handy.

3. “There is an App for that, right?”

All those tools are simply an app you download and use, right?

Nope.

They have to tie into everything else, and it’s not the App that is the challenge. The challenge is getting it adopted, integrated, and quantified. For example a functional testing tool fixes QA challenges, but it has to fit in with delivery automation tools as well.

4. Cloud + Legacy

The reason operations don’t jump at tools at the pace that development and business users would desire, is not because they do not want to. Often it’s because that tool has to fit into an ecosystem of existing applications. Usually there are a few grandpa applications in there that lack have the agility the modern tools have. But they still have to work together.

Not only does the new hybrid environment include on-premise tools, IaaS tools like Amazon, Google, or Azure, PaaS compute services, and finally SaaS business applications. But, they all have to jive together too!

5. Networking is a drag

Networking, not servers, is often the immutable object that is not easy to make agile. Even when working with vLans there is a spider web of IPs, Ports, Routers, routing tables, perimeter networks etc who’s interdependency can’t simply be changed, broken, moved, or replicated.

6. Marginalized and Changing Budgets

it is very cliché to say budgets are being squished while demands are increasing. But that is not the point. The point is the structure of budgets is changing, and many organizations have not figured out how to align that with the shift in types of technology. There are the capital expenses that are separate from the operational ones. However CAPEX spends often are mirrored by sister OPEX ones.

It becomes very confusing when you try to quantify the spend on an on-premise project management tool with a SaaS one as well. While this is a job for the CFOs it impacts the structure of IT budgets, or sometimes means that IT gets even less control over OPEX spends because decision making is distributed, and can happen on a credit card.

Source: logentries

Add instructions to setup Git

You may want to add instructions to setup Git after installation for Lab 3.

For example if you don't have an ssh key setup for your git account you will get a permission denied error when you tor to clone the bootcamp repository

git clone [email protected]:devsecops/bootcamp.git

You can follow the steps described here,

https://gist.github.com/adamjohnson/5682757

to resolve.