Software Compliance Attestation

From IDESG Wiki
Jump to navigation Jump to search

Full Title

A Software Compliance Attestation is a machine readable json packet that can be sent by a software application to a Relying Party attesting to the application source and compliance status.

Context

  • Software that is responsible for protecting access to important resources must be able to get an attestation as to its capability to perform the protection functions reliably.
  • NIST 800-63-3B allows authenticators to exist on a user's mobile computing device. This attestation provides the evidence need for meeting the requirements of that specification at the highest levels of assurance.

Use Case

As a non-normative example of Software Compliance Attestation its use in protecting patient health information (PHI) is described. In this case the user will be either the patient or their guardian and the Relying party will be a depository of PHI called an Electronic Health Record (EHR).


The final rule on the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (issued 2020-05-01) has a fairly large chunk of guidance for software application compliance needed to access a patient's health information.

  • First the FDA part is interesting because upload of data to the EHR would probably trigger section 618 of FDASIA. That would require all such software to be approved by the FDA, but would not necessarily apply to software that only downloaded data.
  • Section III Application registration = We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server. - - - However, implementers of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion.
  • The phrase "health IT developer" is not clear if it is each individual programmer, or the team or company that developed the program. since there could be many programs, and since there is no concept of "professional engineer" in the software industry to sign the certificate, we presume that the company will designate a "responsible party to assert the competence of the team.

Problems

  • No matter how the responsible party is determined, there must be means for the software to provide some attestation to the EHR that it has been so approved.

Solutions

  1. There must be criteria established to determine that the developer is qualified.
  2. There must be a machine readable json packet sent by the software to the RP attesting to its provenance.
  3. There must be a registrar to establish a chain of trust to each party.
  4. It would be best if the same attestation could provide "proof-of-presence" or other data needed by the EHR to determine the assurance that both the software and the user had achieved. This would satisfy the TEFCA IAL2, AAL2 requirements at that same time.

CSP=

software statement. There are three audiences for software statements. They are represented in the following table by these codes:

  1. M = mandatory part of the software statement that the software can furnish to the Relying Party.
  2. H = Human readable required but may be part of consent receipt (Note that this could be localized or accessible via the URL.)
  3. R = recommended depending on local conditions

Some interesting context fields. The final document will be longer. It is expected that the machine readable version will be used for machine verification and the human readable fields will typically be accessible on the URL listed. The first three elements taken together are an unique identifier of the software running on the user's device at the the the statement was provided. The statement is signed by the CSP and is invariant over the lifetime of the software installation.

Element Name Contents Cat Explanation for category
name identifier unique in publisher M required to verify app - computer friendly - should require a version based on this
version monotonically increasing M Canonical business version required if updates to app are to preserve credential integrity.
platform usually name of o/s M This or the optional source element provides context for the name which will be in a format determined by the platform (or source)
min-platform typically a version number R describes the minimal API support required by the platform
source Location that hosts the app if absent, the platform will be considered as determining the source
experimental name R A taxonomy of states will be provided
jurisdiction M Intended jurisdiction for maintenance and disputes, MUST not be a flag of convenience
user-authn json M Method used to assure user agreement for valid authentication
date Unix epoch M last modified - (perhaps we need date signed as a separate field?)
trust-registry uri M the location for an API to validate sites and apps
url name M Canonical identifier for this capability statement - all human readable elements will be found here
title H Human friendly, possibly localized
publisher H Who wrote the app, got it approved, or at least is responsible for maintenance and redress
contact H Contact details for the publisher
description H Natural language description of the capability statement

References

  • NIST laboratory Accredidation Program for Voting Machines
  • NIST NVLAP Common Criteria Testing LAP for security testing of computer software.
  • NIST NVLAP Cryptographic and Security Testing LAP initially named Cryptographic Module Testing (CMT), was established by NVLAP to accredit laboratories that perform cryptographic modules validation conformance testing under the Cryptographic Module Validation Program (CMVP)
  • NIST NVLAP Healthcare Information Technology LAP In response to the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009, the U.S. Department of Health and Human Services along with the Office of the National Coordinator for Health Information Technology requested establishment of the Healthcare Information Technology Testing Laboratory Accreditation Program by NVLAP to accredit laboratories that perform functional and conformance testing of electronic health record (EHR) technology products to meaningful use requirements as defined in the nationally recognized EHR products testing standards.