Software Compliance Attestation: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Full Title==
==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.
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.
* This wiki may not be up-to-date with the emerging Kantara MAAS Recommendation on [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations Recommendations].
.


==Context==
==Context==
Line 7: Line 9:


==Use Case==
==Use Case==
As a non-normative example of [[Software Compliance Attestation]] its use in protecting patient health information (PHI) is described.
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).




Line 19: Line 21:
==Solutions==
==Solutions==
# There must be criteria established to determine that the developer is qualified.
# There must be criteria established to determine that the developer is qualified.
# There must be a machine readable sent by the software to the EHR attesting to its provenance.
# There must be a machine readable json packet sent by the software to the RP attesting to its provenance.
# There must be a registrar to establish a chain of trust to each party.
# There must be a registrar to establish a chain of trust to each party.
# 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.
# 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===
Existing standards include software statements that are not focused on the ability to protect user authentication secrets. The Mobile Authentication Assurance Statement (MAAS) 1.0.0 [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations (current draft here)] is designed to fill that need for authentication assurance.


==References==
==References==
* [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations Mobile Authentication Assurance Statement (MAAS) 1.0.0] is a specification under development in Kantara.
* [https://www.nist.gov/itl/voting/nvlap-laboratory-accreditation NIST laboratory Accredidation Program for Voting Machines]
* [https://www.nist.gov/itl/voting/nvlap-laboratory-accreditation NIST laboratory Accredidation Program for Voting Machines]
* NIST NVLAP [https://www.nist.gov/itl/voting/nvlap-laboratory-accreditation Common Criteria Testing LAP] for security testing of computer software.
* NIST NVLAP [https://www.nist.gov/itl/voting/nvlap-laboratory-accreditation Common Criteria Testing LAP] for security testing of computer software.
Line 31: Line 36:
[[Category: Assurance]]
[[Category: Assurance]]
[[Category: Compliant Implementations]]
[[Category: Compliant Implementations]]
[[Category: Health]]
[[Category: Profile]]

Latest revision as of 19:07, 22 January 2021

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.

  • This wiki may not be up-to-date with the emerging Kantara MAAS Recommendation on Recommendations.

.

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

Existing standards include software statements that are not focused on the ability to protect user authentication secrets. The Mobile Authentication Assurance Statement (MAAS) 1.0.0 (current draft here) is designed to fill that need for authentication assurance.

References

  • Mobile Authentication Assurance Statement (MAAS) 1.0.0 is a specification under development in Kantara.
  • 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.