Skip to main content

Patch Monitoring & Validation

To maintain security and compliance, this document establishes the official procedure for managing systems that fail to receive timely OS updates due to extended offline periods. This protocol, which outlines enforcement and remediation steps, is derived from and built upon the university's overarching information security policy.

We use the following websites to check OS build release dates:

Patch Monitoring​

The first week of the month we will check our Axonius Dashboard for OS builds and categorize based on the build release date as green, yellow or red specified below.

tip

Use Windows (MECM), macOS (JAMF) and Linux (Ansible) to verify Axonius is accurate

Compliant (Green)​

  • Definition: The OS build that the device is running has been released within 30 days by the manufacturer.
  • Required Action: None. These devices are in full compliance with university policy and will continue to be monitored as part of routine operations.

Noncompliant (Yellow)​

  • Definition: The OS build that the device is running has been released between 30-90 days by the manufacturer.
  • Required Action:
    • Move device to the PVFA>ADMINISTRATIVE>PATCH division in Sassafras.
    • Create service ticket AND put a note in the asset with the ticket number, PATCH TICKET #123456
      • Owner Notification: The assigned device owner is contacted with a request to power on the machine and connect it to the campus network to receive updates.
      • Manual Intervention: If owner-assisted remediation is not successful, IT support will attempt to apply the updates through a remote connection or, for accessible on-campus devices, through direct physical access.
danger

Be sure MULTIPLE attempts are documented in the ticket before moving to the next stage.

Nonresponse Noncompliant (Red)​

  • Definition: The OS build that the device is running has been released more than 90 days by the manufacturer and owner has ignored repeated attempts to communicate by IT.
  • Required Action:
    • Device will be disabled in MECM, JAMF or Ansible, removing their access to all network resources.
    • A full system reimage will be required to bring device back into compliance.
    • The device must be physically brought to the IT office for this service.
    • We will attempt to migrate data, but no guarantees will be made, the reimaging process is inherently destructive and could result loss of user data.
    • Move device to PVFA>ADMINISTRATIVE>ISSUE division in Sassafras

Patch Validation​

To supplement automated reporting and provide additional assurance, PVFA will perform a monthly manual verification check:

Storage Location: Patch Validation & Verification

Sampling Methodology​

  • The 1st week of the month we will run this validation
  • A minimum of five (5) Windows workstations will be randomly selected
    • We pull the sample of 10 machines with the expectation that not all will be online or available
  • Selected systems should represent a mix of end-user (faculty/staff) and classroom/lab devices
  • Random selection helps identify edge cases and systems with unreliable reporting
  • Check the PatchManagementReviewlog for prior month’s validation test and if any were listed as failed, those devices automatically are added to the sample for re-verification that patching is now working as expected

Windows Verification Procedure​

  1. Connect to endpoint directly (either in person or via remote console)
  2. Run the Get-ExecutionPolicy command to view currently set policy, note this down so you can reset after.
  3. Run WindowsPatchValidation.ps1 script on the endpoint
  4. You will need to set the execution policy to bypass temporarily with this command:
    Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
  5. Reset initial execution policy
  6. Place a copy of the output file in our “Validation Results” teams’ location

Verification Failure​

  • If a device fails in the verification test it should be noted and remediated using logs or other troubleshooting tools.
  • The failed status should not be changed even after remediation is complete so it can be re-checked.
  • This device will automatically be in the following months sample to verify the issue does not persist, this will be an addition to the random sample.