16. Vulnerability Scanning Policy

Luma is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis.

Luma utilizes GitHub security and AWS Intruder to consistently scan, identify, and address vulnerabilities on our systems.

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

  • 10.m - Control of Technical Vulnerabilities

16.1.2 Applicable Standards from the HIPAA Security Rule

  • 164.308(a)(8) - Evaluation

16.2 Vulnerability Scanning Policy

  1. GitHub security management is performed by the Luma Security Officer, or an authorized delegate of the Security Officer.
  2. Intruder is used to monitor all internal IP addresses (servers, VMs, etc) on Luma networks.
  3. Frequency of scanning is as follows:
    • on a weekly basis
    • after every production deployment
  4. Intruder is used to monitor external and internal vulnerabilities on Luma’s AWS infrastructure.
  5. Frequency of scanning is as follows:
    • on a monthly basis
    • after the deployment of new IP targets
    • when an emerging threat is identified
  6. Reviewing GitHub and Intruder reports and findings, as well as any further investigation into discovered vulnerabilities, are the responsibility of the Luma Security Officer or a delegate. The process for reviewing the reports is outlined below:
    1. The Security Officer initiates the review of a GitHub Report by creating an Issue in ClickUp. If deemed appropriate, the Security Officer may choose to address the issue without creating a ticket with the aid of a delegate.
    2. The Security Officer, or a Luma Security Engineer assigned by the Security Officer, is assigned to review the Report.
    3. If new vulnerabilities are found during review, the process below is used to test those vulnerabilities is outlined below. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
  7. In the case of new vulnerabilities, the following steps are taken:
    • All new vulnerabilities are verified manually to assure they are repeatable. Those not found to be repeatable are manually tested after the next vulnerability scan, regardless of if the specific vulnerability is discovered again.
    • Vulnerabilities that are repeatable manually are documented in the Risk Register and reviewed by the Security Officer and Privacy Officer to see if they are part of the current risk assessment performed by Luma.
      • Those that are a part of the current risk assessment are checked for mitigations.
      • Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the Luma Risk Assessment Policy.
  8. All vulnerability scanning reports are retained for 6 years by Luma. Vulnerability report review is monitored on a quarterly basis using ClickUp reporting to assess compliance with above policy.
  9. This vulnerability policy is reviewed on a quarterly basis by the Security Officer and Privacy Officer.
  10. Luma recieves weekly intelligence reports on emerging new threats and infrastructure is automatically scanned for new threats as they are identified to assess is we are vulnerable.
  11. External Vulnerability Scanning is also performed:
    • Scans are performed by a PCI SCC Approved Scanning Vendor (ASV)
    • Scans are performed no less than quarterly, and/or following any material change to the production environment
    • Scans and any rescans performed shall satisfy the ASV Program Guide Requirements
    • Should any scan fail ASV Program Guide Requirements, remediation will be performed in accordance with Luma Health policy detailed above, and appropriate rescans shall be performed

16.3 Penetration Testing

Luma engages a qualified third-party to perform an application penetration and vulnerability test. This takes place no less than annually, and after any significant infrastructure or segmentation changes. Any findings will be handled following this policy.

The penetration test methodology includes but is not limited to:

  • Based on industry-accepted approaches such as NIST SP800-115;
  • Coverage for all critical systems;
  • Testing from both inside and outside the network;
  • Review and consideration of threats and vulnerabilities experienced in the last 12 months;
  • Retention of results and remediation activity results;
  • Repeated testing following remediation of exploitable vulnerabilities to verify corrections;
  • Testing of all segmentation methods, to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE;
  • Coverage for all segmentation controls and methods;
  • Defines application-layer penetration tests to include common coding vulnerabilities
  • Defines network-layer penetration tests to include components that support network functions as well as operating systems