The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 

Post

Advice for Software Vendors to Prepare for OMB M-22-18 Requirements

image credit: Unknown author
Richard Brooks's picture
Co-Founder and Lead Software Engineer Reliable Energy Analytics LLC

Dick Brooks is the inventor of patent 11,374,961: METHODS FOR VERIFICATION OF SOFTWARE OBJECT AUTHENTICITY AND INTEGRITY and the Software Assurance Guardian™ (SAG ™) Point Man™ (SAG-PM™) software...

  • Member since 2018
  • 1,505 items added with 651,434 views
  • Oct 8, 2022
  • 876 views

On September 14, 2022 the Office of Management and Budget published a memo, M-22-18, advising Federal Agencies on the steps to secure the software supply chain as part of procurement activities for software products. The memo identifies specific steps and timeframes for agencies to implement, starting in January 2023. The memo is very clear in setting expectations for Federal Agencies “Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.”

This article contains information to help software vendors prepare for the forthcoming M-22-18 requirements identified as “NIST Guidance” which will begin to appear in formal requests from Procurement Officers starting in January 2023.

Three main artifacts are described in this article:

  1. Open source, free to use Vendor Response File
  2. NIST SSDF SP 800-218 spreadsheet listing SDLC practices
  3. Placeholder for CISA’s “self-attestation letter” (format description coming in 2023)

Vendor Response File

The free to use, open-source Vendor Response File (VRF) machine readable format is used by software vendors to provide Procurement Officers with information required under M-22-18. The material included in the VRF contains links to several evidentiary files based on the requirements needed to meet NIST’s SP 800-161 and SP 800-218 standards, which are part of the “NIST Guidance” identified in the OMB memo and the North American Transmission Forum Security Assessment Model to satisfy FERC Order 850. The following table lists the data provided in a VRF. NOTE the VendorLegalName and the Product LicensorName may be different entities, this occurs often when resellers are the “Vendor” i.e. System Integrators and they are supplying software products from various Software Product Suppliers. It is common to find the VendorLegalName and Product Licensor Name belong to the same entity, i.e. Microsoft Corporation

Element Name

Description

VendorLegalName

Legal name of the vendor that supplied this information

SupplierID

A unique identifier for the vendor that supplied this information, i.e. dns:reliableenergyanalytics.com

StreetAddress

Postal address of the vendor that supplied this information

City

City or Town where the postal address is located

StateOrProvince

State or Province where the City or Town is located

ZipCode

Postal zip code of the vendor’s address

Country

Country where the vendor address is located

WebsiteURL

A website URL where vendor information is located

ContactTelephone

 

Telephone number for a contact person that can answer questions about VRF information

ContactEmail

 

Email address for a contact person that can answer questions about VRF information

ContactPerson

 

Name of person that can answer questions about VRF information

DUNSNumber

DUNS Number assigned to the vendor. May be blank.

NAESBEIRID

 

Identify ID assigned in the NAESB Energy Industry Registry (EIR). May be blank

CyberSecPolicyURL

 

Link to the cybersecurity policies and practices document implemented by the vendor,  across the company

FinancialDataURL

 

Link to the most current financial data available from the vendor, i.e., EDGAR documents

CompanyDataURL

 

Link to Company Data, i.e. ownership information, locations and other information the vendor chooses to disclose. A good example for Company Data is available here.

Products

 

Container element for all products listed in the VRF

                              Product

Occurs once per product listed under Products. The following elements occur for each Product listed under Products

                              LicensorName

Name of licensor for this product, i.e. Microsoft Corporation. Equated to NTIA minimum element "Supplier Name"

                              ProductName 

 

Name of product, as assigned by the product licensor, i.e. Windows 10. Equates to NTIA minimum element "Component Name" for the "Primary Component" in an SBOM.

                              Version

Version identifier for this product. Equates to NTIA minimum element "Version of Component" in the NTIA minimum elements.

                              SBOM

 

Link to the SBOM file associated with this product name and version provided by the Licensor of the product

                              SourceLocationURL

 

URL where this software product package is available for download by the consumer

                              DigitallySigned

 

a Y or N flag indicating that the software product package is digitally signed, or not

                              UnsolvedVulnerabilities" 

 

