Assets

The Assets module is used for Inventory Management needs for both Devices and Applications, or Cloud Assets. The functionality allows an Organization to build out appropriate Inventory lists for Compliance Purposes, but The Guard also provides Task Generation features for missing Security Controls, should an Organization have Devices/Applications unprotected but need to remediate these items and will use The Guard to track the progress of doing so. 

TABLE OF CONTENTS

• Devices
• Applications

Devices

Device Assets are an Organization’s Workstations. The Device Asset Inventory allows an Organization to create individual objects (individually or via Bulk Upload) to represent the Workstations and important details for those devices. The Guard provides a form to fill out with some required fields, as well as some additional fields that may be helpful when tracking devices. 

• Device Name ( * Required) – The name of the Device (Host Name, ID Tag, etc)

• Device Type ( * Required) – The Type of Device:

  • Desktop Computer

  • Laptop

  • Server

  • Network Device (Firewall, Router, Access Point, etc)

  • Cell Phone

  • Tablet

  • VoIP Phone

  • Removable Media (USB Drive/SD Card/External Hard Drive/etc)

  • Scanner

  • MDF Scanner/Printer

  • Virtual Machine

  • Other – Recommended to provide a description of the device in NOTES when adding “Other” devices

• Activation Date (* Required) – Estimation or Exact Date the Device was “Activated”

• Deactivation Date – This field can be filled in when creating devices, but will be filled in by The Guard when “Deactivating” a device that has been added to the inventory

• Asset Tag – If the Organization uses Asset Tags, this filed allows entry

• Model – Model of the Device being listed

• Serial Number – Serial Number of the Device being listed

• Physical Location – Physical Location of the Device (Address, General Location [Front Desk, Exam Room 1, AWS Data Center, etc], etc)

• Security Controls (* Required) – The Device Protections enabled/installed on the device, as related to HIPAA “Best Practices” for device security:

  • Endpoint Protection – Antivirus/Antimalware/etc

  • Encryption – At-Rest Encryption / Full Disk Encryption – For Windows: BitLocker; For MacOS: FileVault; Other devices/OS may have different protocols

  • Providing a NO answer for these fields, while the Stores/Touches ePHI dropdown is marked “Yes”, will generate Open Tasks for this Device to be Protected

• Stores/Touches ePHI (* Required) – Yes/No Dropdown – If the device is being used to Store/Touch ePHI, then provide a Yes. If the device is not being used to Store/Touch ePHI, then provide a No

  • If a NO is given, then The Guard will not generate any Open Tasks even if the Security Control is marked “NO”. Task Generation will only occur when Stores/Touches ePHI is a YES

• Associated Site (* Required) – Org-Wide or an Organization can specify which location a device belongs to, if applicable – Which Site in The Guard does the Device belong to

• Last Known IP Address – If the Organization is tracking Last Known IP, this field allows entry

• Risk Rating – Default Value is 5 – Allows Organization to attach a Risk Rating to each device, establishing criticality of systems in the Inventory

• User Assigned (* Required) – Allows an Organization to identify which Workforce Member/User uses the device. The User Assigned to a Device will receive any Open Tasks that are being generated; It is OK to first specify an Officer/Admin for Task Assignment, then adjust the User Assigned field to the actual End User

• Notes – For any additional details regarding the Device. If an Organization has any special factors, like implementing alternative mechanisms for Security Controls, Notes is the best place to document this

All fields listed above are available on the Bulk Upload spreadsheet as well. Simply fill in all the Required fields, then select Add Device or Upload the Bulk Upload Template after it has been filled in and The Guard will add the device object.

After creating a Device Asset, an Organization may also Deactivate, "Destroy", Upload Evidence, and DELETE

• Deactivate – 

  • Choose Action > Deactivate Selected – Allows for Bulk Deactivation of device assets; Updates Status field to “Deactivated”

  • Hamburger Menu > Deactivate – Allows for Individual Deactivation for a Device; Updates Status field to “Deactivated”

• Destroy – Must be done Individually

  • Hamburger Menu > Destroy – Updates Status field to “Destroyed” - used to signify when a Device has been completely destroyed

