owned this note
owned this note
Published
Linked with GitHub
# OSCAL Implementation Layer - FedRAMP System Security Plan (SSP) Modeling
This defines the data fields to express a FedRAMP SSP in machine redable format. The intent is to translate this to XML and JASON for adoption as part of the Open OSCAL Implementation Layer specification.
This is part of the NIST OSCAL effort as covered by [Issue #246](https://github.com/usnistgov/OSCAL/issues/246).
---
Modeled Sample SSP:
https://hackmd.io/UPEc5ya7Sfmu3wcg2UzGzw
---
# User stories
1. As a system owner and/or administrator I am able to express my existing MS Word or PDF-based FedRAMP SSP in an OSCAL-compliant, machine readable format.
1. As a FedRAMP reviewer, I am able to use tools to expedite the review of a FedRAMP SSP submitted in an OSCAL-compliant format through automated:
-- **validation of the information submitted;**
--- is all appropriate content provided?
(i.e. every control has an implementation status? were any controls incorrectly omitted?; was the system owerner identified?)
--- does the content correlate?
(i.e. if a control indicates inheritence, were details provided about the underlying system in the appropriate section?; if FIPS 140-2 validated modules are indicated, were the certificate numbers provided? If a role was specified for a control, was the role described in the appropriate section?)
--- can external references be validated?
(i.e. can the indicated FIPS 140-2 validation certificate numbers be found in the NIST Labs Database; are all attachments and external references accessible?)
-- **review tracking;**
--- Has this control been reviewed?
--- Did the reviewer find the content to be fully compliant, partially compliant, or non-compliant?
--- What feedback does the reviewer have?
(if not fully compliant, the reviewer must cite the nature of the partial- or non-compliance)
--- What is the disposition of cited partial- or non-compliance?
---
## FedRAMP SSP Overview
FedRAMP currently provides SSP templates in MS Word format. There are SSP templates for FedRAMP High, Moderate, and Low cloud service offerings, as well as a template for Low Impact (LI) SaaS Systems under FedRAMP Tailored.
Relevant Links:
* High: https://www.fedramp.gov/assets/resources/templates/FedRAMP-SSP-High-Baseline-Template.docx
* Moderate: https://www.fedramp.gov/assets/resources/templates/FedRAMP-SSP-Moderate-Baseline-Template.docx
* Low: https://www.fedramp.gov/assets/resources/templates/FedRAMP-SSP-Low-Baseline-Template.docx
* LI-SaaS: https://www.fedramp.gov/assets/resources/templates/APPENDIX-B-FedRAMP-Tailored-LI-SaaS-Template.docx
The information requires for High, Moderate, and Low SSPs are identical from a data modeling perspective. The front-matter (Title page through chapter 12) of each is essentially identical, and contains a significant amount of structured data. The fundamental difference between these three SSP templates is the specific controls required in each baseline.
When complete, these templates include attachments and diagrams. Some attachments are also based on FedRAMP templates, such as for system inventory and the privacy impact analysis. Some of these attachments are highly structured and easily modled. Others are not. All are assessed and addressed following the core SSP content.
The structure of the FedRAMP Tailored for LI-SaaS template provides for a sub-set of the typical FedRAMP SSP data, as well as a place to capture assessment details in an attmept to keep that package lgiht-weight. Anything we model for the High/Moderate/Low SSP templates above will work for for the LI-SaaS template with the exception that much of the required content from these SSP templates becomes optional for the LI-SaaS template.
## Proto-model
The following applies to FedRAMP High, Moderate, and Low SSPs unless otherwise noted.
### Authoritative Control References
Points back to the specific authoritative control references, such as the FedRAMp Moderate baseline, or the NIST High baseline.
```yaml=
# Indicates what control data should be referenced
# Cardinality: 1 or more
import: What OSCAL profile(s) or catalog(s) should be used as the source for control information?
href: Where can it be found?
```
### Publication Characteristics
```yaml=
# High level "document" identification
# Cardinality: 1
publication:
publication_id: Unique document ID, generated by the publishing organization (for SSPs this is typically the CSP)
publication_title: The title of the publication (typically "FedRAMP System Security Plan (SSP) [High | Moderate | Low ] Baseline [CSP Name] [System Name]")
publication_version: The CSP-assigned version number of this publication
publication_date: The CSP's publication date for this publication
publication_sensitivity: Indicates any document sensitivity such as Controlled Unclassified Information (CUI), Proprietary, Confidential
# What is the history of this publication?
# Cardinality: 1 or more
publication_history:
publication_date:
publication_version:
publication_notes: Notes about what was changed.
# Other publication meta-data relevant to the FedRAMP PMO
# Cardinality: 1
publication_details:
prepared_by:
organization_name
organization_address
prepared_for:
organization_name
organization_address
```
### Approvals
The content of an officially delivered SSP must be signed by one or more appropriate approving officials within the CSP's organization.
```yaml=
# Approvals -
# Cardinality: 1 or more
publication_approvals:
approver:
approver_signature: Scanned image or certificate-based
approval_date
approver_name
approver_title
approver_organization: Typically the name of the CSP.
```
### Attachments
Whether for the formally required attachments in Chapter 15, or other attachments as needed, a mechanism is needed to embed and/or reference attachments from within the SSP data.
```yaml=
# Attachments - .
# Cardinality: 0 or more
publication_attachments:
attachment_id
attachment_name
attachment_description
attachment_format
attachment_date
attachment_version
attachment_type
attachment_href (either this or base64_embeded is required, but not both)
attachment_base64_embeded (either this or href is required, but not both)
attachment_base64_filename
```
### System
FedRAMP requires the following information about the system. Much of this information is re-used across many FedRAMP artifacts including the FedRAMP Marketplace, authorization letters, and monthly ConMon Reporting.
```yaml=
# Chararacteristics and meta-data about the system itself
# Cardinality: 1
system_information:
# Table 1-1: Information System Name and Title
# Cardinality: 1
system_id: This is the FedRAMP Application Number - a unique ID assigned by the FedRAMP PMO
# Table 1-1: Information System Name and Title
# Cardinality: 1
system_name: The full name of the system
# Table 1-1: Information System Name and Title
# Cardinality: 1
system_name_short: Often the system acronym or abbreviation
# Section 9.1 System Function or Purpose
# Cardinality: 1
description: A brief description of the function or purpose of the system (1 - 3 paragraphs)
# Table 2-1: Security Categorization
# ALSO -- Table 2-4: Baseline Security Configuration
# Cardinality: 1
security_sensitivity_level:
- low
- moderate
- high
# Table 2-3: Security Impact Level
security_objective_confidentiality:
- low
- moderate
- high
# Table 2-3: Security Impact Level
security_objective_integrity:
- low
- moderate
- high
# Table 2-3: Security Impact Level
security_objective_availability:
- low
- moderate
- high
# Optional for FedRAMP. Only overall eauth_level is required based on high water mark of ial, aal, and fal.
# Cardinality: 0 or 1
security_auth_ial:
- low
- moderate
- high
# Optional for FedRAMP. Only overall eauth_level is required based on high water mark of ial, aal, and fal.
# Cardinality: 0 or 1
security_auth_aal:
- low
- moderate
- high
# Optional for FedRAMP. Only overall eauth_level is required based on high water mark of ial, aal, and fal.
# Cardinality: 0 or 1
security_auth_fal:
- low
- moderate
- high
# Table 15-5: Digital Identity Level
# Cardinality: 1
security_eauth_level:
- low
- moderate
- high
# Table 7-1: System Status
# Cardinality: 1
deployment_status:
- operational
- under_development
- major_modification
- other
other_description: if deployment_status = "other", this contains an explamantion
# Table 8-1: Service Layers Represented
# FedRAMP limits values to "SaaS", "PaaS", "IaaS", and/or "other"; however, outside of FedRAMP, this field may be used more broadly
# Cardinality: 1 or more
deployment_model:
- saas
- paas
- iaas
- other
other_description: if deployment_model = "other", this contains an explamantion
# Table 8-2: Cloud Deployment Model Represented in this SSP
# FedRAMP limits values to "Public", "Private", "Government Only Community", and/or "other"; however, outside of FedRAMP, this field may be used more broadly
# Cardinality: 1 or more
service_model:
- public
- private
- government_only_community
- other
other_description: if service_model = "other", this contains an explamantion
# Table 8-3: Leveraged Authorizations
# The Leveraged Authorizations table details the pre-existing FedRAMP Authorizations being leveraged by this Information System
# Cardinality 0 or more
leveraged_authorizations:
leveraged_authorization_name: The Leveraged Information System Name
leveraged_authorization_service_provider: The Leveraged Information System Service Provider
leveraged_authorization_date_granted: The date this system started leveraging the Leveraged Information System
```
### Boundaries and Components
```yaml=
# Section 9 General System Description
# Cardinality: 1
system_boundary:
boundary_description: one or more paragraphs that describe the system's authorization boundary.
# Section 9.2 Information System Components and Boundaries
#Cardinality: 1 or more
boundary_diagram:
diagram-id: unique id for the diagram
diagram_attachment_id: [id of attachment]
diagram_title: title of the diagram
diagram_description: description of the diagram
# Section 9.4 Network Architecture
#Cardinality: 1 or more
network_diagram:
diagram-id: unique id for the diagram
diagram_attachment_id: [id of attachment]
diagram_title: title of the diagram
diagram_description: description of the diagram
# Section 10.1 Data Flow
#Cardinality: 1 or more
data_flow_description
data_flow_diagram:
diagram-id: unique id for the diagram
diagram_attachment_id: [id of attachment]
diagram_title: title of the diagram
diagram_description: description of the diagram
# This needs to tie tightly to the OSCAL Capabilities/Components Definition
system_components:
[Model based on OSCAL capabilities/components definition]
```
### Authorized Connections
Although this is part of CA-3, it may not be part of the standard set of elements for controls. This could be merged into the standard OSCAL controls set later.
```yaml=
# Table 13-3. CA-3 Authorized Connections
# Cardinality: 0 or more
authorized_connections:
external_system_name: Name of the system to which this system connects
external_system_org: Organization that owns the system to which this system connects
isa_authorization: Who signed and authorized the Interconnection Security Agreement (ISA)?
isa_name: Name of the ISA
isa_date: Date of the ISA
```
### Types of Users
```yaml=
# Section 9.3 Types of Users
# Table 9-1: Personnel Roles and Privileges
# Cardinality: 1 or more
system_user:
user_role
#Cardinality: 1
user_type:
- internal
- external
#Cardinality: 1
user_privilege_type:
- p # Privileged
- np # Non-Privileged
- nla # No Logical Access
user_sensitivity_level:
- moderate
- limited
- n_a
- ???? others?
user_authorized_privilege: [description, such as "Full administrative access (root)", or "Portal administration"]
functions_performed: [description, such as "add/remove users, install and configure software, OS updates, patches and hotfixes, perform backups"]
internal_user_total_current: number of internal personnel now
internal_user_total_future: expected number of internal personnel within one year
external_user_total_current: number of external personnel now
external_user_total_future: expected number of external personnel within one year
```
### Information Types
```yaml=
# Table 2-2: Sensitivity Categorization of Information Types
# Cardinality: 0 or more *
# * NOTE: In theory, an IaaS or PaaS may have no data. Any leveraging SaaS would have data and be responsible for enumerating it in the SSP for the SaaS. In reality, cardinality should probably be "1 or more", not "0 or more".
information_types:
information_type_id: NIST 800-60 identifier (ie. C.3.5.1)
information_type: NIST 800-60 information type name
information_description: Description of information that fits this type
information_sensitivity_confidentiality:
- low
- moderate
- high
information_sensitivity_integrity:
- low
- moderate
- high
information_sensitivity_availability:
- low
- moderate
- high
```
### Ports, Protocols and Services
```yaml=
# Section 10.2 Ports, Protocols and Services
# Table 10-1: Ports, Protocols and Services
# Cardinality: 0 or more (realistically 1 or more)
ports_protocols_services_entry:
#Cardinality: 0 or more
port_range
#Cardinality: 0 or more
port_type:
- tcp
- udp
#Cardinality: 0 or more
protocol
#Cardinality: 0 or more
service
#Cardinality: 1 or more
purpose
#Cardinality: 1 or more
used_by
```
### Information System Owner
```yaml=
# Table 3-1: Information System Owner
# Cardinality: 1
system_owner_information: Contact information for the system owner
system_owner_name: Who is the main system owner
system_owner_title: What is their title within their organization
system_owner_organization: What organization does the system owner work with
system_owner_address: What is the organization street adress
system_owner_city: What city is the organization based out of
system_owner_state: What state is the organization based out of
system_owner_zip: What is the zip code for the organization
system_owner_phone: What is the contact number for the system owner
system_owner_email: What is the email for the system owner
```
### Authorizing Official
```yaml=
# Section 4. Authorizing Officials
# Cardinality: 1 or more
authorizing_official: The Authorizing Official is determined by the path that the CSP is using to gain authorization
jab_or_agency: Is the CSP going through the JAB P-ATO process or direct Agency Authorization
authorizing_offical_name: The name of the authorizing official
authorizing_official_title: The title of the authorizing official
authorizing_official_organization: The organization that the authorizing official belongs to
authorizing_official_email: The email address of the authorizing official
authorizing_official_phone: The phone number of the authorizing official
```
## Other Designated Contacts
### Information System Management Point of Contact
```yaml=
# Table 5-1: Information System Management Point of Contact
# Cardinality 1 or more
system_management_information: Contact information for the system management point of contact
system_management_name: Who is the system management POC
system_management_title: What is their title within their organization
system_management_organization: What organization does the system management POC work with
system_management_address: What is the organization street adress
system_management_city: What city is the organization based out of
system_management_state: What state is the organization based out of
system_management_zip: What is the zip code for the organization
system_management_phone: What is the contact number for the system management POC
system_management_email: What is the email for the system management POC
```
### Information System Technical Point of Contact
```yaml=
# Table 5-2: Information System Technical Point of Contact
# Cardinality 1 or more
system_technical_information: Contact information for the system technical point of contact
system_technical_name: Who is the system technical POC
system_technical_title: What is their title within their organization
system_technical_organization: What organization does the system technical POC work with
system_technical_address: What is the organization street adress
system_technical_city: What city is the organization based out of
system_technical_state: What state is the organization based out of
system_technical_zip: What is the zip code for the organization
system_technical_phone: What is the contact number for the system technical POC
system_technical_email: What is the email for the system technical POC
```
### Information System Additional Point of Contact
```yaml=
# Table 5-3: Information System Additional Point of Contact
# Cardinality 0 or more
system_additional_information: Contact information for the system additional point of contact
system_additional_name: Who is the system additional POC
system_additional_title: What is their title within their organization
system_additional_organization: What organization does the system additional POC work with
system_additional_address: What is the organization street adress
system_additional_city: What city is the organization based out of
system_additional_state: What state is the organization based out of
system_additional_zip: What is the zip code for the organization
system_additional_phone: What is the contact number for the system additional POC
system_additional_email: What is the email for the system additional POC
```
### CSP Internal ISSO (or Equivalent) Point of Contact
```yaml=
#Table 6-1: CSP Internal ISSO (or Equivalent) Point of Contact
#Cardinality 1 or more
csp_isso_information: The contact information for the CSP ISSO
csp_isso_name: Who is the CSP ISSO
csp_isso_title: What is the title of the CSP ISSO
csp_isso_organization: What organization does the CSP ISSO work with
csp_isso_address: What is the organization street address
csp_isso_city: What city is the organization based out of
csp_isso_state: What state is the organization based out of
csp_isso_zip: What is the zip code for the organization
csp_isso_number: What is the contact number for the CSP ISSO
csp_isso_email: What is the email address for the CSP ISSO
```
### AO Point of Contact
```yaml=
# Table 6-2: AO Point of Contact
# Cardinality 1 or more
ao_information: The contact information for the Authorizing Official
ao_name: Who is the AO
ao_title: What is the title of the AO
ao_organization: What organization does the AO work with
ao_address: What is the organization street address
ao_city: What city is the organization based out of
ao_state: What state is the organization based out of
ao_zip: What is the zip code for the organization
ao_number: What is the contact number for the AO
ao_email: What is the email address for the AO
```
## SSP Minimum Security Controls
Security controls are the main focus of OSCAL. The implementation layer control modeling is being addressed in a parallel effort as part of [Issue #217](https://github.com/usnistgov/OSCAL/issues/217), with the modeling efforts found [HERE](https://hackmd.io/x43sK8IvSyOhW3no7fdh2w?view). That effort will be merged with this representation after each is developed separately
It is import each control traces back to the control requirement statements. Each control should trace to the most down-stream reference to it. This is especially important to ensure proper parameter values are established.
For example AC-2 appears in the FedRAMP Moderate Profile, which references the NIST Moderate Profile, which in turn references the 800-53 catalog. This should point to the FedRAMP Moderate profile to ensure the FedRAMp parameter constraint in (j) is maintained.
```yaml=
# Section 13: Security Controls
# Cardinality: one
control_id: The ID of the control as it appears in the appropriate profile or catalog.
href: A pointer to the actual profile or catalog.
# Cardinality: zero or more
# Validation: one for each parameter
parameter-value: The actual value of the paramter supplied by the system owner to complete the requirement statement.
parameter_id: The ID of the parameter as it appears in the appropriate profile or catalog.
# Cardinality: one or more
# Validation: Every role here should match a role in the roles and responsibilities table
responsible_role: Who is responsible for maintaining the control?
# Cardinality: one
implementation_status: The status of the control (Implemented, Partially Implemented, Planned, Alternative Implementation, N/A)
# Cardinality: one if marked Planned or Partialy Implemented above. Zero otherwise
planned_implementation_date
# Cardinality: one or more
control_origination: The origina of the control (Service Provicder Corporate, Service Provider System Specific, Configured by Customer, Provided by Customer, Inherited)
# Cardinality: one if marked Configured by Customer or provided by Customer above. Zero otherwise.
customer_responsibility:
# Cardinality: one if marked Inherited above. Zero otherwise.
inherited_system_id: The id of the underlying cloud or general support system from which this control is inherited.
# NOTE: Other data about the underlying system, such as name and authorization date, can be presented as a result of the pointer to that system.
# Cardinality: one or more (One per control part)
control_response: A description of HOW the organization is meeting the control. One per control part.
```
### Cryptography
```yaml=
# Need a list of all crpytography used within
# within the system, along with the NIST Labs
# certifiate number and supporting details
# for FIPS 140-2 validation
cryptography:
certificate_no
module_name
version_number
```
## SSP Attachments
### Attachment 1: Information Security Policies and Procedures
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 2: User Guide
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 3: Digital Identity Worksheet
- This section is mostly guidance, which should be addressed by tooling external to the OSCAL SSP content.
-Table 15-2 Information System Name and Title, duplicates the content in Table 1-1, thus this content will be visually repeated here, rather than entered a second time.
- The only data entered by a CSP is as follows:
```yaml=
# Table 15-5
# Cardinality: Exactly 1
digital_identity_level: Level 1 (AAL1, IAL1, FAL1), 2 (AAL2, IAL2, FAL2) or 3 (AAL3, IAL3, FAL3)
```
### Attachment 4a: Privay Threshold Analysis
- Table 15-6 Privacy POC is simply another system role that will be addressed in the OSCAL SSP content with all other system roles (Approver, ISSO, Managemet POC, etc.)
- Table 15-7 Laws and Regulations and Table 15-8 Standards and Guidance are addressed in the OSCAL SSP content with the other Laws, Regulations, Standards, and Guidance. That content will have an attribute to flag it as privacy-related.
- This is structured information, and will appear in in the OSCAL SSP structure as follows:
```yaml=
# Attachment 4: Privay Threshold Analysis
# Cardinality 4
# FedRAMP has four (4) yes/no questions, that must be present and answered. Answering any one "yes" requires the PIA
pta_question:
question_text: The FedRAMP question
response_text: The CSP's yes/no response
```
### Attachment 4b: Privacy Impact Assessment
- Attachment Table 1-1 Privacy POC is simply another system role that will be addressed in the OSCAL SSP content with all other system roles (Approver, ISSO, Managemet POC, etc.)
- Attachment Table 1-2 Laws and Regulations is addressed in the OSCAL SSP content with the other Laws, Regulations, Standards, and Guidance. That content will have an attribute to flag it as privacy-related.
**Privacy Designation**
```yaml=
# Attachment Section 2
# Cardinality 1
privacy_designation: boolean ("yes" to indicate the vendor is willing to host privacy information in system. "no" to opt-out)
# Attachment Table 3-1 PII Mapped to Components
# Cardinality 1 or more
components:
# Cardinality 1
component
# Cardinality 1
pii_contact: "yes" if the component stores, processes, or transmits PII; "no" otherwise.
# Cardinality 1 or more
pii_type: identify the type of PII stored, processed or transmitted by the component
# Cardinality 1
pii_reason: Explain why the PII is collected. (NOTE: This may be more appropriately addressed with the data types, rather than the components.)
# Cardinality 1 or more
pii_safeguard: Describe safeguards for protecting the PII relative to this component.
# Attachment Sections 3.2 thru 3.10
# These are a series of questions. Most require a text-field response. One also requires a yes/no response.
# Cardinality 36
pia_question:
# Cardinality 1
question_text: The FedRAMP question
# Cardinality 1 or more (one quesiton has a yes/no, and a text response if yes, which requires two responses in that case. All others are a single text field response.)
response_type: typically "text" or "boolean" - indicates the type of response required.
response_text: The response provided by the CSP
signatures:
assessor_signature
chief_privacy_officer_signature
```
### Attachment 5: Rules of Behavior
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 6: Information System Contingency Plan
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 7: Configuration Management Plan
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 8: Incident Response Plan
- This is typically not structured information.
- With the OSCAL SSP format, this will only exist as an entry in the <attachments> element that points to the external documents.
- This will continue to be handled only as an attachment. The content will not appear in the OSCAL SSP format at this time.
### Attachment 9: CIS Workbook
- This will exist as a summary view of control information
- There is no additional information in this summary view. It is simply a reduction of control information that already exists in the complete detail of each control.
### Attachment 10: FIPS 199
- This is structured information
- This is a more detailed version of the information that exists in Table 2-2. The two will be combined into one structure, with different views of the data presented by tools to re-create Table 2-2 and Table 15-9.
### Attachment 11: Separaton of Duties Matrix
- There is no set template for this; however, this is structured information
- The syntax for expressing the system's user roles (Table 9-1) will be extended to enable basic separation of duties information.
- Until this has more maturity, the CSP will have the option of either using the extended syntax, or attaching their own matrix.
### Attachment 12: FedRAMP Laws and Regulations
- The syntax ... ****
### Attachment 13: FedRAMP Inventory Workbook
- This is structured information, and will appear in in the OSCAL SSP structure as follows:
```yaml=
# Inventory Workbook (Spreadsheet)
# NOTE: Each inventory_item must have either one set of host_item details or one set of software_item details.
# Cardinality 1 or more
inventory_item:
# Cardinality 1 per inventory_item
asset_id: unique asset identifier
# Cardinality 0 or more per inventory item
ip_address: IPv4 or IPv6
# Cardinality 1 per inventory_item
virtual: yes/no field
# Cardinality 1 per inventory_item
public: yes/no field
# Cardinality 0 or more per inventory_item
network_name: DNS Name or URL
# Cardinality 0 or more per inventory_item
host_item: OS/Infrastructure Inventory
# Cardinality 0 or more per host_item
netbios_name: NetBIOS Name
# Cardinality 0 or more per host_item
mac_address: MAC Address
# Cardinality 1 per host_item
authenticated_scan: Authenticated Scan
# Cardinality 1 per host_item
baseline_template: Baseline Configuration Name
# Cardinality 0 or 1 per host_item
os_name
# Cardinality 0 or 1 per host_item
os_version
# Cardinality 0 or 1 per host_item
location
# Cardinality 1 per host_item
asset_type
# Cardinality 1 per host_item
hardware_vendor
# Cardinality 1 per host_item
hardware_model
# Cardinality 1 per host_item
scanned: In Latest Scan? (yes/no)
# Cardinality 0 or more per inventory_item
software_item: Software and Database Inventories
# Cardinality 1 per software_item
software_vendor: Software/ Database Vendor
# Cardinality 1 per software_item
software_name: Software/ Database Name & Version
# Cardinality 1 per software_item
software_version
# Cardinality 0 or 1 per software_item
software_patch_level
# Cardinality 1 per software_item
function: A description of the function provided by the software or database
# Cardinality 0 or 1 per software_item
Comments: Any comments about the inventory item
# Cardinality 0 or 1 per software_item
serial_no: Product serial number or asset Tag number
# Cardinality 0 or 1 per software_item
network_id: VLAN/Network ID
# Cardinality 1 or more per software_item
asset_owner: organizational owner of the hardware or software asset.
# Cardinality 1 or more per software_item
asset_administrator: organizational administrator of the hardware or software asset.
```