Skip to content

Security: How to address NESSUS scan findings

Emmanuel Nwakire edited this page Nov 14, 2024 · 17 revisions

Addressing NESSUS scan findings

Standard Operating Procedure (SOP) for Updating Nessus Scan Findings

IMPORTANT: Nessus findings should be addressed on PROD after COB EST. This is to mitigate potential site outages during times where there may be traffic on the site. DEV and STG can be addressed at any time.

  1. Inform the team that the Nessus findings are going to be addressed prior to performing any actions, to ensure at least one other person is in the loop.
  2. Address the findings (refer to the information below), starting with DEV.
  3. After making the necessary changes, make sure the app is still running. If not, check to see if the server/container is running. If the server/container is not running, try the following:
  • Server: Go into AWS, and under EC2 instances, start the server.
  • Container: In the diffusion-marketplace directory, run docker-compose down and then ./scripts/start-container-app.sh.
  1. If neither of these actions work, reach out for help.
  2. Once the server/container is fully operational, repeat the above steps for the STG environment.
  3. If on DEV or STG the server/container stopped running, DO NOT move onto PROD. Instead, try to figure out what caused the issue.
  4. When both DEV and STG have been updated, you may proceed to PROD. If necessary, inform the product owner/stakeholders that the site may go down temporarily.

Prerequisites

  • Obtain the monthly NESSUS scan findings
  • Go through each entry in the findings and update the specified package/kernel for the affected server
  • Go to to the session manager and open up the console for the affected server

Updating Linux packages

  • Check the package version rpm -qa | grep <package>

  • Update the package sudo yum update <package>

Automation Script for addressing NESSUS scan findings.

  • In other to eliminate the manual process of updating the Nessus findings on our servers, a bash shell automation script has been put in place to have this process automated.
  • cd into bin directory starting with the Dev server, then stage and lastly production servers respectively
  • Check the package version of each package you wish to update rpm -qa | grep <package>
  • Then sudo vi pack.sh and uncomment out the package you want to update. Same file name applies to all our servers pack.sh
  • once you are done editing the script, use sudo sh pack.sh to run the script and all the packages will be successfully installed.
  • KINDLY NOTE if you come across these packages named Containerd and Docker if you chose to update this package, it clears out the underlying docker containers that host the application. Once you are done updating this package. kindly return back to the our Deployment tool Jenkins and rebuild the application according to each environment

Updating the kernel

  • Check the current version of the kernel uname -a

  • Update the kernel sudo yum install -y kernel

  • Be sure to reboot the instance after updating the kernel

- AFTER REBOOTING, start the containers again by running the start_appcontainer.sh script

  • Make sure to check the version of the kernel to ensure it updated after rebooting NOTE: If the kernel version did not change, but was successfully installed (confirm using sudo yum list kernel), there may have been an issue during the install process. Try reinstalling the kernel using sudo yum reinstall kernel* -y, reboot the server AND container, and check the version again.
Clone this wiki locally