• Evidence Locker – Available for each Device

  • Hamburger Menu > Evidence Locker – Allows an Organization to upload relevant documentation for an Individual Device (Logs, Reports, Scans, Certificates of Destruction, etc)

• DELETE - Allows the Device to be PERMANENTLY Deleted

  • Hamburger Menu > Delete - Will be prompted to confirm deletion - Deleted devices cannot be restored

Applications

Application Assets are an Organization’s “Cloud Assets” or “Software Assets” that allow an Organization to create, receive, maintain, or transmit Electronic Protected Health Information (ePHI). An Organization need not list every single Program that is installed on each device. This is meant to be centrally focused on the main Software Solutions being leveraged by the Organization. For example – An Organization’s Email Provider: Microsoft 365 or Google Workspace; An Organization’s Cloud Storage Solution: OneDrive, Google Drive, etc. So rather than per device, this Inventory is meant to be Org-Wide. The same functionality exists for the Application Asset Inventory as does for the Device Asset Inventory. By creating an object in this list, The Guard allows for Task Generation for any missing Security Controls, as well as additional details for tracking purposes. 

• Application (* Required) – The Application Name or Solution Name

• URL – If available, the URL used to access the cloud solution; May not be applicable or necessary

• Version or License Type – If available, a field to enter in License / Versioning information for the solution/service

• License Number – Accompanies the above field, if applicable

• Activation Date (* Required) – Estimated Activation Date of the solution in the Organization’s environment/network

• Deactivation Date - This field can be filled in when creating Applications, but will be filled in by The Guard when “Deactivating” an Application that has been added to the inventory

• User Access (* Required) – General selection for how the Organization provides access

  • All Users – All users in the Organization have access to this Solution

  • Departmental – Access to the solution is allowed based on Departments

  • Management Only – Access to the solution is Management-Only

• Notes - For any additional details regarding the Application. If an Organization has any special factors, like implementing alternative mechanisms for Security Controls, Notes is the best place to document these items

• Administrator (* Required) – The primary Administrator of this software – This allows an Organization to assign any Registered Officer/Admin/User in The Guard. The Administrator will be assigned to all Tasks generated by missing Security Controls

• Security Controls (* Required) - The Application Protections enabled/installed on the for the solution, as related to HIPAA “Best Practices” for Application security:

  • Encryption – Is the platform encryption data at-rest/in-transit?

  • Antivirus/Malware Protection – Is the platform guarded against malicious threats?

  • Strong Password – Is a Strong Password required for Users of the platform to gain access?

  • Multi-Factor Authentication – Is MFA/2FA enabled on the platform? 

  • Backups – Is the Organization backing up data stored/created in this platform?

  • Other Forms of Protection – Enabling this will add an additional text field so an Organization may describe any additional security features included with the platform

  • Important Note: Encryption, AV/Malware Protection, and Strong Passwords answers may vary. Oftentimes the Software/Application/Cloud Asset Vendor is responsible for securing the platform with respect to these Security Controls. Generally, an Organization may follow-up with the Vendor to confirm these items are enabled; Or if it is the Organization’s responsibility to configure the platform for these controls, then Task generation that occurs will help in both cases – Acknowledgement and Verification that controls are in-place; As well as, ensuring that security controls are configured appropriately

• Associate Site (* Required) - Org-Wide or an Organization can specify which location an Application “belongs” to, if applicable – Which Site in The Guard does the Application/Cloud Asset “belong” to

• BAA with Vendor (This is “required”, but is not marked the same as others) – Does the Organization have a BAA with the Vendor of the Solution? – This is a Yes/No; Any Vendor/Solution that will be used to create, receive, maintain, or transmit PHI/ePHI is a Business Associate and must sign a BAA.

  • If NO, The Guard will create a task indicating a BAA is needed

  • If YES, The Guard will not create a task

• Risk Rating – Default Value is 5 – Allows the Organization to apply Risk factor to different Solutions/Applications based on criticality or protections

These are meant to be running lists that can be managed and updated, as needed, over time.