2.1 Project Goals

Apple releases a new macOS version every year, and generally, agencies and organizations must wait for guidance or accept risk before deploying the new macOS version. Most agencies or organizations must create their own internal security configuration, which delays the deployment of the new macOS version or new hardware that only supports the new macOS version. The mSCP assists organizations in upgrading sooner. Generally, the technical security settings in macOS do not drastically change from release to release, with only a handful of new settings being introduced. By pursuing a rules-based approach, mSCP rules that remain applicable can be reused and incorporated into guidance for the latest macOS version. This enables quicker adoption of new security features that are not offered in prior versions of macOS.

The goals of the mSCP are:
• Develop recommended security baselines using a risk-based approach based on the impact of the data.
• Normalize and accelerate annual adoption of the new operating system and hardware by providing guidance to meet the security needs of new operating systems at the earliest availability.

1 See https://github.com/usnistgov/macos_security#authors for a current list of project contributors.
• Reduce worldwide efforts in creating annual guidance by unifying and consolidating compliance efforts into a single project.
• Develop a methodology to foster collaboration between baseline authors, reducing overhead and redundancy.
• Establish a unified approach for the configuration and assessment of controls across multiple sources and tools.
• Enable the customization of existing content and the creation of new content, including creating custom baselines in order to meet organization-specific security requirements.
• Provide device management and security tool vendors, auditors, and Apple insight into customer security configuration needs.

2.2 mSCP Content Use

mSCP content can be used by any organization to assist in setting and assessing the security configuration of macOS systems. Security baselines can map to existing guidance or controls, such as those in NIST SP 800-53, Revision 5 [6] , or they can be customized to meet an organization’s specific needs. In mSCP terminology, a security baseline is represented as a baseline file that designates the rules for meeting a specific set of requirements. The mSCP provides a library of rules that are macOS settings. Each rule is mapped to a requirement within a security standard, framework, etc. Baseline files and rules comprise much of the mSCP’s content.

The mSCP offers several example baselines, including the following, with descriptions adapted from FIPS 199 [11] :
• The SP 800-53, Revision 5 low baseline is a defined map of controls to secure a system defined as a low-impact information system. The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.
• The SP 800-53, Revision 5 moderate baseline is a defined map of controls to secure a system defined as a moderate-impact information system. The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.
• The SP 800-53, Revision 5 high baseline is a defined map of controls to secure a system defined as a high-impact information system. The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Organizations using any baseline example should take a risk-based approach for selecting the appropriate settings and organizationally defined values depending on the context under which the baseline will be applied. Organizations can tailor any of the baselines to include controls specific to their needs and to produce evidence of control enforcement. Additional information on baseline customization can be found in SP 800-70 [4] , which discusses the importance of customizing and testing baselines before applying them to a production system. The mSCP provides scripts that can be used with baselines for several purposes, including the following:
• Creating scripts and profiles for configuring macOS
• Generating a mapping between security standards, regulations, frameworks, etc.
• Producing human-readable documentation in a variety of formats
• Customizing existing baselines

mSCP content can also be used to generate Security Content Automation Protocol (SCAP) content for automated security compliance scans. The SCAP generated follows the SCAP 1.3 specification [12] . Generation of SCAP content uses an Extensible Stylesheet Language Transformations (XSLT) file to create an Extensible Configuration Checklist Description Format (XCCDF) checklist document with an accompanying Open Vulnerability and Assessment Language (OVAL) document.

The XCCDF and OVAL documents are bundled into an SCAP data stream collection document with accompanying files that include Common Platform Enumeration (CPE) dictionary [13] information and an Open Checklist Interactive Language (OCIL) document. This creates an SCAP 1.3 document that validates using the NIST SCAP Content Validation Tool 2 and can be used by SCAP tools on macOS. More information on SCAP content generation is available at https://github.com/usnistgov/macos_security/wiki/SCAP-Content-Generation .

2 See https://csrc.nist.gov/projects/security-content-automation-protocol/scap-releases/scap-1-3 . 3 mSCP Components

This section provides an overview of several components of the mSCP: security baseline files, configuration profiles and scripts, content generation scripts, customization capabilities, and directories. More information about all of these is available from the GitHub wiki at https://github.com/usnistgov/macos_security/wiki .

3.1 Security Baseline Files

