Questions and Thoughts on a component description

[cbashioum]

I think there are 4 components in my "stack":

1. HDPF PMO component
   a. which may be a capability
   b. includes all of the documentation based stuff for a gov't program implementing a COTS product, e.g., CM plan, Incident handling, etc.
2. Hortonworks HDP/HDF (or HDPF) COTS product with pre-set configurations
3. OS
   a. Centos 7
4. Cloud Provider
   a. AWS

Questions:

1. For component descriptions
   a. About NAs, should I ignore or should I provide a description as to why it is N/A?
   b. Especially in cases where the COTS product expects something from the underlying OS or Cloud provider?
   c. About controls that we know are going to be "POAM'd". Is there any kind of identifier for that or should I just do 'POAM:xyz'?
2. Do the answers in the HDPF Component Description look reasonable?
   a. I am a developer/engineer, and not an accreditor
   b. Any input would be appreciated
3. Does anyone know whether RedHat or AWS has an OSCAL Component Description for RHEL or AWS?
   a. Do they have the same thing in another format that i can leverage and turn into OSCAL?
   b. If I create them, I am definitely willing to put the AWS and Centos 7 versions of component descriptions on NIST site for re-use if helpful
   i. but if anyone is part of Red Hat or AWS on the OSCAL WG, I would love to work with them on it.
4. I will have to put this together into an SSP
   a. Not clear to me how it all really ties together
   b. May need some help showing inheritance vs. stacking of control implementations
   c. Is there anyone I can work with on getting feedback for this

[cbashioum]

HDPFComponentDescriptionForOscal.zip

[ohsh6o]

I have some clearly opinionated thoughts on approach. I am an outsider, but will definitely check that out this week, As a community member, I am loving other people showing real-world examples!

[cbashioum]

Note for all that I am open for all criticisms to help make this a better description. I really appreciate any thoughts from anybody that takes the time to actually look at it ; )

[ohsh6o]

FYI, the annotation[@name='implementation-status'] is no longer a FedRAMP extension, but as of 1.0.0-rc1 is part of the core syntax, so you might want to consider that for where you implemented-requirement description, for example here.

            <implemented-requirement uuid="2643692a-0dec-47c8-a66a-1d6ba02d7293" control-id="ac-9.1">
                <description>
                    <p>Not Applicable</p>  
                    <p>The HDPF does not have any end-users as such.  It is a machine-2-machine system such that
                        the only users are other systems.  For HDPF Operators, they must SSH through a bastion host
                        to access the HDPF administrative functions.  Any user notification of the date, time, and number of 
                        failed logon attempts will be displayed via the bastion host when setting up the SSH tunnel</p>
                </description>
            </implemented-requirement>

Might become this:

            <implemented-requirement uuid="2643692a-0dec-47c8-a66a-1d6ba02d7293" control-id="ac-9.1">
                <!-- I added this thing below, but did not remove your p free-form Not Applicable for clarity for now -->
                <annotation name="implementation-status" value="not-applicable">
                <description>
                    <p>Not Applicable</p>  
                    <p>The HDPF does not have any end-users as such.  It is a machine-2-machine system such that
                        the only users are other systems.  For HDPF Operators, they must SSH through a bastion host
                        to access the HDPF administrative functions.  Any user notification of the date, time, and number of 
                        failed logon attempts will be displayed via the bastion host when setting up the SSH tunnel</p>
                </description>
            </implemented-requirement>

I am not sure how by-component with the this-system requirement works for a component, but I might have misunderstood if that is required for 1.0.0-rc1 in a component definition; it is usually referenced just in a SSP.

[cbashioum]

https://docs.cloudera.com/HDPDocuments/Ambari-1.6.1.0/bk_using_Ambari_book/content/index.html

https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS218-351/index.html&request_locale=ja#:~:text=Hortonworks%20DataFlow%20(HDF)%20is%20an,the%20data%20center%20and%20cloud.

[cbashioum]

This are links that describe the HDP and HDF COTS products that are part of what I am working with.

[cbashioum]

BTW, based on today's discussion, after I finish the last few controls on this description, I plan on going back through and re-wickering it into multiple descriptions. Those should be easier to look at. I will also think about the N/A portion. I can state at the top of the description for a given component that controls not addressed are N/A to that component. Sort of make it explicit in one fell swoop by a single statement.

[sunstonesecure-robert]

maybe useful:

https://github.com/ComplianceAsCode/redhat