anchor.diff:  
   If this doesn't work, go back to https://github.com/dm-academy/aitm-labs/blob/master/Lab-02/02-tech-lab.adoc[Lab 2] and follow the Section 1 instructions just up through getting the simple Vagrant machine running (do not continue to section 2 in that lab.)
   
  -Now, install Lynis. The overall instructions are here:
  +Now, start by logging into your personal server. You should be in `/home/vagrant`. Install Lynis. The overall instructions are here:
   
   https://cisofy.com/documentation/lynis/get-started
   
   You should download using the git approach.
   
  -NOTE: If you choose to clone into /usr/local, you will need to sudo. 
  +NOTE: If you choose to clone into /usr/local, you will need to sudo.
   
   This scan is run internally on the server, as a script or application that reviews the server's configuration in painstaking detail. It will generate hundreds of findings. You should pick one or two and research them and figure out if there is an easy fix.
   
  -Start by logging into your personal server. You should be in `/home/vagrant`. Go to:
  +Start by logging into your personal server. You should be in `/home/vagrant`. 
   
  -https://cisofy.com/documentation/lynis/get-started/#first-run
  +Go to:
   
  -You should be able to run the first scan as the lynis directions suggest. Lots of output that looks like:
  +https://cisofy.com/documentation/lynis/get-started/#first-run and run the scan.
  +
  +You should be able to run the first scan as the lynis directions suggest. This scan is run internally on the server, as a script or application that reviews the server's configuration in painstaking detail. Lots of output that looks like:
   
   ....
   - Checking for old files in /tmp                            [ OK ]
  
positive.code: === Web vulnerability testing scan
  (if time)
  
  When you have reflected enough on the Java deserialization vulnerability and the implications of that article, move on to a Web vulnerability.
  
  First review the first few pages of the https://github.com/zaproxy/zaproxy/releases/download/2.4.0/ZAPGettingStartedGuide-2.4.pdf[zaproxy docs].
  
  Exit from your VM to the main server. You should be in your publicxx directory (go `cd` if you are not).
  
  Create a directory called "lab-10" there, if your teammates have not already.
  
  (Seems like you just did this, what's up with that?)
  
  Go:
  
  ....
  wget https://github.com/zaproxy/zaproxy/releases/download/2.5.0/ZAP_2.5.0_Linux.tar.gz
  tar -xvf ZAP_2.5.0_Linux.tar.gz
  
  cd ZAP_2.5.0/
  ./zap.sh -cmd -quickurl http://10.xx.0.15:8080/MainServlet
  ....
  
  We run this script externally to the machine being tested, and give it the URL. It then probes the URL and the server, as a form of penetration testing. It will again generate a number of findings. Research them and figure out if there is an easy fix. Share with class on Slack.
  
  NOTE: You will get raw XML dumped to the terminal. You can cut and paste this to an HTML document on your workstation and open it with a browser for an easier view.
  
  Now, try
  
  `./zap.sh -cmd -quickurl http://10.xx.0.12:8081/artifactory`
  
  More errors than before... why? Discuss. How would you fix these?
  
  == Permanently fixing one or more vulnerabilities
  
  First, you need to figure out the configuration change required to fix the vulnerability. It should be something that you can script.
  
  For this reason, you should choose a vulnerability that is relatively simple to fix.
  
  * something installed that doesn't need to be
  * something that should be there, that isn't
  * permissions that need to be tightened down.
  
  In order to fix the vulnerability (fixing something on caraXX would probably be simplest):
  
  . Run the necessary commands to fix the vulnerability.
  . Put them into a shell script.
  
  So, you have a script called servername.sh. Perhaps you've run it on the current server and fixed things, but that doesn't help if we refresh the server.  We need to suggest the script as a change to the core recipe.
  
  To do this, you need to create a team fork in the main Calavera repository. Clone down to a working directory you have write access to on the main server (either your home dir or an `su`'d publicxx dir), vagrant up the virtual server in question, and work the fix. When you are satisfied, submit a pull request.
  
  
  === Optional ITSM process
  Time and instructor lab preparation permitting:
  
negative.code: http://www.sonatype.org/nexus/2015/11/13/did-you-wake-up-to-an-alert-about-the-java-deserialization-vulnerability
  
  http://continuousdelivery.com/2013/08/risk-management-theatre/
  