a Y or N flag indicating that the software product package has known unsolved vulnerabilities as of the LastModification date of this Product, shown below

                              KnownVulnInfoURL

 

The URL to a NIST Vulnerability Disclosure Report (VDR) showing the vulnerability status of each component in the product SBOM, an example NIST VDR is provided here 

                              SDLCPolicyURL 

 

URL to SDLC policy and practices documentation that is followed throughout the lifecycle for this product from inception to retirement. The NIST SP 800-218 SSDF spreadsheet is an excellent choice for communicating this information.

                              SDLCEvidenceDataURL

 

URL to the M-22-18 self-attestation letter which CISA will be providing a “boilerplate format”. A placeholder may be used until such time that the formal CISA document is available and is completed by the software product licensor.

                              CommercialStatus

 

An enumerated set of options indicating the various states, see open-source VRF XML Schema for the list of valid options

                              SupportStatus 

 

An enumerated set of options indicating the various support statuses for a product, see open-source VRF XML Schema for the list of valid options

                              LastModifiedDateTimeUTC

Date and Time in UTC representation when this product information was last updated.

 

NIST SP 800-218 spreadsheet

NIST provides the software vendor community with a spreadsheet listing the SP 800-218 secure software development practices identified in M-22-18 under “NIST Guidance”, which include a set of practices that create the foundation for developing secure software. “The NIST Secure Software Development Framework (SSDF), SP 800­218,3 and the NIST Software Supply Chain Security Guidance4 (these two documents, taken together, are hereinafter referred to as “NIST Guidance”). This spreadsheet may be used to indicate a software vendors conformance with each requirement listed in the spreadsheet. There are 43 requirements listed in the spreadsheet, all pertaining to NIST SP 800-218 best practices, as of this writing.

 

CISA’s “self-attestation letter”

The OMB memo M-22-18 clearly indicates that CISA will be providing a self-attestation format within 120 days of publication (January 2023);

CISA will establish a self-attestation common form for PRA clearance, incorporating the minimum elements of NIST 800-218 as identified by OMB.

Within 120 days

CISA

This article is being provided to help software vendors and others in the software supply chain prepare to respond to Federal Procurement Officer information requests for self-attestation pursuant to requirements M-22-18

Agencies shall collect attestation letters for “critical software” subject to the requirements of this memorandum

Within 270 days

Agencies

Agencies shall collect attestation letters for all software subject to the requirements of this memorandum

Within 365 days

Agencies

 

My advice to software vendors is to begin preparing for M-22-18 compliance by creating your evidentiary materials which you may be required to submit, per product, i.e. SBOM (SBOM element), a vulnerability disclosure report (KnownVulnInfoURL element), SP 800-218 SDLC practices and policy  documentation spreadsheet (SDLCPolicyURL element) , and SP 800-218 SDLC self-attestation letter (SDLCEvidenceDataURL element), and create your digitally signed VRF XML file containing links to these artifacts. Using the NIST SSDF spreadsheet, fill-in your response to each of the 43 requirements listed and prepare to deliver this to Federal Agencies by providing links to this information in your own Vendor Response File, using the open-source VRF format, if you desire. Place your completed Vendor Response File, it's digital signature file and other artifacts, i.e. SBOM, Vulnerability Disclosure Reports, self-attestation placeholder file and SP 800-218 SDLC SSDF Spreadsheet in an access controlled location, such as a customer portal and provide Federal Procurement Officers with a link to the VRF file in this location. The VRF contains links to all of the other required artifacts so a vendor only needs to supply Federal Agencies with a link to the VRF, that lists all of the other evidence data, along with other required information. In January, 2023, when CISA publishes the official “self-attestation letter” format replace the URL placeholder identified in the SDLCEvidenceData element with the official CISA version. Federal procurement officers must begin collecting self-attestation letters and other artifacts by June 2023, for critical software and September 2023 for all other software.

Procurement Officers can automatically retrieve the VRF file, in JSON or XML format, and all of the other evidence files listed in the VRF using available commercial tools, i.e. SAG-PM

Discussions

No discussions yet. Start a discussion below.

Richard Brooks's picture
Thank Richard for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »