Emerging Specification Listing
The following listing represents specifications for emerging security automation capabilities:
Languages
Metrics
Specification Descriptions
Asset Summary Reporting (ASR)
The Asset Summary Reporting (ASR) is a data model to express the transport format of summary information about one or more sets of assets. The standardized data model facilitates the interchange of aggregate asset information throughout and between organizations. ASR is vendor and technology neutral, flexible, and suited for a wide variety of reporting applications.
Web site: Asset Summary Reporting (ASR)
Common Misuse Scoring System (CMSS)
A set of standardized measures for the characteristics of software feature misuse vulnerabilities. A software feature misuse vulnerability is present when the trust assumptions made when designing software features can be abused in a way that violates security. NISTIR 7864 defines the CMSS specification, and it also provides examples of how CMSS measures and scores would be determined for software feature misuse vulnerabilities. Once CMSS is finalized, CMSS data can be used along with CVSS and CCSS data to assist organizations in making sound decisions as to how their host vulnerabilities should be addressed. CMSS data can also be used in quantitative assessments of host security.
Web site: The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities
Open Checklist Reporting Language (OCRL™)
Open Checklist Reporting Language is a language for writing machine-readable XML definitions that gather information from systems and present it as a standardized report for human evaluation of policy compliance. Each generated report file corresponds to a single policy recommendation.
OCRL complements existing benchmark languages such as Extensible Configuration Checklist Description Format (XCCDF) and Open Vulnerability and Assessment Language (OVAL®) - which already provide capabilities for structuring security guidance in a machine-understandable way and describing how to gather and evaluate system information to determine compliance - by addressing those instances where a human is necessary to determine compliance with a given policy recommendation, or where XCCDF and OVAL do not have the necessary capability to evaluate collected information for compliance with a recommendation. For example, a policy recommendation that states, ?The user should disable unnecessary services on the computer,? requires human judgment to determine what services are unnecessary. An OCRL Definition could be written to provide a report of all the services running on the computer, which could then be used by a person to determine whether any unwanted services are present.
OCRL was specifically designed to work with the XCCDF and OVAL benchmark authoring languages. While OCRL documents can be used alone by a software program to create one or more reports, by using OCRL in conjunction with OVAL more automation can be called out from an XCCDF document than using OVAL alone, resulting in significantly enhanced capabilities for benchmark automation.
Web site: http://ocrl.mitre.org/
) or https:// don't prove our archive is authentic, only that you securely accessed it. Note that we are working to fix that :)