In the mSCP, a security baseline is defined in a Yet Another Markup Language (YAML) file. A YAML file is a human-readable file format commonly used by configuration files where data are stored and/or transmitted. A baseline YAML file consists of the following required fields. The code immediately below this list provides a partial example of a YAML file that illustrates the use of these fields (with field names bolded).
• title – a human-readable name for the baseline
• description – a short description of the baseline, including its use case and target operating system (OS) version
• authors – developers of the baseline
• profile – the security content portion of the baseline o section – a keyword for organizing settings o rules – the names of the rule files that are a part of this baseline

title: "Apple macOS 11 (Big Sur) Test Baseline" description: | This guide describes the prudent actions to take when securing a macOS 11 system against the Test Baseline. authors: | |=== |Joe Doe|NIST |=== profile:
- section: "Authentication" rules:
- auth_pam_login_smartcard_enforce
- auth_pam_su_smartcard_enforce
- auth_pam_sudo_smartcard_enforce
- auth_smartcard_allow
- section: "Auditing" rules:
- audit_acls_files_configure
- audit_acls_files_mode_configure
- audit_acls_folder_wheel_configure

3.1.1 Rule File Composition

A YAML rule file is broken down into the following subsections. The code immediately below this list provides a notional example of a YAML rule file (with field names bolded). This example is from the Rules section of the mSCP wiki ( https://github.com/usnistgov/macos_security/wiki/Rules ).
• id – the name of the rule file, excluding the .yaml file extension
• title – a human-readable rule title
• discussion – a short description of the rule and its use case
• check – the check to assess the system for the specified rule; this is typically shell code
• result – the expected result of running the check
• fix – the necessary fix in case the check fails; if [source,bash] is included, the fix will be included in the configuration script
• references – references, including identifiers and mappings such as security frameworks, guidance, and controls; the references always include a Common Configuration Enumeration (CCE) identifier, which is assigned to this rule file and can be found in the official repository of NIST CCEs [14]
• macOS – the validated macOS version for this rule
• tags – modifiable keywords for categorizing and identifying related rules
• severity – the severity level specified in the DISA STIG, if applicable
• mobileconfig – if true , this rule will be used to generate configuration profile content
• mobileconfig_info – if mobileconfig is set to true , this field specifies the information required to produce configuration profile content id: os_airdrop_disable title: "Disable AirDrop" discussion: AirDrop _MUST_ be disabled to prevent file transfers to or from unauthorized devices.

AirDrop allows users to share and receive files from other nearby Apple devices. check: | /usr/bin/profiles -P -o stdout | /usr/bin/grep -c 'allowAirDrop = 0' result: integer: 1 fix: | This is implemented by a Configuration Profile. references: cce:
- CCE-85293-9 cci:
- CCI-000381 800-53r5:
- AC-3
- AC-20
- CM-7
- CM-7(1) 800-53r4:
- CM-7
- CM-7(1)
- AC-3
- AC-20 srg:
- SRG-OS-000095-GPOS-00049 disa_stig:
- APPL-11-002009 800-171r2:
- 3.1.1
- 3.1.2
- 3.1.16
- 3.1.20
- 3.4.6 macOS:
- "11.0" tags:
- 800-53r5_low
- 800-53r5_moderate
- 800-53r5_high
- 800-53r4_low
- 800-53r4_moderate
- 800-53r4_high
- 800-171
- cnssi-1253
- stig severity: "medium" mobileconfig: true mobileconfig_info: com.apple.applicationaccess: allowAirDrop: false 3.1.2 Rule File Categories

The mSCP organizes YAML files in the rules directory into the following subdirectories, each corresponding to a category of settings:
• audit – OpenBSM 3

• auth – smartcard authentication
• icloud – Apple’s iCloud/Apple ID service
• os – rules to configure the operating system that do not fit into the other categories
• pwpolicy – password policy
• sysprefs – settings controlled within the System Preferences application

The rules directory also includes a supplemental subdirectory, which contains additional information that supports the guidance provided by the baselines. Supplemental content contains information for rules that are not part of an existing baseline but could be beneficial for certain use cases. Supplemental content may not have mappings and may not contain the YAML rule file check and fix sections mentioned in Section 3.1.1 . Supplemental content can be added to enhance baselines where organizational requirements are different than the system baseline requirements.

3.2 Configuration Profiles and Scripts

When an mSCP YAML file is processed, it yields a configuration script and/or configuration profile ( mobileconfig file) as outputs. Both are used to apply configuration settings to a system.

A configuration profile is an Extensible Markup Language (XML) formatted file with a mobileconfig extension containing a configuration payload. macOS can automatically configure itself based on a mobileconfig file’s contents upon execution. Configuration profiles offer a convenient, Apple-supported mechanism for applying security settings to a macOS environment. Additionally, they can be cryptographically signed to ensure integrity and authenticity. These factors make configuration profiles the preferred vehicle for configuration delivery. However, mobileconfig files cannot modify all macOS settings, so a configuration script is needed for those settings that are not supported. See https://developer.apple.com/documentation/devicemanagement/loginwindow for an example configuration profile and brief descriptions of its properties.

A configuration script is a shell script that manipulates operating system files directly. The script content is derived from all YAML rule files that have a mobileconfig value of false and belong to the specified baseline. The YAML rule file must contain the fix section in order to generate its corresponding configuration script entry.

3 See OpenBSM at https://github.com/openbsm/openbsm . 3.3 Content Generation Scripts

The mSCP provides several types of scripts for generating baselines, human-readable guidance, baseline compliance checkers, and other types of content. Each script is described below.

3.3.1 Generate Baseline Script

The generate_baseline.py script compiles a list of security rules into a single baseline YAML file. It can be used to modify an existing security baseline or create a new one. See https://github.com/usnistgov/macos_security/wiki/Scripts#generate_baselinepy for additional information.

3.3.2 Generate Guidance Script

The generate_guidance.py Python script can produce human-readable guidance and generate the macOS Security Compliance Tool, which is a Z shell script.

The generate_guidance.py script takes a baseline file and produces a human-readable guide with information from the YAML rules files. The script can create documentation in several formats. The script always generates an AsciiDoc file. AsciiDoc (. adoc ) is a plain text format that uses markup conventions for traditional document formatting and organization. AsciiDoc files are easily transformable into many other formats via the generate_guidance.py script, including Hypertext Markup Language (HTML), PDF, and Excel. The Excel format is particularly useful for quickly viewing all the rules of a baseline, and it contains all of the data in the YAML rules files.

The generate_guidance.py script can also create configuration profiles ( mobileconfig files) and the macOS Security Compliance Tool. Using the -s argument, the generate_guidance.py script will generate an org.{baseline}.audit.plist file and another script, the macOS Security Compliance Tool, that can check and remediate compliance settings. The audit.plist file can be used to set an exemption to organizational rules for approved users so that compliance checks can succeed without findings. To create an exemption for a rule, the exempt field should be set to true and an exempt_reason should be added.

See https://github.com/usnistgov/macos_security/wiki/Scripts#generate_guidancepy-script for more information on the generate_guidance.py script.

3.3.3 macOS Security Compliance Tool

The {baseline}_compliance.sh script runs interactively by default. It can evaluate a system’s conformance to a baseline or remediate any incorrectly configured settings. Alternatively, the script can autonomously assess a system with the –check argument or automatically remediate baseline settings with –fix .

The lines below provide an example of the results of running the script. Thu Jan 21 15:09:41 UTC 2021 auth_pam_login_smartcard_enforce passed (Result: 2, Expected: {integer: 2}) Thu Jan 21 15:09:41 UTC 2021 auth_smartcard_allow passed (Result: 1, Expected: {integer: 1}) Thu Jan 21 15:09:41 UTC 2021 auth_pam_sudo_smartcard_enforce passed (Result: 2, Expected: {integer: 2}) Thu Jan 21 15:09:41 UTC 2021 auth_smartcard_certificate_trust_enforce_moderate passed (Result: 2, Expected: {integer: 2}) Thu Jan 21 15:09:41 UTC 2021 auth_smartcard_enforce has an exemption (Reason: Broken Reader)

For more information on the macOS Security Compliance Tool script, see https://github.com/usnistgov/macos_security/wiki/Compliance-Script .

3.3.4 OVAL Generation Script

The OVAL generation script, generate_oval.py , takes a baseline YAML file and generates OVAL checks for any rule file where possible. Note that this script does not recognize any custom settings. For more information, see https://github.com/usnistgov/macos_security/wiki/Scripts#generate_ovalpy .

3.3.5 Generate Mapping Script

The generate_mapping.py script allows for the quick creation of custom rules and baselines for a compliance framework not published by the mSCP. The script requires a user-created comma- separated values (CSV) file containing control identifiers that maps to a new framework (CSV column 1) from another already defined by the project (CSV column 2). By default, the script is designed to map a framework to the NIST SP 800-53, Revision 5 [6] set of controls. Adding the -f argument allows for mapping to another supported framework. See https://github.com/usnistgov/macos_security/wiki/Generate-Mapping for more information on the generate_mapping.py script.

3.4 Customization

Organizations should make the risk-based decision on what controls and rules to use and how to apply them, as stated by NIST SP 800-53, Revision 5 controls PL-10 and PL-11. Customization allows organizations to generate their own customized content outside of that provided by the project. Additionally, it allows them to add content for internal-only controls, which are not suitable for inclusion in a global baseline. Customization primarily takes place within the custom folder. Here are examples of customization supported by mSCP:
• Baselines : A baseline folder can be included within the custom folder to create customized baselines that fit an organization’s needs. These baseline files may include rule, section, and template customization (discussed below).
• Rules : Existing rules can have their setting values overridden via the custom folder instead of modifying the mSCP-supplied rule file. New rules can be created and added to existing baselines or to user-defined baselines. Organizations can create their own discussions, checks, results, fixes, and mappings of rules to security frameworks not included in the project. In order to override an existing rule, the custom rule file name must match an existing rule so that the generate_guidance.py script will pick up the new values. New rules not included in mSCP must be listed in the baseline YAML file specified when running generate_guidance.py . Additional information on custom rules can be found in an article written by mSCP contributor Allen Golbig [15] .
• Sections : Custom sections can be used to organize existing or custom YAML rule files. Sections defined in the custom folder must be included in a baseline YAML file in order to be used by generate_guidance.py .
• Templates : Custom templates can be used to define new template structures for the project and affect the organization and appearance of generated documentation. The template files must match the name of an existing template and will override that template when running generate_guidance.py .
• Logos : An organization can include a custom logo when running the generate_guidance.py script by using the -l argument to point to an image file.

3.5 Directories

mSCP releases available at https://github.com/usnistgov/macos_security/releases include the following directories:
• baselines – contains the defined YAML baseline files
• build – holds scripts, documents, and configuration profiles generated by running scripts
• custom – used for creating customized baselines, rules, sections, or templates to meet an organization’s requirements
• includes – contains YAML-based libraries required for running the scripts
• rules – contains YAML rule files, with one rule per file
• SCAP – contains the required files for generating SCAP content
• scripts – contains the content generation scripts and their required files
• sections – defines the sections that correlate to the directories in the rules folder; each section has its own YAML file containing the section name and description as it will appear in the generated guide, which is human-readable documentation
• templates – includes AsciiDoc templates for generating an AsciiDoc guide References

[1] macOS Security Compliance Project (2022) macOS Security Compliance Project . Available at https://github.com/usnistgov/macos_security

[2] Trapnell M, Scarfone KA, Trapnell E, Badger ML, Souppaya MP, Yaga DJ (2016) Guide to Securing Apple OS X 10.10 Systems for IT Professionals: A NIST Security Configuration Checklist. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-179. https://doi.org/10.6028/NIST.SP.800-179

[3] Trapnell M, Scarfone KA, Trapnell E, Badger ML, Souppaya MP, Yaga DJ (2018) Guide to Securing Apple macOS 10.12 Systems for IT Professionals: A NIST Security Configuration Checklist. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-179, Rev. 1. Available at https://csrc.nist.gov/CSRC/media/Publications/sp/800-179/rev- 1/draft/documents/sp800-179r1-draft.pdf

[4] Quinn SD, Souppaya MP, Cook MR, Scarfone KA (2018) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800- 70, Rev. 4. https://doi.org/10.6028/NIST.SP.800-70r4

[5 ] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

[6 ] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[7 ] Ross R, Pillitteri V, Dempsey K, Riddle M, Guissanie G (2020) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800- 171, Rev. 2, Includes updates as of January 28, 2021. https://doi.org/10.6028/NIST.SP.800-171r2

[8 ] Department of Defense (2021) DISA STIG for macOS . Available at https://public.cyber.mil/stigs/

[9 ] Committee on National Security Systems (2014) Security Categorization and Control Selection for National Security Systems. (National Security Agency, Ft. Meade, MD), Committee on National Security Systems Instruction (CNSSI) No. 1253. Available at https://www.cnss.gov/CNSS/issuances/Instructions.cfm

[10 ] Center for Internet Security (2021) CIS Critical Security Controls Version 8 . Available at https://www.cisecurity.org/controls/v8/ [11 ] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

[12] Waltermire DA, Quinn SD, Booth H, III, Scarfone KA, Prisaca D (2018) The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-126, Rev. 3. https://doi.org/10.6028/NIST.SP.800- 126r3

[13] National Institute of Standards and Technology (2021). Official Common Platform Enumeration (CPE) dictionary . Available at https://nvd.nist.gov/products/cpe

[14] National Institute of Standards and Technology (2021) CCE Platform Listing . Available at https://ncp.nist.gov/cce

[15] Golbig A (2021) Getting to Know: macOS Security Compliance Project – Part 2 . Available at https://golbiga.medium.com/getting-to-know-macos-security-compliance- project-part-2-24131b60cdfb mSCP User Roles

The mSCP was designed to meet the needs of different security roles. These perspectives are briefly examined below.

Security policy authors define the policies for their organizations. The customization and ease of extensibility offered by the mSCP facilitate new content creation. Policy authors will need to familiarize themselves with the YAML rule file format described in Section 3.1.1 . Of particular interest is the ability to map rules directly to references. Additionally, the generate mapping script (Section 3.3.5 ) enhances portability between compliance frameworks.

System administrators and security professionals are responsible for configuring the systems under their purview. They implement the guidance issued by security policy authors. Security professionals may wish to generate baselines (Section 3.3.1 ), guidance (Section 3.3.2 ), and configuration using the macOS Security Compliance Tool (Section 3.3.3 ).

Auditors approach macOS security compliance from a validator perspective, seeking proof that a system is configured in the required way. They are more interested in system setting documentation and compliance evidence than technical tools such as configuration scripts. Both of these needs can be met by mSCP tools. The generate guidance script (Section 3.3.2 ) provides the necessary documentation in a variety of formats, including HTML, PDF, and Excel. The macOS Security Compliance Tool (Section 3.3.3 ) assesses a system and produces a log of the results. Additionally, some auditors may be interested in examining YAML rule content directly (Section 3.1.1 ).

Information security officers have a variety of goals but are ultimately responsible for ensuring that systems are configured according to their organizational requirements. To accomplish this, they need policy documentation (Section 3.3.2 ) and the results of compliance scans (Section 3.3.3 ). Information security officers may also be responsible for reviewing the security rules proposed by the policy authors. If this is the case, they may be interested in YAML rule file components (Section 3.1.1 ).

Vendors of device management, security, configuration assessment, and compliance tools can produce a series of audit files based on mSCP content to support different macOS versions and associated security baselines. These audit files are maintained, tested, published, and supported by the tool vendors. Tool customers can download and import the content into the tool to assess the state of their system against a particular baseline in an automated way.

Specific audit files of the mSCP by tool vendors are described on the project wiki page. This content will be updated as contributing tool vendors develop new audit content. Example of mSCP Usage by a Security Professional

This appendix provides examples of how a security professional might use mSCP content. People in other roles might perform some of the same actions. The examples illustrated below were accurate at the time of publication, but see the mSCP wiki at https://github.com/usnistgov/macos_security/wiki for up-to-date usage guidance. Note that the mSCP scripts are not meant to replace enterprise-class configuration and management tools. Configurations should be tested on development systems before being deployed on end users’ systems.

Preparing to use mSCP

All project components are available from the mSCP GitHub page [1] by navigating to Releases and downloading the latest source code revision for the desired macOS version. Alternatively, the project source code can be downloaded via git, as the example below illustrates.

mSCP components rely on prerequisite software listed at https://github.com/usnistgov/macos_security/wiki/Getting-Started , and any missing software must to be installed.

Changing code branches and generating a baseline

After obtaining a copy of the source code, change the directory to the mSCP git folder, macos_security .

Next, select the appropriate code branch that corresponds to the target OS version. Then choose a baseline and use the generate_baseline.py script to create a baseline YAML file. The example below illustrates these steps for the NIST SP 800-53, Revision 5 moderate baseline for macOS Big Sur. Creating the macOS Security Compliance Tool and configuration profiles

Using the generate_guidance.py script, create the macOS Security Compliance Tool and configuration profiles. The example below illustrates this, continuing from the previous example.

Running a compliance scan

As the example below shows, the macOS Security Compliance Tool is typically run with administrator privileges so that it can access all the settings.

The example below shows the main menu presented by the macOS Security Compliance Tool. Selecting option 2, “Run New Compliance Scan”, from the main menu launches the scan. The example below shows output from the scan, which in this case reflects numerous rule failures, each indicating a deviation from the expected configuration.

Selecting option 1, “View Last Compliance Report”, from the main menu displays a summary of the compliance report results. The example below depicts results indicating that 30 tests passed and 108 tests failed for an overall score of 21.74 % compliant. Fixing non-compliant settings

Selecting option 3, “Run Commands to remediate non-compliant settings”, begins the process of fixing non-compliant settings discovered during a previous compliance scan. The example below illustrates the disclaimer to be reviewed and accepted before fixes are initiated. This disclaimer indicates the potential risk in applying fixes.

After the disclaimer statement is accepted, the fixes are applied to the system, as the example below illustrates. Example of mSCP Usage by an Assessment Tool Vendor

This appendix provides an example of how an assessment tool vendor converted mSCP content to their tool’s proprietary format so that their tool could perform compliance checks against mSCP baselines and rules. Refer to the mSCP GitHub wiki page at https://github.com/usnistgov/macos_security/wiki/Vendor-Attribution for the most current list of tool vendors and associated content that will support the mSCP baselines.

This example is for Tenable, Inc. They automated the conversion of mSCP YAML rules into their . audit format using Python and YAML libraries. Programmatically approaching this conversion allows for faster future releases and greater consistency, and it also maintains the integrity of the source content. Because the YAML content is all command-driven, it is converted to Tenable’s CMD_EXEC check type for use with the Unix plugin. The YAML rules have a “tags” section that was used to create unique audit profiles related to common frameworks. An example of these profiles can be seen in the audit file naming convention:
• NIST_macOS_Big_Sur_800-171_v1.4.0.audit
• NIST_macOS_Catalina_800-53r5_high_v1.5.0.audit

See Tenable’s research highlight at https://community.tenable.com/s/feed/0D53a00008E0hgYCAR for more details.

The following example shows a YAML-to-audit-check conversion. The content has been condensed and abbreviated for the purposes of comparison:

mSCP YAML title: "Limit SSHD to FIPS 140 Validated Ciphers" discussion: | If SSHD is enabled then it _MUST_ be configured to limit the ciphers to algorithms that are FIPS 140 validated. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets federal requirements. Operating systems utilizing encryption _MUST_ use FIPS validated mechanisms for authenticating to cryptographic modules. NOTE: /etc/ssh/sshd_config will be automatically modified to its original state following any update or major upgrade to the operating system. check: | /usr/bin/grep -c "^Ciphers aes256-ctr,aes192-ctr,aes128-ctr" /etc/ssh/sshd_config result: integer: 1

Tenable Audit Check <custom_item> system : "Darwin" type : CMD_EXEC description : "Big Sur - Limit SSHD to FIPS 140 Validated Ciphers" info : "If SSHD is enabled then it _MUST_ be configured to limit the ciphers to algorithms that are FIPS 140 validated. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets federal requirements. Operating systems utilizing encryption _MUST_ use FIPS validated mechanisms for authenticating to cryptographic modules. NOTE: /etc/ssh/sshd_config will be automatically modified to its original state following any update or major upgrade to the operating system." cmd : "/usr/bin/grep -c \"^Ciphers aes256-ctr,aes192-ctr,aes128- ctr\" /etc/ssh/sshd_config" expect : "1" </custom_item> Acronyms

Selected acronyms and abbreviations used in this paper are defined below.

CCE Common Configuration Enumeration CIS Center for Internet Security CNSS Committee on National Security Systems CNSSI Committee on National Security Systems Instruction CSV Comma-Separated Values DISA Defense Information Systems Agency DOE Department of Energy FIPS Federal Information Processing Standards FISMA Federal Information Security Modernization Act FOIA Freedom of Information Act GUI Graphical User Interface HTML Hypertext Markup Language IT Information Technology ITL Information Technology Laboratory LANL Los Alamos National Laboratory mSCP macOS Security Compliance Project NASA National Aeronautics and Space Administration NIST National Institute of Standards and Technology OCIL Open Checklist Interactive Language OS Operating System OVAL Open Vulnerability and Assessment Language SCAP Security Content Automation Protocol SP Special Publication STIG Security Technical Implementation Guide XCCDF Extensible Configuration Checklist Description Format XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformations YAML Yet Another Markup Language

`2.1` Project Goals

Title

Control