Re: [SCITT] CISA: Repository for Software Attestations and Artifacts (RSAA)

[Dick Brooks <[e-mail]>]

Ray, Steve, et al,

 

I'm presenting to a US Government agency on 4/15 describing how the CISA
attestation process can benefit from a SCITT Trust Registry.

This concept was demonstrated at IETF 117.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! T

 <http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]>
[e-mail]

Tel: [phone]

 

 

From: SCITT <[e-mail]> On Behalf Of Steve Lasker
Sent: Friday, April 5, 2024 6:37 PM
To: Ray Lutz <[e-mail]>; [e-mail]
Subject: Re: [SCITT] CISA: Repository for Software Attestations and
Artifacts (RSAA)

 

Good timing, Ray,

A.J. was going to facilitate the SCITT Community Meeting next week, and the
Software Attestations was his first topic. 

Reminder: Community meetings restart on April 8th 4 PM UTC (groups.io)
<https://groups.io/g/scitt-community/message/73> 

 

--> Does this actually do anything to improve software by having producers
say they do everything right?

 

This is the interesting part, and why enabling others to comment on the same
artifact is so important. 

There are two major categories of vulnerabilities:

1.	A software vendor/project inadvertently published a vulnerability.
It may not have been known at the time, or it was a bug. In this case, the
vendor/project is motivated to fix it. They're motivated to put testing in,
to catch their mistakes. They're motivated to publish new information about
their artifacts, indicating they found an issue and the steps they're taking
to resolve it.
2.	A group is maliciously working to circumvent the security gates.
They study all known checks, and intentionally design a vulnerability to get
through them undetected. The better funded, the more they can invest. In
this case, they're not motivated to communicate problems.

 

In both cases, it's important for others to make statements about other
publishers artifacts. Verifiers can choose which additional publishers they
wish to trust. Otherwise, a malicious company can pretend to be a good
security company and say good, or bad things about software.

This was captured here, on scitt.io: Extending Services - SCITT - Supply
Chain Integrity and Trust
<https://scitt.io/scenarios/extending-existing-services.html> 

 

This brings up the value of the subject field, where multiple issuers can
make additional statements about the same artifact. 

 

At IETF 119, it was discussed the challenges with combining issuers and
unique subjects, and I'd like to carve that problem out as a focus. So, that
we can assure we can support the above scenarios. 

 

 

 

From: SCITT <[e-mail] <mailto:[e-mail]> > On
Behalf Of Ray Lutz
Sent: Friday, April 5, 2024 2:22 PM
To: [e-mail] <mailto:[e-mail]> 
Subject: [SCITT] CISA: Repository for Software Attestations and Artifacts
(RSAA)

 

This seems to implement a service similar to the vision of SCITT, but with
the user account, and submission front end that is otherwise missing from
SCITT, and it appears to be already endorsed by CISA. They use "self
attestations" which are comparable to SCITT claims. It seems it is limited
to federal users and sw vendors.

https://www.cisa.gov/resources-tools/resources/repository-software-attestati
ons-and-artifacts-rsaa-user-guide

https://www.cisa.gov/sites/default/files/2024-03/CISA_RSAA_User_Guide_18_Mar
ch_2024.pdf

and they use this self-attestation form:
https://www.cisa.gov/sites/default/files/2024-03/Self-Attestation-Common-For
m-03082024-FINAL.pdf

--> Does this actually do anything to improve software by having producers
say they do everything right?



Intro text:
==============
PURPOSE 

OMB issued memorandum M-22-18 on 14 September 2022. Due to the importance
and scope of the Federal Government's information and communications
technology (ICT) products and services, Memorandum 22-18 was drafted to
ensure software integrity. Software integrity is key to protecting Federal
systems from nation state and criminal actors seeking to disrupt our
nation's critical functions. The goal is to reduce overall risk from
cyber-attacks. One way to achieve this is by Federal agencies only using
software from software producers who can attest to complying with the
Government-specified secure software development practices, as described in
the NIST Guidance. 

Following the issuance of M-22-18, on 09 June 2023, OMB issued memorandum
M-23-16. OMB Memorandum M-23- 16 reinforces the requirements established in
M-22-18, reaffirms the importance of secure software development practices,
and extends the timelines for agencies to collect attestations from software
producers. Additionally, this memorandum provides supplemental guidance on
the scope of M-22-18's requirements and on agencies' use of Plan of Actions
and Milestones (POA&Ms) when a software producer cannot provide the required
attestation but plans to do so. To the extent any provision of this
memorandum may be read to conflict with any provision of M-22-18, this
memorandum is controlling. 

The Repository for Software Attestation and Artifacts (RSAA) serves to
satisfy the requirements set forth in M-22-18 and M-23-16. 

INTRODUCTION 

The RSAA User Guide provides users with instructions to create an RSAA
account, the required CISA Okta Partner Platform account with multifactor
authentication (MFA) and use the RSAA application effectively. The RSAA
application serves as a repository for all software producers' Attestations.

==============
Steps are:
1. Create a user account. It lists some but also has a way to request
additional categories.
"If the organization or agency being represented does not appear in the
drop-down lists or options presented,
please contact the CISA Technology Operations Center (TOC) to request the
missing organization or agency be added to
the CISA RSAA system"


Click "Submit for Review." A notification will appear confirming the account
creation request has been successfully submitted. Click "OK" to complete the
process. Account requests are reviewed and processed within approximately 2
business days. Upon processing, an email is sent to the requestor to notify
that the account has been created. 

2. Create a software record.
With an RSAA account created AND activation of the CISA Okta Partner Portal
account with MFA, registered users may
create software record(s) for the agency or organization. Each record is
specific to the software product and version(s).
Registered users may also search existing software records, subject to the
user privileges.

Step 6. If creating a new software record, complete the required fields in
the Create Software Record form which displays and identifies required data
for the submission: 
a. Populate the Name of Product or Product Line field. 
b. Enter the Version Number Range (if applicable). 
c. Enter the software producer entity. If the software producer is not
registered in the system, Click the "Add New" option, and when prompted,
enter the software producer entity, and click "OK." The entity will now be
available to enter in the software producer field of the Create Software
Record form. 
d. Enter the Release/Publish Date. 
e. Click "Save Record." 

artifacts may be uploaded using the "Upload Artifact" feature.




-- 
-------
Ray Lutz
Citizens' Oversight Projects (COPs)
http://www.citizensoversight.org <http://www.citizensoversight.org/> 
619-820-5321